As the headline states, LVM does not work with this release of the baselayout. Comparing /etc/init.d/checkfs with the previous version I found that following lines are missing: --snip-- # Start RAID/LVM/EVMS/DM volumes for /usr, /var, etc. # NOTE: this should be done *before* mounting anything [[ -z ${CDBOOT} ]] && start_volumes --snip--
you neglected to post any real info the lines arent missing, they've been moved to /sbin/rc
ok, saw that now that you mentioned it. I only checked /etc/init.d/* for it. But there is definitly a problem here. When executed from /sbin/rc I get: "locking type1 initialization failed" and later on of course checkfs fails since the LVM drives are not available. When adding the call to checkfs it works. (In reply to comment #1) > you neglected to post any real info > > the lines arent missing, they've been moved to /sbin/rc >
no idea what that error means
Two things I could imagine here. Could it be that udev did not yet create the /dev/mapper/control device by the time the start_volumes is called? Second could it be that / is not yet writable, since lvm wants to write to /etc/lvm. (In reply to comment #3) > no idea what that error means >
I had the same problem with MD/cryptfs/LVM & backed down to 1.11.14 to get things going again. I have a custom RC_VOLUME_ORDER="raid dm dm-crypt lvm", but that's just to make sure my LVM-on-dm-crypt-on-md starts and stops in the right order.
Sorry for providing so little information on the issue, but I was pretty busy. Finally I found the time to investigate a bit more. I added calls to start_volumes to checkroot right before mounting / rw and after that. As I mentioned in #3 it proved that running start_volumes requires / to be mounted rw. (In reply to comment #3) > no idea what that error means >
I've had similar problems with LVM, but in my case LVM would start about 1/3 to 1/2 the time and fail to start the rest of the time. It seems to be related to loading of kernel drivers for the disks. I've got both an SATA disk and a PATA disk managed by a VIA chipset in my motherboard. I'd had the SATA driver (in the SCSI section of the kernel) compiled into the main kernel file and the ATA driver as a module. I did it this way because in earlier kernels (circa 2.6.6), the ATA driver took precedence and tried to control the SATA drive, but I wanted the SATA driver to handle it, so I did it this way. In my case, though, it seems that the SATA driver wasn't being reliably loaded, at least not in time for the LVM startup commands to work correctly. With a 2.6.15 kernel, compiling both the ATA and SATA drivers into the kernel works correctly, and also gives the SATA driver control of the SATA disk.
(In reply to comment #6) > Sorry for providing so little information on the issue, but I was pretty busy. > Finally I found the time to investigate a bit more. I added calls to > start_volumes to checkroot right before mounting / rw and after that. As I > mentioned in #3 it proved that running start_volumes requires / to be mounted > rw. This should not happen because vgchange is started with --ignorelockingfailure. The exact error message i am getting is "locking disabled". I sound to me that vgchange is ignoring the --ignorelockingfailure option.
Doesn't work with 1.12.0_pre15 either... The problem seems to be that vgscan/vgchange with udev would modify /dev (and create symlink in /dev/vg/* to device/mapper/* etc.), while / is mounted read-only. quick hack/workaround: move start_volumes from /sbin/rc to /etc/init.d/checkroot after remounting root rw. At least made my laptop boot properly and let me log on to write this note.
> Doesn't work with 1.12.0_pre15 either... The problem seems to be that > vgscan/vgchange with udev would modify /dev (and create symlink in /dev/vg/* to > device/mapper/* etc.), while / is mounted read-only. / has nothing to do with /dev udev mounts a writable ramdisk on /dev so it doesnt matter whether / is still readonly
Yeah, scratch comment #9. Looks like adding --ignorelockingfailure to both vgscan and vgchange in /lib/rcscripts/addon/lvm-start.sh would work with baselayout 1.12.0_pre15 and gentoo-sources 2.6.14-r5 (amd64)
Just wanted to note that for me the issue is resolved. Please close the bug as soon as everybody in here got his things working. (In reply to comment #6) > Sorry for providing so little information on the issue, but I was pretty busy. > Finally I found the time to investigate a bit more. I added calls to > start_volumes to checkroot right before mounting / rw and after that. As I > mentioned in #3 it proved that running start_volumes requires / to be mounted > rw. > > (In reply to comment #3) > > no idea what that error means > > >
Eric: check out comment #11 please
I am not sure why you dont have this .. --ignorelockingfailure has been in the file for sometime.
Same problem here with baselayout-1.12.0_pre15-r1 :( My system doesn't boot correctly... lvm devices aren't inizialized at boot, I need to manually run "vgchange -a y" to mount /var /usr /home and adding --ignorelockingfailure to both vgscan and vgchange in /lib/rcscripts/addon/lvm-start.sh doesn't work for me!!!
During boot this error appears: Locking type 1 initialisation failed I need to entrer interactive mode... switch to console and run # vgchange -a y # mount -a then I can continue booting the system correctly
There aren't any news guys? :(
Nope, still broken AFAICT. Tried 1.12.0_pre15-r1 on my LVM-heavy server this weekend and didn't find any improvement.
Shit, probably my mistake :) I've recompiled 2.6.15-gentoo-r1 using genkernel with lvm2 option enabled, now all works well!!!
My concerns have been addressed - running 1.12.0_pre16-r1 and everything seems to work right for me.
can we close this? - using w/ sys-apps/baselayout-1.12.0_pre16-r3 no probs
no more probs here
Everything seems OK with 1.12.0_pre17-r2.
k
