After talking to cjwatson on irc, there is another option. update-grub is failing because /dev/disk/ is not set up in the container. So we could add an upstart job which runs only in containers, and manually sets up /dev/disk/. This also might help other software which relies on /dev/disk/. However, as grub is not installed in ubuntu containers by default (but is installed in ubuntu-cloud containers) we can't blindly re-use grub-probe. If we use grub-probe only if it is available, then we are helping fewer cases. If we detect the root device by hand, I fear we are duplicating too much fragile code.
Perhaps the best option is simply an upstart job like the below (but smarter and safer):
After talking to cjwatson on irc, there is another option. update-grub is failing because /dev/disk/ is not set up in the container. So we could add an upstart job which runs only in containers, and manually sets up /dev/disk/. This also might help other software which relies on /dev/disk/. However, as grub is not installed in ubuntu containers by default (but is installed in ubuntu-cloud containers) we can't blindly re-use grub-probe. If we use grub-probe only if it is available, then we are helping fewer cases. If we detect the root device by hand, I fear we are duplicating too much fragile code.
Perhaps the best option is simply an upstart job like the below (but smarter and safer):
start on starting mountall `grub-probe -t device /` `grub-probe -t fs_label /` by-label/ $rootlabel `grub-probe -t fs_uuid /` by-uuid/ $rootuuid
task
script
type grub-probe > /dev/null 2>&1 || { exit 0; stop; }
mkdir -p /dev/disk/by-label /dev/disk/by-uuid
rootdev=
do_mknod /dev/rootdev
rootlabel=
ln -s ../../$rootdev /dev/disk/
rootuuid=
ln -s ../../$rootdev /dev/disk/
end script