I'm using LVM2 since several months now with no major problems. A few days ago I updated to 2.00.33-r1 (as this release was marked stable, former used 2.00.08). Now LVM2 dosen't start correctly anymore at boot time, it complains about "Read only filesystem - cannot create lockfile /var/lock/lvm/V_<vgname>" This is AFTER the root filesystem (which is not on a LVM, only the /usr directory is) is remounted rw. After that I can't mount the lv's (not a valid block device) until I manually activate the volume group (vgchange -a y <vgname>). Reproducible: Always Steps to Reproduce: 1. Upgrade to LVM2 2.00.33-r1 2. Let fstab mount some LVM2 volumes at boot time. 3. Watch how it fails ;) Actual Results: LVM2 failed to start Expected Results: Activate the volume group. A quick "fix" is to deactivate lock file using in /etc/lvm/lvm.conf, but since this is marked as "dangerous", this shouldn't be a long time solution.
This one's curious - if Ichange the lock dir in /etc/lvm/lvm.conf from /var/lock/lvm to /tmp, it works - although both folders are on the same partition!!! Seems like a "real" bug. Is the lock feature new in this version?
please add the contents of your fstab.
My /etc/fstab: /dev/hdb6 / reiserfs defaults 1 1 /dev/myvg1/usr /usr reiserfs defaults 0 0 /dev/hda1 /boot ext2 noauto,noatime 1 1 /dev/hda5 none swap sw 0 0 /dev/myvg1/home /home reiserfs defaults 0 0 /dev/myvg1/var_cache /var/cache reiser4 defaults 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0 #/dev/fd0 /mnt/floppy auto noauto 0 0 # NOTE: The next line is critical for boot! none /proc proc defaults 0 0 # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will # use almost no memory if not populated with files) # Adding the following line to /etc/fstab should take care of this: none /dev/shm tmpfs defaults 0 0 none /dev/pts devpts defaults 0 0
does /var/lock/lvm exist and what are its permissions? /var/lock/lvm should be a directory.
/var/lock/lvm is a directory with permissions 777 (they were a bit more restrictive before, but I changed them to 777 to ensure that it's not a permissions problem).
Could you try emerging the 2.00.33-r2 ebuild and run the command /sbin/lvm without rebooting to see if it complains about locking? That ebuild forces the build to compile the binaries statically. Which is what they should be for a sbin directory. This is an odd situation as I am not seeing the issue on my machine.
please run vgscan -vvv and see if it produces any output as far as locking is concerned.
Locking is no problem once the system is booted. I don't even know if it is really a LVM problem, and it's hardly reproducable - appearing not every bootup, but every 3rd or so. Could it be a kernel problem (using 2.6.11-nitro0)? Fact is, it also appears with statically compiled LVM, so that's not the point. Also, it did also happen once with /tmp as lock dir, so that's also not the problem. Maybe I just have a messed up system??
it may be the kernel you are using. Try using a gentoo std kernel.
Hmmmmmmm...didn't get the problem the last few days. I think it's really not LVM but anything else on my system (maybe the nitro kernel). I think you can close this bug!
Closing as this is most likely a specific users kernel causing the issue.
