sakaki- / buildkernel Goto Github PK

Hi again: This involves the chromebook signed FIT kernel images (and a few chromebook bootloader unknowns and possible tie-ins with dm-verity) as well as non-chromebook arm64 using UEFI blobs (as arm64 devices can have multiple bootloader options).

BUT, for now I'm mainly looking for an obvious way to short-circuit the luks/EFI settings/checks in buildkernel (which I couldn't really find). I did see the two DISABLE options but there isn't any explicit ARCH support yet. so I was wondering what you might suggest as an approach for now?

At this point I'd just like to test your kernel/initramfs approach as a signed FIT image on arm64 in a semi-automated fashion (note there are also plenty of x86_64 chromebooks this could work on, but I only have arm/arm64 chromebook hardware). I have a (forked) set of chromebook builder scripts but they're stand-alone and not distro-specific and have nothing to do with genkernel/anything, but at least in this context they can be used to make a bootable sdcard/usb-stick for starting the gnome install...

If i didn't mention it yet, the gnome install parts worked great on arm64 chromeobook, so the thinkpad now has a little brother named kevin ;)

sys-apps/debianutils recently moved installkernel to an external ebuild (2 actually, but I have not tried sys-kernel/installkernel-systemd-boot because I use OpenRC) behind the installkernel USE flag. Without this package installed, the make install at https://github.com/sakaki-/buildkernel/blob/master/buildkernel#L1953 uses the default install script which does not include the version in the resulting filenames. This results in a failure in check_if_enough_disk_space_for_backups

dm-integrity is a ZFS-like feature that can be used together with
buildkernel + LUKS + LVM + ext4
I think dm-integrity should be enabled in buildkernel by default and added to
Sakaki's EFI Install Guide
See also https://security.stackexchange.com/questions/190670/luks2-dm-integrity

Hi Sakaki, thanks for your continued support of this tool.

Is it possible to mount more than a volume at boot time with the same key (or with a different one, though as they would both be on the same USB key, it wouldn't really bring much to do so) without having to copy the key somewhere on the machine?
I have looked around and saw some tips about /etc/fstab and /etc/crypttab but no cmdline options to do that. How would one get around to that?
Specifically I am thinking of moving /home to a separate disk.

Use case: when using a EFI bootloader (for example reFind) it is not required nor advisable to change the efi boot parameters. I made a small, perhaps not very efficient change:

50,51d49
< DEFAULTCREATEEFIBOOT=1
< CREATEEFIBOOT="${DEFAULTCREATEEFIBOOT}"
1391,1395c1389
<     if	((CREATEEFIBOOT==1)); then
<     		declare -i NEWBOOTENTRYNEEDED=1
< 	else
< 		declare -i NEWBOOTENTRYNEEDED=0
<     fi
---
>     declare -i NEWBOOTENTRYNEEDED=1

Hello,

First of all, thank you Sakaki for your tutorials.

does buildkernel support distcc?
I've been trying to run pump buildkernel but to no avail after noticing this page:

https://github.com/sakaki-/gentoo-on-b3/wiki/Set-Up-Your-B3-as-a-distcc-Client

Now you have everything set up, using distributed cross-compilation from your B3 is really easy. In fact, the (installed) scripts genup and buildkernel-b3 will automatically make use of it 

or is that feature only available for buildkernel-b3?

As it stands, the configuration for buildkernel is completely oriented toward devices that use GPT disks. This is fine (mostly), but it's caused issues for me as I use a USB key as a boot device, but also wish to use it as a data drive. Unfortunately, Windows doesn't seem to support GPT USB disks with EFI system partitions on them (as it seems to cause some weird funkiness where it tries to treat it as a single-partition disk but chooses the ESP as the partition it shows). As such, I can't use a disk with a proper EFI system partition and a separate data partition.

My solution to this is to initialize the disk as an MBR disk, create a FAT32 partition on it, and simply place the EFI directory/files/keyfile on it. It's not perfect (there's no separate partition where the boot stuff is stored separately), but it works enough for me to use the drive as both a boot key and a data drive. My EFI seems to accept these disks (and I've found most EFI implementations are fairly forgiving of MBR boot disks)

However, in order to do this with buildkernel, I've gone in and implemented a kludge. Since MBR disks have no partition UUID, you can't provide one for buildkernel to use. As a workaround, I changed PARTUUIDDEVDIR to point to /dev/disk/by-uuid/ rather than /dev/disk/by-partuuid. This uses the filesystem UUID, which both the LUKS partition and the boot key have. I also disable the lowercase fixing for the boot partition, as FAT32 UUIDs are uppercase.

Would it be possible to have more formal support for filesystem UUIDs? This kludge is a bit of an annoyance to go in and add and I also feel it would be useful for others in a similar situation.

I just found out binutils-config has dropped the --linker flag completely (even though the man page says otherwise). The result is now I have broken genkernel/buildkernel on pretty much everything :(

Sorry, if the "issue" isn't clear, if the system is already built with default-gold then buildkernel just errors out with:

# buildkernel --verbose --clean --unmount-at-end
* Updating old config using make olddefconfig
scripts/kconfig/conf  --olddefconfig Kconfig
scripts/Kconfig.include:43:  gold linker 'ld' not supported
make[1]: *** [scripts/kconfig/Makefile:75: olddefconfig] Error 1
make: *** [Makefile:568: olddefconfig] Error 2

* buildkernel: Error: Caught signal - exiting

Did you have any plans to address this in buildkernel? If not, I could use some suggestions...

Recently set_kernel_config "CMDLINE" "\"${KERNEL_CMD_LINE}\"" (https://github.com/sakaki-/buildkernel/blob/master/buildkernel#L1671) started causing the following error:

* Setting kernel command line = 'root=/dev/ram0 crypt_root=/dev/disk/by-partuuid/9e5664ef-8698-46dd-8553-8faac7d3ad62 dolvm real_root=/dev/mapper/vg1-root rootfstype=btrfs
btrfs
btrfs real_init=/lib/systemd/systemd real_resume=/dev/mapper/vg1-swap keymap=us quiet splash udev.log-priority=3 root_trim=yes elevator=bfq kvm_intel.nested=1'...
sed: -e expression #1, char 216: unterminated `s' command

For some reason "\"${KERNEL_CMD_LINE}\"" caused insertion of newlines, that render the sed expression invalid.

I am not sure why the issue started occurring now and not previously.

I found out that having vfat compiled in as a module breaks the automated booting (automated mount failed, 'mount -t vfat PARTUUID=etcetc' on ramdisk commandline worked), the script should either force compiling into kernel or perhaps load the module/give extended mount command before trying to mount the USB key.

Alright, this is maybe not a buildkernel issue, since it looks like it may happen in genkernel, but have you seen this before? I get this in the last steps of buildkernel.

*         >> Finalizing cpio...

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...
* add "dolvm" for lvm support
grep: : No such file or directory

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
* 
* Make sure you have the latest ~arch genkernel before reporting bugs.
* Unpacking initramfs cpio archive to /boot/initramfs...
1191583 blocks
* Copying static gpg program into initramfs...
* Copying contents of /etc/modprobe.d directory into initramfs...
* Deleting old initramfs cpio archive, and repacking...
1195539 blocks
* Building linux-4.19.86-gentoo (pass 2, to include real initramfs)...
  DESCEND  objtool

my buildkernel version:

# ~$> eix buildkernel
[I] sys-kernel/buildkernel [1]
     Available versions:  (~)1.0.34^m{tbz2} (~)1.0.35^m{tbz2} {+plymouth}
     Installed versions:  1.0.35^m{tbz2}(22:47:45 24/12/19)(-plymouth)
     Homepage:            https://github.com/sakaki-/buildkernel
     Description:         Build secure boot EFI kernel with LUKS, LVM and plymouth

[1] "sakaki-tools" /usr/local/portage/sakaki-tools

In case both buildkernel.conf and genkernel.conf set the same variable (e.g. ADDITIONALKERNELCMDS) the one in genkernel.conf takes precedence and the one in buildkernel.conf will be silently ignored. So I wonder, why in the first place encourage users to configure these variables in buildkernel.conf and not in genkernel.conf?

i.e. man buildkernel.conf says

          ADDITIONALKERNELCMDS
                 If you wish to pass any additional command line parameters in the kernel boot line (either for attention of the kernel itself, or  for  genkernel(8)'s
                 init(8) script), you can specify them here. All of the important values for booting will be set by buildkernel, so this defaults to an empty string if
                 not set.

                 One parameter you may wish to consider here is "root_trim=yes"; this will enable TRIM support on the encrypted LUKS partition (turned off by default).

This would be useful for some custom kernel configs.
I will probably write a PR for this

As the title says, buildkernel hardcodes some commandline options to genkernel that are better left as options to the user. These are specifically --firmware and --all-ramdisk-modules. The first is especially egregious when there is limited disk space to work with in /boot.

I'm testing a patch for this right now and will submit a PR if successful.

Just a heads up: I am now getting this message upon updating my system with buildkernel installed:

!!! The following installed packages are masked:
- sys-kernel/genkernel-next-69::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Andreas K. Hüttel <[email protected]> (2020-07-11)
# Fails to build with recent glibc, bug 719968
# Removal in 30 days

First thanks for creating this script and the guide!

As far as I see the buildkernel script builds the kernel in the LINUXDIR="/usr/src/linux" directory, which in case of newer devices is often located on a SSD. It would be nice to allow the user to optionally specify a builddirectory to which the contents of /usr/src/linux are then copied and in which the compilation is subsequently performed.

This would allow to specify a directory on a tmpfs and thereby to work around unnecessary stressing of the SSD.

So, I use buildkernel as part of your EFI guide, as I'm sure many others do.

I was looking to enable early microcode updates for my system in order to patch it for recent CPU vulnerabilities. The usual way of doing this is one of three methods:

1. Load the microcode archive before initrd from bootloader (not applicable; EFI stub)
2. Append the initrd to the microcode archive (buildkernel doesn't support this, as it builds and appends it internally)
3. Include the microcode binaries directly in the kernel via CONFIG_EXTRA_FIRMWARE.

I'm currently including it in the kernel via method 3 in buildkernel.conf.

user_conform_config_file() {
    FW=$(ls -xw0 /lib/firmware/intel-ucode/ | sed -r 's/([^ ]+)\s*/intel-ucode\/\1 /g')
    set_kernel_config "EXTRA_FIRMWARE" "\"${FW}\""
}

This will stick the contents of the intel-ucode directory into the list of firmware in the kernel. This works, but it's a bit clunky considering gentoo offers the ability for intel-ucode to produce a cpio archive at /lib/firmware/microcode.cpio that includes the microcode for you. If buildkernel could pick this up and create the appropriate conjoined image, that would be nice. Alternatively, including the support for AMD and Intel microcode updates in buildkernel would be good in general in light of CPU-level issues like this.

I've been following your guide on the gentoo wiki on secure book, and found this tool.

I ran into an issue with the script where whenever the system booted up with plymouth it would immediately crash out due to an error from lvmetad. It seems the kernel is trying to grab the lvm disks before they are decrypted. After quite a bit of digging through the various problems, I have come to find that the issue exists in the script.

On my laptop the simplest fix is omitting the dolvm flag from the kernel parameters, and it magicall fixes it. I'd submit a PR for the fix but if someone could repro this first that'd be handy.

Thanks a lot for the guide by the way, it's actually easier to follow than the official handbook.

Hi,

I am not sure if this doesn't break anything else, but I needed to remove "--all-ramdisk-modules" from the genkernel parameters, or else, I would run into an issue via cpio.

See here for reference:
https://forums.gentoo.org/viewtopic-t-1068036-start-0.html

Thanks,
sege

Bug: https://bugs.gentoo.org/625462

Description

As of systemd-234-r2, /usr/lib/systemd/systemd is a symlink to /lib/systemd/systemd; As a consequence, the SYSTEMD_INIT variable in buildkernel:59 should be adjusted accordingly.

Note

It looks like starting with systemd-235 the symlinks implemented in sys-apps/systemd-234-r2 will be deprecated.

This won't work for nvme device nodes (i.e. /dev/nvme0n1p1): https://github.com/sakaki-/buildkernel/blob/master/buildkernel#L1396

I installed Gentoo on my laptop following your guide (great work!) and ever since used genup/buildkernel for kernel updates. This worked fine for kernel version < 4.10.

Every version newer than that hangs at boot. The screen just stays blank where the EFI kernel used to take over and I don't see any output nor a password prompt to decrypt the hard drive.

At that point I decided to wait for the stable update and hoped for this problem to be fixed by then.
Unfortunately it isn't.

Are you aware of anything that changed with kernel 4.10? A new option set (or not set) by default that renders my kernel unbootable?
Do I have to change something in the config files manually? I don't even know where to look for information on this problem, since I don't have any dmesg output or something similar.

My kernel .config looks like this.

Thanks a lot for your work anyways! ;)