Bug 758173 – Vanilla install of Hardened on BtrFS in LUKS Failing.

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Diagon 2020-12-03 06:20:58 UTC]

I did a basically vanilla (*) install of gentoo hardened onto my thinkpad.  Since this is my first insall, I used genkernel, and since I'm using BtrFS in LUKS I ran:

genkernel --luks --btrfs all

(*) Only non-vanilla element is that I want to run a BtrFS RAID-1 in LUKS. The only way to do that is to open two LUKS disks at boot.  So, I employed this patch to genkernel: https://bugs.gentoo.org/694778

All appeared to go well so I continued with the install and hit an error:

   emerge --ask net-wireless/iw 
   <all went well> 

   emerge --ask net-wireless/wpa_supplicant 
   <...> 
   !!! Multiple package instances within a single package slot have been pulled into the dependency graph, resulting in a slot conflict: 

   dev-libs/openssl:0 
   <...> 
   It might be possible to solve this slot collision by applying the following changes: 
   - dev-libs/openssl-1.1.1g (Change USE: +bindist) 
   - net-wirelss/wpa_supplicant-2.9-r2 (Change USE: +bindist) 

Since I can do without wireless for the moment, and I wanted to get on with the project, I installed grub and rebooted.  The first problem I encountered was that the grub.cfg was completely fracked.  Note here the line-break:

   linux   /vmlinuz-5.4.72-gentoo-x86_64 root=/dev/mapper/luks.root
/dev/mapper/luks.root.copy ro

(FWIW, that first line plus the "ro" is how it looks on my Ubuntu install, but that uses systemd.)  I corresponded with the author of the patch and identified that it should actually be:

   linux   /vmlinuz-5.4.72-gentoo-x86_64 dobtrfs real_root=/dev/mapper/root crypt_roots=/dev/sda crypt_roots=/dev/sdc rootfstype=btrfs

I tried editing the grub menu to that on boot, and got to the point of being asked to put in my password for the first disk.  When I did, I got the following error (note the spaces):

   device-mapper: reload ioctl on <spaces> failed: No such file or directory"

Dropping into the initramfs and using `cryptsetup open` I get the same response, though `cryptsetup isLuks` responds appropriately.

The author of the patch tells me this is may be a kernel configuration issue, but is unlikely to be related to his patch.

I will attach the output of `emerge --info`.

Reproducible: Always

Steps to Reproduce:
1. Follow the wiki directions for doing the install of a hardened gentoo
2. Use genkernel --btrfs --luks all, with the genkernel patch (https://bugs.gentoo.org/694778)
3. Ignore the problem with wpa_supplicant
4. Install grub
5. Reboot, and edit grub menu as in the Description.
Actual Results:  
In the Description

Expected Results:  
A working system

[Comment 1 Diagon 2020-12-03 06:22:28 UTC]

Created attachment 676384 [details]
emerge --info output

[Comment 2 Jonas Stein 2020-12-03 17:07:32 UTC]

That sounds really bad and should be fixed. 
But the situation seems to be a bit more complicate and requires some analysis.
We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. 

In order to push things quickly forward I suggest the following.
I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3].
I hope you understand, if [e-mail] closes the bug here therefore and I wish you good luck on one of the mentioned channels [4].
Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product.

#gentoo is the right channel for you to start.

[1] https://www.gentoo.org/get-involved/irc-channels/
[2] https://forums.gentoo.org/
[3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html
[4] https://www.gentoo.org/support/

[Comment 3 Ben Kohler 2020-12-03 17:50:47 UTC]

Your emerge issues are due to skipping this step in the handbook: https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Updating_the_.40world_set

Your LVM issues are almost certainly due to kernel configuration problems.

If you think grub is creating a mangled config, open a report about that.

This kind of bug report with all sorts of miscellaneous issues, is hard to deal with.

[Comment 4 Diagon 2020-12-03 22:06:20 UTC]

Ben - Happily I have thorough notes, and it appears you are right.  I will try again, thank you.  I don't have LVM though.  I do have BtrFS in LUKS.

Jonas - Thanks for your input on resources, though:

I tried two email lists -user and -alt, and received no responses.  Indeed the former list is quiet and the latter seems totally dead :(  

I tried IRC, but got banned from Freenode!  Trying to post on the wireless issue was too big, I guess.  (Though my post was smaller than someone just prior... :(

Somehow it took until last night to find the Forum, which I was planning on trying next, but since I finally got movement on my bug in -alt, since some months, I thought to try here.

[Comment 5 Diagon 2020-12-04 06:45:18 UTC]

I was able to solve the wireless problem, thanks to Ben.

Rerunning everything from that point in the install procedure, `genkernel --btrfs --luks all` ends up creating an initramfs with many missing modules that the options should be including.  I am attaching a comparison of the `lsmod` output from the chroot'd environment and the modules included in the initramfs.  Also, my kernelconfig as genkernel created it.

[Comment 6 Diagon 2020-12-04 06:46:51 UTC]

Created attachment 676606 [details]
lsmod output compared to modules in genkernel's initramfs

[Comment 7 Diagon 2020-12-04 06:47:40 UTC]

Created attachment 676609 [details]
genkernel's generated kernelconfig

[Comment 8 Diagon 2020-12-04 06:49:38 UTC]

Created attachment 676612 [details]
emerge --info - new output

[Comment 9 Diagon 2020-12-05 21:46:47 UTC]

*** This bug has been marked as a duplicate of bug 758710 ***

[Comment 10 Diagon 2020-12-05 21:48:14 UTC]

As Jonas requested, I have broken out the genkernel issue into its own bug, and will deal with the grub issue in a separate one later.  I did not see how to close this, so I marked it as duplicate.