Common: Keep other version files under /boot when install kernel

[hzyitc]

Description

When we try to install a new kernel. All files under /boot will be removed.

This PR will keep them until the special version kernel was removed.

How Has This Been Tested?

Need to be tested on other devices.

• Test A
• Test B

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

[SteeManMI]

Hopefully you have finally fixed the mv vs. cp issue. I've attempted to fix this before, but it seems to keep coming back:
PR4508
PR2697

[rpardini]

seems to keep coming back

Indeed. The whole thing is very fragile, even on ext4/symlinks. On fat32 this is even worse. This is due to the way we do "bootscripts" that expect a certain, fixed, filename, the "one true kernel/initrd/dtb" that will be booted.

We need to convene and start moving to generating bootscript/extlinux.conf/etc, something like u-boot-menu and align with EFI, then most of those whackjob postinsts go away.

[rpardini]

Seems to me this is mostly about #4886 so @amazingfate ?

[rpardini]

I also fixed #4886 in 994b80a -- but by then I confess I had no idea why it was being done to begin with.

[hzyitc]

We need to convene and start moving to generating bootscript/extlinux.conf/etc, something like u-boot-menu and align with EFI, then most of those whackjob postinsts go away.

Well, what I'm going to do is:

• Keep two version of boot files, named uInitrd and uInitrd.old
• Or create a source-able file to special every version boot files. source bootconfig -> KERNEL_NAME=uImage-6.2.0; source bootconfig.old -> KERNEL_NAME=uImage-6.1.0
• Add a meta package to point the truly kernel package, so we can install multi-version kernel. linux-image-edge-meson -> linux-image-6.2-edge-meson

But I have no idea about how to let use choose menu. There is no keyboard, instand we only have button. What it can do is just, unpressed -> normal boot; pressed -> boot old kernel

[rpardini]

how to let use choose menu

It's not about being able to choose, instead, not having hardcoded uImage or vmlinuz or whatever in bootscript or extlinux. Example: see grub and what update-grub (grub-mkconfig in disguise) does.

[hzyitc]

how to let use choose menu

It's not about being able to choose, instead, not having hardcoded uImage or vmlinuz or whatever in bootscript or extlinux. Example: see grub and what update-grub (grub-mkconfig in disguise) does.

If I remember correctly, grub also code vmlinuz in grub.cfg. It same as what I said and what we do in armbianEnv.txt.

Create a file named /boot/bootconfig, and contain some auto-generated config:

# Auto-generated
KERNEL_PATH=vmlinuz-6.1.0
INITRD_PATH=uInitrf-6.1.0
DTB_PATH=dtb-6.1.0

Then in bootscript:

load ${devtype} ${devnum} ${addr} bootconfig
env import -t ${addr} ${filesize}

load ${devtype} ${devnum} ${kernel_addr} ${KERNEL_PATH}
load ${devtype} ${devnum} ${initrd_addr} ${INITRD_PATH}
load ${devtype} ${devnum} ${dtb_addr} ${DTB_PATH}/${device_dtb_name}

[SteeManMI]

IMO there are two basic steps to this:
First is allowing multiple kernels to be installed/updated/removed without conflicts (which is what the recent PRs are all about)
Second is figuring out how to choose which kernel to boot.

Given our mix of u-boot scripts, extlinux, efi, grub across the various boards/architectures there won't be one solution to the "how to choose which kernel to boot" problem, as each boot method varies in how it does this. However we shouldn't build a dozen different solutions either. We need to standardize this as much as possible, then integrate with the booting mechanisms.

At the heart of the issue here IMO is what is the future of armbianEnv.txt? There is a lot of functionality that this provides (besides various boot parameters, the whole overlay mechanism is tied to this currently). But armbianEnv.txt in it's current form is really incompatible with extlinux, and likely efi/grub as it was designed for the u-boot script world. I think we are trying to move away from customized u-boot scripts to more modern booting methods so how do we continue to support the functionality provided by armbianEnv.ext while moving to modern boot methods?

In my limited thinking about the problem, we need a 'tool' like update-grub/extlinux-update that understands armbianEnv.txt (or some replacement) and merges that information into the format that the various boot methods understand (extlinux.conf, boot.scr, etc)

[rpardini]

If I remember correctly, grub also code vmlinuz in grub.cfg

Nope, here's how it does it: https://sources.debian.org/src/grub2/2.06-3~deb11u5/util/grub.d/10_linux.in/

Create a file named /boot/bootconfig, and contain some auto-generated config:

So you don't have to tell GRUB mkconfig which kernel to boot. It has its own internal logic, run in userspace, to select against which kernel/initrd/dtb it will run against.

The part about the dtb is important here, it conflicts with what Armbian's linux-dtb currently produces (grub wants a file there and Armbian linux-dtb puts a directory with the same name).

[rpardini]

the whole overlay mechanism is tied to this currently

Yes, the (many) families that use overlay "fixups" (which are actually fragments of bootscripts) are tied to bootscripts. I've the intention of getting rid of those completely (by templating the overlay and outputting pre-fixed-up dtbos). There's a whole bag of pending work on overlays before we can dream of any non-bootscript capability.

At the heart of the issue here IMO is what is the future of armbianEnv.txt?

You nailed it. armbianEnv.txt could still be the "source of truth", but then be processed into 3/4 different outputs. One for bootscript, one for extlinux, one for efi.

In my limited thinking about the problem, we need a 'tool' like update-grub/extlinux-update

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)

[hzyitc]

Can we merge this first ?

The bootconfig can be discussed more. But this issue break the multi-version kernel for FAT filesystem.

[SteeManMI]

I agree that this can be merged now while the full solution is being designed. However 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.

[rpardini]

Let's get an RC out first. If these initiatives prove to fix more than they break, we can move faster, otherwise, 23.08.