As of baselayout-1.12.9-r2, the following lines have been removed from /etc/init.d/checkfs: # Start RAID/LVM/EVMS/DM volumes for /usr, /var, etc. # NOTE: this should be done *before* mounting anything [[ -z ${CDBOOT} ]] && start-volumes This results in lvm volumes no longer coming up on startup. I have a suspicion they're supposed to be started elsewhere, but at least on my system they're not. Reproducible: Always Steps to Reproduce: 1. Be using LVM for crucial volumes. 2. Update to latest baselayout-1. 3. Reboot. 4. Cry when all your volumes don't exist. Actual Results: Cry, because all my lvs are not active, and so don't mount, and so my system is sad. Expected Results: Not cry, because my lvs are activated on boot, and get mounted before login starts. Like I said, I'm sure this is supposed to be happening somewhere else, since it was very clearly explicitly removed from checkfs, but I'll be damned if I can figure out where. Possibly some ebuild I don't have installed that should be a dependency of lvm2 but isn't.
Have a look at this commit: http://sources.gentoo.org/viewcvs.py/baselayout?rev=1776&view=rev The start_volumes moved from checkfs to /sbin/rc, and then changed to use the RC_VOLUME_ORDER variable to start the addons directly.
Ok, I think I've figured out what's going on here. /lib/rcscripts/addons/lvm-start.sh conditions the starting of lvm on the existence of /proc/lvm, and even though I'm using lvm, for some reason that directory does not exist on my system, so LVM doesn't start. (I have no idea what the implications of the nonexistence of that directory are. This may be related to the fact that I have lvm statically compiled into my kernel, not as a module?) So switching from start_volumes to the more modular addons system caused LVM to stop working for me. Let me know if I need to refile my bug against sys-fs/lvm2-2.02.28-r2, or if you can do that, or how I should proceed.
Oh, I should warn you I'm running 2.4, since that's probably atypical these days. gwillen@lemur ~ $ uname -a Linux lemur 2.4.31-hardened #7 SMP Mon Mar 6 10:51:21 EST 2006 i686 AMD Athlon(tm) XP 2200+ AuthenticAMD GNU/Linux
Are you using a kernel with the device-mapper+LVM patches or not? Either /proc/lvm should exist, or 'device-mapper' should exist in at least one of /proc/devices, /proc/misc. The line that checks is: if [ -d /proc/lvm ] || dm_in_proc ; then (where dm_in_proc looks at those files mentioned above) So start by checking your RC_VOLUME_ORDER, then adding some debug print statements around the lvm addon script. However I would strongly suggest moving to a 2.6 kernel, as 2.4 isn't really unsupported anymore. If you are using an LVM-patched kernel, it should be quite easy (there is a howto on the site about it, with LVM mentioned).
(In reply to comment #4) > Are you using a kernel with the device-mapper+LVM patches or not? > Either /proc/lvm should exist, or 'device-mapper' should exist in at least one > of /proc/devices, /proc/misc. Sorry, I was in too much of a hurry when I was reading that. Yes, I do have device-mapper in /proc/devices and /proc/misc. So the script should be working. > So start by checking your RC_VOLUME_ORDER, then adding some debug print > statements around the lvm addon script. Ok, will do. I was hoping I could solve this by visual inspection, because it's a pain to keep rebooting to test the script, and temporarily takes down my email. > However I would strongly suggest moving to a 2.6 kernel, as 2.4 isn't really > unsupported anymore. If you are using an LVM-patched kernel, it should be quite > easy (there is a howto on the site about it, with LVM mentioned). LVM isn't the reason for the lack of upgrade -- originally it was because 2.6 was still too new, I felt, and now it's mainly because 2.4 does everything I need, so I haven't gotten around to it.
(In reply to comment #4) Okay, two observations. > Either /proc/lvm should exist, or 'device-mapper' should exist in at least one > of /proc/devices, /proc/misc. At boot time (while the relevant script is running) it exists in misc, but NOT in devices. Later, once the machine is booted, it exists in both. (I don't know what the mechanism is here, I just put a 'cat' in the script.) > (where dm_in_proc looks at those files mentioned above) Would you say it's an error in dm_in_proc that it wants to find device-mapper in _both_ of the above-mentioned files, as currently implemented? Because I would expect it to be looking for only one, and if that were the case it would work for me. (The error, if it indeed is one, is that it adds together the return codes from the greps, where it should probably be multiplying them: since 0 is true and 1 is false in the shell, true + false = false, so a failure to find device-mapper in either file causes an overall failure.)
Hmm, I see that there. I'll dig in the morning, as to why the kernel would only have it in one side. Could you please tell me exactly what kernel sources you are using?
I'm running sys-kernel/hardened-sources-2.4.33.4 .
Potentially interesting: On startup only (not when I run it once the system is up), /sbin/vgscan --mknodes --ignorelockingfailure says error calling: "unlink" in "GLOBAL" The internet tells me devfsd is what emits this, and that it is "usually harmless", but I figured I'd mention it, as it seems like it might be related to the fact that /proc/devices doesn't show device-mapper on startup (but does once the system is up).
This is a really old bug, that I think was fixed long since. Please retest and report back if needed.
This machine died last year. ;-) Since I am the only reporter I am closing the bug in hopes that your guess is correct. Thanks for your work on it.
