
On 2022-10-12, Tom Rini wrote:
On Fri, Sep 02, 2022 at 01:06:16AM +0300, Andrey Skvortsov wrote:
If extlinux.conf is used, then it's not possible to customize boot environment, because scripts are not loaded. Usually it's possible to make some changes manually using command line and save boot environment. But if exlinux.conf is loaded from ext4 partition (for example on PinePhone), then environment are not saved/loaded at boot time from boot partition and it's not possible to persistently change boot environment without recompiling u-boot.
Signed-off-by: Andrey Skvortsov andrej.skvortzov@gmail.com
include/config_distro_bootcmd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index 5506f3168f..7f4ef960a1 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -477,8 +477,8 @@ "echo Scanning ${devtype} " \ "${devnum}:${distro_bootpart}...; " \ "for prefix in ${boot_prefixes}; do " \
"run scan_dev_for_extlinux; " \ "run scan_dev_for_scripts; " \
"done;" \ SCAN_DEV_FOR_EFI \ "\0" \"run scan_dev_for_extlinux; " \
Reworking the CC list a bit, I think this works against the intent. If the distro provides extlinux.conf, that's what should be used, and customized by the user (through normal distro methods), rather than looking for a boot script that might be out of date / etc. Can you please elaborate on what you're seeing and trying to do on the PinePhone?
With my Debian hat on, I would prefer to not change default behaviors; these have been present in this order for many years now. It is also not uncommon (for better or worse) for a Debian system to have both a boot script and an extlinux.conf, and possibly an EFI boot option, so this would be a significant behavior change...
There are definitely cases where the flexibility of a bootscript might be preferred, but in those cases, one should remove the extlinux.conf and the packaging hooks that generate it (e.g. u-boot-menu package on debian).
Alternately, adding another search for a bootscript at a different path before extlinux.conf is loaded *might* be worth considering, but not sure the extra complication and duplication is worth it...
Also curious on the status of "U-boot Standard Boot" https://u-boot.readthedocs.io/en/latest/develop/bootstd.html which might solve some of these problems?
live well, vagrant