Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

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

wants to merge 3 commits into from

Conversation

hzyitc
Copy link
Member

@hzyitc hzyitc commented Apr 19, 2023

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

@hzyitc hzyitc requested a review from a team as a code owner April 19, 2023 18:07
@SteeManMI
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

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

@rpardini rpardini requested a review from amazingfate April 20, 2023 20:20
@rpardini
Copy link
Member

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

@hzyitc
Copy link
Member Author

hzyitc commented Apr 21, 2023

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
Copy link
Member

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
Copy link
Member Author

hzyitc commented Apr 21, 2023

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
Copy link
Contributor

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
Copy link
Member

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).

@hzyitc hzyitc mentioned this pull request Apr 21, 2023
Open
9 tasks
@rpardini
Copy link
Member

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:

@hzyitc
Copy link
Member Author

hzyitc commented Apr 22, 2023

Can we merge this first ?

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

@SteeManMI
Copy link
Contributor

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
Copy link
Member

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

@hzyitc hzyitc force-pushed the tweak-kernel-install-script branch 2 times, most recently from f9b30e4 to 4515f8a Compare May 4, 2023 05:46
hzyitc added 3 commits May 28, 2023 23:37
@hzyitc
Only remove the special uInitrd when remove kernel
1c9ec23 
`initrd.img-${version}` will be remove by command `update-initramfs -d -k "${version}"`,
so we don't need to care about it.
@hzyitc
Not to remove files under /boot when install kernel.
ad81c77 
`System.map-*`, `config-*` and `vmlinuz-*` will be removed by apt.
`$image_name` or `uImage` will be overrided by `postinst` script.

So we don't need to do any clean in here.

Revert "remove files in /boot at preinst when bootfs is vfat (#4886)"

This reverts commit 6c758e6.
@hzyitc
Copy instand of move the boot files for symbolic-unsupported /boot …
809b8cd 
…filesystem

Just for keeping them
@hzyitc hzyitc force-pushed the tweak-kernel-install-script branch from 4515f8a to 809b8cd Compare May 28, 2023 15:42
@igorpecovnik igorpecovnik added Help needed We need your involvement and removed 23.08 labels Nov 15, 2023
@ColorfulRhino
Copy link
Collaborator

🧹 PR Cleanup Quest 🧹

Is the issue that this PR tries to solve still present today? @hzyitc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@amazingfate amazingfate Awaiting requested review from amazingfate

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
Help needed We need your involvement
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@hzyitc @SteeManMI @rpardini @ColorfulRhino @igorpecovnik