# Mender-convert activate PARTUUID option **URL:** \ **Category:** General Discussions\ **Tags:** mender-convert\ **Created:** [June 25, 2020, 5:15pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110 "2020-06-25T17:15:02Z")\ **Posts on this page:** 16\ **Page:** 1
**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:** [June 25, 2020, 5:15pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/1 "2020-06-25T17:15:02Z")
Looking at the grub.cfg in the EFI partition I can see that there is provision for using PARTUUID’s instead of device names. However in the mender-convert code i cannot see anything that actually sets the mender\_rootfsa\_uuid and mender\_rootfsb\_uuid variables in grub.cfg. I assume this is because these options are driven from meta-mender and there is just not a direct option in mender-convert to activate this option yet. Is my assessment correct? I assume i could just add these variables in with a a mender script hook, although might it be better to support an option in the config to enable the generation of these variables as part of the build ---
**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:** [June 26, 2020, 7:38am UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/2 "2020-06-26T07:38:04Z")
> assume this is because these options are driven from meta-mender and there is just not a direct option in mender-convert to activate this option yet. Is my assessment correct? Yes 🙂 > [@dellgreen](#): > > although might it be better to support an option in the config to enable the generation of these variables as part of the build Yes 🙂 ---
**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:** [June 26, 2020, 12:06pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/3 "2020-06-26T12:06:30Z")
looks like any required changes to work/boot and work/rootfs will need to happen as part of the mender-convert-package script as its only then that the PARTUUID’s will be known once the image partition layout is written out (GPT) so this looks like it will comprise changes being made to grub.cfg in work/boot as already discussed and also fstab in work/rootfs as it references /boot/efi and /data by device name currently ---
**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:** [June 26, 2020, 9:29pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/4 "2020-06-26T21:29:05Z")
presumably to be complete the references in /etc/fstab are going to need to be changed as well as I am seeing the ESP and data partitions referenced in mine. However this probably means that we need to allow the user to supply consistent partuuids to the build so that the mender artifact updates contain consistently the same partuuids between successive builds otherwise they change on each build. As the partuuids need to be provided in the config to facilitate reproducible builds, this takes away the restriction of having to make the change in mender-convert-package script ---
**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:** [June 27, 2020, 1:06pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/5 "2020-06-27T13:06:11Z")
in meta-mender it appears that the following variables are being used to contain paths to partuuids as well as devices, so propose we should use the same in mender-convert MENDER\_BOOT\_PART MENDER\_ROOTFS\_PART\_A MENDER\_ROOTFS\_PART\_B MENDER\_DATA\_PART > ---
**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:** [June 27, 2020, 1:34pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/6 "2020-06-27T13:34:31Z")
Issue link: [https://tracker.mender.io/browse/MEN-3725](https://tracker.mender.io/browse/MEN-3725) ---
**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:** [July 3, 2020, 1:58pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/7 "2020-07-03T13:58:27Z")
Pull request here: [https://github.com/mendersoftware/mender-convert/pull/220](https://github.com/mendersoftware/mender-convert/pull/220) ---
**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:** [July 11, 2020, 3:42pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/8 "2020-07-11T15:42:01Z")
@mirzak, @kacf I seem to have uncovered some sort of systemd issue with the data.mount service now that I’m using partuuid device paths in fstab. On the very first boot from a fresh image created, the data.mount unit now fails to mount with an error unable to find the device listed in fstab. On subsequent boots everything just works fine. So initially I thought this was some kind of race condition between udev creating the device path symlinks and the data.mount systemd unit. However I have a service of my own that runs much early in the boot sequence that uses the exact same entry in fstab to check and fix gpt header errors and extend data partition to fill remaining block device on data partition, and this runs just fine every single time irrespective of whether its first boot or subsequent boots. So as most examples of using partuuid don’t use the udev device path symlink in fstab, but instead use the key value pair notation I re-tested with this, and the problem no longer presented itself. So the use of the udev symlink paths in fstab seem to not fully be supported correctly under some scenarios/implementations. My hunch is there is possibly a bug in systemd/mount-generator that is not resolving the symlink correctly prior to internal usage as less eyes or on the use case, compared to key/value notation in some circumstances. My proposal is that I provide a pull request to update the partuuid support recently just merged into master to change the fstab entries to use the key/value notation for partuuid use. Will this cause and issue for any of your tooling that may happen to parse fstab for any reason? The reason I initially went with device paths was incase any tooling expected this field to be a path. ---
**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:** [July 11, 2020, 4:35pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/9 "2020-07-11T16:35:15Z")
To further support the hunch, when you compare the status of the data.mount unit in the two scenarios, when using the udev device path by-partuuid symlink notation the ‘What’ is /dev/disk/by-partuuid/26445670-f37c-408b-be2c-3ef419866623 for when it fails, however when using the key/value pair notation the ‘What’ is /dev/sda4 meaning it has correctly mapped the partuuuid in fstab to device. [https://dl.dropboxusercontent.com/s/lva0ybyu6egmhpd/dells-mender-data-mount.webm?dl=0](https://dl.dropboxusercontent.com/s/lva0ybyu6egmhpd/dells-mender-data-mount.webm?dl=0) ---
**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:** [July 12, 2020, 1:00pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/10 "2020-07-12T13:00:33Z")
A possible explanation for the differences, is that systemd-fstab-generator that creates the mount units dynamically runs before either of the services and at that point the udev symlinks don’t exists. When a symlink is used in the mount unit, it cannot be resolved when systemd-fstab-generator runs hence the symlink is set as the What. At run time it just seems like the symlink is used as an absolute path to the block device without any further resolution of the link. When a PARTUUID key value pair is used a different code path is taken that yields the resolved absolute path to the real block device. ---
**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:** [July 12, 2020, 1:01pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/11 "2020-07-12T13:01:49Z")
If everyone is happy with the proposed change then I’ll put up an issue on the tracker on Monday and work on it, should be a fairly quick one to fix ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [July 13, 2020, 7:59am UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/12 "2020-07-13T07:59:47Z")
Thanks for the investigation. Could it be that systemd-fstab-generator is missing a dependency on the udev unit file? Could be a possible upstream fix, but I’m fine with fixing it the way you proposed as well. Mender does not use the information inside the fstab file, we get all our info from mender.conf. ---
**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:** [July 13, 2020, 9:15am UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/13 "2020-07-13T09:15:02Z")
cool, ok I’ll progress with a fix 🙂 ---
**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:** [July 13, 2020, 12:06pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/14 "2020-07-13T12:06:20Z")
[https://tracker.mender.io/browse/MEN-3817](https://tracker.mender.io/browse/MEN-3817) ---
**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:** [July 13, 2020, 5:58pm UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/15 "2020-07-13T17:58:03Z")
Looks like I have been given the complete run-around by a spurious race-condition as after many runs I managed to create the same error with the key/value notation as well. After more investigation its starting to indeed look like a dependency issue. The /etc/fstab file created by mender-convert doesn’t set the fs\_passno whereas all my servers virtual or physical are setting the fs\_passno by default to do fsck checks in correlation with UUID= notation for partitions. When the fs\_passno is set then the systemd-fstab-generator created mount unit files have a dependency on the /lib/systemd/system/systemd-fsck@.service services which in-turn has a BindsTo= and After= dependency on the .device block device in question, so this is why I am seeing it work on all my servers. Looks like the solution is to also add something like x-systemd.requires= with the by-partuuid device as the parameter which the documentation implies should give us the dependency between the mount unit and device unit without imposing the fs\_passno on developers. I’ll give it a test and report back ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [July 15, 2020, 6:18am UTC](https://hub.mender.io/t/mender-convert-activate-partuuid-option/2110/16 "2020-07-15T06:18:45Z")
Thanks for investigating!