Update Issue When /dev/sda Is Variable

General Discussions
,
1

Hi,

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,
James

2

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.

Drew

3

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.

4

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)?

5

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
6

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?

Image from iOS
Image from iOS1334×750 199 KB

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

Here are the configs I’m currently using:

MENDER_ENABLE_SYSTEMD="n"

MENDER_PARTITION_SCHEME="gpt"

MENDER_BOOT_PART_SIZE_MB="512"

MENDER_DATA_PART_SIZE_MB="64"

MENDER_ENABLE_PARTUUID="y"

# Partition used as the boot partition.
MENDER_BOOT_PART="/dev/disk/by-partuuid/12341234-1234-1234-1234-123412341231"

# Partition used as the first (A) rootfs partition.
MENDER_ROOTFS_PART_A="/dev/disk/by-partuuid/12341234-1234-1234-1234-123412341232"

# Partition used as the first (B) rootfs partition.
MENDER_ROOTFS_PART_B="/dev/disk/by-partuuid/12341234-1234-1234-1234-123412341233"

# Partition used as the persistent data partition.
MENDER_DATA_PART="/dev/disk/by-partuuid/12341234-1234-1234-1234-123412341234"

MENDER_DEVICE_TYPE="x86_64"

MENDER_STORAGE_TOTAL_SIZE_MB="14400"

# Nothing to copy
MENDER_COPY_BOOT_GAP="n"

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"
    fi
}
7

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

8

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.

9

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!

10

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.

2 Likes
11

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!