I would like to convert an x86 system with Mender. I currently can’t set the right partitions.
Can anyone tell me where I still need to adjust something?
Thanks
Dirk
Mender convert creates this:
'/dev/mmcblk02‘
but I need this value:
/dev/mmcblk0p2
2021-05-06 15:05:39 [INFO] [mender-convert-modify] Using root device A in mender.conf:
/dev/mmcblk02
2021-05-06 15:05:39 [INFO] [mender-convert-modify] Using root device B in mender.conf:
/dev/mmcblk03
MENDER_STORAGE_DEVICE="/dev/mmcblk0p"
MENDER_STORAGE_DEVICE_BASE="/dev/mmcblk0p"
MENDER_DEVICE_TYPE="x86_64"
# Partition number of boot partition
MENDER_BOOT_PART_NUMBER="1"
# Partition number of root filesystem A
MENDER_ROOTFS_PART_A_NUMBER="2"
# Partition number of root filesystem B
MENDER_ROOTFS_PART_B_NUMBER="3"
# Partition number of persistent data partition
MENDER_DATA_PART_NUMBER="4"
# Use partition uuids rather than device and partition numbers
MENDER_ENABLE_PARTUUID="n"
# Partition used as the boot partition.
MENDER_BOOT_PART="${MENDER_STORAGE_DEVICE_BASE}1"
# Partition used as the first (A) rootfs partition.
MENDER_ROOTFS_PART_A="${MENDER_STORAGE_DEVICE_BASE}2"
# Partition used as the first (B) rootfs partition.
MENDER_ROOTFS_PART_B="${MENDER_STORAGE_DEVICE_BASE}3"
# Partition used as the persistent data partition.
MENDER_DATA_PART="${MENDER_STORAGE_DEVICE_BASE}4"
MENDER_STORAGE_TOTAL_SIZE_MB=16000
# 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
}
mender_config:
# Device file corresponding to the root filesystem partitions, without number.
MENDER_STORAGE_DEVICE_BASE=/dev/mmcblk0p
# Partition number of boot partition
MENDER_BOOT_PART_NUMBER="1"
# Partition number of root filesystem A
MENDER_ROOTFS_PART_A_NUMBER="2"
# Partition number of root filesystem B
MENDER_ROOTFS_PART_B_NUMBER="3"
# Partition number of persistent data partition
MENDER_DATA_PART_NUMBER="4"
# Use partition uuids rather than device and partition numbers
MENDER_ENABLE_PARTUUID="n"
# Partition used as the boot partition.
MENDER_BOOT_PART="${MENDER_STORAGE_DEVICE_BASE}1"
# Partition used as the first (A) rootfs partition.
MENDER_ROOTFS_PART_A="${MENDER_STORAGE_DEVICE_BASE}2"
# Partition used as the first (B) rootfs partition.
MENDER_ROOTFS_PART_B="${MENDER_STORAGE_DEVICE_BASE}3"
# Partition used as the persistent data partition.
MENDER_DATA_PART="${MENDER_STORAGE_DEVICE_BASE}4"
My command:
MENDER_ARTIFACT_NAME=$RELEASE_PREFIX-$(date +'%m-%d-%Y-%H-%M')
info "The new release name: ${MENDER_ARTIFACT_NAME}"
./scripts/bootstrap-rootfs-overlay-hosted-server.sh --output-dir ${PWD}/rootfs_overlay_demo --
tenant-token ${MENDERTOKEN}
MENDER_ARTIFACT_NAME=${MENDER_ARTIFACT_NAME} ./docker-mender-convert --disk-image
${INPUT} --config configs/generic_x86-64_hdd_config --overlay rootfs_overlay_demo/
This looks like a regression introduced with the PARTUUID support. It seems like this line is the root cause but I don’t know exactly what the fix is since it’s not immediately clear what this line is intending to do.
@dellgreen I think this was your feature. Do you have any ideas how to handle this?
cc: @oleorhagen@kacf
Its not immediately obvious to me how this is not failing for everyone else if its just this commit.
I think possibly there is an inconsistency here as to how MENDER_STORAGE_DEVICE_BASE can be interpreted semantically as most of the code for this commit was ported over from meta-mender.
looking at the commit it makes the assumption that MENDER_STORAGE_DEVICE_BASE should be the device path not including the partition suffix, however looking at some of the mender-configs files they make the assumption that MENDER_STORAGE_DEVICE_BASE should include ‘p’ (in the case of mmc) at the end of the device path which can be argued then isn’t the true device base path as you would expect the base block device to be.
Somewhere else in the code must also be conflicting as MENDER_ROOTFS_PART_B must be getting redefined somewhere else after this commit has redefined the MENDER_STORAGE_DEVICE_BASE.
One possible solution if the expectation the MENDER_STORAGE_DEVICE_BASE should contain everything up to an including the ‘p’ suffix is to edit the disk_get_device_base() function to return back everything but the partition number.
on further inspection i suspect that why most people are not hitting this issue is that they are not explicitly setting the fine-tuning exact devices paths in the following variables:
@Dirk you are defining both, theoretically if you remove the following from your config then it should work for you as by default these variables are empty.
@dellgreen yesterday I started first at all without any changes, but I runs direct into this issue. So I tried to solve this, and modified first the parameter “MENDER_STORAGE_DEVICE_BASE“ in the mender_config file. But it doesn’t work. Only after this I tried to modified the other values. I geted the same bevavior.
So I found the “MENDER_STORAGE_DEVICE_BASE“ parameter in generic_x86-64_hdd_config file and modified it too. The issue remained.
My solution was very simple, I reseted all configuration files an modified only the “MENDER_STORAGE_DEVICE_BASE“ parameter in the generic_x86-64_hdd_config file. Now it works fine for me.
For me wasn’t clearly witch file overwrite the other. This parameter are located in all other config files.
Glad you have it working, On a personal recommendation, i would recommend you take a look at using PARTUUIDS as a form of indirection, so that the same image you create can be used to write and boot from any storage medium without having to worry about what type of storage medium your target is using and the kernel naming convention for it. Mender stores the device names for A/B in the image.
The motivation for this, was that a single image can be used to image different types of devices and VM’s irrespective of the storage, i.e USB, NVME, SATA, PATA, SCSI, EMMC. Its helpful for testing as you can image a USB stick and boot PC from it.
The partuiids can be anything you like as long as they follow the PARTUUID naming convention and each PARTUUID is unique.