You are not logged in.
Hello,
probably due to somewhat slower detection of devices in the latest device-mapper driver I had to add "lvmwait=/dev/mapper/<root-volume> rootdelay=1" kernel command-line parameters in order to boot my system normally. I'm writing this just in case someone runs into the "Activating logical volumes... No volume groups found" message while booting her lvm-rooted system.
edit: this was more an ugly workaround rather than real solution
Last edited by laloch (2012-07-24 21:41:49)
Offline
Confirmed.
I have a LVM root, kernel 3.5-1 fail to boot reporting:
No volume groups found,
and drop me to the busybox shell.
In the busybox I execute this commands:
lvm vgchange -ay
lvm reports the following message:
//sbin/dmeventd: stat failed: No such file or directory
But still it managed to find other logical volumes. Now i quit the busybox and the system boots like normal.
Offline
Works for me....
Loading /vmlinuz-linux......
Loading /initramfs-linux.img......ready.
:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
:: running hook [lvm2]
Activating logical volumes...
3 logical volume(s) in volume group "VolGroup00" now active
:: performing fsck on '/dev/mapper/VolGroup00-root'
root: clean, 57394/327680 files, 616107/1310720 blocks
:: mounting '/dev/mapper/VolGroup00-root' on real root
:: running cleanup hook [shutdown]
:: running cleanup hook [udev]
Welcome to Arch Linux!
btw the default rootdelay is 10 seconds assuming that udev is present (it's ignored when udev isn't running). You aren't doing yourself any favors by decreasing the root delay.
Last edited by falconindy (2012-07-24 03:58:20)
Offline
You aren't doing yourself any favors by decreasing the root delay.
I am. Relevant part of the lvm2 hook:
# If the lvmwait= parameter has been specified on the command line
# wait for the device(s) before trying to activate the volume group(s)
for pvdev in ${lvmwait//,/ }; do
poll_device ${pvdev} ${rootdelay}
done
Offline
I'm aware of what the lvm2 hook does. You're still decreasing the delay with no conceivable gain. If the device shows up in 1 second, poll_device returns in 1 second whether the delay is 10 seconds or 10 minutes. If the device doesn't show up for 5 seconds, your decreased delay will cause boot to fail.
Offline
After re-reading the OP I'm convinced you're even misusing the lvmwait parameter. You're meant to add member devices to lvmwait=, not the resultant assembled device (which is waited for by resolve_device in /init).
No idea what's going on here, but without config and/or lsinitcpio -a output from the image, this isn't going to go any further.
Offline
See here: https://wiki.archlinux.org/index.php/Mk … #Using_LVMAs for the rootdelay timeout, it even waits for 10 seconds for each volume in the lvmwait array.
edit: @falconindy: You are right. It does not make any sense to poll-wait for the LVM volume and then do the vgchange -a y ... but waiting for physical volumes doesn't work for me either, because they are already there. It's the dm-mod module initialization. It just seems to be too slow.
Last edited by laloch (2012-07-24 20:28:54)
Offline
So I modified my lvm2 hook to look like this:
#!/usr/bin/ash
run_hook() {
local pvdev
modprobe -q dm-mod >/dev/null 2>&1
# If the lvmwait= parameter has been specified on the command line
# wait for the device(s) before trying to activate the volume group(s)
for pvdev in ${lvmwait//,/ }; do
poll_device ${pvdev} ${rootdelay}
done
msg "Activating logical volumes..."
lvm pvscan
[ -d /etc/lvm ] && lvm vgscan
if [ -n "$quiet" ]; then
lvm vgchange --sysinit -a y >/dev/null
else
lvm vgchange --sysinit -a y
fi
}
which seems to be better solution
Offline
So I modified my lvm2 hook to look like this:
msg "Activating logical volumes..." + lvm pvscan [ -d /etc/lvm ] && lvm vgscan
which seems to be better solution
Has anybody reported upstream, that there is a problem and that the problem can be solved by inserting one line as shown above?
I can also confirm, that there is the very same problem on my machine and recent updates did not solve it.
Cheers,
Ignas
Offline
Same problem here. I tried to downgrade the kernel from [core], but it didn't work.
Offline
I ran into the same problem as linux 3.5 now is in [core].
For me using lvmwait=/dev/sdXX did the job (sdXX is the partition which acts as LVM physical volume).
Offline
Same problem just now after updating to linux 3.5.3-1. I added lvmwait=/dev/mapper/<volume group name><logical volume name> from https://wiki.archlinux.org/index.php/Mk … #Using_LVM to my /etc/default/grub file under "GRUB_CMDLINE_LINUX_DEFAULT", run grub-mkconfig and I now have no problem. Without it, my system sometimes boots, sometimes doesnt - with the error "No volume groups found".
What is the best or permanent solution? my boots are now a little slower, with a blank pause after the grub menu
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
Same problem after updating to linux 3.5.3-1.
Utilizing the lvmwait temporary workaround.
lsinitcpio output:
==> Image: /boot/initramfs-linux.img
==> Created with mkinitcpio 0.10
==> Kernel: 3.5.3-1-ARCH
==> Size: 4.25 MiB
==> Compressed with: gzip
-> Uncompressed size: 11.73 MiB (.362 ratio)
-> Estimated extraction time: 0.112s
==> Included modules:
ahci hid-elecom hid-roccat i2c-algo-bit
button hid-emsff hid-roccat-arvo i2c-core
crc16 hid-ezkey hid-roccat-common i915 [explicit]
dm-log hid-gaff hid-roccat-isku intel-agp
dm-mirror hid-generic hid-roccat-kone intel-gtt
dm-mod hid-gyration hid-roccat-koneplus jbd2
dm-region-hash hid-holtekff hid-roccat-kovaplus lcd
dm-snapshot hid-hyperv hid-roccat-pyra libahci
drm hid-kensington hid-saitek libata
drm_kms_helper hid-keytouch hid-samsung mbcache
efivars [explicit] hid-kye hid-sjoy scsi_mod
ehci-hcd hid-lcpower hid-sony sd_mod
ext4 hid-logitech hid-speedlink snd
fb_sys_fops hid-logitech-dj hid-sunplus snd-rawmidi
ff-memless hid-magicmouse hid-tivo snd-seq-device
hid hid-microsoft hid-tmff soundcore
hid-a4tech hid-monterey hid-topseed syscopyarea
hid-apple hid-multitouch hid-twinhan sysfillrect
hid-aureal hid-ntrig hid-uclogic sysimgblt
hid-axff hid-ortek hid-wacom usb-common
hid-belkin hid-petalynx hid-waltop usbcore
hid-cherry hid-picolcd hid-wiimote usbhid
hid-chicony hid-pl hid-zpff video
hid-cypress hid-primax hid-zydacron xhci-hcd
hid-dr hid-prodikeys hv_vmbus
==> Included binaries:
blkid dmsetup fsck.ext4 lvm switch_root udevd
busybox fsck kmod mount udevadm
==> Early hook run order:
udev
==> Hook run order:
udev
lvm2
resume
==> Cleanup hook run order:
udev
Last edited by wop138 (2012-08-28 21:04:38)
Offline
It looks like `lvm pvscan' helps just because it produces short delay before `lvm vgchange'. I guess if /etc/lvm exists on initrd then it also should work because `lvm vgscan' should run and produce a delay, but delay looks like a crutch in this case.
I also tryed to add `udevadm settle' to lvm2 hook and scsi_wait_scan to MODULES in mkinitcpio.conf but both variants don't work.
BTW, current kernel provides devtmpfs enabled by default. Did anybody try to use devtmpfs instead of udev in the initrd?
Offline
I also tryed to add `udevadm settle' to lvm2 hook
Of course not. Assuming sane hook ordering on your image, the udev hook runs this before the lvm hook runs. Running it again won't do any good because the event queue will already be empty.
Did anybody try to use devtmpfs instead of udev in the initrd?
That isn't a "pick one" option. You always have devtmpfs because udev is incapable of creating device nodes these days. Rather, it depends on devtmpfs (the kernel) to handle this. Regardless, lvm isn't really swayed by what udev does beyond creating the underlying block devices. It depends on brute force scanning to find volumes as opposed to the evented model that udev encourages (requires?).
Offline
I am having the same issue, after upgrading to kernel 3.5.1.
1/ what is the recommended place of lvm2 in the HOOKS array in mkinitcpio.conf ? I have not found any hint in the documentation.
I am currently using:
HOOKS="base udev autodetect pata scsi sata lvm2 filesystems usbinput fsck"
2/ is there an official or at least clean fix for this issue ?
3/ I am quite disappointed that an issue seen 1 month ago in testing has not been solved and is not blocking the release of the new kernel to core.
It means that all people, even the beginners, can be badly impacted. New kernel release shall have been delayed until a fix (temporary or permanent) has been found, no ?
Offline
3/ I am quite disappointed that an issue seen 1 month ago in testing has not been solved and is not blocking the release of the new kernel to core.
It means that all people, even the beginners, can be badly impacted. New kernel release shall have been delayed until a fix (temporary or permanent) has been found, no ?
That's why I also have Ubuntu installed. It is very useful when Arch stops booting. I wish I could trust Arch more than I do. I suggest voting for https://bugs.archlinux.org/index.php?do … k_id=30966
Offline
I suggest voting for https://bugs.archlinux.org/index.php?do … k_id=30966
I suggest doing something more productive than voting on a bug that's clearly a kernel issue if you want this solved.
Offline
cemsbr wrote:I suggest voting for https://bugs.archlinux.org/index.php?do … k_id=30966
I suggest doing something more productive than voting on a bug that's clearly a kernel issue if you want this solved.
I do not have anything new to share so far and If I have, I certainly will. Maybe a kernel that doesn't boot moved from testing because it wasn't affecting many people and voting is a way to show that more people are having problems. With more votes, I believe the priority can become higher than "normal", attracting more people to solve the problem quicker. To finish, I'll quote falconindy from the bug report:
Yes, thanks for reiterating what's already been said multiple times in this bug report. If you have nothing useful to add, there's a vote button you can click.
Offline
Maybe a kernel that doesn't boot moved from testing because it wasn't affecting many people and voting is a way to show that more people are having problems.
Except that it does boot and affects only a fraction of the userbase. Reread the thread if you aren't convinced that people have found ways around this inconvenience.
To finish, I'll quote falconindy from the bug report:
falconindy in bug report wrote:Yes, thanks for reiterating what's already been said multiple times in this bug report. If you have nothing useful to add, there's a vote button you can click.
Right. Voting satisfies some invisible need for people to feel heard, and it prevents my inbox from filling up with garbage that I don't need to be reading.
Bisect the changes in drivers/dm in the kernel tree, report it upstream, be an hero.
Last edited by falconindy (2012-08-30 02:25:11)
Offline
Same problem here. Cannot open encrypted swap over lvm. Work after several reboots.
Last edited by post-factum (2012-08-30 09:13:22)
uname == latest pf-kernel
Offline
I just formatted and removed grub and Im trying syslinux, I notice when my computer boots now by default I get "Waiting 10 seconds for device /dev/sda1". With grub I never saw that, I have "quiet" off with both bootloaders.
Not sure if this will help anyone
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
I have exactly the same problem. It seems that with this new kernel the detection of my hard drive is slower. That's why the LVM volumes aren't detected.
To solve the problem, I added this option to the kernel line in my grub.cfg file :
lvmwait=/dev/mapper/VolGroup00-root
Since, I haven't any more that problem during the boot.
Offline
Except that it does boot and affects only a fraction of the userbase. Reread the thread if you aren't convinced that people have found ways around this inconvenience.
It boots if you like digging through forums for a solution on a different computer. Though people have been saying it sometimes works, I never had such luxury. It failed every time for me, until I added lvmwait. Any bug that breaks the boot cycle post-upgrade should have top priority, I would think. These are the kind of bugs that detract users from wanting to stick with Archlinux.
Offline
Offline