Hi,
If I build my image based on Yocto Warrior based for example on meta-tegra. What would be the proper procedure to upgrade the system to Zeus hypothetically.
Update all the metas to zeus branches :
Build the new image (on condition of having it running on a device) and the .mender file to mender servers ?
Is that all or am I missing something ?
Best regards,
Hi @Austriker in theory that is all however sometimes there are changes in the Yocto branches that may require one time extra steps for the upgrade. For instance, the default partition layout changed several versions ago, resulting in different partition numbers being required on systems that had upgraded rather than being freshly provisioned. I’m unaware of any such issues with Warrior->Zeus but we don’t officially support it yet so it has not been looked at closely. Please let us know if you uncover anything.
Drew
Hi @drewmoseley, thank you for you answer. It is the case for Thud to Warrior apparently so we are working directly on warrior. The case where the partition layout changes how do we handle it. Do you need to reflash the device ?
Don’t worry, there are no partition layout changes between thud and warrior AFAIK. That was just an example from even earlier versions. It’s worth checking out the changelog between the two though. In particular, there is a section about “mender-migrate-configuration” that might be of interest. I don’t think it’s required to perform this upgrade step, but it’s definitely recommended.
And to add a bit more color, the change mentioned above was fixed by simply adjusting the partition numbers in the bitbake variables.
But, that said, we cannot guarantee that no matter what changes are made in the future with Yocto we can support them without extra efforts. We’ll have to take each case individually to figure out how to address it.
GPT partitions support labels for each partition. You can label them whatever you want. If update software, mount points, rootfs selection all use labels (they can!), then there is no longer any dependency on the precise number and order of partitions.
If something keeps breaking because partition order changes, there is a way to address this fragility with a less fragile system.
Can the bootloader identify partitions by labels?
Yes, both Barebot and U-Boot can parse GPT tables and identify a partition by label or by UUID.
The kernel can do the same. You can tell it what rootfs to use with root=PARTLABEL=rootA or also with root=PARTUUID=xxxx-xxxx-xxxx. However, barebox has a bootm.appendroot option that’s even better if you boot a kernel that is on the rootfs: it will automatically create a “root=” kernel option, using the partition UUID, to use as rootfs whatever device the kernel barebox is booting is on.
And once in Linux userspace, udev will create /dev/disk/by-partlabel/* and /dev/disk/by-partuuid/* with symlinks to device nodes.
So there’s really no need to ever care about what the exact dynamic partition and device enumeration will be, in the bootloader and in the kernel.