1

I have the following setup:

  • artix linux OS
  • linux-hardened kernel “6.1.24-hardened1-1-hardened”
  • encrypted root partition (no lvm)
  • unencrypted boot partition (GRUB installed)
  • device is a USB stick
  • no EFI partition, modules, hooks, etc.
  • mkinitcpio.conf HOOK order: base udev autodetect modconf kms block lvm2 encrypt keyboard keymap consolefont resume filesystems fsck

I have 2 machines with differing behavior when booting from this USB. Machine 1 boots normally with no issues. Machine 2 boots normally until the initramfs is loaded. When it gets to the encrypt hook it fails to find the encrypted root partition by UUID and gives up trying to decrypt after 10 seconds. This drops me into a rescue shell. In this shell, running blkid does not produce any information about the USB or its partitions whatsoever, including the boot partition it just booted from. It does provide the UUIDs and device mappings of machine 2’s internal HDD, however.

I figured this might have something to do with UEFI boot, so I went into the BIOS settings and made sure it was set to legacy boot. I confirmed in the BIOS boot menu that there was no option to UEFI boot to the USB.

I decided to see if GRUB itself had any issues with recognizing the root partition. I pressed c to enter the GRUB command line and entered ls and there is the root partition and boot partition of the USB, along with the internal HDD partitions.

Despite setting the log level to 999 in the grub config, there doesn’t seem to be any warnings or errors besides not being able to find the root partition. All of the aforementioned behavior is consistently reproducible and has no impact on machine 1's ability to boot to the USB normally.

3
  • So from what I gather your problem is not actually with the initramfs at all. Your one and only problem is that the Linux kernel cannot see the USB device. Which usually means missing drivers. Do you have all the required drivers built-in or on the initramfs?
    – Daniel B
    Commented Apr 29, 2023 at 17:52
  • @DanielB I'm not sure what you mean by "built-in" but I installed the kernel and modules using the artix installation guide wiki.artixlinux.org/Main/InstallationWithFullDiskEncryption. Specifically, I installed these packages: linux-hardened linux-hardened-headers lvm2 cryptsetup glibc mkinitcpio. So I would assume that they are not exclusive to the initramfs Commented Apr 29, 2023 at 18:57
  • Built-in means what it says: in the kernel binary, not as a module. Modules required to boot must be included in the initramfs. Maybe use some other live Linux and check what's necessary.
    – Daniel B
    Commented Apr 29, 2023 at 19:07

1 Answer 1

0

Machine 2 was able to successfully boot to the USB after performing the following steps:

  • remove autodetect from HOOKS in /etc/mkinitcpio.conf
  • run mkinitcpio -p linux-hardened
  • run update-grub

I came across this idea after reading the arch mkinitcpio page: https://wiki.archlinux.org/title/mkinitcpio#Build_hooks. The page mentions several quirks of the autodetect hook throughout, including the fact that “the autodetect hook is skipped during creation, thus including a full range of modules which supports most systems” when talking about the “fallback ramdisk image”. I didn’t think it would work but I decided to rebuild the image without autodetect and now machine 2 and 1 are both able to boot to the USB. To make sure this wasn’t just a fluke, I rebuilt the image with autodetect enabled as before, and once again only machine 2 could not properly boot to the USB. I disabled autodetect again, and once again it was working.

I am not entirely certain why this solved the issue. My guess is that @DanielB was correct about potentially missing drivers, and that perhaps autodetect was preventing the image from being built with the necessary drivers to properly interface with machine 2.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .