>>>       Anyway I think there's a simple method to live without the
>>> initramfs. Everything which is done from initramfs could be done the
>>> same way from a disk partition, which might make it easier to debug:
>>> have a /os directory containing all the necessary subdirs, /os/proc,
>>> /os/sys, /os/dev, /os/run /os/usr, /os/lib, /os/var, /os/home... , 
>>> mount
>>> the first five, create the few necessary files and symlinks and
>>> switch_root() to /os. This is exactly what your initramfs does.
>> Nope, that negates one of the principle reasons to use an initramfs in
>> the first place.  You assume the stock kernel can see the drive where
>> you intend to put this new partition; one of the big drivers of initrd
>> in the first place was exotic hardware, etc. so GRUB uses BIOS
>> (including extension ROMs on controller cards) to load both the kernel
>> and the initrd so it can take whatever steps are needed, i.e load the
>> right modules, start lvm, setup encrypted filesystem magic, etc. to make
>> the main drive/partitions/etc. visible.  Your idea could deal with most
>> everything that didn't need a kernel module but totally fails at that
>> task.

>     Now you've found another corner case:

>     "Grub doesn't know your hardware" AND " You refuse to use a 
> proposed workaround"

>     Everyone has to live with one's own contradictions :-) . And this 
> case has no relation with the /usr merge.

>     Didier