#2576 PR merged: Do not specify '-F 16' for mkfs.vfat and also no '-o fat=16' when mounting it

Labels: enhancement, cleanup, fixed / solved / done, minor bug

jsmeix opened issue at 2021-02-25 13:11:

Do no longer specify '-o fat=16' when loop mounting efiboot.img file
but rely on the automatic FAT type detection when mounting
cf. https://github.com/rear/rear/issues/2575
plus some general generic code cleanup in
output/ISO/Linux-i386/700_create_efibootimg.sh

jsmeix commented at 2021-02-25 13:27:

@gdha @gozora
could you have a look here if that change looks OK to you?

I wonder if -F 16 is actually needed for mkfs.vfat ?

output/ISO/Linux-ia64/200_mount_bootimg.sh
indicates -F 16 was specified because 'size >30MB'

# make sure we select FAT16 instead of FAT12 as size >30MB
mkfs.vfat $v -F 16 $TMP_DIR/boot.img

but on my openSUSE Leap 15.2 "man mkfs.vfat" reads (excerpt)

-F FAT-SIZE
  Specifies the type of file allocation tables used (12, 16 or 32 bit).
  If nothing is specified, mkfs.fat will automatically select between
  12, 16 and 32 bit, whatever fits better for the filesystem size.

so also for mkfs.vfat it seems to be better to
rely on what "mkfs.fat will automatically select".

jsmeix commented at 2021-02-25 13:43:

@rmetrich
could you have a look here if that should be OK for Red Hat
in particular for older Red Hat versions, see also
https://github.com/rear/rear/issues/2575#issuecomment-785901507
how things look on SLES11 according to what the man pages tell there.

jsmeix commented at 2021-03-01 12:48:

@gozora
thank you for having a look!
I did not expect that you test it.
But perhaps you had known a reason why FAT16 was enforced with -F 16
(there was no comment that could have explained why that -F 16 was there).

What do you think about
https://github.com/rear/rear/issues/2575#issuecomment-787922681

gozora commented at 2021-03-01 19:37:

Hello @jsmeix,

What do you think about

I think that changing defaults to 512MB is OK. 400MB is not a nice number and I'm not surprised that some UEFI versions might have problems with.

V.

jsmeix commented at 2021-03-03 12:13:

From my point of view this pull request is now sufficiently complete
so I would like to merge it tomorrow afternoon
unless there are objections.

jsmeix commented at 2021-03-04 12:35:

@OliverO2 @gozora
thank you for your help with this issue!
It is much appreciated because I am really not an expert in that area.

[Export of Github issue for rear/rear.]