Make boot mount-point configurable #195
Conversation
On RaspiOS (and many derivatives) the boot mount-point is always /boot. However on Ubuntu (and Debian), it is /boot/firmware (/boot is still the target for kernel installation and initramfs generation, but flash-kernel then copies files from there to /boot/firmware). This patch changes references to /boot to $BOOT to make it easier to configure the boot mount-point. Please note that in the overlayfs routines, the location of the generated initramfs is deliberately left as /boot (as this is always correct even when the boot partition is *not* mounted there).
|
Not sure I follow how this is meant to work. It's still a hardcoded path that will get over-written any time the package is updated. Would something like Or is this just to simplify a patch for another distro? |
|
I'd be happy to update the patch to use a default, but yes you are correct that this is largely to ease patching raspi-config to run on Ubuntu (and potentially other variants relying on A bit of context: raspi-config got added (rather carelessly) to the Ubuntu archive back in impish (21.10) and, as it's looking at |
|
How about updating raspi-config to source something under /etc/defaults (if present) to set the default environment parameters (BOOT)? |
|
But yeah, if it makes things easier, I'm okay with merging it as is. We could use something like |
Ok. Btw, rpi-eeprom-update also needs to know where the BOOT mount is so that it can write recovery.bin to the write place. If there's a system wide setting for this then we can point rpi-eeprom-update at it as well. |
It's an interesting idea; off the top of my head we already patch
Indeed -- that task's been on my "would be nice if I ever had the time" list for ... too long! Unfortunately it appears others got impatient and just imported (As an example of potential for breakage, I discovered while working through it that the current overlay handling would render an Ubuntu system unbootable when disabling it. The function assumes that it can remove the
Thanks! |
| @@ -2611,21 +2612,21 @@ EOF | |||
| update-initramfs -c -k "$KERN" | |||
|
|
|||
| # rename it so we know it has overlay added | |||
| mv /boot/initrd.img-"$KERN" /boot/"$INITRD" | |||
| mv /boot/initrd.img-"$KERN" "$BOOT"/"$INITRD" | |||
There was a problem hiding this comment.
Sorry about the delay
I'm guessing the /boot on this particular line is expected because update-initramfs will always write to /boot?
There was a problem hiding this comment.
btw: When patching cmdline.txt (after init_resize) scripts should really check the overlay_prefix parameter from /proc/device-tree/chosen should be checked.
https://www.raspberrypi.com/documentation/computers/configuration.html#part4
Otherwise, it's possible that the wrong cmdline.txt will be patched
There was a problem hiding this comment.
check the overlay_prefix parameter from /proc/device-tree/chosen should be checked.
overlay_prefix or os_prefix?
Also, wouldn't the whole mechanism be broken on Pi OS, which assumes that /boot is THE place where everything is?
In either case, I think that one is for @spl237, since the overlayfs parts of raspi-config are his.
There was a problem hiding this comment.
OK, I've now spent ten minutes scratching my head about this...
What does the overlay_prefix parameter from /proc/device-tree (which is used for loading kernel overlays) have to do with patching cmdline.txt (which is used for adding a file system overlay)? Are those things not completely different, with the only common factor being the word "overlay"? Or am I missing something?
There was a problem hiding this comment.
Thanks! Now fixed.
I'm pretty sure it only breaks things. All the related packages install files to /boot and it's hardcoded all over the place (which is reasonable).
If things are instead in a subdirectory, nothing is going to work. The system should be set up to bind /boot to the appropriate subdirectory instead.
There was a problem hiding this comment.
Well, it is now in a global variable in raspi-config which is used instead of /boot/cmdline.txt throughout. So if it does break things, it's trivial to remove - just hard-code PREFIX to an empty string on line 24.
I've got no idea what this breaks or doesn't break - I just do what I'm told... ;)
There was a problem hiding this comment.
Had a chat with Tim and yeah, it breaks things, but not in the context os_prefix is expected to be used in. I'll move it to public and get this PR sorted when I've got a spare moment.
Thanks
|
I guess this can be closed, now that Bookworm has been released? (5dbaf53 seems to be the relevant commit) |
On RaspiOS (and many derivatives) the boot mount-point is always /boot.
However on Ubuntu (and Debian), it is /boot/firmware (/boot is still the
target for kernel installation and initramfs generation, but
flash-kernel then copies files from there to /boot/firmware). This patch
changes references to /boot to $BOOT to make it easier to configure the
boot mount-point.
Please note that in the overlayfs routines, the location of the
generated initramfs is deliberately left as /boot (as this is always
correct even when the boot partition is not mounted there).