# Root partition changes randomly from A to B

**URL:** <https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152>\
**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:** 20\
**Page:** 1

<div class="post-metadata">

**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 6, 2021, 12:54pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/1 "2021-10-06T12:54:41Z")

</div>

Hi,

I’m new in Mender and currently working on a PoC to evaluate it. After having a good start with Mender based on the “Get started” projects I’m now struggling with my first own “golden image” based on Ubuntu 20 LTS on a x86\_64 Intel system.

The most time I start the system the root partition changes from A to B. From time to time it stays constant for 2 or 3 times but then it changes again.

I try to change this behavior by using PARTUUID but it doesn’t change.

One thing struck me: after “install” the “golden image” with dd the system runs up into GRUB shell. The reason for that is that the fs\_uuid of the root partition is set wrong (maybe a defualt value): in the ubuntu/grub.cfg on the boot partition (mapped to /boot/efi/EFI/BOOT) and the grub.cfg on the root partitions (/boot/grub).

Any ideas? Hints are welcome!

---

<div class="post-metadata">

**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 6, 2021, 1:13pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/2 "2021-10-06T13:13:19Z")

</div>

Sounds remarkably similar to the problem discussed below.

> [@Dual boot toggles partition at each reboot. GRUB UEFI (x86)](https://hub.mender.io/t/dual-boot-toggles-partition-at-each-reboot-grub-uefi-x86/3686/8):
>
> I’m not an expert on this topic and not clear on how mender bootstraps with respects to efi files, and I think the mender team can better answer this, but you have an awful lot of efi files. My initial guess would be your uefi is going around the mender booltloader and trying to start from one of the Debian efi files instead of the mender efi file. @drewmoseley is there some documentation somewhere that explains how mender bootstraps itself with UEFI as i’m strugging to find anything to link t…

---

<div class="post-metadata">

**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:** [October 7, 2021, 7:46am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/3 "2021-10-07T07:46:51Z")

</div>

Hey @Sven_DS, what are you using to partition the image to begin with? Mender-convert?

I’m asking because mender-convert doesn’t use UUIDs, precisely because they are unstable identifiers in the dual rootfs scenario. PARTUUIDs may work, but this is untested on Debian, and I know from experience with Yocto that it has some pitfalls too. How you created the image may shed some light on this.

---

<div class="post-metadata">

**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 8, 2021, 9:54am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/4 "2021-10-08T09:54:26Z")

</div>

Thanks for your support. - I read this topic before I wrote my question. It ends up with no answers except that it works when you “do the things right”. I think I do the things right; as right the Mender documentation makes it possible. 🙂

---

<div class="post-metadata">

**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 8, 2021, 10:08am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/5 "2021-10-08T10:08:25Z")

</div>

Thanks for your support. - Yes, I’m using mender-convert to modify a “standard” Ubuntu installation into a Mender conform installation. My 1st try was without PARTUUID’s which results in /dev/sdaX. But my system has an additional drive so the system drive is /dev/sdbX. Yes, I could also define /dev/sdbX in the mender-convert config file. But I thought PARTUUID’s make it “biunique”. 🙂  
I don’t know why mender-convert writes a wrong fs\_uuid in the grub.cfg files. And there is no documentation around this. At the end I haven’t a good feeling about the Mender toolchain and I’m thinking about not to recommend it in our current project.

---

<div class="post-metadata">

**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 8, 2021, 2:35pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/6 "2021-10-08T14:35:59Z")

</div>

There must be something else at play here, as I am rolling out many mender-converted Ubuntu installations using PARTUUIDS into production which are not affected by this. I see that you are using Ubuntu 20 lts which is the same ones I’m rolling out.

It maybe helpful to dump the dir listing of your efi directory to see if anythings conflicting.

---

<div class="post-metadata">

**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 8, 2021, 3:07pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/7 "2021-10-08T15:07:43Z")

</div>

Form one of my mender-converted production systems this is what its /boot/efi contents looks like

```auto

/boot/efi
├── EFI
│ └── BOOT
│ ├── BOOTX64.EFI
│ ├── grub.cfg
│ ├── mender_grubenv1
│ │ ├── env
│ │ ├── lock
│ │ └── lock.sha256sum
│ └── mender_grubenv2
│ ├── env
│ ├── lock
│ └── lock.sha256sum
└── ubuntu
    ├── initrd.img-5.11.0-27-generic
    └── vmlinuz-5.11.0-27-generic

```

---

<div class="post-metadata">

**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 8, 2021, 3:08pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/8 "2021-10-08T15:08:55Z")

</div>

and /boot/efi/EFI/BOOT/grub.cfg contents:

```auto
mender_rootfsa_part=2
mender_rootfsb_part=3
mender_grub_storage_device=hd0
kernel_imagetype=kernel
initrd_imagetype=initrd
mender_rootfsa_uuid=26445670-f37c-408b-be2c-3ef419866621
mender_rootfsb_uuid=26445670-f37c-408b-be2c-3ef419866622
# End of ---------- 00_mender_grubenv_defines_grub.cfg ----------
# Start of ---------- 01_console_bootargs_grub.cfg ----------
set console_bootargs="console=tty0,115200n8 console=ttyS0,115200n8 console=ttyO0,115200n8 console=ttyAMA0,115200n8"
# End of ---------- 01_console_bootargs_grub.cfg ----------
# Start of ---------- 02_root_bootargs_grub.cfg ----------
set rootargs="rootwait"
# End of ---------- 02_root_bootargs_grub.cfg ----------
# Start of ---------- 05_mender_setup_grub.cfg ----------
# See the fw_printenv script for how this works.

function maybe_pause {
    # By default we do nothing. debug-pause PACKAGECONFIG replaces this so we
    # can pause at strategic places.
    echo
}

drop_to_grub_prompt="no"
function maybe_drop_to_grub_prompt {
    # By default we do nothing. force-grub-prompt PACKAGECONFIG replaces this so we
    # can bypass boot and stop at the grub prompt.
    echo
}

# Load environment.

MENDER_ENV1=${prefix}/mender_grubenv1/env
MENDER_ENVPREFIX1=${prefix}/mender_grubenv1/
MENDER_LOCK1=${prefix}/mender_grubenv1/lock
MENDER_LOCKSUM1=${prefix}/mender_grubenv1/lock.sha256sum
MENDER_ENV2=${prefix}/mender_grubenv2/env
MENDER_ENVPREFIX2=${prefix}/mender_grubenv2/
MENDER_LOCK2=${prefix}/mender_grubenv2/lock
MENDER_LOCKSUM2=${prefix}/mender_grubenv2/lock.sha256sum

function mender_check_and_restore_env {
    if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX2} --check ${MENDER_LOCKSUM2}; then
        load_env --skip-sig --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        save_env --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        editing=0
        save_env --file ${MENDER_LOCK2} editing
        if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX2} --check ${MENDER_LOCKSUM2}; then
            echo "Environment 2 still corrupt after attempted restore. Halting."
            halt
        fi
    elif ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX1} --check ${MENDER_LOCKSUM1}; then
        load_env --skip-sig --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        save_env --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        editing=0
        save_env --file ${MENDER_LOCK1} editing
        if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX1} --check ${MENDER_LOCKSUM1}; then
            echo "Environment 1 still corrupt after attempted restore. Halting."
            halt
        fi
    fi
}

function mender_save_env {
    # Save redundant environment.
    editing=1
    save_env --file ${MENDER_LOCK2} editing
    save_env --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
    editing=0
    save_env --file ${MENDER_LOCK2} editing

    editing=1
    save_env --file ${MENDER_LOCK1} editing
    save_env --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
    editing=0
    save_env --file ${MENDER_LOCK1} editing
}

function mender_check_grubenv_valid {
    if ["${mender_boot_part}" != "${mender_rootfsa_part}" -a "${mender_boot_part}" != "${mender_rootfsb_part}"]; then
        return 1
    fi

    if ["${bootcount}" != "0" -a "${bootcount}" != "1"]; then
        return 1
    fi

    if ["${upgrade_available}" != "0" -a "${upgrade_available}" != "1"]; then
        return 1
    fi

    return 0
}

mender_check_and_restore_env

# Now load environment.

# Skipping signatures?? Yes, because these values will change over time, so they
# cannot be signed. There is also no checksum facility that will work for
# changing values. Instead we check their content for validity.
load_env --skip-sig --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id

if ! mender_check_grubenv_valid; then
    if ["${check_signatures}" == "enforce"]; then
        echo "Unverified environment and signatures enabled. Halting."
        halt
    fi
fi

if ["${upgrade_available}" = "1"]; then
    if ["${bootcount}" != "0"]; then
        echo "Rolling back..."
        if ["${mender_boot_part}" = "${mender_rootfsa_part}"]; then
            mender_boot_part="${mender_rootfsb_part}"
        else
            mender_boot_part="${mender_rootfsa_part}"
        fi
        upgrade_available=0
        bootcount=0
    else
        echo "Booting new update..."
        bootcount=1
    fi

    mender_save_env
fi

regexp (.*),(.*) $root -s mender_grub_storage_device
# End of ---------- 05_mender_setup_grub.cfg ----------
# Start of ---------- 06_systemd_machine_id_grub.cfg ----------
if test -n "${mender_systemd_machine_id}"; then
   systemd_bootargs="systemd.machine_id=${mender_systemd_machine_id}"
fi
# End of ---------- 06_systemd_machine_id_grub.cfg ----------
# Start of ---------- 10_bootargs_grub.cfg ----------
set bootargs="${bootargs} ${console_bootargs} ${rootargs} ${systemd_bootargs}"
# End of ---------- 10_bootargs_grub.cfg ----------
# Start of ---------- 11_bootargs_grub.cfg ----------
set bootargs="${bootargs} fsck.mode=force fsck.repair=yes"
# End of ---------- 11_bootargs_grub.cfg ----------
# Start of ---------- 90_mender_boot_grub.cfg ----------
maybe_drop_to_grub_prompt

if test -e (${mender_grub_storage_device},gpt${mender_boot_part})/; then
    ptable_type=gpt
else
    ptable_type=msdos
fi

if test -n "${mender_rootfsa_uuid}" -a test -n "${mender_rootfsb_uuid}"; then
    if ["${mender_boot_part}" = "${mender_rootfsa_part}"]; then
        mender_root="PARTUUID=${mender_rootfsa_uuid}"
    elif ["${mender_boot_part}" = "${mender_rootfsb_part}"]; then
        mender_root="PARTUUID=${mender_rootfsb_uuid}"
    fi
else
    mender_root="${mender_kernel_root_base}${mender_boot_part}"
fi

if ["${drop_to_grub_prompt}" = "no"]; then
    if linux (${mender_grub_storage_device},${ptable_type}${mender_boot_part})/boot/${kernel_imagetype} root=${mender_root} ${bootargs}; then
        if test -n "${initrd_imagetype}" -a test -e (${mender_grub_storage_device},${ptable_type}${mender_boot_part})/boot/${initrd_imagetype}; then
            initrd (${mender_grub_storage_device},${ptable_type}${mender_boot_part})/boot/${initrd_imagetype}
        fi
        maybe_pause "Pausing before booting."
        boot
    fi
    maybe_pause "Pausing after failed boot."
fi
# End of ---------- 90_mender_boot_grub.cfg ----------
# Start of ---------- 95_mender_try_to_recover_grub.cfg ----------
if ["${drop_to_grub_prompt}" = "no"]; then
    if ["${upgrade_available}" == "1"]; then
        reboot
    fi
fi
# End of ---------- 95_mender_try_to_recover_grub.cfg ----------
# Start of ---------- 99_mender_end_of_grub.cfg ----------
if ["${drop_to_grub_prompt}" = "yes"]; then
    echo "Dropping to grub prompt intentionally."
    sleep --interruptible 10 --verbose
else
    echo "Dropping to grub prompt for unknown reason. Should never get here."
    sleep --interruptible 10 --verbose
fi
menuentry 'Dummy Entry for Debug.' 'Wait' {
   echo Menu Entry for debug/command prompt access
}
# End of ---------- 99_mender_end_of_grub.cfg ----------

```

---

<div class="post-metadata">

**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 11, 2021, 10:37am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/9 "2021-10-11T10:37:26Z")

</div>

This is how my tree looks like. Please ignore the \*.org files as these are only backups of the original Mender converted files. All other files are exactly the result of mender-convert.

```auto
/boot/efi
.
└── EFI
    ├── BOOT
    │ ├── BOOTX64.EFI
    │ ├── fbx64.efi
    │ ├── grub.cfg
    │ ├── grub.cfg.org
    │ ├── mender_grubenv1
    │ │ ├── env
    │ │ ├── lock
    │ │ └── lock.sha256sum
    │ ├── mender_grubenv2
    │ │ ├── env
    │ │ ├── lock
    │ │ └── lock.sha256sum
    │ └── mmx64.efi
    └── ubuntu
        ├── BOOTX64.CSV
        ├── grub.cfg
        ├── grub.cfg.org
        ├── grubx64.efi
        ├── mmx64.efi
        └── shimx64.efi

```

---

<div class="post-metadata">

**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 11, 2021, 10:46am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/10 "2021-10-11T10:46:35Z")

</div>

My grub.cfg looks like yours. The only thing I changed was mender\_grub\_storage\_device=hd1 because my device has two drives: hd0 is a 1TB hard disk only for data, hd1 is a 120 GB SSD disk and works as system disk.

```auto
# Start of ---------- 00_mender_grubenv_defines_grub.cfg ----------
mender_rootfsa_part=2
mender_rootfsb_part=3
mender_grub_storage_device=hd1
kernel_imagetype=kernel
initrd_imagetype=initrd
mender_rootfsa_uuid=aadf3a2f-43cc-44eb-8237-31711b75e4c9
mender_rootfsb_uuid=abdf3a2f-43cc-44eb-8237-31711b75e4c9
# End of ---------- 00_mender_grubenv_defines_grub.cfg ----------
# Start of ---------- 01_console_bootargs_grub.cfg ----------
set console_bootargs="console=tty0,115200n8 console=ttyS0,115200n8 console=ttyO0,115200n8 console=ttyAMA0,115200n8"
# End of ---------- 01_console_bootargs_grub.cfg ----------
# Start of ---------- 02_root_bootargs_grub.cfg ----------
set rootargs="rootwait"
# End of ---------- 02_root_bootargs_grub.cfg ----------
# Start of ---------- 05_mender_setup_grub.cfg ----------
# See the grub-mender-grubenv-print script for how this works.

function maybe_pause {
    # By default we do nothing. debug-pause PACKAGECONFIG replaces this so we
    # can pause at strategic places.
    echo
}

drop_to_grub_prompt="no"
function maybe_drop_to_grub_prompt {
    # By default we do nothing. force-grub-prompt PACKAGECONFIG replaces this so we
    # can bypass boot and stop at the grub prompt.
    echo
}

# Load environment.

MENDER_ENV1=${prefix}/mender_grubenv1/env
MENDER_ENVPREFIX1=${prefix}/mender_grubenv1/
MENDER_LOCK1=${prefix}/mender_grubenv1/lock
MENDER_LOCKSUM1=${prefix}/mender_grubenv1/lock.sha256sum
MENDER_ENV2=${prefix}/mender_grubenv2/env
MENDER_ENVPREFIX2=${prefix}/mender_grubenv2/
MENDER_LOCK2=${prefix}/mender_grubenv2/lock
MENDER_LOCKSUM2=${prefix}/mender_grubenv2/lock.sha256sum

function mender_check_and_restore_env {
    if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX2} --check ${MENDER_LOCKSUM2}; then
        load_env --skip-sig --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        save_env --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        editing=0
        save_env --file ${MENDER_LOCK2} editing
        if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX2} --check ${MENDER_LOCKSUM2}; then
            echo "Environment 2 still corrupt after attempted restore. Halting."
            halt
        fi
    elif ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX1} --check ${MENDER_LOCKSUM1}; then
        load_env --skip-sig --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        save_env --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
        editing=0
        save_env --file ${MENDER_LOCK1} editing
        if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX1} --check ${MENDER_LOCKSUM1}; then
            echo "Environment 1 still corrupt after attempted restore. Halting."
            halt
        fi
    fi
}

function mender_save_env {
    # Save redundant environment.
    editing=1
    save_env --file ${MENDER_LOCK2} editing
    save_env --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
    editing=0
    save_env --file ${MENDER_LOCK2} editing

    editing=1
    save_env --file ${MENDER_LOCK1} editing
    save_env --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id
    editing=0
    save_env --file ${MENDER_LOCK1} editing
}

function mender_check_grubenv_valid {
    if ["${mender_boot_part}" != "${mender_rootfsa_part}" -a "${mender_boot_part}" != "${mender_rootfsb_part}"]; then
        return 1
    fi

    if ["${bootcount}" != "0" -a "${bootcount}" != "1"]; then
        return 1
    fi

    if ["${upgrade_available}" != "0" -a "${upgrade_available}" != "1"]; then
        return 1
    fi

    return 0
}

mender_check_and_restore_env

# Now load environment.

# Skipping signatures?? Yes, because these values will change over time, so they
# cannot be signed. There is also no checksum facility that will work for
# changing values. Instead we check their content for validity.
load_env --skip-sig --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available mender_systemd_machine_id

if ! mender_check_grubenv_valid; then
    if ["${check_signatures}" == "enforce"]; then
        echo "Unverified environment and signatures enabled. Halting."
        halt
    fi
fi

if ["${upgrade_available}" = "1"]; then
    if ["${bootcount}" != "0"]; then
        echo "Rolling back..."
        if ["${mender_boot_part}" = "${mender_rootfsa_part}"]; then
            mender_boot_part="${mender_rootfsb_part}"
        else
            mender_boot_part="${mender_rootfsa_part}"
        fi
        upgrade_available=0
        bootcount=0
    else
        echo "Booting new update..."
        bootcount=1
    fi

    mender_save_env
fi

regexp (.*),(.*) $root -s mender_grub_storage_device
# End of ---------- 05_mender_setup_grub.cfg ----------
# Start of ---------- 06_systemd_machine_id_grub.cfg ----------
if test -n "${mender_systemd_machine_id}"; then
   systemd_bootargs="systemd.machine_id=${mender_systemd_machine_id}"
fi
# End of ---------- 06_systemd_machine_id_grub.cfg ----------
# Start of ---------- 10_bootargs_grub.cfg ----------
set bootargs="${bootargs} ${console_bootargs} ${rootargs} ${systemd_bootargs}"
# End of ---------- 10_bootargs_grub.cfg ----------
# Start of ---------- 90_mender_boot_grub.cfg ----------
maybe_drop_to_grub_prompt

if ["${mender_boot_part}" = "${mender_rootfsa_part}" -a test -n "${mender_kernela_part}"]; then
    mender_ptable_part=${mender_kernela_part}
    mender_kernel_path="(${mender_grub_storage_device},${ptable_type}${mender_kernela_part})"
elif ["${mender_boot_part}" = "${mender_rootfsb_part}" -a test -n "${mender_kernelb_part}"]; then
    mender_ptable_part=${mender_kernelb_part}
    mender_kernel_path="(${mender_grub_storage_device},${ptable_type}${mender_kernelb_part})"
else
    mender_ptable_part=${mender_boot_part}
    mender_kernel_path="(${mender_grub_storage_device},${ptable_type}${mender_boot_part})/boot"
fi

if test -e (${mender_grub_storage_device},gpt${mender_ptable_part})/; then
    ptable_type=gpt
else
    ptable_type=msdos
fi

if test -n "${mender_rootfsa_uuid}" -a test -n "${mender_rootfsb_uuid}"; then
    if ["${mender_boot_part}" = "${mender_rootfsa_part}"]; then
        mender_root="PARTUUID=${mender_rootfsa_uuid}"
    elif ["${mender_boot_part}" = "${mender_rootfsb_part}"]; then
        mender_root="PARTUUID=${mender_rootfsb_uuid}"
    fi
else
    mender_root="${mender_kernel_root_base}${mender_boot_part}"
fi

if ["${drop_to_grub_prompt}" = "no"]; then
    if linux ${mender_kernel_path}/${kernel_imagetype} root=${mender_root} ${bootargs}; then
        if test -n "${initrd_imagetype}" -a test -e ${mender_kernel_path}/${initrd_imagetype}; then
            initrd ${mender_kernel_path}/${initrd_imagetype}
        fi
        maybe_pause "Pausing before booting."
        boot
    fi
    maybe_pause "Pausing after failed boot."
fi
# End of ---------- 90_mender_boot_grub.cfg ----------
# Start of ---------- 95_mender_try_to_recover_grub.cfg ----------
if ["${drop_to_grub_prompt}" = "no"]; then
    if ["${upgrade_available}" == "1"]; then
        reboot
    fi
fi
# End of ---------- 95_mender_try_to_recover_grub.cfg ----------
# Start of ---------- 99_mender_end_of_grub.cfg ----------
if ["${drop_to_grub_prompt}" = "yes"]; then
    echo "Dropping to grub prompt intentionally."
    sleep --interruptible 10 --verbose
else
    echo "Dropping to grub prompt for unknown reason. Should never get here."
    sleep --interruptible 10 --verbose
fi
menuentry 'Dummy Entry for Debug.' 'Wait' {
   echo Menu Entry for debug/command prompt access
}
# End of ---------- 99_mender_end_of_grub.cfg ----------

```

---

<div class="post-metadata">

**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 11, 2021, 11:48am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/11 "2021-10-11T11:48:06Z")

</div>

ok great, as mentioned in the posting link above, we discussed the possibility that having multiple .efi files meant that the wrong one was been selected by the UEFI firmware and that removing the extra ones may force it to use the correct one.

Trying removing all .efi files except /boot/efi/EFI/BOOT/BOOTX64.EFI and see if that works

---

<div class="post-metadata">

**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 12, 2021, 9:58am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/12 "2021-10-12T09:58:13Z")

</div>

Doesn’t work … ☹

 ![IMG_20211012_111823858](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/2X/b/ba51f2606c08f8c89b6854831156d203a74831d0.jpeg)

grubx64.efi was under /boot/efi/EFI/ubuntu

Maybe this is interesting: under /boot/efi/EFI/ubuntu are two files

“grub.cfg” with following content:

```auto
search.fs_uuid 6143e8dc-fdd5-4ec4-aebd-7965b377af6b root hd1,gpt2 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

```

And “BOOTX64.CSV” with following content:

```auto
shimx64.efi,ubuntu,,This is the boot entry for ubuntu

```

---

<div class="post-metadata">

**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 12, 2021, 10:36am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/13 "2021-10-12T10:36:14Z")

</div>

try deleting the ubuntu folder as I thought the default fallback bootloader was normally

```auto
\EFI\boot\bootx64.efi

```

it should be case-insensitive, so its not clear to me why its not falling back to the default path when it cannot find what its looking for. Unless your bios/uefi firmware is causing they issue?

---

<div class="post-metadata">

**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 12, 2021, 12:31pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/14 "2021-10-12T12:31:17Z")

</div>

Doesn’t change. Runs in the same failure.

I think the BIOS recognizes the OS (see picture). Before I delete the “ubuntu” folder there was written “ubuntu OS” instead of “UEFI OS”.

 ![IMG_20211012_142338376](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/2X/1/111e95f8be8b323103049841a4b21d85089c3872.jpeg)

---

<div class="post-metadata">

**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 12, 2021, 1:04pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/15 "2021-10-12T13:04:21Z")

</div>

in the Failed to open messages, is the path different now as originally it was looking for “grubx64.efi” as opposed to “BOOTX64.EFI”

---

<div class="post-metadata">

**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 12, 2021, 1:10pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/16 "2021-10-12T13:10:50Z")

</div>

No - it’s the same (“grubx64.efi”).

---

<div class="post-metadata">

**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 12, 2021, 1:34pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/17 "2021-10-12T13:34:53Z")

</div>

At this point I would be trying to clear the bios NVRAM via its options, and looking to see if there is a bios update for your device, as its doesn’t seem to being exhibiting behaviour i recognize.

---

<div class="post-metadata">

**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 12, 2021, 2:44pm UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/18 "2021-10-12T14:44:23Z")

</div>

The board is a Fujitsu D3543-Sx1 with BIOS rev. 1.12.0. It’s the latest release. - I will try to clear the NVRAM.

---

<div class="post-metadata">

**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, 8:32am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/19 "2021-10-13T08:32:31Z")

</div>

I took a look in the EFI entries of the NVRAM.

```auto
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0006,0005,0001,0002,0003,0004,0000
Boot0000* Diagnostic Program	FvVol(5c60f367-a505-419a-859e-2a4ff6ca6fe5)/FvFile(085e8cc2-8ec9-4666-bd2a-49d481e95fa7)
Boot0001* UEFI: PXE IP4 Realtek PCIe GBE Family Controller	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x5,0x0)/Pci(0x0,0x0)/MAC(0030591b9ad1,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0002* UEFI: PXE IP6 Realtek PCIe GBE Family Controller	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x5,0x0)/Pci(0x0,0x0)/MAC(0030591b9ad1,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0003* UEFI: PXE IP4 Intel(R) I210 Gigabit Network Connection	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)/MAC(00305914304d,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0004* UEFI: PXE IP6 Intel(R) I210 Gigabit Network Connection	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)/MAC(00305914304d,1)/IPv6([::]:<->[::]:,0,0)..BO
Boot0005* UEFI OS	HD(1,GPT,acdf3a2f-43cc-44eb-8237-31711b75e4c9,0x4000,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0006* ubuntu	HD(1,GPT,acdf3a2f-43cc-44eb-8237-31711b75e4c9,0x4000,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)

```

I changed the BootOrder to 0005,0006,0001,0002,0003,0004,0000. After restart the system “heals” itself.

```auto
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0005,0001,0002,0003,0004,0000
Boot0000* Diagnostic Program	FvVol(5c60f367-a505-419a-859e-2a4ff6ca6fe5)/FvFile(085e8cc2-8ec9-4666-bd2a-49d481e95fa7)
Boot0001* UEFI: PXE IP4 Realtek PCIe GBE Family Controller	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x5,0x0)/Pci(0x0,0x0)/MAC(0030591b9ad1,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0002* UEFI: PXE IP6 Realtek PCIe GBE Family Controller	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x5,0x0)/Pci(0x0,0x0)/MAC(0030591b9ad1,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0003* UEFI: PXE IP4 Intel(R) I210 Gigabit Network Connection	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)/MAC(00305914304d,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0004* UEFI: PXE IP6 Intel(R) I210 Gigabit Network Connection	PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)/MAC(00305914304d,1)/IPv6([::]:<->[::]:,0,0)..BO
Boot0005* UEFI OS	HD(1,GPT,acdf3a2f-43cc-44eb-8237-31711b75e4c9,0x4000,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0007* ubuntu	HD(1,GPT,acdf3a2f-43cc-44eb-8237-31711b75e4c9,0x4000,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)

```

Maybe I should delete the entry “ubuntu”!?

---

<div class="post-metadata">

**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, 9:30am UTC](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152/20 "2021-10-13T09:30:34Z")

</div>

yer i would delete the NVRAM ubuntu entry as its no longer a valid option,

[Next page](https://hub.mender.io/t/root-partition-changes-randomly-from-a-to-b/4152.md?page=2)