[U-Boot] [PATCH] allow config_distro_bootcmd to pass uuid to extlinux.conf

[Stephen Warren <swarren@nvidia.com>]

On 12/14/2014 02:35 PM, Iain Paton wrote:
> On 14/12/14 17:22, Stephen Warren wrote:
>> On 12/14/2014 07:52 AM, Iain Paton wrote:
>>> Set ptuuid and fsuuid variables to the partition / filesystem
>>> where we found extlinux.conf which allows us to use a replaceable
>>> parameter in the append line in extlinux.conf like this
>>>
>>> append root=PARTUUID=${ptuuid}
>>>
>>> this means we never have to hardcode a root=/dev/mmcblk0p1 type path
>>> anywhere.
>>
>> Wouldn't the distro/... that creates extlinux.conf simply put the UUID
>> into the file when it's generated? That's how things normally work in
>> similar setups such as grub.conf...
> 
> Perhaps, but that's just another assumption. No less valid than mine, just
> different.

It's also consistent with all the other (generic distro) boot methods
that already exist e.g. for x86.

>>> Since the uuids are only looked for after we've already found extlinux.conf
>>> there's little cost/risk to making them available.
>>> I realise that assuming extlinux.conf is on the root partition isn't perfect
>>> but for the common case where it will be, there are many advantages to 
>>> this.
>>
>> ... and completely avoids the issue of U-Boot making assumptions about
>> the partition layout that the distro installer used.
> 
> Well making some information available hardly forces anyone to use it.
> 
> I'd like to be able to make use of some of the commands and information that
> are available and to do it in a way that's compatible with config_distro_bootcmd.
> Perhaps by expanding it's capabilities along the way, if that's acceptable.

However, it affects the definition of extlinux.conf, since it means that
variable references are expanded in the command-line parameter, which
changes the definition/syntax of extlinux.conf. This isn't something
that should happen via a patch to one bootloader, but by general
agreement to change the specification of extlinux.conf's format.

> Part of my motivation is to decouple the assumption that the user writable 
> UUID will never change on disk and make the system unbootable and difficult 
> to recover,

If the user changes the UUID, it seems perfectly reasonable to require
them to update any config files that mention this UUID, or rebuild their
extlinux.conf from scratch using whatever mechanism is normally used to
build it.

Again, this is entirely consistent with boot config files in grub, LILO, ...

Recovery from such a change seems very simple; just edit extlinux.conf
so it's correct.

> using extlinux.conf is one step, the patch is another.

I don't understand this part.

> Ideally I want to largely ignore the u-boot environment and just use 
> extlinux.conf, but without access to some of the discovered information 
> from the boot process I'm just moving a set of hard coded assumptions from 
> point A to point B. I may as well just use boot.scr in this case.

The primary advantage is that extlinux.conf is not a bootloader-specific
format, but will/does work across bootloaders. A secondary advantage is
that it's a simple text file that any distro can genrate without
requiring tools to create binary formats.

Any distro install script should be able to generate extlinux.conf just
like it could generate boot.scr. The benefit is alignment in concepts.
There was never an intent to remove the need to define the Linux kernel
command-line.

> Is the intention that config_distro_bootcmd be rigid and inflexible, only 
> catering to a single way of doing things?

The intention is to provide a single standard that works in a similar
way to existing boot methods (e.g. on x86) that distros are already
familiar with. Doing things differently from other boot methods breaks
the usefulness of it.