im not sure, but looks the problem i have here is the same problem 14.04
gave up waiting for root device
common problems:
--boot arts (cat /proc/cmdline)
-check root delay (did the system wait long enough?)
-check root (did the system wait for the right device?)
-missing modules ls/dev
ALERT!
** Changed in: initramfs-tools (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: lvm2 (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: hundredpapercuts
Status: Confirmed => Fix Released
I have this problem as well on my 14.04.2 Dom0 cloud1. The VG that
holds all VMs does not come up active on boot so no VMs set to autostart
are started. I have another 14.04.2 which is on matching hardware and
configured very similar to cloud1. It reboots and starts up the VMs
properly. like
I don't get this bug.
I have at least 1 snapshot going on my /home partition all the time.
The VG that /home is in contains most of my partitions (26), with
2 more partitions on a separate (VG+PD's) VG.
Now, I've noticed when I am booting, it *does* take a bit of time to mount
bring up and
@Astara:
Now, I've noticed when I am booting, it *does* take a bit of time to mount
bring up and mount all of the lvs, but you can the root mount is NOT
in an VG/LV -- It's on a regular device (numbers on left are w/kernel time
printing turned on -- so they are in seconds after boot):
[
With the knowledge that the hang is caused by snapshots, some googling has
brought up some duplicates:
https://bugs.launchpad.net/lvm2/+bug/360237
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/995645
It seems the issue was hanging around since 2009 or earlier.
In Trusty (or probably even
Got an interesting reply from the Red Hat LVM mailing list:
https://www.redhat.com/archives/linux-lvm/2015-March/msg00022.html
Haven't tested the suggestion yet.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in
Turns out, the suggested --setactivationskip option is not present in
Utopic, as Utopic comes with an LVM version which dates back to 2012
(2.02.98(2) (2012-10-15)), while the feature was implemented in 2013.
Vivid will come with a newer LVM: 2.02.111(2) (2014-09-01).
Activation skip could be a
** Changed in: initramfs-tools (Ubuntu)
Importance: Undecided = High
** Changed in: hundredpapercuts
Importance: Medium = High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
** Also affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
Now I have some more info about this. What actually makes the VG
activation so long is that I have a snapshot. Activating the snapshot
takes very long, and bringing up the entire VG takes about 5 minutes.
This wouldn't be such a big problem, as I could just patiently wait for
the activation (with
Alberto Salvia Novella, thanks for the QA, and helpful suggestion. From my
understanding, the Ubuntu Kernel Team prefers to mark reports like these High
(not sure why I marked it Medium initially, probably was on auto-pilot) as
defined in https://wiki.ubuntu.com/Bugs/Bug%20importances :
Makes a
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: lvm2 (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
@ Christopher M. Penalver:
Because this bug renders the system temporally unusable, it looks like
it should have an importance of critical.
** Changed in: lvm2 (Ubuntu)
Importance: Undecided = Medium
** Also affects: hundredpapercuts
Importance: Undecided
Status: New
** Changed
MegaBrutal, you may want to ping an lvm2 maintainer about this. As per
https://launchpad.net/ubuntu/+source/lvm2/+changelog the most recent
person to commit to this is Dave Chiluk chi...@canonical.com .
** Changed in: linux (Ubuntu)
Status: Incomplete = Confirmed
--
You received this
I've had a backup of my old Trusty system, and I've built an initrd for
3.16.0-23-generic in that environment. With that initrd, the kernel
booted properly. Note, still it takes several minutes for the VG to
activate, but it eventually comes up if the kernel waits enough with
rootdelay=300.
Now,
16 matches
Mail list logo
