Bugzilla Bug 50711

/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 an attachment (id=31143) [edit]
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 an attachment (id=46322) [edit]
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 an attachment (id=55554) [edit]
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 an attachment (id=59859) [edit]
evms-start.sh for sys-fs/evms/files

Created an attachment (id=59860) [edit]
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. ***