From what I have read, a raspberry pi 3b should be able to boot with the boot partition’s file system either FAT16 or FAT32.
My issue is that some of my raspberry pis don’t boot unless I remake the filesystem as FAT32 and replace the files of the boot partition.
This happens with my yocto build and also the mender raspberry pi demo images found here https://docs.mender.io/2.1/getting-started/download-test-images. I’ve also tried previous versions 1.6 and 1.7.
Is there a way to set the filesystem type to FAT32 for the boot partition instead of FAT16?
Changing the mkfs call of the sdcard_image-rpi within meta-raspberrypi doesn’t seem to work since rpi-sdimg is removed from IMAGE_FSTYPES in conf/local.conf.
Where/when is the uboot.env populated with the boot partition files?
Correct me if I’m wrong, with the raspberrypi, the boot partition is rawcopy from uboot.env within mender-part-image.bbclass.
All suggestions are greatly appreciated.
My apologizes if there is a enforced forum format which I have not followed.
Hi @conker00, welcome to Mender hub.
I think you should be able to set the “MENDER_BOOT_PART_FSTYPE” bitbake variable to handle this.
Thank you for the suggestion. Unfortunately, changing the MENDER_BOOT_PART_FSTYPE variable didn’t help. It appears to only change the entry within fstab.
I’ve done some more reading about my issue and it seems to be a rare occurrence on the cm3 as described in the troubleshooting section here
For a small percentage of Raspberry Pi Compute Module 3s, booting problems have been reported. We have traced these back to the method used to create the FAT32 partition; we believe the problem is due to a difference in timing between the BCM2835/6/7 and the newer eMMC devices. The following method of creating the partition is a reliable solution in our hands.
sudo parted /dev/<device>
(parted) mkpart primary fat32 4MiB 64MiB
sudo mkfs.vfat -F32 /dev/
$ sudo cp -r /*
I have tried a build with MACHINE = “raspberrypi-cm3” with the same results.
My current workaround is to recreate the filesystem as described in the same troubleshooting section directly on the built image using loop devices.
$sudo fdisk -lu core-image-base.sdimg
$sudo losetup --offset $((<sector size> * <boot partition start>)) --sizelimit $((<sector size> * <sectors in boot partition>)) --show --find core-image-base.sdimg
$sudo mkdir -p /mnt/img
$sudo mount /dev/loopX /mnt/img # where loopX is the device from losetup
$sudo cp -r /mnt/img/* backup/
$sudo umount /mnt/img
$sudo mkfs.vfat -F32 /dev/loopX
$sudo mount /dev/loopX /mnt/img
$sudo cp -r backup/* /mnt/img/
$sudo umount /mnt/img
$sudo losetup -d /dev/loopX
@conker00 is the only difference the forcing if 32-bit using “-F32” with mkfs.vfat?
I do see that mender-part-images.bbclass always uses type vfat instead of MENDER_BOOT_PART_FSTYPE. @kacf is that intentional or should we update it to use MENDER_BOOT_PART_FSTYPE there?
Although it sounds like in this case it wouldn’t help since it appears to be hardware-releated. The bbclass uses WIC to create the file so that logic would somehow need to force 32-bit if that is indeed the fix.
From my understanding, yes. Just forcing with mkfs.vfat -F32 fixes the issue. The partition was not altered.
I believe that should be changed, yes. Be aware that
MENDER_BOOT_PART_FSTYPE is often set to
auto though, since it is primarily used in
/etc/fstab at the moment. There is some similar handling for
MENDER_DATA_PART_FSTYPE, which can be used for inspiration.
Great. I created https://github.com/mendersoftware/meta-mender/pull/1035 which should allow the boot partition type and options to be customized.
@conker00 once this is merged you can specify:
MENDER_BOOT_PART_FSOPTS_append = " -F 32 "
to avoid the post processing step. If you have a chance to test it and confirm whether it works for you or not that would be most helpful.