About dracut and detached luks headers

[Screenager]

Hello,

does anybody have a valid setup for dracut and detached luks headers, without modifying dracuts source? It refuses to mount my LVM inside luks setup. I tried so many different rd.luks and crypttab variances, but none work. I even replicated: https://github.com/dracutdevs/dracut/issues/1778
It boots after I manually mount my luks container and then activate the volume group (just like in the workaround patches discussed in this bug)
What would be the best way to modify dracut without losing the changes if there will ever be an update to dracut in the repo?
I want to automate everything around the dist-kernel so I can update the system by just running emerge without breaking my boot process.

[alamahant]

Where is the header stored?
Plz post

[Screenager]

Header is stored next to my initramfs image and kernel on /boot

[alamahant]

Try this
I hope you have grub

[Hu]

[Screenager]

My reasons are: merciless unification of installation setups, I am not going to use a boot stick with detached headers on this device, but I will on others. It should not matter where the header is located, why support it if nobody is going to use it? Might even change the script and store headers remotely when traveling, so even if the entire travelbag get's stolen there is no header anywhere

Thank you alamahant, but it still does show the same behaviour: dracut drops to rescue shell -> openLuks -> lvm_scan -> vgchange -a y vg1 -> exit , and then it boots.

I'll guess I'll just add my own workaround as a user patch for now. I will do many more installs in the future and somewhere along this path I will figure out if it really is buggy or if it is just due to my user error. That was the main reason I asked if anybody has a working detached headers+dracut setup, cause then it would be obvious I am doing something wrong. I am still very noobish if it comes to bash scripting and the raw dracut code is certainly not easy to understand, would be easier for me if it was made in C

EDIT:
Because this thread is found searching for "dracut luks detached header" and I did some more digging, here is some information for the pour souls trying to do the same:

If you are not using systemd, just stop and fix the script yourself by either following https://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ and creating your own function call that will do what needs to be done or
modify your dracut source with this rejected pull request which will add rd.luks.header and rd.luks.header.disk parameters to work with.

[Screenager]

I found the bug!!! But I can't even fathom WTF is going wrong here, much less formulate a coherent bug report for that which I am about to show you:

So I went deep into the dracut source, wrote my own module and hooked it into dracuts initqueue. I then found out that it prints my prompt to enter somewhere right inbetween the dmesg lines. So I just enter my pw and voilà - it boots. So I refactored my module, added more checks, even started to use dracuts own ask_for_password functions - and what did I see - somewhere in the dmesg before it halted, it was now asking for the original prompt as defined in cryptroot-ask.sh - so it is working like it should the only problem is: it prints the input prompt somewhere where it should not:
https://i.imgur.com/xKf47Vh.png
It is important to note: This line is not logged to /var/log/dmesg according to the log that line never existed.
So dracut is somehow not putting the prompt into the right pipe... WTF is going on here... I propably need to join their mailing list at this point, but I am completly flabbergasted - how many times did I not see that prompt in the past weeks? How many of my tries where actually valid configs? Ahhhhhhh

[Hu]

This is entirely normal, and I'm not sure it even counts as a bug. I get behavior like this somewhat often, too. The problem is that the system console is a shared resource. It can be written to by the kernel and by any process running on the terminal. The flow is:

• Kernel gains control from bootloader, and begins initializing the system
• Kernel probes asynchronous hardware, like USB and mass storage
• Kernel starts your initramfs
• Initramfs prints the prompt
• Probes of asynchronous hardware complete, and the kernel prints the results of those probes, which necessarily appear later in the console than the prompt

The initramfs is still waiting for input at this point. You cannot see the initramfs prompt in /var/log/dmesg because that file is a snapshot of the output of dmesg. The initramfs did not write to the kernel's ring buffer; it wrote directly to your screen.

If this really bothers you, you might be able to fix it by setting the kernel to minimum verbosity before you request the password from the user, so that the slower asynchronous probes never print anything when they finish.

[Screenager]

Ahhh I see, so that is what is happening. I was under the impression I am already in a blocking bash shell... at least I could use non POSIX bash scripting...
Thank you! That workaround sounds like it should work on every machine. I guess it will also be no problem if using a plymouth splash screen. A little bit of sleep before invoking the prompt should be fine too, although the optimal amount will vary for each machine.
So I will fix this up, complete my own documentation and share a little bit more info about custom modules to the wiki.

[Screenager]

Sorry for the doubleposting, but it is done and works like a charm.
I documented the whole installation and how to do the custom dracut module here
I already decided to start over again, because I noticed so much stuff I could do better, so I won't update the wiki page any longer, but it seems like valuable information for anyone who wants to do dracut with detached headers so I decided to bump the thread and share.

[Hu]

Announcing additional progress is a good reason for a bump, so there is no need to apologize for the follow-up posting.