Hi,
I first used mender with a IMX board and now I also use it with QEMU machine for testing and easy deployement as a Virtual Machine.
My issue is that with KVM the disk is launched as a paravirtualized disk and Linux mount it as /dev/vda
whereas on Microsoft Hyper-V the disk is laucned as fully-virtualized and Linux mount is as /dev/sda
Is there a way to have the same image compatible with both KVM and Hyper-V ?
Thanks for your help
Hi, I use the partuuid feature to reference partitions in mender setup for exactly these type of situations, as well as being able to boot the same image from USB sticks.
I have only tested with mender-convert see variables here:
Yocto meta-mender also has support with mender-partuuid feature
Hi,
Indeed it could be a good fix, I’m already using the LABEL instead of PartUUID to detect /data and /boot
because the Part UUID were not equal regarding hardwares (see: Introduce partlabel feature to find partition by their label by clementperon · Pull Request #1543 · mendersoftware/meta-mender · GitHub).
Could it be a nice feature to introduce label for ROOTFS_A and ROOTFS_B ?
@kacf @lluiscampos what do you think?
because the Part UUID were not equal regarding hardwares
Are you able to elaborate on this further?
I have different hardware ARM / x86 and now QEMU, If I do blkid to look for the PartUUID each hardware have a different one. So i choose to use the label which were present on all hardware.
With PARTUUID, you set it to what you want to embed in the device’s GPT partition table in the mender config, this is different from the UUID which is globally unique per device.
Sorry I meant the hardware has been alread shipped and is used on-the-field.
My first hardware was built on Zeus release when I look at the boot partition for example PartUUID using blkid
TYPE=“vfat” PARTUUID=“41b418dd-01”
Second hardware X86
TYPE=“vfat” PARTUUID=“bbc1178a-7f7f-4719-baa6-7d616155adcd”
And my latest hardware QEMU
TYPE=“vfat” PARTUUID=“994c8c84-3c62-4538-94d3-64a33ada7822”
Ah, if it’s already shipped, then it’s probably safer to stick with what you are using then
After talking with @kacf,
I think I will switch to PARTUUID, as explained by @kacf the LABEL are not “stuck” to the GPT partition table but to the partition itself.
Whereas PARTUUID and PARTLABEL are defined in the GPT partition table, so they are less likely to be changed.
Thanks for your help @dellgreen 
Just replying to myself in case someone has the same issue.
Instead of migrating to PARTUUID, I will do a mix between LABEL and PARTUUID.
I will keep the LABEL for boot and data partitions in /etc/fstab/
And generate new images / bootloader with PARTUUID support.
This will avoid a migration on the machine already shipped.
(This is actually not supported by mender but I could open a MR not sure it will be accepted)