Hi Peter, On Sat, Jun 08, 2013 at 12:06:03PM +0100, Peter Denison wrote: > * What led up to the situation? > Installed upstart, replacing sysvinit, then rebooted > * What was the outcome of this action? > Boot hung after fsck of /root, /boot and /home > * What outcome did you expect instead? > Boot as far as a console login at least > * What exactly did you do (or not do) that was effective (or > ineffective)? > Recovered by using init=/bin/bash on kernel cmdline, and manually > ran sysv startup scripts, to the point where I could run apt-get again > to restore sysvinit
> The boot process stopped after fsck, leaving no console access, and an > essentially unusable system. > By comparing the failed startup with the manual startup from /bin/bash, it > appears that the upstart-driven startup is not enabling LVM early enough, so > that mountall does not complete mounting the LVM-hosted partitions, and then > nothing else happens. > /etc/fstab: (with the noauto,user mounts removed) > # /etc/fstab: static file system information. > # > # <file system> <mount point> <type> <options> > <dump> <pass> > proc /proc proc defaults 0 > 0 > UUID=f5ebf199-5396-4b0c-a3e5-f35833e99473 / ext3 > errors=remount-ro 0 1 > UUID=92f30fdb-364b-4978-8918-e820ba9c8570 /boot ext3 defaults > 0 2 > UUID=5d778b04-aef3-47ec-965d-b6ccbd6da7fa /home ext3 defaults > 0 2 > UUID=9791c6cc-84b6-4f47-a613-1ddb1af14a8c none swap sw > 0 0 > UUID=E4C010C1C0109BBC /mnt/windows/e ntfs user,exec,utf8 0 > 0 > /dev/disk_group/usrlocal /usr/local ext3 defaults 0 > 2 > /dev/disk_group/music /mnt/music ext3 user 0 > 2 It's expected that LVM volumes will be activated by udev. I confess I hadn't checked whether this works right currently in Debian; while I use LVM on my Debian systems, my root fs is always on LVM as well, which means the VG activation is handled from the initramfs before upstart starts up. From your fstab, would it be correct to assume that /usr/local and /mnt/music are the only two filesystems on LVM? (I ask, because some people will use UUID in their fstab for LVM filesystems - though this is an error, as, due to snapshotting, fs UUIDs are not guaranteed to be unique on LVM). If so, you should be able to work around this incompatibility by adding a 'nobootwait' option to your /usr/local fstab entry. This will instruct mountall to not hold up the boot waiting for this filesystem to become available, breaking the deadlock between /etc/rcS.d/S??lvm2 and mountall. This means there will be a slight race condition introduced on your system, but assuming you aren't starting any services out of /usr/local at boot time, this should be ignorable. If you can confirm this fixes the problem for you, I'll work with the lvm2 maintainers to come up with an appropriate fix here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
