RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2119436 - EFI partition configured as FAT16 instead of 32
Summary: EFI partition configured as FAT16 instead of 32
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: fwupd
Version: CentOS Stream
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard Hughes
QA Contact: Oliver Gutiérrez
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-08-18 14:24 UTC by Carlos Mogas da Silva
Modified: 2023-05-09 10:24 UTC (History)
5 users (show)

Fixed In Version: fwupd-1.8.10-2.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-09 08:18:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
anaconda-logs.tar.xz (340.67 KB, application/x-xz)
2022-08-19 11:10 UTC, Carlos Mogas da Silva 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1975375 0 unspecified CLOSED Rawhide arm/aarch64 disk images fail to boot on Raspberry Pi SBCs 2022-08-23 09:55:01 UTC
Red Hat Issue Tracker RHELPLAN-131455 0 None None None 2022-08-18 14:37:11 UTC
Red Hat Product Errata RHSA-2023:2487 0 None None None 2023-05-09 08:18:18 UTC

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
Note You need to log in before you can comment on or make changes to this bug.