Attempting to start the virtual machine progressed a little further, but I was now greeted with:
Not sure what the issue here is… When I try to edit settings I'm greeted with:
Clicking OK allowed me enter the settings, but I couldn't change anything. The solution for me was to discard the saved state for the VM, go into the settings and disable the host-only adapter (not sure if this step was necessary), then boot the VM.
Using LVM allows you to add space to a virtual machine without rebooting it. However you need to be using it already if you want to grow existing file systems. This post only covers increasing the size, as shrinking is more risky and I generally avoid it. Increasing the size of a filesystem where LVM is used directly on the disk:
If you're using LVM on the storage device (not partition) directly, it's trivial to add more space.
Increase the size of the virtual machine's storage device.
Run `dmesg` and find the appropriate SCSI device (e.g. 2:0:0:0)
Tell the kernel to rescan that device:
$ echo 1 | sudo tee /sys/class/scsi_device/2\:0\:0\:0/device/rescan $ sudo dmesg … [151064.769416] sda: detected capacity change from 5368709120 to 6442450944
Use `pvresize` to increase the size of the physical volume:
This is only possible when the drive isn't partitioned. If the drive is partition, the easiest solution is to add a new storage device to the VM, use LVM directly on that, and add it to the existing volume group:
Add new storage device and detect it in the guest using scsitools:
If you want to use Postgres.app, you'll probably want to turn off any existing PostgreSQL servers you have run to free up port 5432. Typically these are configured to run via launchd, so you'll need to use launchctl to disable them, e.g.:
It's generally good practice to run unit tests with warnings turned into errors to ensure deprecation warnings are honoured in a timely manner. Despite often coming across people saying that this can be done with a command line flag, after a bit of searching around I couldn't find a simple example of how to do this.
After a bit of trial and error it turns out to be very simple:
python -W error foo.py
The above flag will turn all warnings into errors.
For more complex usage Doug Hellman has a good write up: http://doughellmann.com/PyMOTW/warnings/
I've come across an issue with Upstart – user jobs' start on stanzas
aren't honored at boot time.
The real issue is more general: user jobs aren't loaded into Upstart
until the user creates an Upstart session. If a job isn't loaded into Upstart, it's basically invisible and hence its start on stanzas won't be honored.
Loading user jobs into Upstart is simple. It happens automatically when a user creates an Upstart session by connecting via D-Bus
using initctl or one of the shortcuts (e.g. start or
status). Until user jobs are loaded into Upstart, they're completely disabled.
So the problem at boot time is that user's don't have the opportunity to create an Upstart session prior to the
rc-sysinit job emitting runlevel, this makes it impossible for user jobs with
start on runlevel [2345] to be honored.
Perhaps this is by design – I'm not sure – but I wrote the following job to
get around the issue by blocking rc-sysinit and creating an Upstart
session for each user with an .init/ directory in their home:
The following job should be installed into /etc/init/load-user-jobs.conf:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
