Persistent changes to /boot/extlinux/extlinux.conf? We are not supposed to edit the file directly, since updates may over write the customization of the file. Had that happen once or twice now.
Documentation says file is generated by u-boot-update, fine… but how do I use u-boot-update, without wiping out any customization to /boot/extlinux/extlinux.conf? There must be some other file we can customize, so u-boot-update adds customization to the generated file /boot/extlinux/extlinux.conf.
Well, /etc/default/u-boot file is empty, so going to be a trick to figure this out.
/boot/extlinux/extlinux.conf is generated by /usr/sbin/u-boot-update.
Yes… but changing /etc/default/u-boot, so that u-boot-update adds changes to /boot/extlinux/extinux.conf appears to be failing, broken or ignoring /etc/default/u-boot. So… per the documentation of how u-boot-update should work is not working based on all the testing I have been doing. This effectively means there is no way to customize the u-boot configuration that will not be destroyed by any future update/package that calls u-boot-update.
What do you want to change on /boot/extlinux/extlinux? You can list them and I’ll see how to do the corresponding operations on our system.
Now that is not the point is it? If you customize /etc/default/u-boot, those changes ‘should be’ honored. And from what I have experienced, that is not the case. So it that something RADXA has broken? changed? If so, please explain how and why that was done.
I want explicitly to use the features of u-boot as designed and expected to work. I have other devices that use u-boot and support u-boot customization via /etc/default/u-boot and u-boot-update correctly, per the u-boot documentation.
But for the sake of your question, here are some of the settings I want to change to the kernel parameters:
Add…
ipv6.disable=1 fsck.mode=force fsck.repair=yes
Remove…
quiet splash
You cannot replicate all of these completely or consistently via other methods other than kernel parameters. There are others which are dtoverlay specific which I want to ‘selective’ enable or disable at boot via the u-boot menu options I will explicitly create in the /etc/default/u-boot file, which I will use, at the time of boot… which I will only know I want… at that time of boot, for example.
Bottom line if something is breaking u-boot flexibility of configuration such that u-boot-update does not honor /etc/default/u-boot, how about we move the conversation to that point… and resolve that issue, before we band-aid anything, or come up with some odd-ball work arounds. I am sure, many others would like the u-boot support to be fixed versus ad-hoc work arounds, no?
This is the default content of /etc/default/u-boot: https://salsa.debian.org/debian/u-boot-menu/-/blob/debian/master/etc/default/u-boot?ref_type=heads
We override a few default values here: https://github.com/radxa-pkg/radxa-system-config/blob/main/radxa-system-config-common/usr/share/u-boot-menu/conf.d/radxa.conf
If you want to change the kernel parameter you can edit /etc/kernel/cmdline.
Thanks! Will give this a shot. So, is it that /etc/default/u-boot is just not applicable to RADXA devices in general, given the OS customization? Just asking for clarification. Meaning, when I did try to make changes to u-boot, via the documentation, /etc/default/u-boot should augment, what u-boot-update generates. If anyone else trips over this, this topic would let them know why, is my thinking.
For example if I set U_BOOT_TIMEOUT="100" then run u-boot-update, per the u-boot documentation, the timeout should now be 100… but on RADXA Zero 3E and 3W, running the Debian XFCE B6 image, on reboot, the timeout is still ‘10’. And when I look at /etc/extlinux/extlinux.conf… timeout is in fact ‘10’ of course.
In point of fact, it just so happened or happens, U_BOOT_TIMEOUT is overridden by the RAXDA customization. So then the question is, why is RADXA overriding this? And why /etc/default/u-boot does not override what RADXA did in override. Looks to me, like it is an order of precedence. The /etc/default/u-boot customization is not honored when RADXA customization is present, which leads back to why did RADXA choose to override anything not explicitly hardware dependent? I don’t know.
The issue I see with /etc/kernel/cmdline… is that I cannot customize the various boot options that u-boot supports per u-boot menu option, say I want to remove entries in u-boot? In my specific use case, I never want ‘quiet’ and ‘splash’ to be enabled only the main kernel load menu items only, and I always want ipv6.disable=1 to be true only on the recovery menu items. So if I change /etc/kernel/cmdline, that is fine for the default. But not per kernel version? Or customize u-boot in a more detailed or complex manor.
I added to /etc/kernel/cmdline…
ipv6.disable=1 fsck.mode=force fsck.repair=yes
Rebooted… ipv6 was not disabled, fsck did not execute.
# cat /etc/kernel/cmdline
console=ttyFIQ0,1500000n8 quiet splash loglevel=4 rw earlycon consoleblank=0 console=tty1 coherent_pool=2M irqchip.gicv3_pseudo_nmi=0 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 ipv6.disable=1 fsck.mode=force fsck.repair=yes
# cat /proc/cmdline
root=UUID=e4dc7fb3-d6e7-4a53-8267-0b5688ac4ff3 console=ttyFIQ0,1500000n8 quiet splash loglevel=4 rw earlycon consoleblank=0 console=tty1 coherent_pool=2M irqchip.gicv3_pseudo_nmi=0 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
If I add the above directly to /boot/extlinux/extlinux.conf, to the kernel parameters for the default option selected, i.e. 10, not only is ipv6 disabled, but fsck runs as expected.
# cat /proc/cmdline
root=UUID=e4dc7fb3-d6e7-4a53-8267-0b5688ac4ff3 console=ttyFIQ0,1500000n8 quiet splash loglevel=4 rw earlycon consoleblank=0 console=tty1 coherent_pool=2M irqchip.gicv3_pseudo_nmi=0 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 ipv6.disable=1 fsck.mode=force fsck.repair=yes
So… it looks like /etc/kernel/cmdline is not honored as well! Did I miss something? Any suggestions?
It helps if u-boot-update is executed after /etc/kernel/cmdline is changed!
Yes that’s the key. u-boot-update is THE command to update the boot configuration on our system. We copied this behavior from systemd-boot, which also reads /etc/kernel/cmdline, and requires a bootctl update to apply the change.
I don’t yet see how I can isolate ‘recovery’ append list from the ‘main’ append list per kernel version. But that is not critical to my use case.