Update Issue When /dev/sda Is Variable


Depending on if I have a usb inserted my hard disk can be either at /dev/sda or /dev/sdb. When making mender-convert artifacts you must specify the exact location, my update needs to work for several different USFFCs so I cannot use a specific partuuid.

I assumed it would be easiest to use /dev/disk/by-path/ as this will be consistent across multiple devices - indeed this works for installing the original image, however as the links are not resolved when trying to perform an update I get an error saying “Active root partition matches neither RootfsPartA nor RootfsPartB”.

I feel sure I am missing something obvious - and something as simple as having a usb present at boot isn’t enough to dismantle all the efforts of Mender??

Please let me know if you have any solutions to this issue,

Hi @jemzp, welcome to Mender hub.

I have not investigated the /dev/disk/by-path mechanism with Mender and I have not heard of anyone doing so. It doesn’t surprise me there are issues with it. I suspect we would gladly take pull requests to enable that if it is possible to do so.

That said, I don’t understand why you cannot use the PARTUUID support. The PARTUUID values only need to be unique within a system so reusing them across multiple hardware platforms should not be an issue.


Like as @drewmoseley states, this is the reason why I use PARTUUID’s so as to abstract away from underlying disk technologies like usb disks, ssd’s, hard drives, nvm drives across many different systems. If I recall PARTUUID’s are embedded in the partition table records and are not inadvertently changed by subsequent replacement of the partitions contents.

Thanks for your quick responses, your suggestion is that I instead make a script that creates all four necessary partitions on each device and assign them specific PARTUUIDs, before copying over the partitioned image generated by mender-convert (which will have been given the same specific partuuids in mender-convert-config)?

Unless i have misunderstood your requirements, the partitioning is part of the mender-convert process already, and from version 2.2.0 partuuid configuration can be defined in the mender-convert config file

1 Like

Hi @dellgreen thanks very much for your responses thus far - I have switched to using partuuid paths and have made sure I’m on version 2.2.0. I have had success making a mender-convert image that is booting okay, I can also begin a standalone update now - but I’m running into issues rebooting into it (see picture). Any ideas?

Also is there an easy way to get a log info from an update?

Here are the configs I’m currently using:






# Partition used as the boot partition.

# Partition used as the first (A) rootfs partition.

# Partition used as the first (B) rootfs partition.

# Partition used as the persistent data partition.



# Nothing to copy

function platform_modify() {
    # Make sure /lib64 exists since the Mender binary requires it.
    # Some systems put everything under /lib (ie Yocto) and a simple
    # symlink is enough to find everything Mender needs.
    if [ ! -e work/rootfs/lib64 ]; then
        run_and_log_cmd "ln -s /lib work/rootfs/lib64"

I think the issue will be in the alterations I made following this commit https://github.com/nandra/mender-conversion-tools/commit/0f500f215a9c944c85df731b2e499c6e111a5cc8

However, using just plain 2.2.0 results in an image that just wouldn’t even boot

the first thing i would check would be to mount the A/B partitions of the disk-image, on your desktop/laptop machine and inspect the contents to see if the kernel its trying to load actually exists at the path it outlines in your grub screenshot.

Hi @dellgreen, this issue is looking a bit more insidious - it only occurs when I try to update the OS from 18.04 LTS to 20.04 LTS (if I update to the same version it is fine). And indeed the kernel image it is looking for “vmlinuz-4.15.0-118-generic” is not on the update, it has the newer “vmlinuz-5.4.0-52-generic”.

Is updating the OS in this way beyond Mender’s remit - is there any way around this issue?

Thanks for your time thus far!

Is updating the OS in this way beyond Mender’s remit - is there any way around this issue?

I think this was bug that was fixed in the following commit.


Thank you very much @mirzak, making those changes on top of the 2.2.0 tag allowed teh kernel image to update successfully form 18.04 to 20.04!