Bug 2119436

Summary: EFI partition configured as FAT16 instead of 32
Product: Red Hat Enterprise Linux 9 Reporter: Carlos Mogas da Silva <r3pek>
Component: fwupdAssignee: Richard Hughes <rhughes>
Status: CLOSED ERRATA QA Contact: Oliver Gutiérrez <ogutierr>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bstinson, jstodola, jwboyer, richard, vtrefny
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: fwupd-1.8.10-2.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-09 08:18:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
anaconda-logs.tar.xz none

Description Carlos Mogas da Silva 2022-08-18 14:24:06 UTC 
Description of problem:
A recently installed server got configured with a FAT16 /boot/efi when in reality it is a FAT32 (MBR).
Found out about the issue (vfat really doesn't care AFAIK) because fwupdmgr complains about a missing ESP/EFI partition.


Version-Release number of selected component (if applicable): don't really know the anaconda version, but it's the same that's on the release iso (if it didn't change on the last 15 days)


How reproducible: didn't try it


Steps to Reproduce:
1. install centos with a split /boot/efi
2. check efi partition type with fdisk
3. check what the actual fs is on the partition

Actual results:
# fdisk -l /dev/nvme0n1

Device         Boot     Start        End   Sectors   Size Id Type
/dev/nvme0n1p1 *         2048    1230847   1228800   600M  6 FAT16

# file -s /dev/nvme0n1p1 
/dev/nvme0n1p1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 32, heads 64, hidden sectors 2048, sectors 1228800 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1200, reserved 0x1, serial number 0x1f25a1b2, unlabeled

Expected results:
fdisk shoud report FAT32

Additional info:
Comment 1 Jan Stodola 2022-08-19 07:46:48 UTC 
Can you please provide the installation logs? You can find them in /var/log/anaconda on the installed system.

I tried to reproduce the problem with a fresh installation in a VM using CentOS-Stream-9-20220808.1-x86_64 and the partition type was set to "EFI System":

[root@localhost ~]# fdisk -l /dev/vda
Disk /dev/vda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A0A5FCB3-8E98-47B4-A614-F3BE5F3D7F9E

Device       Start      End  Sectors  Size Type
/dev/vda1     2048  1230847  1228800  600M EFI System
/dev/vda2  1230848  3327999  2097152    1G Linux filesystem
/dev/vda3  3328000 41940991 38612992 18.4G Linux LVM
[root@localhost ~]#

(but as you can see, I didn't use an NVMe device)
Comment 2 Carlos Mogas da Silva 2022-08-19 11:10:36 UTC 
Created attachment 1906538 [details]
anaconda-logs.tar.xz

The partition type is MBR, not GPT.

I'll leave the logs anyway.
Comment 3 Jan Stodola 2022-08-23 09:33:48 UTC 
Right, thanks for pointing out it's MBR. I'm able to reproduce it now as well.

Vojto, is the partition type set by blivet? or parted?
Comment 4 Vojtech Trefny 2022-08-23 09:55:01 UTC 
The partition type is set by blivet, we set the parted PARTITION_BOOT flag for /boot/efi on msdos partition table which sets the partition type to 0x06. We had a bug for fedora few releases back to change this to the PARTITION_ESP flag which sets the partition type to 0xef[1] (which should be the correct partition ID for EFI partition[2]), but we had to revert this because on some systems this actually caused it to not boot[3], so from my point of view, there actually isn't a "correct" partition type for ESP on msdos but if the systems boots with 0x06 we shouldn't change that to something that can make other systems unbootable and it should be fixed in fwupdmgr (if possible) and not in Anaconda/Blivet.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1930486
[2] https://en.wikipedia.org/wiki/Partition_type#PID_EFh
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1975375
Comment 5 Jan Stodola 2022-08-23 10:28:41 UTC 
Thanks for the background, Vojto.
Moving the bug to fwupd in case the problem can be fixed there.
Comment 6 Richard Hughes 2022-08-23 15:56:36 UTC 
Carlos, can you get me the output of `sudo fwupdtool esp-list -v` please.
Comment 7 Carlos Mogas da Silva 2022-08-23 17:46:20 UTC 
Hi @richard 
I pinged you at twitter about this ;) (https://twitter.com/r3pek/status/1560238561957388288)

# fwupdtool esp-list -v
17:43:57:0880 FuDebug              Verbose debugging enabled (on console 1)
17:43:57:0893 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
17:43:57:0895 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x82, internal: 1, fs: swap
17:43:57:0897 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p4, type: 0x0f, internal: 1, fs: 
17:43:57:0898 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p5, type: 0x83, internal: 1, fs: ext4
17:43:57:0901 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0x06, internal: 1, fs: vfat
17:43:57:0903 FuMain               no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b, falling back to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
17:43:57:0912 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
17:43:57:0913 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x82, internal: 1, fs: swap
17:43:57:0915 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p4, type: 0x0f, internal: 1, fs: 
17:43:57:0916 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p5, type: 0x83, internal: 1, fs: ext4
17:43:57:0919 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0x06, 
no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

# lsblk
NAME                                                                                                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                                                                                                     8:0    1   3.6T  0 disk 
└─ceph--b116ccdb--9a2e--4a42--b3bb--6aeac44fed0e-osd--block--3b6803ee--6ae2--4f14--b7de--f329da227435 253:1    0   3.6T  0 lvm  
sdb                                                                                                     8:16   1   3.6T  0 disk 
└─ceph--03ecb5b3--f97d--49fd--956e--59c5d063cb16-osd--block--6f995948--e86c--48df--a138--dcd84f4374b8 253:0    0   3.6T  0 lvm  
nvme0n1                                                                                               259:0    0 476.9G  0 disk 
├─nvme0n1p1                                                                                           259:1    0   600M  0 part /boot/efi
├─nvme0n1p2                                                                                           259:2    0 459.4G  0 part /var/lib/containers/storage/overlay
│                                                                                                                               /
├─nvme0n1p3                                                                                           259:3    0    16G  0 part [SWAP]
├─nvme0n1p4                                                                                           259:4    0     1K  0 part 
└─nvme0n1p5                                                                                           259:5    0     1G  0 part /boot

# fdisk -l  /dev/nvme0n1
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: SAMSUNG MZVLB512HBJQ-00000              
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x61c84605

Device         Boot     Start        End   Sectors   Size Id Type
/dev/nvme0n1p1 *         2048    1230847   1228800   600M  6 FAT16
/dev/nvme0n1p2        1230848  964560895 963330048 459.4G 83 Linux
/dev/nvme0n1p3      964560896  998113279  33552384    16G 82 Linux swap / Solaris
/dev/nvme0n1p4      998113280 1000214527   2101248     1G  f W95 Ext'd (LBA)
/dev/nvme0n1p5      998117376 1000214527   2097152     1G 83 Linux
Comment 8 Richard Hughes 2022-08-23 19:25:18 UTC 
Upstream patch for review: https://github.com/fwupd/fwupd/pull/4939
Comment 10 Oliver Gutiérrez 2023-01-31 12:20:03 UTC 
After talking with Richard, the fix for this bug is included in the rebase https://bugzilla.redhat.com/show_bug.cgi?id=2165096

I will ack the bug and verify this special case manually after verifying the rebase.
Comment 18 errata-xmlrpc 2023-05-09 08:18:05 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: fwupd security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2487