EVMS Boot-Problem

Binary package hint: evms

On my machine (Laptop with AMD Athlon64 Mobile 3000+ CPU, Seagate ST9160821A Harddisk and Samsung SN-S082D DVD-Writer) Booting with Ubuntu7.04 stops booting, because the
boot-device ist not found. The Problem does not occur, when i replace /usr/share/initramfs-tools with the folder from an older Ubuntu6.10 Installation and rebuild the initial ramdisks
(thiswas my first solution of this problem). 2 days ago, i found a solution for use without replacing the whole directory with the "dapper" Version:

The problem seems to be, that evms_activate does not find any EVMS-Volume, if it is called to early after loading the dm-mod and raid* Modules. The failed boot-sequence drops me to a shell (after a timeout of 180 seconds). In that shell, i notice, that there are no volumes in /dev/evms. After running /sbin/evms_activate (or running /scripts/local-top/evms) all EVMS-Volumes show up and leaving that shell resumes to the normal boot-sequence. When there is more time (a few seconds) between loading of device-mapper and raid modules and evms_activate, all volumes are found. 5 seconds seems to be enough on my machine (i don't know, if this value depends on my hardware or my EVMS-configuration), 3 seconds is not enough on my machine. I inserted a "sleep 5" command in the file /usr/share/initramfs-tools/scripts/local-top/evms before the last line of the script (which calls evms_activate) and booting works.On my machine, there are only EVMS-Volumes (no compatibility-Volumes), even the partition with the Windows XP-installation is an EVMS-Volume on my machine. The partitioning on my machine is currently as follows:

root@talaxia:~# fdisk -l /dev/evms/.nodes/hda

Disk /dev/evms/.nodes/hda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

               Device Boot Start End Blocks Id System
/dev/evms/.nodes/hda1 1 3985 32009481 7 HPFS/NTFS
/dev/evms/.nodes/hda2 3986 18196 114149857+ 5 Extended
/dev/evms/.nodes/hda5 3986 4110 1004031 83 Linux
/dev/evms/.nodes/hda6 4111 4298 1510078+ 82 Linux swap / Solaris
/dev/evms/.nodes/hda7 4299 4799 4024251 83 Linux
/dev/evms/.nodes/hda8 4800 6103 10474348+ 83 Linux
/dev/evms/.nodes/hda9 6104 8714 20972826 83 Linux
/dev/evms/.nodes/hda10 8715 10018 10474348+ 83 Linux
/dev/evms/.nodes/hda11 10019 11975 15719571 83 Linux
/dev/evms/.nodes/hda12 12629 18196 44724928+ 83 Linux

But the same problem existed also before creating the (temporarily used) Volume on /dev/evms/.nodes/hda12.

Even, if the "sleep 5" solves the problem for me, i don't know, if this value is enough for *every* installation with / on an EVMS-Volume ...
Maybe we should replace the single call to evms_activate with a loop:

for i in 1 2 3 4 5 6 7 8 9 10; do
    /sbin/evms_activate
    test -f $ROOT && break
    sleep 1
done

which (hopefully) tries to run evms_activate up to ten times until the root-device appears or 10 seconds are over (whichever is first reached), but i did not try it, because the "sleep 5" works for me ...

Btw.: There is an error-message while starting evms_activate (even if evms_activate seems to work correctly), because libgcc_s.so is not found: evms_activate is linked against libpthread, and threading with libpthread seems to need loading libgcc_s.so to initialize threading ... I would suggest to insert /lib/libgcc_s.so.1 in the initial ramdisk (to do this, only a "1 line path" to /usr/sbin/mkinitramfs is needed) to avoid this error-message (even, if this patch is not really necessary for a working system):

ilse@talaxia:~$ cat mkinitramfs.diff
198a199,201
> # /lib/libgcc_s.so.1 mit hineinnehmen, Juergen Ilse 21.04.2007
> ln -s /lib/libgcc_s.so.1 ${DESTDIR}/lib

I hope, this bugreport will help to avoid this kind of problems in the final release of feisty.