Created attachment 1539048 [details] lshw.xml Intel NUC, x86_64 Fedora 29 kernel 4.20.12-200.fc29.x86_64 (gcc version 8.2.1 20181215) glibc-2.28-26.fc29.x86_64 lshw-B.02.18-18.fc29.x86_64 It seems if lshw doesn't know what it is, description defaults to "EFI partition". *-volume:0 description: EFI partition *-volume:1 UNCLAIMED description: EFI partition *-volume:2 description: EFI partition None of these are EFI partitions. The GPT uses type guid 0FC63DAF-8483-4772-8E79-3D69D8477DE4 for Linux filesystem for all three. 0=Btrfs, 1=plaincrypt, 2=LUKS. *-volume:3 description: Windows FAT volume vendor: mkfs.fat This volume is in fact an EFI system partition, and has guid type code C12A7328-F81F-11D2-BA4B-00A0C93EC93B. It's better described as "EFI system" than "Windows FAT volume".
Yeah, something is wrong here. Can you post output from: gdisk -l /dev/sda or fdisk -l /dev/sda
The originally reported hardware is not immediately available. On my laptop running Fedora 30 lshw-B.02.18-20.fc30.x86_64 with NVMe, lshw doesn't show any partitions at all, maybe it doesn't support NVMe. I'll report back in a few days once the original hardware becomes available again.
Yeah, that's different problem: https://github.com/lyonel/lshw/pull/45
NVME fix available: https://bodhi.fedoraproject.org/updates/FEDORA-2019-bbf31538c7
OK with the NVMe fix, I can reproduce this bug on different hardware running Fedora 30 than was originally reported above. *-nvme description: Non-Volatile memory controller product: NVMe SSD Controller SM951/PM951 vendor: Samsung Electronics Co Ltd physical id: 0 bus info: pci@0000:6d:00.0 logical name: /dev/nvme0 version: 01 width: 64 bits clock: 33MHz capabilities: nvme pm msi pciexpress msix nvm_express bus_master cap_list configuration: driver=nvme latency=0 resources: irq:16 memory:9b000000-9b003fff ioport:3000(size=256) *-disk description: NVMe disk product: SAMSUNG MZVLV256HCHP-000H1 physical id: 0 logical name: /dev/nvme0n1 version: BXV72H0Q serial: [REMOVED] size: 238GiB (256GB) capabilities: gpt-1.00 partitioned partitioned:gpt configuration: guid=ffb6fbf4-ba2a-461c-bde8-b8b6ce43bb5a logicalsectorsize=512 sectorsize=512 *-volume:0 description: Windows NTFS volume vendor: Windows physical id: 1 logical name: /dev/nvme0n1p1 version: 3.1 serial: [REMOVED] size: 497MiB capacity: 498MiB capabilities: boot precious nomount ntfs initialized configuration: clustersize=4096 created=2018-06-26 01:53:36 filesystem=ntfs label=Recovery state=clean *-volume:1 description: Windows FAT volume vendor: MSDOS5.0 physical id: 2 logical name: /dev/nvme0n1p2 logical name: /boot/efi version: FAT32 serial: [REMOVED] size: 76MiB capacity: 99MiB capabilities: boot nomount fat initialized configuration: FATs=2 filesystem=fat mount.fstype=vfat mount.options=rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro name=EFI system partition state=mounted *-volume:2 description: reserved partition vendor: Windows physical id: 3 logical name: /dev/nvme0n1p3 serial: [REMOVED] capacity: 15MiB capabilities: nofs nomount *-volume:3 description: Windows NTFS volume vendor: Windows physical id: 4 logical name: /dev/nvme0n1p4 version: 3.1 serial: [REMOVED] size: 49GiB capacity: 49GiB capabilities: ntfs initialized configuration: clustersize=4096 created=2018-06-26 01:53:39 filesystem=ntfs name=windows10 state=clean *-volume:4 description: Windows NTFS volume vendor: Windows physical id: 5 logical name: /dev/nvme0n1p5 version: 3.1 serial: [REMOVED] size: 917MiB capacity: 941MiB capabilities: boot precious nomount ntfs initialized configuration: clustersize=4096 created=2019-03-05 00:50:38 filesystem=ntfs state=clean *-volume:5 UNCLAIMED description: EFI partition physical id: 6 serial: [REMOVED] capacity: 8191MiB configuration: name=cryptoswap *-volume:6 description: EFI partition physical id: 7 logical name: /dev/nvme0n1p7 logical name: / logical name: /home serial: [REMOVED] capacity: 177GiB configuration: mount.fstype=btrfs mount.options=rw,seclabel,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=257,subvol=/home30 name=linux state=mounted *-volume:7 description: EFI partition physical id: 8 logical name: /dev/nvme0n1p8 serial: [REMOVED] capacity: 1919MiB configuration: name=spare [chris@flap ~]$ sudo blkid /dev/nvme0n1: PTUUID="ffb6fbf4-ba2a-461c-bde8-b8b6ce43bb5a" PTTYPE="gpt" /dev/nvme0n1p1: LABEL="Recovery" UUID="AA1CC9AC1CC9743B" TYPE="ntfs" PARTUUID="9c7a60bd-98dc-4a88-87d7-6df67fcad985" /dev/nvme0n1p2: UUID="54CA-6D03" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="0273e9d0-2c96-49fc-a046-b67914664deb" /dev/nvme0n1p3: PARTUUID="9df407fc-1e6e-4d5c-ada9-35c8c77265e7" /dev/nvme0n1p4: UUID="328ECBDC8ECB972F" TYPE="ntfs" PARTLABEL="windows10" PARTUUID="bfd45d0a-4353-4d64-9801-4c32dc10c05c" /dev/nvme0n1p5: UUID="6A821FC8821F97A1" TYPE="ntfs" PARTUUID="9f77809c-9b4f-4d55-afc8-27af9d3c65d0" /dev/nvme0n1p6: PARTLABEL="cryptoswap" PARTUUID="688b193f-3b38-4ca5-8b65-2ef61f27ec83" /dev/nvme0n1p7: LABEL="fedora" UUID="2662057f-e6c7-47fa-8af9-ad933a22f6ec" UUID_SUB="7d9fb14c-d135-4bf6-8bc7-b92f2f1168c6" TYPE="btrfs" PARTLABEL="linux" PARTUUID="c05e54f1-86ea-4232-89b4-fe7add49a6d8" /dev/nvme0n1p8: LABEL="varlogs" UUID="8dc11660-492e-4a18-bee0-1df256fd5101" TYPE="f2fs" PARTLABEL="spare" PARTUUID="07e9aac9-b75c-4998-8c31-2ff7bde12a87" /dev/mapper/eswap: UUID="285f7650-d949-4308-bf21-e2b3e20c525d" TYPE="swap" [chris@flap ~]$ [chris@flap ~]$ sudo gdisk -l /dev/nvme0n1 GPT fdisk (gdisk) version 1.0.4 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/nvme0n1: 500118192 sectors, 238.5 GiB Model: SAMSUNG MZVLV256HCHP-000H1 Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): FFB6FBF4-BA2A-461C-BDE8-B8B6CE43BB5A Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 500118158 Partitions will be aligned on 2048-sector boundaries Total free space is 4791 sectors (2.3 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 1023999 499.0 MiB 2700 2 1024000 1228799 100.0 MiB EF00 EFI system partition 3 1228800 1261567 16.0 MiB 0C01 4 1261568 104185126 49.1 GiB 0700 windows10 5 104185856 106115071 942.0 MiB 2700 6 106117120 122894335 8.0 GiB 8300 cryptoswap 7 122894336 496187391 178.0 GiB 8300 linux 8 496187392 500118158 1.9 GiB 8300 spare [chris@flap ~]$ Referring to the lshw output: volume 0 info looks sane volume 1 info has problems, the description "Windows FAT volume" is not as correct as "EFI system partition". This is the real and only EFI system partition. volume 2 info looks sane volume 3 info looks sane volume 4 info looks sane volume 5 info has problems, it's not EFI, this is a plain dmcrypt volume (random seed at boot, no header). Nothing could be expected to know what the contents are or who claims it, but the GPT partition type GUID suggests it's for Linux usage so it could be LINUX UNKNOWN with no description. volume 6 info has problems, it's not EFI, it's an unencrypted Btrfs volume. volume 7 info has problems, it's not EFI, it's an f2fs volume.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.