Raspberry Pi OS • Re: Disk Encryption since Bookworm

I've taken a cursory look at those two sdm links. I don't see anything there which strikes me as a show-stopper regards LVM.

LOL. I wouldn't expect there to be any showstoppers for using LVM. I have a few questions on the rest of your post (see below). I don't think it would be too terribly difficult to implement LVM (as I remember it...haven't used it since my XenSource days).

My intention was to write a QT GUI app to do the conversion after the fact. This would require either (a) two spare partitions or (b) another empty device upon which to create two partitions from which you'd subsequently boot. I can't see me having the time to do that. However, that GUI app (at least initially) would have done little more than generate shell script to execute. If nspawn (I've never used it) can wake up LVM and generate an initramfs then it could be done directly.

GUI apps are definitely nice, especially for dinking around with partitions and partition sizes, but they do require (a lot?) more work than a cmd line.

That said, the process that sdm implements to encrypt the root partition a) is outside of sdm's use of nspawn, and b) automatic with no human intervention required except during initramfs where the actual conversion is done, and I have doubts about whether the initramfs environment is a hospitable environment for real GUI software, but that may just be me!

LVM has the notion of a physical volume (PV). It has a notion of a volume group (VG). It has a notion of a logical volume (LV). Documentation almost always is impenetrable. Dunno why. In essence one creates a PV on an empty partition. Then you assign (one or more PV's) to a VG. Once you've got a VG, you create one or more LV's within it - which are then formatted like usual. LVM uses names (under /dev/mapper) and once activated, will look after itself, largely transparent to the operating system. Thus if I create a 32G LV called "rootfs" and format it ext4, copy the rpi OS into it, I can adjust "root=" in cmdline.txt to use the /dev/mapper/ name (ditto /etc/fstab) it will boot. The problem, previous to bookworm, was any kernel update would render the system unbootable - the only way to avoid this was to manually check, before reboot, if there had been a kernel update and type the relevant initramfs commands.

If this is an issue, the only way that this would be viable as a somewhat general solution IMHO is if smartening up initramfs could 100% eliminate any manual intervention on a kernel update. While I learned a bunch about initramfs doing this, I didn't venture into whether some initramfs triggers could be implemented to run code on an initramfs regeneration to avoid borking the system.

I should now be in a position to confirm if rpi bookworm solves this. I am not (time constraints again). I'm assuming it does from the /boot/firmware/ rearrangement and would be surprised if it does not now work. Add into the mix, GPT disk support, there's much flexibility to be gained - live runtime snapshots and moving disks while the operating system is running.

If you look into it at all and have any questions I might be able to help with, LMK.

Wrt to /bin/sh, I had to deal with that issue back when people were dumb enough to employ me! I had to support unix (Aix/BSD) plus SuSE and Redhat. Add into the mix multiple versions across almost a decade, the only sane(*) way forward was to use /bin/sh because each had their own default shell. Moreover, some would change shell when you became root - and not all /bin/sh are equal (being restricted versions of their real shell). You can see hints of that in https://github.com/swampdawg/go/blob/master/f_var (another thing I haven't had time to finish). Essentially, everything has to be a global variable. The main "user" script will source a library (like f_go) which in turn source the above f_var. The rule was any function in that library had to be prefixed with "f_" and any variable with "F_". Then add on the name of the script itself, hence F_VAR_* and F_GO_*. I'd always argued from the outset that as SuSE/Redhat (and other linux we came to support) used 'bash' and that it was available to Aix/BSD then bash was the way to go. Almost no-one from the BSD world was interested so that left Aix which has two versions of 'ksh', the default version of which created a new file in /tmp for every subshell. eg:

Code:

X=$(command)

..yields a /tmp/ for each $(command). It would take minutes to run the initial 'configure' for gcc whereas bash would take seconds.

(*) For some definition of pointy haired boss.

You'll note from https://github.com/swampdawg/go it specifically says 'bash'. It's had the (potentially) proprietary stuff ripped out and first thing I did was require bash. 'dash' wasn't about back then although I've never had a problem in that regard - and the above link isn't something I'm likely to respond to for support requests. It does, however, form the basis of how I build QT so I will update it at some point in the future. Although it requires bash now (yeah local variables!) I've not changed anything I haven't had to thus, should you need to stick with /bin/sh, feel free to liberate what you want. Some if it harks back to redhat 4.x!

Thx. Not sure what your go stuff does, but I had no problems simply stuffing bash into the initramfs while it was being used for the encryption conversion, and then removing it once done. No muss, no fuss.

#!/bin/bashSUB="/usr/local/sd/syschk/lib". "$SUB/f_tmp"fcp_main (){ localt locali f_tmp_add t=`f_tmp_top` echo "A tmpfile.. $t" f_tmp_add echo "Another tempfile.. "$(f_tmp_top) f_tmp_rem read i f_tmp_rem}fcp_main "$@"

Statistics: Posted by swampdog — Tue Jan 30, 2024 5:08 pm