Steve,
Several corresponding root-in-lvm lvm-udev timeout/deadlock bugs have been
placed (including bug #902491, bug #912876, bug #909805), but all - at least
superficially - appear to be as a result of the same udev/lvm deadlock as this
bug, and all are fixed (or at least ameliorated) by the lv
Steffen, have you tried the "--noudevsync" fix from bug #802626?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/596554
Title:
Unable to mount root LVM partition
To manage notifications about this bu
Changed title to reflect the larger scope of this bug (it definitely
also impacts situations where root fs /is/ in lvm).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may dead
I have a VM running fully-updated precise (as of today precise-generic
3.2.0-9 - presumably including the fix for #818177?), with the entire
file-system in lvm, which requires the "--noudevsync" fix to prevent a
60 second boot-delay.
I also have...
- Beige-box running oneiric-server with entire f
*** This bug is a duplicate of bug 802626 ***
https://bugs.launchpad.net/bugs/802626
Given that the "--noudevsync" work-around from #802626 also appears to
reliably fix this bug, I'm marking this bug as a duplicate of #802626.
** This bug has been marked a duplicate of bug 802626
vgchange
*** This bug is a duplicate of bug 802626 ***
https://bugs.launchpad.net/bugs/802626
** This bug is no longer a duplicate of bug 902491
Severe regression with latest kernel update: 3.0.0-14.23 takes an
unreasonable amount of time to boot due to udev
** This bug has been marked a duplicate
*** This bug is a duplicate of bug 802626 ***
https://bugs.launchpad.net/bugs/802626
** This bug is no longer a duplicate of bug 902491
Severe regression with latest kernel update: 3.0.0-14.23 takes an
unreasonable amount of time to boot due to udev
** This bug has been marked a duplicate
I've also run into this bug.
3.0.0-14 introduced a - precisely - 60 second delay into my boot-time.
Tried 3.0.0-15 from proposed, with the same result. The only way to
alleviate it was to roll-back to 3.0.0-13 (last kernel to not exhibit
this behaviour). I've also tried a 3.2 kernel from Pangolin,
*** This bug is a duplicate of bug 902491 ***
https://bugs.launchpad.net/bugs/902491
Yes, it appears to be the same bug. Same symptoms, same fix.
** This bug has been marked a duplicate of bug 902491
Severe regression with latest kernel update: 3.0.0-14.23 takes an
unreasonable amount of
I've reinstalled several times and tried a few different permutations to
see if anything helped. This is all Xubuntu 11.10 from the alternate-iso
image on LVM on a GPT'd SSD.
A fresh install causes no problems. An upgrade to 3.0.0-13 causes no
problems. Upgrading to 3.0.0-14 (with no other updates
** Summary changed:
- Boot process hangs for 60 seconds on every boot
+ [3.0.0-14] Boot process hangs for 60 seconds on every boot
** Tags added: ext4 lenovo ssd ureadahead x100e
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:
Public bug reported:
3.0.0-14 has introduced something that causes the boot-process to hang
for 60 seconds (as seen in dmesg) on every boot.
Rolling-back to 3.0.0-12/13 and the problem disappears. However, the
problems remains in 3.0.0-15 (Ubuntu proposed).
Issue is evident in dmesg between the
12 matches
Mail list logo