# Root partition changes randomly from A to B **URL:** \ **Category:** Debian family\ **Created:** [October 6, 2021, 12:54pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152 "2021-10-06T12:54:41Z")\ **Posts on this page:** 12\ **Page:** 2
**Author:** ![Sven\_DS](https://avatars.discourse-cdn.com/v4/letter/s/b38774/32.png) [@Sven\_DS](https://hub.mender.io/u/Sven_DS)\ **Post date:** [October 13, 2021, 1:06pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/21 "2021-10-13T13:06:02Z")
So - after reverting the previous changes I deleted the “/boot/efi/EFI/ubuntu” folder again and I deleted the “ubuntu” entry in the EFI boot table. The boot order changes to 0005, … which directs to \EFI\BOOT\BOOTX64.EFI. The result is that the system doesn’t startup and stays in reboot loop. ---
**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 13, 2021, 2:33pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/22 "2021-10-13T14:33:00Z")
At this point, I have exhausted ideas, maybe others have more. At this point i would be looking into how to drop into a UEFI shell on your machine and try and get more debug/error information as to why it doesn’t boot by using efi commands. ---
**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 14, 2021, 11:45am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/23 "2021-10-14T11:45:30Z")
can you post your mender-convert config file that your using to see if theres anything in their that may be causing the problem. ---
**Author:** ![Sven\_DS](https://avatars.discourse-cdn.com/v4/letter/s/b38774/32.png) [@Sven\_DS](https://hub.mender.io/u/Sven_DS)\ **Post date:** [October 14, 2021, 2:42pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/24 "2021-10-14T14:42:44Z")
Hi Dell, when I used mender-convert the 1st time I used ~/mender-convert/configs/generic\_x86-64\_hdd\_config. After having problems with the partitions I decided to use PARTUUID’s. So I made a copy of generic\_x86-64\_hdd\_config, call it ds\_edge\_poc\_config and added some values that I got from the 1st run config in the deploy directory (which seems a conclusion of all config values used to generate the image). This is how it looks: ```auto # This configuration can be used to run any distribution on a any x86-64 machine. # As example is used CentOS distribution but can be applied to others also. # # Install CentOS using classic partition scheme (not use LVM) with minimal # 2 partitons /boot/efi and /root. For root please choose only necessary size # e.g. 10G (or desired size). # # This has been tested on images generated with the following command: # # Boot live USB and copy the data from internal storage (hdd, eMMC) e.g. for eMMC: # # dd if=/dev/mmcblk0 of=/media/usb/centos.img bs=1M count=10000 status=progress # # Before running mender-convert we need to fix GPT partition table (as we didn't copy # whole hdd). Run following command to fix GPT partition table on copied image: # # sgdisk -e /media/usb/centos.img # # Converted with the following command: # # MENDER_ARTIFACT_NAME=release-1 ./docker-mender-convert \ # --disk-image input/centos.img \ # --config configs/centos_x86-64_hdd_config \ # --overlay rootfs_overlay_demo/ # # and image must be then copied back after conversion to internal storage (when booted again from live USB) e.g. for hdd: # # zcat /media/usb/centos-x86_64-mender.img.gz | sudo dd of=/dev/sda bs=1M status=progress # # after copy run again (to fix GPT partition table): # sgdisk -e /dev/sda # # MENDER_STORAGE_DEVICE_BASE=/dev/sda # MENDER_DEVICE_TYPE="x86_64" # MENDER_STORAGE_TOTAL_SIZE_MB=16000 MENDER_ENABLE_PARTUUID="y" MENDER_BOOT_PART="/dev/disk/by-partuuid/acdf3a2f-43cc-44eb-8237-31711b75e4c9" MENDER_ROOTFS_PART_A="/dev/disk/by-partuuid/aadf3a2f-43cc-44eb-8237-31711b75e4c9" MENDER_ROOTFS_PART_B="/dev/disk/by-partuuid/abdf3a2f-43cc-44eb-8237-31711b75e4c9" MENDER_DATA_PART="/dev/disk/by-partuuid/addf3a2f-43cc-44eb-8237-31711b75e4c9" MENDER_BOOT_PART_MOUNT_LOCATION="/boot/efi" #MENDER_BOOT_PART_SIZE_MB="512" #MENDER_DATA_PART_SIZE_MB="1024" MENDER_DEVICE_TYPE="ds_edge_poc" MENDER_STORAGE_TOTAL_SIZE_MB=64000 MENDER_ARTIFACT_NAME="system_image_rel-1" MENDER_FEATURES="mender-convert mender-grub mender-client-install" DEPLOY_DIR_IMAGE="/mender-convert/deploy" MENDER_MACHINE="x86_64" MENDER_STORAGE_DEVICE_BASE="/dev/sdb" IMAGE_FSTYPES="ext4 mender sdimg" ARTIFACTIMG_FSTYPE="ext4" # 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:** ![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 14, 2021, 3:13pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/25 "2021-10-14T15:13:19Z")
one difference i can see is, you may want to set the partition scheme explicitly in case there is a bug somewhere mender-convert code as if i recall partuuids are a gpt feature. `MENDER_PARTITION_SCHEME="gpt"` ---
**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 14, 2021, 3:40pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/26 "2021-10-14T15:40:51Z")
another difference i can see is remove MENDER\_STORAGE\_DEVICE\_BASE as it wont be needed if you enable partuuids ---
**Author:** ![Sven\_DS](https://avatars.discourse-cdn.com/v4/letter/s/b38774/32.png) [@Sven\_DS](https://hub.mender.io/u/Sven_DS)\ **Post date:** [October 15, 2021, 9:55am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/27 "2021-10-15T09:55:44Z")
Ok - I will try both. Did you think it make sense to change IMAGE\_FSTYPES=“ext4 mender **sdimg** ” to IMAGE\_FSTYPES=“ext4 mender **uefiimg** ”? And what did you think about the use of “sgdisk” before and after running mender-convert? Btw: all config variables we talking about and also the use of sgdisk isn’t part of Mender’s documentation at all or the Debian family part of the documentation. ---
**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, 2021, 11:28am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/28 "2021-10-15T11:28:27Z")
i don’t have IMAGE\_FSTYPES set for my projects as the defaults are enough for me apart from i do have MENDER\_USE\_BMAP=“y” set as i use bmaptools to image devices ---
**Author:** ![Sven\_DS](https://avatars.discourse-cdn.com/v4/letter/s/b38774/32.png) [@Sven\_DS](https://hub.mender.io/u/Sven_DS)\ **Post date:** [October 15, 2021, 12:57pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/29 "2021-10-15T12:57:57Z")
MENDER\_USE\_BMAP means that the image generated by mender-convert is “bmapped”. Is mender-convert able to accept “bmapped” images as input? ---
**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, 2021, 1:27pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/30 "2021-10-15T13:27:39Z")
MENDER\_USE\_BMAP creates another output artifact “.bmap” file from the already produced disk image file that mender-convert creates. It doesn’t change the disk image in any way just records in the bmap file what blocks in your disk image file actually need to be written as opposed to writing empty ones. sorry Its not relevant to the problem your trying to solve. ---
**Author:** ![Sven\_DS](https://avatars.discourse-cdn.com/v4/letter/s/b38774/32.png) [@Sven\_DS](https://hub.mender.io/u/Sven_DS)\ **Post date:** [October 20, 2021, 9:07am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/32 "2021-10-20T09:07:31Z")
Hi Dell, I think I found the reason the system doesn’t startup after the changes we made. > Trying removing all .efi files except /boot/efi/EFI/BOOT/BOOTX64.EFI and see if that works The solution was not to delete ALL .efi files. I just deleted the /boot/efi/EFI/ubuntu folder and didn’t touch any file in the /boot/efi/EFI/BOOT folder. Now the system falls back to BOOTX64.EFI, produces a lot of startup output on the screen and runs up the root A partition. So - I will test if this behavior is reproducible. And I will check what happens after an update via Mender. ---
**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 20, 2021, 10:47am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/33 "2021-10-20T10:47:46Z")
glad its working for you now 😃 [Previous page](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152.md?page=1)