> Date: Sat, 20 Aug 2022 19:04:05 +0200 > From: Manuel Bouyer <bouyer%antioche.eu.org@localhost> > > On Sat, Aug 20, 2022 at 04:14:46PM +0000, Taylor R Campbell wrote: > > What is the specific problem you foresee? > > /boot can either be a directory or a file and upgrade tools will have to > deal with that (with the risk of ending up with an unbootable system if > things go wrong) A putative upgrade tool can simply refuse to continue if it finds the system in a state it doesn't understand, like having a legacy BIOS bootloader at /boot instead of /biosboot. If an upgrade tool will just blithely remove an existing file without understanding it, that's a much more severe problem. > To me it looks like easier and less error-prone to rename /boot to /efi > on these systems than change the purpose of exising /boot on x86. If you're volunteering to: 1. find a name that also makes sense for fdt (`/efi' is obviously wrong when it's not for efi boot!), 2. convince the arm/mips/riscv maintainers that it's worth the trouble, and 3. do all the work to (a) change the existing set lists, (b) update postinstall as needed, (c) fix image construction scripts and configuration files, (d) deal with other things like creds_msdos(8), (e) make sure all the boards that relied on /boot as the mount point still boot and run with all these changes, (f) test new installations, and whatever else might rely on /boot as a directory for more than just EFI as is, would you like to send an alternative proposal with a patch that does all these things? I proposed to move the x86 bootloader file to /biosboot because it didn't involve any of this trouble. I'm open to being convinced that changing all the other platforms is easier, but you have to show me to convince me -- from everything I'm aware of about x86 and non-x86 platforms, the change on x86 that I actually implemented looks a lot easier and less risky.