Check FAT format - Config PART /boot/efi esp 256M

[mvphost]

The following is suggested to create an ESP :

          add this to the config `PART /boot/efi esp 256M`

Originally posted by @Lusitaniae in #63 (comment)

I would suggest that the code - if not already present - checks for the proper FAT format, being either FAT12, FAT16, FAT32.

This to prevent that nvme disks are refusing efi boots.

For instance, this can occur when using 4KiB clusters on the nvme disk.

These 4KiB clusters require at least 256.5 MiB.

Is it possible to include a sectors-per-cluster check that allows the appropriate FAT format to be set, given a specific amount of MiB (or MB) set at /boot/efi ?

[asciiprod]

Do you mean you are using 4K disk sectors instead of 512B? While there are some provisions, using 4K sectors is untested and currently not supported by installimage.

[mvphost]

That is correct, I am "testing" 4KiB sectors.......

....... and the main purpose (of one of the tests) is to test the (proper) functionality of the installimage script.

The test setup is :

• 2x 960 GB nvme disks
• 2x 3.84 TB nvme disks

and that test setup should become and/or result in :

1 - 2x 960 GB in RAID 1, with

1.1 - gpt : intallimage automatically sets dos partitions, but this can be enforced by FORCE_GPT 1 (no issues here)
1.2 - BIOS boot : installimage takes care of that (no issues here)
1.3 - /boot : a boot partition of 512M in ext3 format (issues here, the /boot is not mounted - see details below)
1.4 - / : a general partition in xfs format (issues here - see details below)

2 - 2x 3.84TB in RAID 1, with

2.1 - gpt : installimage configures this correctly by default (no issues here)
2.2 - /[dirname] : a general partition with xfs format (minor issues here - see details below)

and please note that the disk sizes are in line with the server hardware - they are "as delivered", so the disk sizes themselves are not (test) variables in this setup.

A - GENERAL ISSUE 1 :
Installimage is rather random when setting up multiple disks : including all disks gives unpredicted RAID 1 results.

SOLUTION : allow installimage to configure other RAID setups that include separate sets of disk arrays.

EXAMPLE : 2x 2x disks (4 disks) should be configurable in 2x RAID 1 disk arrays

ISSUE: installimage does not allow this type of behavior (read: it - by default - includes ALL disks for RAID purposes)
ISSUE: installimage creates partitions as instructed (without making distinctions between disks or disk sizes)

WORKAROUND : exclude a subset of disks and create the RAID 1 disk array afterwards

NOTE : the workaround provides a simple solution for an improvement of the installimage script - it can be simply altered to create a (re-)iteration of subsets of code that handle or deal with partitioning and RAID setup : just run a subset of code first on a disk array and then rerun the same subset of code on another disk array ......

.... and this (re-)iteration / rerunning of code would prevent any unexpected and random (RAID and partitioning) behavior, as well as allow installimage to deal properly with RAID configurations that involve multiple RAID x disk arrays.

B - GENERAL ISSUE 2 :
Installimage does not clean the system properly, when the installimage script is rerun in a system started in Rescue mode.

As a result, RAID and/or partitioning settings are left behind, creating unpredictable behavior when the installimage is rerun for the (second, third and so on) time.

As an endresult, the system become unbootable after rerunning installimage !!!

SOLUTION : not present

WORKAROUND : not known to me, working on it

C - ISSUE - see 2.2
Installimage does not mount the /[dirname] (a general partition with xfs format) on the 2x 3.84TB disks in RAID 1.

This is surprising, since installimage should not be bothered at all by

• the xfs format : this is supported,
• the gpt partitioning : that is default.

The 4KiB sectors should not matter at all.

NOTE : manually creating a RAID 1 and mounting the raid device works like a charm, so there is no reason to assume that the 4KiB sectors are problematic.

ISSUE : installimage does not populate /etc/fstab

D - ISSUE - see 1.3 and 1.4
Installimage does not mount the /boot partition and the / partition on the 2x 960GB disks in RAID 1.

Again, xfs format and gpt partitioning cannot be the culprit.

Again, the 4KiB sectors should not matter at all.

ISSUE : installimage is not able to populate /etc/fstab - it is completely empty!!

CAUSE: it is (very likely) to be the endresult of installimage not cleaning previous installations properly.

IMPORTANT: the gdisk -Z command, used by installimage, does not always result in the expected wipe of disk data - I am not sure why and when this happens, but it happens : I have to clean the disk data manually (and with crude measures).

IMPORTANT NOTE : even when manually populating /etc/fstab, the server still will not boot - this is a clear indication that the issue is not related to the 4KiB sectors and/or the installimage script failing to populate /etc/fstab.

Can anyone give me some more input and/or solutions?

I will keep you (all) updated.

Kind regards .......