[PATCH] distro_bootcmd: Always check for custom boot scripts first

[Vagrant Cascadian]

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 at 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; "                      \
>> +			"run scan_dev_for_extlinux; "                     \
>>  		"done;"                                                   \
>>  		SCAN_DEV_FOR_EFI                                          \
>>  		"\0"                                                      \
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221012/c925daec/attachment.sig>