by summers » Sun Aug 21, 2016 10:20 am
@hfrjkse
What happens is that there are two levels, uboot, and kernel. Now each of those independently needs to know where the boot files, and root file system, is.
Now if you check the enviroment variables set up in typical modern uboot, you see it is set up to effcency scan all partitions it can find (typicaly on usb, sd*, and on these embedded board flash memory). Uboot then loads the uEnv.txt file, kernel, initramfs, device tree - all from where it finds a viable file system.
Uboot then tries to boot linux, it passes a command line to linux, that sets up thing like the console output, and where the root file system is. Now problem with the root file system, is two fold. 1) root may not be where the boot files are, and historically on linux these where often sepearte partitions (when lilo could only access the start of HDD). 2) the kernel has many an varied ways of identifying the root file system, labels, UUID, PARTUUID, device.
So as these two are so different, uboot boot directory, and kernel root fs, is why they get set up separately.
As to can PARTUUID (and UUID) change - we'll not easlly - thats the idea. So when you have a file system on a device, you have a unique way of identifying the file system. Now this doesn't say its impossible, I think if you do a byte my byte copy of the entire disk then you would copy the PARTUUID and UUID. (e.g. think "dd if=/dev/sda of=/dev/sdb" - and commands like that, obviously changing sda and sdb to be approriate drives).
So how modern uboot is set up, by reading uEnv.txt from the boot directory, gives a chance to set up each file system you boot from, so it defines its own root.
So say you set up a rescue USB memory stick, with the right file structure on it. Now having created this on a 3rd computer, you can then idenifty the PARTUUID of the nominal root filesystem, then add that information to uEnv.txt. Now the beauty of the system, when you unplug to USB, and move it to the target machine, the PARTUUID don't change.
Then that the target system uboot, scans filesystems, means it can find the USB, read the uEnv.txt, and know where that boot partition wants its root fs to be.
So actually the current system, is actually very flexable.
Guess if I have a hassle with the current system, is using the PARTUUID to identify the root. Problem is that PARTUUID isn't really used elsewhere, and not all commands work everywhere (e.g. blkid) - so it looses out by not being well known.