- This topic has 0 replies, 1 voice, and was last updated Oct 6-11:31 am by amidfour.
October 6, 2019 at 11:31 am #27784Memberamidfour
Hello to all. I’m new to antiX, but I have a few decades experience with Linux. I’ve been trying all sorts of interesting things with antiX 17 & 19b3 in the past few weeks. And…
I think there’s a bug in the 19b3 live-usb-maker’s encrypted USB creation and how it interoperates with the 19b3 bootup scripts with live encrypted USB devices.
Debian buster added support for LUKSv2 (and argon2i/id), so unless ‘–type luks1’ is given to cryptsetup, it’ll go with luks2.
I successfully can make encrypted 19b3 sticks using live-usb-maker from MX and from AntiX 17 using the 19b3 iso. They boot fine.
If I then use THAT 19b3 system to do a live-usb-maker to make another stick, it fails to boot. If I pick a custom install, encrypted, with a leading data partition, and choose to pick keys at boot time, it boots, but it’ll error out and say it can’t read the encrypted partition. For some reason, I couldn’t get the encrypted full featured option to boot at all, but haven’t really isolated that one, could have been bad luck.
I don’t really know the specifics of the antiX live/encrypted boot process yet (I’ll get there eventually, most likely), so I fixed it with a hammer:
I added ‘–type luks1’ to every instance of ‘cryptsetup luksFormat’ & ‘cryptsetup open’ in /usr/local/bin/live-usb-maker. And the resulting stick booted just fine.
I’ve also noticed some intermittantly-odd behavior with live USBs in 19b3, including some that just won’t save BIOS settings while some will. Guessing there are still a few “live-usb-maker meets 19b3 boot” wrinkles to iron out. And I’m guessing most have to do with cryptsetup/etc changes with LUKSv2.
Will try to isolate more as I get time.
I’ll keep trying to learn more about how antiX is put together, have a ton of things to figure out still. I’m trying to do it do do something a little non-traditional with it (basically, using encrypted live+toram to boot a KVM hypervisor that’s largely amnesiac/ephemeral, mostly loading the VM disk images out of ‘tomb’ archives hosted on non-bootable LUKS drives in the laptop). I’ll explain a little more in another post if anybody’s interested, it’s like Qubes gone horribly wrong.
- This topic was modified 2 months ago by amidfour.
- You must be logged in to reply to this topic.