$summary The problem lies in that if the ramdisk contains /init the kernel tries to launch it using the ramdisk as root instead of root=/dev/whatever resulting in an message saying "Failed to execute /init" followed by the same message but with whatever you specified as init=. Genkernels problem is that append_auxilary adds /init whatever you do, and if there is no busybox in the ramdisk then there is nothing that can execute /init. The solution: If --no-busybox do not add /init to the ramdisk.
If you don't want busybox or /init in your initramfs, what's the point of building an initramfs?
The problem is that the ramdisk is broken with --no-busybox since the ramdisk anyway has a /init that can't be run without a /bin/sh. My goal was to see if I could with the help of genkernel generate a ramdisk with just the files to get uvesafb and fbsplash/fbcondecor working (which does not need /init). Using that together with --integrated-initramfs felt like something that could make my kernel-recompilations a one-liner. There are also other use-cases for a ramdisk without a /init including providing firmware for drivers.
And how exactly are all those things supposed to work without the /init script to set it all up?
I actually do not know. You may have to ask spock about that. But the default ramdisks for both uvesafb and fbcondecor/fbsplash contains no init. As far as I can tell they just provide files the kernel needs, but when the kernel can not find a /init on the ramdisk it will go ahead and mount root= and execute init=. This may be a dead end for me, but I still have to ask why you have the --no-busybox option makeing genkernel create a broken ramdisk.
I took a read in the documentation and as far as I can see uvesafb and fbcondecor only needs their helper applications and their data files to be present in te ramdisk, the rest takes the kernel part care of. The /init is only really needed if you want to be able to boot into your ramdisk (to have it to do things like detecting and setup your real_root). And in that case you have to have something like busybox that can execute your /init or you will end up with a kernel panic.
And where did you read that it works like this? I'd really like to see it. Right now, it sounds to me like you're saying "just install firefox in your / without anything else and the kernel will know what to do with it". The --no-busybox option has been in genkernel since long before the two current maintainers took over. Unless someone can give me a compelling reason to keep the option, I'm going to remove it at some point.
Did you really read what I wrote? uvesafb only works if it can find a /sbin/v86d in the initramfs, else it will not work since it needs that executable and nothing else. It does NOT need a init, since the uvesafb part knows what to do with it. Then there comes another part of the kernel which wants to mount your root. If that part of the kernel finds a /init in your ramdisk it assumes you want the ramdisk to init, setup and mount root and then do what it wants with it. If it does not find a /init in your ramdisk the kernel assumes "legacy mode" and mounts your root= and then launches /sbin/init if you have not specified a init=. The documentation in question about what fbcondecor and uvesafb needs you can find in /usr/src/linux/Documentation/fb/fbcondecor.txt and /usr/src/linux/Documentation/fb/uvesafb.txt Mentions nothing of a needed /init and their examples works nice without it. Really you should talk to Michal Januszewski <spock@gentoo.org> about this since he wrote those parts and knows how they work and can tell you better why they does not need anything more then their helper-applications. The other part about what the kernel assumes if it finds /init comes from experiments and /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Good reading in full. And I am sorry if I may come out a bit aggressive, but I did some research and *a lot* of testing, and pretty sure about these parts, and it feels like you do not listen. Or just do not even want to understand. And if you had read what I had wrote I think you would realise that what I am trying to say is more of: "Put v86d in /sbin in your ramdisk, and the uvesafb-part of the kernel will know what to do with it. But if you put a script called /init in your ramdisk without a shell to execute it, then the mount-root part of your kernel will not have a clue about what to do with it and panic."
You can if you have the time "emerge v86d && cat /usr/share/v86d/initramfs". That will list the only files uvesafb needs int he ramdisk. Just some directories, /sbin/v86d and some /dev/*. No init. If you emerge splashutils, creates a initramfs with splash_geninitramfs and unpacks it you will find /sbin/fbcondecor_helper, a symlink to that file called /sbin/splash_helper, /dev/* and the theme of your choice. No init.
I'll consider myself educated. I've broken apart the cryptsetup stuff into a separate append_luks() and made append_auxilary() dependent upon ${BUSYBOX}.
Was this ever fixed? I am going trough my list of bugs, and saw this one. Nowdays I use LVM and have to have busybox in my initramfs, so this is not something failing for me anymore. Maybe RESOLV LATER if nothing else?
Yes, I committed this last year and there have been multiple releases since then.
