Closed mvphost closed 1 month ago
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.
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 :
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 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 .......
Thank you for the extensive report, however using 4k sector is currently not supported at all and is expected to break at various levels.
I am sorry, but
why does Hetzner sell expensive disks with 4K sector support if they cannot be supported by Hetzner?
why does Hetzner not support 4K disks if it is actually possible to configure and USE those disks in 4K mode?
In short, I am flabergasted.
You state
" .... is expected to break at various levels."
Could you give me an indication of the levels at which 4K support could "break" and what exactly could be "broken"?
Kind regards.....
The following is suggested to create an ESP :
Originally posted by @Lusitaniae in https://github.com/hetzneronline/installimage/issues/63#issuecomment-1652892021
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 ?