You are not logged in.
First: I do *not* want a detached header and unlock an encrypted system with a USB stick.
Unfortunately that's basically the only scenario that turns up when I try to search for help with my particular enterprise.
I am trying to set up a persistent system on a USB stick and have it use partition layout like this:
/dev/sda1
/boot
/dev/sda2
- $CRYPTO_TARGET
-- $VOLUME_GROUP
--- lv1 /root
--- ...sgdisk -n 1:0:200M $DEVICE
sgdisk -t 1:ef00 $DEVICE
sgdisk -n 2:201M:$ENDSECTOR $DEVICE
sgdisk -t 2:8e00 $DEVICE
cryptsetup -q luksFormat "${DEVICE}2"
cryptsetup -q open "${DEVICE}2" $CRYPTO_TARGET
pvcreate $CRYPTO_MAP
vgcreate $VOLUME_GROUP $CRYPTO_MAP
lvcreate -L 5G $VOLUME_GROUP -n root
lvcreate -l 100%FREE $VOLUME_GROUP -n stuff
mkfs.fat -F32 "${DEVICE}1"
mkfs.ext4 -FqO ^has_journal "/dev/${VOLUME_GROUP}/root"
mkfs.ext4 -FqO ^has_journal "/dev/${VOLUME_GROUP}/stuff"Doing this in a loopback device apparently worked fine and as expected. However, my current configuration on the USB stick "doesn't boot" - the bootloader never shows up.
Note: USB boot is properly configured in my firmware, works fine when I set up a drive without LUKS/LVM.
These are my mkinitcpio HOOKS:
HOOKS=(base udev keyboard keymap encrypt lvm2 block autodetect consolefont modconf filesystems fsck)and these are my kernel params in the syslinux.cfg:
"APPEND cryptdevice=UUID=XXXXX:${CRYPTO_TARGET} root=/dev/${VOLUME_GROUP}/root rw"I have no quotes around the UUID here, but I have seen people using quotes and I had the problem that (for a plain root-by-uuid config) quotes around the UUID seemed to be necessary.
In this case however no combination of quotes seemed to do the trick.
The UUID is the UUID of /dev/sda2 as by /dev/disk/by-uuid.
I have packages base, base-devel, linux, linux-firmware, lvm2 and syslinux installed when I tried to boot.
I guess (since the USB boot in general works fine) that there ought to be some way to get error messages when syslinux starts up (which it should ...?!) and sets up the kernel and initrd - however as far as I could observe so far, when there is something wrong with the kernel params or the initcpio, this all seems to fail quickly, silently and invisibly and the bootloader on my machines HDD is started.
So basically my question is - as there should be nothing wrong with the boot partition, I'm using the exact same setup for the working unencrypted device - how can I make syslinux talk to me about what fails here?
Obviously, if someone sees at a glance what I screwed up here I'd appreciate a comment to that effect too.
Last edited by Schmoho (2020-06-21 10:34:39)
Offline
If the boot loader never shows up, there's no need to diagnose kernel/initramfs issues (yet).
Is the installation for BIOS or UEFI? If BIOS, does your firmware support BIOS/GPT booting?
Did install the boot loader (not just its package)?
Are you trying to boot the disk in the mode (BIOS or UEFI) in which you installed the boot loader?
What exactly happens when "the bootloader never shows up"?
Offline
If the boot loader never shows up, there's no need to diagnose kernel/initramfs issues (yet).
Is the installation for BIOS or UEFI? If BIOS, does your firmware support BIOS/GPT booting?
It's for UEFI.
Did install the boot loader (not just its package)?
I did this:
cp -r /usr/lib/syslinux/efi64/* /boot/EFI/syslinux/
rm -rf /boot/EFI/boot
mv /boot/EFI/syslinux /boot/EFI/boot
mv /boot/EFI/boot/syslinux.efi /boot/EFI/boot/bootx64.efi
And set up the kernel params as mentioned.
Are you trying to boot the disk in the mode (BIOS or UEFI) in which you installed the boot loader?
Firmware is set to "UEFI first, Legacy after"
What exactly happens when "the bootloader never shows up"?
Nothing visible.
The bootloader of my HDD is started - which ranks lower in Firmware boot order.
Offline
If the firmware skips it then it doesn't consider it a valid entry to boot.
Does your firmware have a option to select a file to boot? If it does choose EFI/boot/bootx64.efi, it might tell you why it doesn't like that file. On the same note, are the ESP contents browsable from firmware?
Note: USB boot is properly configured in my firmware, works fine when I set up a drive without LUKS/LVM.
Was this setup also a syslinux UEFI installation? Does only the syslinux configuration differ?
Offline
I overread this note on syslinux installation:
The config file for UEFI is esp/EFI/syslinux/syslinux.cfg, not /boot/syslinux/syslinux.cfg. Files in /boot/syslinux/ are BIOS specific and not related to UEFI Syslinux.
So you were correct, apparently the other setup didn't use UEFI, unlike I intended and assumed it did.
My firmware interface does not provide any such capabilities and I wouldn't even know where to start to dig deeper into it.
Last edited by Schmoho (2020-06-21 16:54:12)
Offline
Since you're using the default/fallback boot path, your config should be /boot/EFI/boot/syslinux.cfg.
Syslinux's UEFI can be problematic. Try finding out if the issue is with syslinux or the firmware (or maybe the file system).
Rename bootx64.efi to syslinux.efi, copy a UEFI shell to /boot/EFI/boot/bootx64.efi and see if the shell starts. If it runs, try launching syslinux.efi and the kernel (vmlinuz-linux and specify the command line manually).
Last edited by nl6720 (2020-06-21 17:00:56)
Offline