# Update Issue When /dev/sda Is Variable **URL:** \ **Category:** General Discussions\ **Tags:** ubuntu, standalone\ **Created:** [October 15, 2020, 6:09pm UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677 "2020-10-15T18:09:12Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![jemzp](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jemzp](https://hub.mender.io/u/jemzp)\ **Post date:** [October 15, 2020, 6:09pm UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/1 "2020-10-15T18:09:12Z")
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 ---
**Author:** ![drewmoseley](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/drewmoseley/32/47_2.png) [@drewmoseley](https://hub.mender.io/u/drewmoseley)\ **Post date:** [October 15, 2020, 6:24pm UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/2 "2020-10-15T18:24:08Z")
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 ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [October 15, 2020, 10:00pm UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/3 "2020-10-15T22:00:31Z")
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. ---
**Author:** ![jemzp](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jemzp](https://hub.mender.io/u/jemzp)\ **Post date:** [October 16, 2020, 10:36am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/4 "2020-10-16T10:36:19Z")
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)? ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [October 16, 2020, 11:54am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/5 "2020-10-16T11:54:00Z")
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 > ---
**Author:** ![jemzp](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jemzp](https://hub.mender.io/u/jemzp)\ **Post date:** [October 19, 2020, 9:02am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/6 "2020-10-19T09:02:24Z")
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](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/1X/421e46324406a773620da8745dad1472a5b1c519.jpeg) 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 } ``` ---
**Author:** ![jemzp](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jemzp](https://hub.mender.io/u/jemzp)\ **Post date:** [October 19, 2020, 9:20am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/7 "2020-10-19T09:20:14Z")
I think the issue will be in the alterations I made following this commit [https://github.com/nandra/mender-conversion-tools/commit/0f500f215a9c944c85df731b2e499c6e111a5cc8](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 ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [October 19, 2020, 11:05am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/8 "2020-10-19T11:05:00Z")
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. ---
**Author:** ![jemzp](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jemzp](https://hub.mender.io/u/jemzp)\ **Post date:** [October 20, 2020, 8:47am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/9 "2020-10-20T08:47:40Z")
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! ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [October 20, 2020, 9:53am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/10 "2020-10-20T09:53:39Z")
> 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. > > > Because we hardcode the name in the boot loader script, you can never > upgrade to… a kernel with a different version string. Fix by using a > generic name and symlinking instead. > > Changelog: Title > > Signed-off-by: Kristian Amlie \ ---
**Author:** ![jemzp](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jemzp](https://hub.mender.io/u/jemzp)\ **Post date:** [October 20, 2020, 11:32am UTC](https://hub.mender.io/t/update-issue-when-dev-sda-is-variable/2677/11 "2020-10-20T11:32:13Z")
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!