The new version of EVMS (2.0.0 and greater) now runs in "user-land" much like the original Linux LVM and RAID solutions. As such it is necessary to include support for "activating" the EVMS2 volumes in /etc/init.d/checkfs (as there is such support for LVM-Classic and RAID w/ raidtools). The /etc/init.d/evms script is completely useless due to the fact that the init system runs localmount to mount all local file systems before it runs most of the scripts so it becomes a major problem if you are running /var or /usr inside EVMS volumes. With the /etc/init.d/evms script (even if the dependencies are adjusted) /var and /usr are not available in time for localmount to mount them. I will attach a small patch for /etc/init.d/checkfs that "fixes" this problem. I simply replicated the LVM portions of checkfs for EVMS2. It should not cause any problems with EVMS-1 installs or with people with no EVMS support. Note: I have checked with the EVMS developers and they say that the lock file which is created by evms_activate (/var/lock/evms_engine) is not used once the system is running (after evms_activate closes) so it is not a problem if "/var" is mounted later from an EVMS volume. evms_activate versions 2.1.0 and greater will not fail if the log or lock files cannot be created and version 2.0.1 will just create a /var/lock folder for the log on the mounted root filesystem.
Created attachment 14241 [details, diff] /etc/init.d/checkfs Patch for EVMS2 support
Created attachment 14242 [details, diff] /etc/init.d/checkfs Patch for EVMS2 support
Comment on attachment 14242 [details, diff] /etc/init.d/checkfs Patch for EVMS2 support duplicate
I can confirm that his patch is working fine. If its going to be applied, just fix the "EVMS22" typo, and the one space identation of the if and that's it. BTW, I would change the bug's severity as critical, as a box with evms2 cannot boot with this patch.
Never write patches at 4 in the morning.. you always end up entering something wrong. I didn't want to list it as critical as EVMS2 is still very beta in the gentoo kernels, but I agree it is a bit of a pain to have a machine that can't boot. I also think it may be wise to move evms2 into a seperate "SLOT" like gtk+-1.2 and gtk+-2.x. One machine I have keeps trying to update to evms-2.x even though I am using 1.x on that box... This is not something that should just update without at least a warning.. it could leave peoples machines in a very sad state. Just my thinking though.
Is it evms_activate or evms_deactivate that is depricated ?
evms_deactivate... Understandable since once evms loads the volumes it shuts off. EVMS it is now basically a userland utility that configures the device manager/software raid system/logical volume manager. These are all seperatly maintained kernel systems. EVMS was (until 1.8 iirc) completely kernel-based with it's "own" RAID system, LVM system, etc. All evms_deactivate would do is force their removal them from the device manager. This is usefuly when developing EVMS, but has no other purpose.
*** Bug 24933 has been marked as a duplicate of this bug. ***
Added to CVS, thanks.
