RFC: Introduce armbian-bootconfig

[hzyitc]

Description

Add a tool named armbian-bootconfig to manage the boot files.

If this is OK, I will update all bootscripts to support it.

The previous discussions are in #5076.

How Has This Been Tested?

• Build
• apt install linux-image-current-meson and reboot to current
• apt install linux-image-edge-meson and reboot to edge
• apt purge linux-image-edge-meson and reboot to current

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• ✕ Any dependent changes have been merged and published in downstream modules
  Need Common: Keep other version files under /boot when install kernel #5076

[rpardini]

Cool. I'm gonna copy&paste from other PR, for context.

---

I mentioned u-boot-menu because it is already similar enough to grub-mkconfig, and is actually written in bash.

Digging into u-boot-menu's source there's some interesting and sincerely quite familiar ideas:

• https://salsa.debian.org/debian/u-boot-menu/-/blob/debian/master/u-boot-update u-boot-update itself is 300 lines of shell
• Configfile https://salsa.debian.org/debian/u-boot-menu/-/blob/debian/master/default which can simply output info to
• Copying DTBs from canonical place to /boot: https://salsa.debian.org/debian/u-boot-menu/-/blob/debian/master/zz-sync-dtb (thus not requiring our kernel packages to do anything, we'd just "drop" the linux-dtb package)

---

Your implementation here is essentially making the kernel package drop a "note" (say, /boot/bootconfig-6.2.12-meson64) in a dir, then sort all notes by date and pickup up the most recent as a message to the bootscript.

I'd invert this, by templating the bootscript itself, not making it read yet-another file (we already have armbianEnv.txt). That's the same way u-boot-update creates extlinux.conf (extlinux.conf doesn't get any other external info).

[hzyitc]

Well, I think here are our sticking points:

Your options:

• A completely independent tool to scan the kernel files without hacking the linux-image-${version} package
• The tool should copy dtb from /usr/lib/linux-image-${version} to /boot/dtb-${version}
• Let the tool generate the entire bootscript

My options:

• Use some information provided from linux-image-${version}
• The /boot/dtb-${version} should be provided by linux-image-${version}
• Let bootscript read the configuration

---

For the first point, I think you are right.

The previous issue I cared is that different family have different kernel type (Image, zImage, uImage, bzImage, Image.gz) but named same (vmlinuz-${version}). To boot them, we need to use different u-boot commands (bootm, bootz, booti). So at lease we need to known their type.

But now, I think the file may distinguish them.

---

For the second point, here are my options:

/boot/dtb-${version} is necessary for boot and /boot/vmlinuz-${version} is also provided by linux-image-${version}. Both of them are put in same place and named similar. So why not let it be treated same?

What' more, leting it proivded by linux-image-${version} can let dpkg manage the files. It's easier for install/uninstall and dpkg --search to find out which package provide them.

---

For the third point, I think templating bootscript is difficult.

We have multi-version u-boot. Some of them are provided by vender, and we can't change them which cause some incompatible issues.

Writing the normal bootscript is easier than writing a template. For example, as what I said before, use button to choose kernel. And at the same time, provide the support of bootmenu command (Only for newer u-boot). How the template can be written?

And image another situation: user upgrade the kernel but it's failed to boot. We need to provide some methods to let he recover and boot into the system, even auto-fix.

[rpardini]

Yes, your understanding is excellent. Thank you.

/boot/dtb-${version} is necessary for boot and /boot/vmlinuz-${version} is also provided by linux-image-${version}. Both of them are put in same place and named similar. So why not let it be treated same?

Simply because Ubuntu/Debian themselves do not do this. Kernel PPA does not do this. No respectable .deb kernel packaging puts DTBs in /boot directly. That is a bootloader-related detail and should be handled by bootloader-related tooling, not the kernel package.

For the third point, I think templating bootscript is difficult.

Yeah, but actually what we have today are less than 30 bootscripts, while 3-6 of them represent 80%+ of all boards.

In this RFC we'd end up having to modify all bootscripts anyway (to read and use the values in the bootconfig file) so why not go all the way and instead template the whole thing with jinja2 ?

[hzyitc]

so why not go all the way and instead template the whole thing with jinja2 ?

You can think like that: the bootscript is the grub itself, and /boot/bootconfig is the /boot/grub.cfg.

The tool write the configuration into /boot/bootconfig (/boot/grub.cfg). Then the bootscript (grub) read from it and boot.

[SteeManMI]

A note about timing. I think the priority at this point in the release process for 20.05 is not to make invasive changes in this area. We need to get a release out on the new build framework first before we start making fundamental changes to the booting process across boards/families.
So I think this work needs to be targeted at 20.08.

[SteeManMI]

Much of the discussion has been around the bootscripts. I consider all of those "legacy" as there has been much discussion in the past about moving away from bootscriptss to extlinux and/or efi/grub. So I think we need to make sure we are looking at solutions that work for all the environments. I have a particular interest in the extlinux path as that is what the amlogic TV boxes that I support use. So to the extent I can, that is where I intend to contribute.

[igorpecovnik]

So I think this work needs to be targeted at 20.08.

I am also happy we are having a progress here, but from next week on we should move focus to stabilisation of existing code and close as many problems as possible. This still can move on if we have a consensus on how this should look like and where to draw a line - what is considered "legacy" and what should be driven by (u)EFI.

extlinux and/or efi/grub.

We need to sort out two critical mechanism:

• handling of overlays
• GRUB DT loading support

... perhaps something else?