/etc/init.d/checkfs activates LVM and MD volumes, but doesn't care about EVMS. The evms init script is pretty useless for me because even when used in boot runlevel it is called too late, my volumes are not mounted (I have _everything_ on EVMS volumes). The functionality provided by /etc/init.d/evms should move into /etc/init.d/checkfs. I discovered this yesterday when I switched from devfs to udev. With devfs I mount the _same_ /dev twice, first in the initrd, where I also do evms_activate. Then, on the real root I can just mount /dev again with the evms nodes allready present. With udev, the /dev directory in the initrd is different than the one in the real root so I need to evms_activate in the initrd (to get the root volume) and then again as early as possible in the normal boot process to get the other local volumes. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Activate EVMS volumes from within the checkfs init script. Since EVMS can handle LVM and MD, it should be sufficient to call /sbin/evms_activate if present and skip the LVM and MD part alltogether.
Created attachment 31143 [details] This is how it could look like. Since I don't use LVM and MD, this needs some testing first.
sys-apps/baselayout-1.8.12 already contains support for evms in /etc/init.d/checkfs. when looking at the cvs header: # $Header: /home/cvsroot/gentoo-src/rc-scripts/init.d/checkfs,v 1.23 2003/03/24 15:25:05 azarah Exp $ i suppose you forgot to use etc-update and update pending configration files
Yep, you're right. Wasn't aware of it. However, there's still a chicken and egg problem when the system tries to fsck the root filesystem. Since checkroot is started before checkfs and my / is on an evms volume, checkroot fails on my system, because there is no node for it in /dev (which is udev managed).
Hmm, to solve that, I now invoke /sbin/evms_activate from checkroot also. This is possible because /dev is a ramdisk and can stay ro. What about moving the whole MD/LVM/EVMS stuff from checkfs to checkroot or even /sbin/rc (if I look at it, in function populate_udev, there is allready code to create dev nodes for devicemapper and LVM). This way, people with / on MD/LVM/EVMS would be able to get their root volumes checked also.
please review 1.11.4 and see if this is still not fixed
In 1.11.5 the only place I can find code to detect MD/LVM/EVMS volumes is still /etc/init.d/checkfs. This should IMHO be moved to either checkroot or to a separate script which is run before checkroot to catch the case that root is on a logical volume.
Created attachment 46322 [details, diff] Patch for /etc/init.d/checkroot to support EVMS root filesystem. This is a simple patch that I did to enable running a root filesystem on an EVMS volume (using an initrd that supports EVMS, of course). Patch is for /etc/init.d/checkroot (baselayout-1.9.4-r6)
Could somebody apply this patch to 1.11.x, please.
Created attachment 55554 [details] New checkroot for baselayout This is a edited checkroot that works. I propose this over the former patch because that does not allow evms to use a lock file. Please add this to baselayout asap as people using evms for / filesystems must have it to be able to boot!
Could this please be submitted? It is not a big thing and will helt gentooers with evms alot! :)
no, evms no longer is maintained in baselayout, it's been broken out into external files upgrade to baselayout-1.11.12-r1 and update this code to work with the addon volume code ... see raidtools/mdadm and /lib/rcscripts/addons/raid-start.sh for an example
*** Bug 93408 has been marked as a duplicate of this bug. ***
So all we need is a evms-start.sh with: # EVMS2 summport for /usr, /var .... if [[ -f /sbin/evms_activate ]] ; then ebegin "Activating EVMS2" evms_activate retval=$? eend ${retval} fi Installed with the package sys-fs/evms to /lib/rcscripts/addons/ .. or should that be evms2-start ? .. (this code was ripped out of the previous version of baselayout, I wonder who ripped it out without putting it back in somewhere..)
It looks that way to me, as well, but two things must be kept in mind: 1. "start_addon evms" (or evms2) needs to be at the beginning of *checkroot*, not checkfs or localmount (the only places where start_addon is used currently). Otherwise, it STILL won't support root-on-evms, which is the point of this bug; and 2. Since root may (and under normal circumstance is) mount read-only when checkroot starts, evms_activate will emit misleading warnings because it can't create its lockfile. To avoid this evms_activate's stderr should be redirected to /dev/null. Also, current LiveCD behavior (i.e. not activating volume managers) should probably be preserved (remember these packages get installed in CD images, too): if [ -z "${CDBOOT}" -a -f /sbin/evms_activate ]; then ebegin "Activating EVMS2" evms_activate &> /dev/null retval=$? eend ${retval} fi
Heh, removed wrong test, I was thinking we could actually do without the check for /sbin/evms_active because it would be installed with the package which provides it, and then it would be better if it failed a little bit more noisy than just sitting there quiet.. because then it would be something seriously wrong (like somone putting /sbin on a evms or deleting files "on their own").. Also, evms on root works fine aslong as you have an initrd image (or similar), which you would need anyways to be able to tell the kernel where root is? It works for me atleast..
Created attachment 59859 [details] evms-start.sh for sys-fs/evms/files
Created attachment 59860 [details, diff] Patch to sys-fs/evms/evms-2.5.2.ebuild Easily enough read, changes are so small so a manual merge might be best.. just adds installing the evms-start.sh script (and marks everything unstable because I havn't tested on any of those archs).
hm, do we really need CDBOOT check at all? I mean, those that make those livecds shouldn't be putting evms in RC_VOLUME_ORDER at all should they? If they have to have a standard /etc/conf.d/rc, evms could be taken out of the default configuration (and have in a comment above instead), baselayout doesn't even provide it so I don't think it would matter much? Just a thought..
good point, but baselayout *just* introduced that variable in the future we'll take that into consideration :)
(In reply to comment #15) > Heh, removed wrong test, I was thinking we could actually do without the check > for /sbin/evms_active because it would be installed with the package which > provides it Heh...guess you're right. Force of habit. :P > and then it would be better if it failed a little bit more noisy > than just sitting there quiet... The problem with that is that without the redirection, it will ALWAYS complain. Maybe something similar to 'evms_activate &| grep -v lockfile' (I forget the exact error message) is the solution. > Also, evms on root works fine aslong as you have an initrd image (or similar), > which you would need anyways to be able to tell the kernel where root is? It > works for me atleast.. No, that doesn't work so simply for me. The initrd is enough to get root mounted, but by the time the fsck in checkroot comes up, a new /dev has been put in place, so fsck can't find the root device node (/dev/evms/root is missing from *this* /dev). fsck errors if you don't put an evms_activate BEFORE checkroot's fsck (or unless you're using a RC_DEVICE_TARBALL (which you must have doctored to get it working in the first place), and even then it can still fail if you move any drives around because the majors/minors will change: see my bug #93408, and both of these threads from evms-devel: http://marc.theaimsgroup.com/?l=evms-devel&m=111662718822157&w=2 and http://marc.theaimsgroup.com/?l=evms-devel&m=111657581202304&w=2 ).
added evms-start.sh to evms-2
Just realized the problem :) (This wasn't the problem I was actually searching for.. but that seems to be fixed now so..). I'm guessing because of the age of this bug, that it isn't trival to fix or there is some reason to use the proposed solutions.. so a couple of solutions (I have not tested yet): 1. move start_volumes() from checkfs to checkroot 2. put start_volumes() in checkroot if fsck fails ("retry") 3. put start_volumes() as soon as /dev is available 4. make a alternative start_root_volume() which does exactly the same as start_volumes() except that it uses another variable and it is run from checkroot. To me nr 3. makes most sense, but there could be some unforseen sideeffects. 1. is more of a hack. 2. will make ugly error messages (maybe), but people not using evms won't notice.. 4. atleast is as logical as putting start_volumes() in checkfs .. Any comments? If I have missed something please point it out, but I think bug should be closed as soon possible in (~arch atleast) shouldn't be too hard?
Not really tested, but should be working: in /sbin/rc add the line: [ -x /sbin/evms_activate ] && /sbin/evms_activate &>/dev/null to udev_populate() function (about line 108). This is obviously code duplication of some sort.. maybe we should a initscript that runs before checkroot and checkfs that does the plugins.
What I explained at the bottom of comment #20, about needing evms_activate before the fsck in checkroot is still broken in baselayout-1.11.12-r4, which is now marked stable.
Just so summarise, EVMS on root is broken for systems using udev (devfs works, right?). Either a fix needs to be committed to unstable soon, or a notice needs to be added to the install guide about not using EVMS.
Mike added a start_volumes() to /sbin/rc as well ... I guess we will see how that works and what can of worms it opens.
Just a thought: Since users have to use an initrd anyway when having / on an EVMS volume, it seems best to me to check the root device from within initrd and avoid checkroot alltogether. Since my own initrd does it already I just gave it a try. I did it by removing checkroot from the depend() in some init scripts and putting a .critical file which doesn't list checkroot into /etc/runlevels/boot. So far this works fine for me.
You can't force users to do certain things in their initrd. Some of us use automatically generated initrd (splash users, for example) and some of us use official initrds (I myself use the official EVMS initrd). No, better to make the distribution work right than force people to build customized initrds.
This has been fixed in baselayout ... checkfs calls functions.sh/start_volumes, which starts all the subsystems in ${RC_VOLUME_ORDER}. When emvs is installed it makes a file in /lib/rcscripts/addons/evms and this calls evms_activate. No fuss, no muss. Anyway, someone should mark this bug as FIXED (I don't have update permissions on the bug)
Sigh; I had read the description but not all the comments. I guess the mug changed from no evms in checkfs (which is fixed) to evms being called too late if your root uses it (which still exists). Sorry for the bogus comment.
I'm using baselayout 1.12.0_pre6 now and populate_udev in /sbin/rc still only has code for activating LVM volumes. Could somebody please add this simple line [ -x /sbin/evms_activate ] && /sbin/evms_activate -q to that function, or put a start_volumes call into it, so that the bug can be closed. The problem also pops up on the gentoo-users and evms-devel mailing lists every now and then.
(In reply to comment #31) > I'm using baselayout 1.12.0_pre6 now and populate_udev in /sbin/rc still only > has code for activating LVM volumes. Could somebody please add this simple line > > [ -x /sbin/evms_activate ] && /sbin/evms_activate -q > > to that function, or put a start_volumes call into it, so that the bug can be > closed. > > The problem also pops up on the gentoo-users and evms-devel mailing > lists every now and then. Added to baselayout-1.12 svn.
instead of making the udev populate fatter with every additional filesystem thingy, why dont we move the start_volumes code out of checkfs and into rc ?
it is important that evms_activate get's called before the dm and lvm stuff in populate_udev, otherwise evms does not correctly populate the /dev/evms directory.
*** Bug 112948 has been marked as a duplicate of this bug. ***
Just add start_volumes in to /sbin/rc Just above bootlog start problem solved!
I agree with John and SpanKY that we should add a start_volumes call before "bootlog start" in /sbin/rc because: - It would remove a lot of duplication: we'd no longer have to have the start_volumes call in checkfs nor the dmsetup/vgscan/... stuff in populate_uev - It prevents /sbin/rc from having to be changed with each new filesystem remapper (comment 33) - It lets /sbin/rc follow $RC_VOLUME_ORDER, which can be important (comment 34) - It's the simplest and most flexible way. It requires no new code. (While I'm add it, I suppose I should ask for it to be included in currently stable baselayout too.)
we should make this change in 1.12.x i think ... less disruption for stable users
the next release of baselayout 1.12.x will start stuff in /sbin/rc file a new bug for any issues you may have
*** Bug 84242 has been marked as a duplicate of this bug. ***
I am ecstatic to report that this appears to be working correctly now with baselayout-1.11.14-r2, which recently stabilized. The architectural change you devs were discussing for 1.12.x don't appear to have been necessary for this particular issue, though I look forward to the other benefits.
*** Bug 120852 has been marked as a duplicate of this bug. ***
