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.
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.
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, using extlinux.conf is one step, the patch is another.
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.
Is the intention that config_distro_bootcmd be rigid and inflexible, only catering to a single way of doing things?