Root partition changes randomly from A to B

Board Integrations Debian family
21

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.

22

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.

23

can you post your mender-convert config file that your using to see if theres anything in their that may be causing the problem.

24

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:

# 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
}
25

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"

26

another difference i can see is remove MENDER_STORAGE_DEVICE_BASE as it wont be needed if you enable partuuids

27

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.

28

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

29

MENDER_USE_BMAP means that the image generated by mender-convert is “bmapped”. Is mender-convert able to accept “bmapped” images as input?

30

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.

32

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.

33

glad its working for you now :smiley: