2

Goal

I'm trying to install Arch Linux, using systemd-boot, a plain & simple /boot partition, and a LUKS2-crypted / containing btrfs.

Problem

The system encounters a kernel panic during every boot. I believe some config to be at fault.

Config

Here are some config files:

/boot/loader/entries/arch-linux.conf

title Arch Linux :3
linux /vmlinuz-linux-lts
initrd /intel-ucode.img
options rd.luks.name=8870a85d-a205-4f7b-bac7-c8d3929a6df7=root root=/dev/mapper/root rw rd.luks.options=timeout=0,password-echo=no,tries=0

/etc/fstab

# Static information about the filesystems.
# See fstab(5) for details.

<file system> <dir> <type> <options> <dump> <pass>

/dev/mapper/root_map LABEL=edge-root-drive

UUID=7075b490-62e4-4c98-b43b-71bde7cbea25 / btrfs rw,relatime,space_cache=v2,subvol=/ 0 0

/dev/sda1

UUID=3B30-CA28 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2

Parts of /etc/mkinitcpio.conf

MODULES=()
BINARIES=()
FILES=()
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)
# Do I need lvm2? I'm using btrfs on one, crypted drive to boot
# HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt lvm2 filesystems fsck)

A /etc/crypttab that's basically empty

# Configuration for encrypted block devices.
# See crypttab(5) for details.

NOTE: Do not list your root (/) partition here, it must be set up

beforehand by the initramfs (/etc/mkinitcpio.conf).

<name> <device> <password> <options>

home UUID=b8ad5c18-f445-495d-9095-c9ec4f9d2f37 /etc/mypassword1

data1 /dev/sda3 /etc/mypassword2

data2 /dev/sda5 /etc/cryptfs.key

swap /dev/sdx4 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256

vol /dev/sdb7 none

What to do?

systemd-boot presents me with a bootloeader screen, but after choosing "Arch :3" I only get a black screen, followed by this:

A screenshot of Arch Linux trying to boot, but getting a kernel panic

Notice how I'm never even asked for a password.

Some stuff for search indexers (they can't read this image)

dev/root: Can't open blockdev
VFS: Cannot open root device "/dev/mapper/root" or unknown-block(0,0): error -6
Please append a correct "root=" boot option: here are the available partitions:
List of all bdev filesystems:
  fuseblk

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

What are the next steps here?

  • What do I need to do?
  • How can I gather more info to help me help people helping me debug this?
  • Do you thing something is wrong in mkinitcpio?
  • Do you think something is wrong in my systemd-boot entry?
  • What am I missing?

Thank you all so much for your help :3

Tanja
  • 138

1 Answers1

2

You've built an initramfs archive with mkinitcpio, but you've not specified that it should be loaded in your entries/arch.conf – it needs to be loaded as a second initrd option following the microcode archive. The usual path is /initramfs-linux.img (or "initramfs-linux-fallback" for the larger one with extra hardware driver modules).

(With the 'microcode' hook enabled, the generated initramfs can now be the sole initrd option as mkinitcpio now includes the necessary ucode in it.)

If an initramfs were present, the kernel would never try to mount the root filesystem device on its own and wouldn't say VFS: Cannot open root device as the initramfs contents are the initial in-memory "root filesystem". (Not only unlocking, but also mounting the specified root device and pivoting to it as the new '/' becomes the responsibility of the initramfs.)1

If the initramfs weren't able to unlock the new root device (e.g. due to missing modules or hooks), you would get either an error message from systemd or from the actual 'mount' command, and/or an emergency shell prompt, depending on what mkinitcpio included there.


1 (This was different with actual initrd, which would exit back to the kernel to continue boot, but I don't think any distributions have used a real initrd for decades now; for that matter I'm not sure if current kernels even support using one.)

grawity
  • 501,077