allow config_distro_bootcmd to pass uuid to extlinux.conf
PATCH 1/1 allow config_distro_bootcmd to pass uuid to extlinux.conf
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.
---
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.
include/config_distro_bootcmd.h | 2 ++ include/config_distro_defaults.h | 4 ++++ 2 files changed, 6 insertions(+)
include/config_distro_bootcmd.h +2 -0
@@ -166,6 +166,8 @@"bootpart=1\0" \ \"boot_extlinux=" \ +"part uuid ${devtype} ${devnum}:${bootpart} ptuuid; " \ +"fsuuid ${devtype} ${devnum}:${bootpart} fsuuid; " \"sysboot ${devtype} ${devnum}:${bootpart} any " \"${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \ \
include/config_distro_defaults.h +4 -0
@@ -38,8 +38,10 @@#define CONFIG_CMD_EXT4 #define CONFIG_CMD_FAT #define CONFIG_CMD_FS_GENERIC +#define CONFIG_CMD_FS_UUID #define CONFIG_CMD_MII #define CONFIG_CMD_NET +#define CONFIG_CMD_PART #define CONFIG_CMD_PING #define CONFIG_CMD_PXE
@@ -53,4 +55,6 @@#define CONFIG_SUPPORT_RAW_INITRD #define CONFIG_SYS_HUSH_PARSER +#define CONFIG_PARTITION_UUIDS +#endif /* _CONFIG_CMD_DISTRO_DEFAULTS_H */
Signature · 1 line
2.1.3
PATCH 1/1 allow config_distro_bootcmd to pass uuid to extlinux.conf
Quoted 8 lines · Iain Paton
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...
Quoted 5 lines
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.
PATCH 1/1 allow config_distro_bootcmd to pass uuid to extlinux.conf
Quoted 5 lines · Stephen Warren
Quoted 4 lines · Iain Paton
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
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 5 lines
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?
PATCH 1/1 allow config_distro_bootcmd to pass uuid to extlinux.conf
Quoted 11 lines · Iain Paton
Quoted 10 lines · Stephen Warren
Quoted 8 lines · Iain Paton
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
... 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.
Quoted 3 lines
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.
Quoted 1 line
using extlinux.conf is one step, the patch is another.
I don't understand this part.
Quoted 4 lines
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.
Quoted 2 lines
Is the intention that
config_distro_bootcmdbe 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.
PATCH 1/1 allow config_distro_bootcmd to pass uuid to extlinux.conf
Hi,
Quoted 16 lines · Stephen Warren
Quoted 15 lines · Iain Paton
Quoted 13 lines · Stephen Warren
Quoted 8 lines · Iain Paton
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...
Quoted 5 lines
Quoted 2 lines
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.
I've to agree with Stephen here, both Debian and Fedora are already using the extlinux.conf support as it, it is not perfect, but the UUID stuff is not a problem.
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.Quoted 8 lines
Quoted 2 lines
... 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.
Quoted 5 lines
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.
Erm we (u-boot) already have support for using u-boot env variables in the "append" extlinux.conf statement.
I added this a while back to allow having:
append console=${console}
As different boards have different serial console names... (/dev/ttyS, /dev/ttyAMBA, etc.).
Quoted 9 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Ack.
Regards,
Hans