You are not logged in.
What about putting lvm2 at the MODULES=() array?
lvm2 is not a module. The modules related to lvm are pulled in by the lvm2 hook.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
It seems some people fail randomly, like myself, so I wonder if it is something in udev setting up my computer (and a few others) that is messing up lvm. Just to bump some people's brains, I don't know anything about udev or mkinitcpio, obviously. This is the lvm2 hook:
#!/bin/bash
build() {
local mod
for mod in dm-mod dm-snapshot dm-mirror; do
add_module "$mod"
done
add_binary "/usr/sbin/lvm"
add_binary "/usr/sbin/lvmetad"
add_binary "/usr/sbin/dmsetup"
add_file "/usr/lib/udev/rules.d/10-dm.rules"
add_file "/usr/lib/udev/rules.d/13-dm-disk.rules"
add_file "/usr/lib/udev/rules.d/95-dm-notify.rules"
add_file "/usr/lib/udev/rules.d/11-dm-lvm.rules"
add_file "/usr/lib/udev/rules.d/69-dm-lvm-metad.rules"
add_file "/usr/lib/initcpio/udev/11-dm-initramfs.rules" "/usr/lib/udev/rules.d/11-dm-initramfs.rules"
add_file "/etc/lvm/lvm.conf"
add_runscript
}
help() {
cat <<HELPEOF
This hook enables LVM2 volumes in initramfs.
HELPEOF
}
# vim: set ft=sh ts=4 sw=4 et:
Last edited by dbourgeo (2013-02-27 21:47:03)
Offline
I can add my 2 cents.
I run dual boot root-on-lvm arch linux and gentoo. everything lvm except /boot in both cases.
my arch linux boots fine running openrc with the lvm hook of mkinitcpio and it starts lvmetad.
use_lvmetad = 1 is properly set.
My gentoo fails somehow to start the lvmetad, even if I start with systemd. So this seems to be systemd independent problem.
"lvmetad: child exited with code 1" the message it prints.
Using an older hook(pre lvmetad) for mkinitcpio solves the problem, no matter if arch or gentoo.
This patch reverts to earlier and working lvm2 activation.
--- initcpio/hooks/lvm2
+++ initcpio/hooks/lvm2
@@ -1,12 +1,24 @@
#!/usr/bin/ash
-run_earlyhook() {
- mkdir /run/lvm
- lvmetad
-}
+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..."
+ [ -d /etc/lvm ] && lvm vgscan
-run_cleanuphook() {
- kill $(cat /run/lvmetad.pid)
+ if [ -n "$quiet" ]; then
+ lvm vgchange --sysinit -a y >/dev/null
+ else
+ lvm vgchange --sysinit -a y
+ fi
}
# vim: set ft=sh ts=4 sw=4 et:
If you use the patch, set use_lvmetad = 0.
Last edited by artoo (2013-02-28 19:17:11)
Offline
Boot is definitly broken for me after the upgrade. It boots randomly, and I get errors more often than I get to boot up fine. The errors are different each time, and all related to not being able to find a certain lvm volume. Or time outs searching for a volume. The volumes varies, some times is var, some times it's root... I will try the patch from artoo since my system is not usable right now. It surprises me that we are only a few with this problem, and it's not being addressed as critical.
Cheers,
Offline
Artoo's patch does not work for me, exactly the same boot behaviour. ps and udevd information is exactly the same, as well.
Offline
Just want to add my two cents here...
My server has started doing this. I guess I probably just didn't reboot often enough to know that it was happening there as well. The global_filter fix worked for my laptop, but not my server...
Interestingly my server has two seagate HDDs, and the LV that spans across both disks is what seems to fail. This is the /srv partition, so I actually tried quickly rsyncing / and /var to a spare 2.5" drive without LVM2, I chagned the necessary configs, but since it was the /srv partition failing and not the / or /var, even when not using the lvm2 mkinitpcio hook and then enabling lvm-monitoring.service, it still fails because that partition times out.
I'm really not sure what to do now...
Offline
Maybe this is not the same problem. Suddenly my udev hook take a long long time during boot.
Startup finished in 591ms (kernel) + 53062ms (initrd) + 12309ms (userspace) = 65963ms
No errors, only slow boot.
Anyone with something like this?
Sorry for my bad english.
Last edited by dutra.julio (2013-03-01 10:22:38)
Offline
Maybe this is not the same problem. Suddenly my udev hook take a long long time during boot.
Startup finished in 591ms (kernel) + 53062ms (initrd) + 12309ms (userspace) = 65963ms
No errors, only slow boot.
Anyone with something like this?
Sorry for my bad english.
You haven't left enough info to really make any kind of judgement of similarity. Your English is fine, but your details are sparse.
Offline
Artoo's patch does not work for me, exactly the same boot behaviour. ps and udevd information is exactly the same, as well.
You have generated a new initrd after applying the patch, right?
You could also just rename original /usr/lib/initcpio/hooks/lvm2 and replace it with an older version instead of using the patch.
The patch I posted is the hook lvm2 used to provide before lvmetad activation.
https://projects.archlinux.org/svntogit … 231035afdc
Just curious, for me it fixed the boot with mkinitcpio created initrd on gentoo.
Last edited by artoo (2013-03-01 18:07:00)
Offline
Oh my, since I copied my system to a new harddrive and downgraded and then reupgraded, it began to work, sort of. I thought I had reset the use_lvmetad flag to 1. Nope. When I thought to double check it was 0. My system now works fully normally. However, the old drive definitely did not. I think I assumed upgrading would change use_lvmetad, as I did that too quickly for my own good.
Sr. Ssruno might want to double check their lvm.conf, as they fail identically.
Interestingly, Artoo's patch made me double check use_lvmetad, thinking it should be changed to 0, but it won't run on my machine (yes did run mkinitcpio).
I really should triple check that though, but it would probably be better to put back my old harddrive to see if that fails. If it doesn't then I know sometimes my drive controller works, sometimes it doesn't. My issue would then be unrelated, most likely, unless udev somehow imitates that behaviour.
Offline
brain0:
yes, my LVM physical volume is an entire disk "/dev/sdb". Do you still expect the ID_FS_TYPE to be tagged on this volume? (It's not). I also ran ps quickly after booting and there isn't a pvscan running at the time. Still experiencing the pre-boot manual lvm activation being necessary to boot it.
sudo pvdisplay
--- Physical volume ---
PV Name /dev/sdb
VG Name vg-data
PV Size 931.51 GiB / not usable 1.71 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 238467
Free PE 105347
Allocated PE 133120
PV UUID Qv7bYh-ES2K-Zyn8-yj3K-FfXc-1hXs-c3BTmo
Offline
I retried my old harddrive, with arch linux fully upgraded to today's packages. I set use_lvmetad=1, and reran mkinitcpio. Everything worked fine!
I know for a while my new harddrive wasn't working, and with use_lvmetad=1 or 0. I simply forgot what I had done with that variable the last time I booted (I first tried archlinux fully upgraded with "use_lvmetad=1", then downgraded and set use_lvmetad=0. When I upgraded again, it appeared my harddisk began to work again, but I forgot about use_lvmetad, and it was still 0).
So, my problem is a failing sata controller, or something like that. It was giving me trouble earlier in the year. It is funny that the whole while windows and a 2 year old version of ubuntu (using lvm) would boot. However, ubuntu gave me trouble the last time, when lvm would not even scan the volumes from an install disk.
Offline
Just thought I should put this here.
After updating to 3.8.1 from grayskys repo-ck, all is back to normal. Boot is totally consistent on my server. I'm not sure what this implies, but I am just glad to have it working again. Though it would be nice to know what the hell was going wrong there.
Edit: Okay, borked again... not sure if it is 3.8.2 or I was just on a lucky streak... WTF LVM?!?!? I did realize that it was looking for /dev/vol0/<partitions>, and that they weren't showing up. But when I changed it to the /dev/mapper/vol0-<partitions> in both fstab and syslinux.cfg, it got better... but then again, maybe it was a luck streak... or a placebo.
Last edited by WonderWoofy (2013-03-06 04:52:47)
Offline
Word random seems to be the key in here.
I upgraded the packages (device-mapper, lvm2, linux), updated configuration (lvm.conf) and ran mkinitcpio again with promising results: 5 successful boots in a row. I already suspected the issue being fixed somehow. Then on next boot got the error again. And the next boot worked fine
Offline
Same thing happened to me. Let me clarify again, I'm not using LUKS at all. Probably we should start a new thread for those of us not using LUKS? Is this being addressed or is it just a few of us with these issues?
Offline
I have been happily running on brand new hardware that I copied over, no issues, same setup minus a changed fstab (even same video drivers).
I couldn't reproduce my problem on the old hardware, either. For a while I was banging my head on the wall, and now it seems to be fixed permanently. I now have a spare box to try any debugging if anyone wants.
Offline
dutra.julio wrote:Maybe this is not the same problem. Suddenly my udev hook take a long long time during boot.
Startup finished in 591ms (kernel) + 53062ms (initrd) + 12309ms (userspace) = 65963ms
No errors, only slow boot.
Anyone with something like this?
Sorry for my bad english.
You haven't left enough info to really make any kind of judgement of similarity. Your English is fine, but your details are sparse.
How can i get the necessary info?
Offline
Would using the mdadm_udev hook help resolve the issue? According to this:
https://mailman.archlinux.org/pipermail … 23975.html
it is required for lvm to work properly. mdadm_udev is also recommended by the wiki, however it is not mentioned very explicitly.
Offline
I don't think you need mdadm_udev hook, unless you are using RAID:
"If you use both RAID and LVM, make sure that you use the mdadm_udev
hook instead of the mdadm one. I had to do this change to make my
system boot with the lvm2 package in [testing]."
Offline
SOLVED for me. LVM snapshots make volgroup activating very slow. After remove the snapshots the system boots fine.
Offline
SOLVED for me. LVM snapshots make volgroup activating very slow. After remove the snapshots the system boots fine.
This is what I mean by more info is needed. Your problem is not at all the same as the others around here.
What you need to do to have snapshots working is to enable lvm-monitoring.service. If it is not enabled it will cause your system to hang a bit (like you have experienced). Did you ahve it enabled?
Offline
dutra.julio wrote:SOLVED for me. LVM snapshots make volgroup activating very slow. After remove the snapshots the system boots fine.
This is what I mean by more info is needed. Your problem is not at all the same as the others around here.
What you need to do to have snapshots working is to enable lvm-monitoring.service. If it is not enabled it will cause your system to hang a bit (like you have experienced). Did you ahve it enabled?
Yes, i have lvm-monitoring.service enabled. In my case the system not hangs. It only takes a very long time to activate the volume group. When i execute "vgchange -ayv" the command take for a minute to activate all the four snapshots. For a while i realy dont need to use snapshots then i can wait for a solution. Thanks for the patience.
Offline
@dutra.julio
I also have issues when I have snapshots around, though I've never failed to boot. I'd still be interested to know if you saw any symptoms similar to what I described here.
Edit: I also discovered today that dmeventd is using 100% CPU pretty much constantly!
432 root 2 -18 227m 14m 3176 S 100.0 0.4 368:49.82 dmeventd
2353 testing 20 0 1006m 315m 28m S 7.6 8.0 24:23.53 firefox
814 root 20 0 163m 55m 8952 S 2.3 1.4 12:15.47 X
Last edited by alphaniner (2013-03-21 19:19:09)
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
I found a solution that seems to have worked for me:
vgreduce --removemissing vgroupmain
Apparently there was missing device that I was not aware of (causing a delay).
Offline