-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make boot mount-point configurable #195
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I mean os_prefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Now fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).