You are not logged in.
I was testing the install script on a VM, created encrypted BTRFS root with default volumes.
On boot, I am dropped into the emergency shell with the message "new_root: wrong fs type, bad option, bad superblock on dev/sda2" etc
The LUKS volume is unlocked and I can mount all its subvolumes manually, exit out of the shell and the systme will boot just fine.
My suspicion is that it tries to mount the BTRFS filesystem without subvolume=@ option.
Is the initramfs fstab supposed to be empty? Does it not know to use BTRFS?
Not a lot of information, but I believe it should be clear what's going on, if you want me to give more let me know.
EDIT: Using systemd-boot instead of Grub by the way. I'll try reinstalling with grub as well.
Last edited by Orionis (2023-05-05 00:15:29)
Offline
I was testing the install script
Do you mean archinstall?
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Yes, I did. Figured it would be interesting to see how well it worked nowadays.
By the way, it works with GRUB, it's the systemd-boot which doesn't work. I just ran through it on a new disk, same settings but with GRUB.
In theory it should not make a difference, right? The issue appears while in the initramfs with the volume already unlocked. So at that point the boot loader should no longer matter.
Last edited by Orionis (2023-05-04 23:01:00)
Offline
Mod note: moving to archinstall subforum.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Apologies, did not realize there was a subforum for it. And from the looks of it, I may have a duplicate issue as well. Let the abuse begin.
Offline
This was apparently a bug. Post-install the cmdline contains a double entry for the root volume. The first points to the unlocked and mapped BTRFS volume, the second one points to the LUKS volume. Like this:
cryptdevice=PARTUUID=0abcdef1-1234-1234-1234-1abcdef23456:luksdev root=/dev/mapper/luksdev zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs root=PARTUUID=0abcdef1-1234-1234-1234-1abcdef23456 zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs
The fix is the fhe following:
First, in the boot loader, press "e" on the default entry to edit your cmdline. Remove the duplicate. Using my example, the result would be:
cryptdevice=PARTUUID=0abcdef1-1234-1234-1234-1abcdef23456:luksdev root=/dev/mapper/luksdev zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs
Press enter and the system should boot normally.
Once booted, you will find the error in the boot loader entries, which can be found in /boot/loader/entries
Here you will see 2 files, for the default and fallback entries. Inside each are 2 lines starting with options, one starting with options cryptdevice and one with options root. Remove the second one.
Reboot. It should work now.
Offline