I am in the process of installing a new gentoo box, and I'm using evms (as I always do). It's got two IDE drives in it, a 60G and a 120G. I've tried this repeatedly in different combinations, and it's consistent: whenever I use lvm or lvm2 containers, things fail after the next reboot: Using install-x86-minimal-2005.0.iso, I get a bunch of these messages in the kernel log when I run evms_activate (or a UI), and evms fails to activate: device-mapper: dm-linear: Device lookup failed device-mapper: error adding target to table Normally, this would be a result of the bdclaim patch not being applied to the kernel (http://evms.sourceforge.net/faq.html#id2802236), but I don't think that's the case here, because no other partitions are mounted when I run evms_activate, so nothing should have a claim on these block devices at all. The devices are completely managed by evms. Not even so much as a compatibility volume. :) BTW, oddly, I *think* this only happens if I have added filesystems to the volumes. Ok, so I try hardened-x86-2005.0_test9.iso (maybe it's a bug that has been fixed in this later image, don't ya know). With this livecd, any evms tool simply segfaults if any lvm/lvm2 has been used, and evms fails to activate. Unfortunately, I need to get this box up and running, so I'm partitioning without lvm and I won't be able to do continued testing, but I'm hoping someone has a spare box on which to duplicate this. :P Or am I overlooking something?
Additonal info: I've traveled back in time, and this issue does *not* occur with install-x86-minimal-2004.3-r1.iso. LVM and LVM2 seem to work fine with that, so I'll try installing with that and hope that things don't blow up when I reboot with an updated kernel. ;)
I just tested a hardened livecd (a little newer than test9, new version should be available for all in a week or so), and was able to evms_activate, as well as create an lvm2 container and regions using standard lvm methods, and was able to add additonal regions through evms. I can't think of anything important that changed between these two CDs that would affect either evms or lvm. If you have time, and a decently fast connection, e-mai l me, and I can give you instructions on getting the CD I just tested.
livecd@ is only for livecd herded ebuilds... release@ is for release materials... Have you tried booting the LiveCD with "gentoo doevms" and see if it makes a difference?
Ok, this is interesting...After setting up my partitions/volumes using EVMS/LVM2 from install-x86-minimal-2004.3-r1.iso, I booted hardened-x86-2005.0_test9.iso again, to see what happens. Now it *doesn't* segfault. Let me make sure my pronouns are clear: With hardened-x86-2005.0_test9.iso, evms tools segfault if the partitioning was actually set up using hardened-x86-2005.0_test9.iso, but that same livecd evms_activates fine as long as the partitioning was set up with install-x86-minimal-2004.3-r1.iso (but I'm not going to try and write operations with hardened-x86-2005.0_test9.iso's evms). Re: comment #2: Sorry, r2d2, I don't want to rebuild again, so all I could test is whether the newer hardened livecd would evms_activate correctly, but in light of the above, that's of no benefit: I'm 99% sure it would activate - the root of the problem appears to occur during the partitioning. Re: comment #3: Apologies on the wrong CC:. :) And no, I didn't try give the doevms parameter to the kernel. I don't see that in the F2 parameter list anymore...didn't that go away after evms was rejected from the kernel? It just lives in userland now and uses the device-mapper now.
Mike, Could you outline the steps that caused the segfault on the hardened livecd? I'm not an lvm/evms guy myself, so I don't really know what to test. I'll try out whatever you provide with both the test9 and my current working CD. Thanks.
Sure, I'll try...actually, I had done many different permutations, and all of them failed if I used any LVM(2), but here's one. Note: all segment types are Linux except hda1...see below. Note 2: this is from memory, so forgive me if I get a detail wrong. add DosSegMgr to hda (~60g drive) Create segments: hda1 (53.6g, type NTFS -> it's for dual-booting WinXP for games (and MS tries to say *Linux* is the "toy" OS...but I digress :P )) Note 2: I tried it without any NTFS at all, also, but the behavior was identical) hda2 (32m) hda3 (2.3g) add DosSegMgr to hdb (~120g drive) Create one segment (hdb1) for the whole drive (120g) Create LVM2 Container "cont1" from hda3 (gah! this just occurred to me: I was setting the PE size on these containers to 128megs...try that and see if that causes a problem) Create regions (I'm providing region names: root: 256m swap: 2g Create LVM2 Container "cont2" from hdb1 Create regions: opt: 5g home: 30g usr: 20g tmp: 2g var: 30g Create volumes for volname in root swap opt home usr tmp var; do "Create EVMS volume $volname on region $volname" done # :P Create EVMS volume boot on segment hda2 Create compatibility volume on hda1 Add filesystems ReiserFS on volumes root, opt, home, usr, tmp, and var, with matching volume names SWAP on swap NTFS on compatibility volume hda1 with volume name "Windows" Save changes, reboot, attempt evms_activate (or attempt to save from evmsn), and this is when the respective errors for each LiveCD occur. Did I leave anything out?
doevms tells genkernel to enable evms support in the initrd... I don't know if it is necessary or not, not being an evms guy myself... but it could make some sort of difference.
OIC...well, after comment #3 and comment #4, I did try it, but it had no effect.
I've just managed to do some testing on my latest hardened CD. While I did not setup as much as you (limited vmware resources), I did setup an LVM2 container in a dossegmgr, at which point I then added 3 regions/volumes/file systems. After rebooting and running evms_activate, I encountered no problems, and everything appears to be working. I hope to make the next cd available some time this week, hopefully then that actually use evms/lvm2 (it took me ages to figure anything out) can test it. If someone wants to try before that, please let me know.
I'm going to have a new machine (a client's box) to setup in a couple of days. Though it won't be using evms, I'm hoping to have time to use it to try to reproduce the problem. No promises. :|
A day or two after my last post, this problem inexplicably disappeared, and I've been running this box with the setup described above for nearly a month. Yesterday, because a friend had Windows die on him and needed some important documents pulled off the drive, I put it in my machine (slave to the CD on IDE 2), and everything worked fine. After I finished, I shut the machine down and pulled that drive back out. I booted the machine again, and I get an error that the reiserfs superblock can't be found on my root partition. I tried booting the install CD again, and now I've also tried the latest Dolphin, and these device-mapper errors have returned. My box is now dead until I can figure out what's gone wrong. I haven't changed partitions or anything like that. Any advice?
Oddly, if I put my friend's drive back in, everything if fixed (including the device-mapper errors going away when booting from a livecd). Is there something that I have to do to inform EVMS that I'm taking a (non-EVMS) drive out once evms_activate has been run with it in? This is very strange.
Jeez...I'm sorry...I hit "Commit" by accident before actually *completing* my test. Booting from hard drive is fixed with my friend's drive back in, but livecd's still have the errors. I apologize for the confusion.
*** Bug 94330 has been marked as a duplicate of this bug. ***
I went back, deleted the existing partitions and then tried to create them all with evms. This still gave errors. I then booted with gentoo doevms nolvm and although I still get the errors sometimes the volumes get created and I have more options (like BBR segments) available. Where do I get a list of all the boot options - the F2 list sure doesn't cover them all.
Honestly, there isn't one. However, I'm making sure that there will be a file on 2005.1 that lists the various options. Currently, the only real way to find out is to dig both into the genkernel source, but also autoconfig init script from livecd-tools. We're actually expending the do* no* options a bit more, so we decided it would be best to list them all in a file, since there is only 80x25 to work with on the "F2" screen, which we will reserve for "troubleshooting" type options, rather than features.
Thanks. A file on the LiveCD will be very nice. I can understand not getting them all on the screen so as long as there is a place to find them. You might consider putting a note on the screen to see "filname.txt" on the LiveCD root directory for more options. Fortunately, this bug had a clue in it. Thanks.
So... is there any action that actually needs to be taken here?
By you? No. By me? Yes. Reassigning.
I happened to build a new machine a few days ago. With the 2005.0 CD, the problem still exists (this is a completely different machine, AMD instead of Intel, etc.). I tried a couple of other LiveCDs with with EVMS support (which are kindof hard to find, by the way), and they did not exhibit the problem. Just for kicks, I did something I hadn't done before because the machines were in production: I booted the 2005.0 CD and ran evms_activate on machines that were already up-and-running using EVMS, and the problem struck again. Using EVMS from CD: fail. Using newer EVMS packages compiled on the machines: success. Now back to the new machine I built: As I think I made clear, the problem only happens after booting a machine that already has EVMS setup and I run evms_activate (or any other evms tool with save). I went ahead and set up EVMS from the boot disk, got everything installed so I would have a working system upon reboot. If I then reboot from the CD and evms_activate, it fails. If I boot from the hard drive however (using packages I compiled/merged myself during installation), it works. I have no doubt left that there is a problem with the EVMS installation on the CD. Perhaps it's just a version thing and the bug will disappear with 2005.1. I hope.
(In reply to comment #20) >I have no doubt left that there is a problem with the EVMS installation on >the CD. Perhaps it's just a version thing and the bug will disappear with >2005.1. I hope. I don't think so;I had the same issue (even with the dolphin livecd),and I managed that booting the livecd with the "nolvm2" (not "nolvm") option.I have also tried the 2005.1 pre1 livecd,but quite apart from which option I choose ("doevms2","doevms","nolvm2") I can't find the evms tools.Where are they?. Sorry for my poor english.
Well...I don't think I've tried nolvm2, and I can see how that could be the source of the problem (I suppose it would trigger bd-claim). Unfortunately, I don't see having a chance to test it again in the near future. I know would probably be a job for upstream, but just out of curiosity: does anyone know if there is even a mechanism by which the lvm2 code could detect and say to itself "hey, these lvm2 containers are actually evms/lvm2 containers, so I'll leave them alone and leave them to evms to activate later"?
This should be resolved in 2005.1 as none of the volume-management is started by default in the initrd/initramfs.
