Bug 1904779

Summary:	fwupdate fails after upgrade to Fedora 33: "no volumes of type"
Product:	[Fedora] Fedora	Reporter:	bz <bugzillas>
Component:	fwupd	Assignee:	Richard Hughes <rhughes>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	33	CC:	ahogbin, esm, frankk74, mo, rhughes
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-04-13 14:06:08 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:

Description bz 2020-12-06 10:57:59 UTC

Description of problem:

After upgrade to Fedora 33, "fwupdate" fails with error:
"failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7"


Version-Release number of selected component (if applicable):

Fedora 33
fwupdmgr 1.5.2


# fwupdmgr --version
client version:	1.5.2
compile-time dependency versions
	gusb:	0.3.5

daemon version:	1.5.2


# fwupdate --version
fwupd version: 1.5.2
failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7



How reproducible:

The original installation was Fedora 31. Upgraded to Fedora 32, and now upgraded to Fedora 33.
It was working in Fedora 32 several weeks ago.

"udisks2" is already installed.


Actual results:

Each "fwupdate" command fails with the error: 
"failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7"

And "fwupdmgr" commands fails with:
WARNING: UEFI ESP partition not detected or configured


Expected results:

No errors in "fwupdate" and "fwupdmgr" commands


Additional info:

# fwupdate --version
fwupd version: 1.5.2
failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7


As https://kimconnect.com/linux-an-experience-in-resizing-a-root-partition/, those codes are related to disk formatting options:
  EFI System                     C12A7328-F81F-11D2-BA4B-00A0C93EC93B
  Microsoft basic data           EBD0A0A2-B9E5-4433-87C0-68B6B72699C7



# fwupdmgr get-devices
WARNING: UEFI ESP partition not detected or configured
  See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found for more information.



# fwupdtool esp-list --verbose
19:33:49:0318 FuDebug              Verbose debugging enabled (on console 1)
19:33:49:0336 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
19:33:49:0339 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x8e, internal: 1, fs: LVM2_member
19:33:49:0345 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0x06, internal: 1, fs: vfat
19:33:49:0345 FuMain               no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b, falling back to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
19:33:49:0359 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
19:33:49:0363 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x8e, internal: 1, fs: LVM2_member
19:33:49:0369 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0x06, internal: 1, fs: vfat
no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7



# dnf list "*udisk*"

Installed Packages
libudisks2.x86_64                                                                                                        2.9.1-2.fc33                                                                                                  @fedora
udisks2.x86_64                                                                                                           2.9.1-2.fc33                                                                                                  @fedora
udisks2-iscsi.x86_64                                                                                                     2.9.1-2.fc33                                                                                                  @fedora
Available Packages



# lsblk 
NAME                            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1                         259:0    0 476.9G  0 disk 
├─nvme0n1p1                     259:1    0   600M  0 part /boot/efi
├─nvme0n1p2                     259:2    0     1G  0 part /boot
└─nvme0n1p3                     259:3    0 475.4G  0 part 
  ├─fedora_localhost--live-root 253:0    0    70G  0 lvm  /
  ├─fedora_localhost--live-swap 253:1    0     8G  0 lvm  [SWAP]
  └─fedora_localhost--live-home 253:2    0 397.4G  0 lvm  /home



# df -Th /boot/
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p2 ext4  976M  297M  612M  33% /boot


# df -Th /boot/efi/
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p1 vfat  599M   30M  570M   5% /boot/efi

Comment 1 bz 2020-12-11 08:55:36 UTC

Same error with version 1.5.3:

# fwupdate --version
fwupd version: 1.5.3
failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

Comment 2 bz 2020-12-29 17:21:51 UTC

Still failing in 1.5.4

# fwupdate --version
fwupd version: 1.5.4
failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

Comment 3 Richard Hughes 2020-12-30 17:10:02 UTC

What does "sudo fwupdtool esp-list --verbose" say?

Comment 4 Ed Marshall 2021-01-29 21:29:13 UTC

I'm not the original reporter, but I'm also seeing this on a Dell XPS13 with Fedora 33.

$ sudo /usr/bin/fwupdtool esp-list --verbose
21:20:09:0462 FuDebug              Verbose debugging enabled (on console 1)
21:20:09:0493 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
21:20:09:0496 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x83, internal: 1, fs: crypto_LUKS
21:20:09:0501 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p4, type: 0x05, internal: 1, fs: 
21:20:09:0504 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p5, type: 0x83, internal: 1, fs: crypto_LUKS
21:20:09:0511 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0xef, internal: 1, fs: vfat
21:20:09:0512 FuMain               no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b, falling back to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
21:20:09:0539 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
21:20:09:0542 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x83, internal: 1, fs: crypto_LUKS
21:20:09:0547 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p4, type: 0x05, internal: 1, fs: 
21:20:09:0550 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p5, type: 0x83, internal: 1, fs: crypto_LUKS
21:20:09:0556 FuCommon             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0xef, internal: 1, fs: vfat
no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

In my case, /dev/nvme0n1p1 is /boot/efi.

$ sudo udisksctl info --block-device /dev/nvme0n1p1 
/org/freedesktop/UDisks2/block_devices/nvme0n1p1:
  org.freedesktop.UDisks2.Block:
    Configuration:              [('fstab', {'fsname': <b'UUID=60EA-FBD8'>, 'dir': <b'/boot/efi'>, 'type': <b'vfat'>, 'opts': <b'umask=0077,shortname=winnt'>, 'freq': <0>, 'passno': <2>})]
    CryptoBackingDevice:        '/'
    Device:                     /dev/nvme0n1p1
    DeviceNumber:               66305
    Drive:                      '/org/freedesktop/UDisks2/drives/KXG60ZNV256G_NVMe_TOSHIBA_256GB_499S11GFTH8Q'
    HintAuto:                   false
    HintIconName:               
    HintIgnore:                 true
    HintName:                   
    HintPartitionable:          true
    HintSymbolicIconName:       
    HintSystem:                 true
    Id:                         by-id-nvme-KXG60ZNV256G_NVMe_TOSHIBA_256GB_499S11GFTH8Q-part1
    IdLabel:                    
    IdType:                     vfat
    IdUUID:                     60EA-FBD8
    IdUsage:                    filesystem
    IdVersion:                  FAT16
    MDRaid:                     '/'
    MDRaidMember:               '/'
    PreferredDevice:            /dev/nvme0n1p1
    ReadOnly:                   false
    Size:                       209715200
    Symlinks:                   /dev/disk/by-id/nvme-KXG60ZNV256G_NVMe_TOSHIBA_256GB_499S11GFTH8Q-part1
                                /dev/disk/by-id/nvme-eui.00000000000000018ce38e0200060f19-part1
                                /dev/disk/by-partuuid/22c1bf7b-01
                                /dev/disk/by-path/pci-0000:3c:00.0-nvme-1-part1
                                /dev/disk/by-uuid/60EA-FBD8
    UserspaceMountOptions:      
  org.freedesktop.UDisks2.Filesystem:
    MountPoints:        /boot/efi
    Size:               0
  org.freedesktop.UDisks2.Partition:
    Flags:              128
    IsContained:        false
    IsContainer:        false
    Name:               
    Number:             1
    Offset:             1048576
    Size:               209715200
    Table:              '/org/freedesktop/UDisks2/block_devices/nvme0n1'
    Type:               0xef
    UUID:               22c1bf7b-01

I'm guessing this got created incorrectly when I originally installed Fedora.

Comment 5 Ed Marshall 2021-01-29 22:00:57 UTC

Aaaaaaand, I'm an idiot. Not sure how I missed this, but disklabel was mbr instead of gpt (despite being mostly set up for uefi boot; even the bios was correctly configured, I'm unsure how this was even booting). After converting to gpt, no more problems. Sigh. I'm pretty sure I started out with F31 with this machine, and don't recall doing anything special wrt to UEFI.

I'm guessing the original reporter has the same problem, based on the udisks output and errors they're getting.

Comment 6 Frank K 2021-01-31 22:42:09 UTC

Thanks everyone for updating this bug report.

Same problem for me on two different f33 "new" installs of Fedora.

The previous poster noted the GPT/MBR "issue" which is probably the root cause.

I am posting this here for 2 reasons:

1. the fix to update mbr/gpt label on the disk is not clear to me as to how to implement?

2. i have 2 new installs of f33 using defaults including brtfs so the base install is potentially introducing this?

If this is an upstream app problem I can open a ticket on their github page (https://github.com/fwupd/fwupd)... but it is looking like a new f33 base install issue?

Any thoughts?

Thx
Frank

Comment 7 Frank K 2021-01-31 23:51:51 UTC

Maybe the title of this bug should be changed from:

fwupdate fails after upgrade to Fedora 33: "no volumes of type"

to

fwupdate fails on base or upgraded Fedora 33: "no volumes of type"

here is the info:

[root@fedora33 ~]# fwupdmgr --version
client version:	1.5.5
compile-time dependency versions
	gusb:	0.3.5

Unknown                  [***************************************]
daemon version:	1.5.5
[root@fedora33 ~]# fwupdate --version
fwupd version: 1.5.5
failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
[root@fedora33 ~]# /usr/bin/fwupdtool esp-list --verbose
22:28:09:0092 FuDebug              Verbose debugging enabled (on console 1)
22:28:09:0139 FuCommon             device /org/freedesktop/UDisks2/block_devices/sda1, type: 0x83, internal: 1, fs: ext4
22:28:09:0147 FuCommon             device /org/freedesktop/UDisks2/block_devices/sda2, type: 0x83, internal: 1, fs: btrfs
22:28:09:0150 FuMain               no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b, falling back to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
22:28:09:0191 FuCommon             device /org/freedesktop/UDisks2/block_devices/sda1, type: 0x83, internal: 1, fs: ext4
22:28:09:0198 FuCommon             device /org/freedesktop/UDisks2/block_devices/sda2, type: 0x83, internal: 1, fs: btrfs
no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

Comment 8 Richard Hughes 2021-03-02 16:51:02 UTC

I think this is fixed in fwupd 1.5.7, right? https://github.com/fwupd/fwupd/commit/ad3cfc0fea1e0bd21a74131fe9f2789b83e1d73c

Comment 9 Mo 2021-03-14 20:58:04 UTC

I still have the issue with

----8<----
➜  ~ fwupdmgr --version
client version:	1.5.7
compile-time dependency versions
	gusb:	0.3.5

daemon version:	1.5.7
----8<----

on Feodra 33.

Comment 10 Richard Hughes 2021-04-13 14:06:08 UTC

(In reply to Frank K from comment #7)
> failed: no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes
> of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> [root@fedora33 ~]# /usr/bin/fwupdtool esp-list --verbose
> 22:28:09:0092 FuDebug              Verbose debugging enabled (on console 1)
> 22:28:09:0139 FuCommon             device
> /org/freedesktop/UDisks2/block_devices/sda1, type: 0x83, internal: 1, fs:
> ext4
> 22:28:09:0147 FuCommon             device
> /org/freedesktop/UDisks2/block_devices/sda2, type: 0x83, internal: 1, fs:
> btrfs
> 22:28:09:0150 FuMain               no volumes of type
> c12a7328-f81f-11d2-ba4b-00a0c93ec93b, falling back to
> ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> 22:28:09:0191 FuCommon             device
> /org/freedesktop/UDisks2/block_devices/sda1, type: 0x83, internal: 1, fs:
> ext4
> 22:28:09:0198 FuCommon             device
> /org/freedesktop/UDisks2/block_devices/sda2, type: 0x83, internal: 1, fs:
> btrfs
> no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b: no volumes of type
> ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

Unless I'm very confused, there's no ESP present there. I guess you're booting in BIOS compatibility mode, and you won't be able to do firmware updates using UEFI update capsule. We already fall back and assume the ESP is a 0xef (ESP) or 0x0b (vfat) partition if the disk has no EFI partition table and I think that's the best we can do, sorry.