cragw

> @CragW > > Hello, > > I didn't see your comment. Could you help to review it? Here you go the link to discussion in launchpad: https://bugs.launchpad.net/somerville/+bug/2047010/comments/4

> Here is the debug output for different boot on the same machine. you can see that order and index is changed. It's weird that `/dev/nvme0n1` device is being assigned...

> Yes, the userspace reflect sysfs node /sys/class/nvme/nvme0/serial correctly, and the order was changed from time to time. In this case, the target disk for OS installation would be unpredicable...

User needs to determine which drive to be erased for OS installation. With regarding to nvme index somewhat inconsistent to be default selected, I would recommend to compare the PCI...

> I don't see device address in the disk object, I don't know how can you retrieve it. It's essentially in the Symlinks in the Block object, do you have...

> what about the mdraid and mmcblk scenario? I would expect a PCI slot for `mmcblk` too, so the pci address logic apply no problem. On the other hand, the...

What's your system model and OS you're trying to recovery?

> Is `/etc/fwupd/remotes.d/oem-embargo.conf` still set as .xz or did fwupd "upgrade" it to `gz`? The conff persists with `xz` in file. > If you set it to `zst` instead does...

I've just tested this issue with fwupd 1.9.16, the metadata persist with `zst` regardless the `MetadataURI` in conff is given to `xz`. It looks like fwupd 1.9.5 persists with `gz`,...

Sounds like an intentional enforcement to a predefined postfix file format regardless `metadatauri`, as `gz` is in older fwupd. If that is the case then this is probably a won't...