No output visible from initramd using EFI boot

[msst]

I try to achieve since hours now an initramfs disk that allows me to mount a Luks-crypt root. But I am running into a problem with the EFI boot system and debugging the initramdisk.

What I have here is a gentoo system that boots stable from the EFI bios using EFIstup. I can directly point the efibootmgr to the linux kernel, give the correct linux command line with -u (root and rootfstype) and all works. Boots lightning fast any normal root. I set that up a while ago and it was a pain in the a** to set up, but after it was done it worked forever.

Now if I want to boot a crypted root and therefore I need an initramfs that mounts the root in userspace - I read all the scattered documentation and managed indeed to get an initramfs to work! I build it directly into the kernel with the new initramfs source file feature from the kernel. And if I just let that thing mount my normal unencrypted rootfs it kind of works. Just that there is no output at all. I have the init script from the initramfs print status messages such as "mounting root fs...success" but nothing ever shows.

In fact this seems to be connected to the framebuffer thingy from EFI. I have EFI framebuffer enabled (necessary to see anything from the early boot!) and see the kernel coming up right to the moment where it hands over to the initramfs. Then nothing appears on the screen for a short time, and bang the framebuffer from the normal boot / init process kicks in and I see the normal bootcripts running from my now mounted root. I have tried putting in a delay (sleep 10) into the initramfs and then it takes 10 seconds longer but I only start seeing the output from the normal boot process.

Somehow that initramfs is unable to do any output and that prevents me from debugging it quite effectively.

Has anyone done such a thing (self made initramfs on an EFI system using framebuffers) already? Any idea what is going wrong here exactly and what to do now?

[s4e8]

you need a graphics console:

CONFIG_EARLY_PRINTK_EFI=y
CONFIG_FB_EFI=y
CONFIG_FRAMEBUFFER_CONSOLE=y

[khayyam]

s4e8 ... printk is the kernel print function ... much like printf() ... its not required to print to the console (though of course a console is useful ;). In the above list then probably only CONFIG_FRAMEBUFFER_CONSOLE=y is required, if the OP has a framebuffer (ie, inteldrmfb) then CONFIG_FB_EFI isn't needed.

@mas- ... in your init are you creating a /dev/console? ... ie:

[s4e8]

Yes, you are right, that's a safe list. earlyprintk only needed if kernel hang before hardware initialization. FB_EFI is very small, it's better try it first. Real DRM framebuffer is good but maybe buggy, eg: firmware blob or backlight problem.

[tclover]

Did you, by any chance, read dm-crypt LUKS article on the wiki? There are usefull guidances there along with (untested) init script (& build script.)
(Just wrote them down as a minimal tool without any actual testing.) (Yes, I am one of the contributors of the article.)

You do need console node. So, another approach is to include it directly in your initramfs (to not waste time on useless checking.)
Apart from that, checking the fd (for std{out,in,err} won't hurt. (Noticed that an `exec 0<$STDIN 1>$STDOUT (2>&1)' may be necessary.)
And you should _not_ have uvesafb enabled as builtin. (This is a source for trouble for sure.) Lastly, ponder which fb to enable for early boot (efi for you.) And then, modprobe drm kernel driver, if any, later to avoid possible issue. (The kernel config menu are a bit... too confusing for my taste. I've just kept asking to myself which one to use. And then efifb was the right spot because almost all drm stuff is build as module, here, to be able to switch to various drivers (proprietary blobs included) _seamlessly_.)

Or else, follow that better-initramfs link or my sig. to get a functional one (that you don't need compressed... for kernel EFI stub. Available on both directions.) I do prefer mkinitrafs-ll for obvious reasons (not because I am the author but for... really great flexibilitiy and modularity: let the user do whatever (is) needed/wanted.)
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/

[msst]

Wow, lots of helpful comments - thanks. I will go work them one by one.

[msst]

[tclover]

You seem to be using btrfs-root init script and related files. There isn't any `/dev/console' in the files included in the initramfs. You do attach a file listing many devices; and you're saying the console node is created indirectly by mounting devtmpfs on `/dev'. That's slightly a different thing. You _should_ have `/dev/console' in files included in the initramfs. Period. What get mounted on `/dev' is a different story.

This might be the solution of your problem.

(So, you're using BTRFS on LUKS? Lucky you... there is support for that in mkinitramfs-ll.) Good luck.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/

[khayyam]

[msst]

[tclover]

[msst]

Thanks again, you were right, that it was also not the drm modules.

But I did learn that compiling the grafic card driver, drm and drm_kms_helper into the kernel and not using modules there does help - it makes the FB_EFI obsolete and gives a much nicer EFI console view. So I removed FB_EFI now.

And thanks to your help I think I got what the problem was now. I added this

[khayyam]

[tclover]

[tclover]

[msst]

[tclover]

[khayyam]

[tclover]

[khayyam]

[tclover]

[khayyam]

[tclover]

[khayyam]

[tclover]