unable to get udev info for sdd

[rugk]

STR: Start blivet GUI. It scans for devices then.

If I have an external LUKS2 device connected, I get this:

  File "/usr/lib/python3.9/site-packages/blivetgui/communication/server.py", line 270, in _blivet_utils_init
    self.blivet_utils = BlivetUtils(*args)
  File "/usr/lib/python3.9/site-packages/blivetgui/blivet_utils.py", line 164, in __init__
    self.blivet_reset()
  File "/usr/lib/python3.9/site-packages/blivetgui/blivet_utils.py", line 1456, in blivet_reset
    self.storage.reset()
  File "/usr/lib/python3.9/site-packages/blivet/threads.py", line 53, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/blivet/blivet.py", line 142, in reset
    self.devicetree.populate(cleanup_only=cleanup_only)
  File "/usr/lib/python3.9/site-packages/blivet/threads.py", line 53, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/blivet/populator/populator.py", line 416, in populate
    self._populate()
  File "/usr/lib/python3.9/site-packages/blivet/threads.py", line 53, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/blivet/populator/populator.py", line 461, in _populate
    self.handle_device(dev)
  File "/usr/lib/python3.9/site-packages/blivet/threads.py", line 53, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/blivet/populator/populator.py", line 267, in handle_device
    device = helper_class(self, info).run()
  File "/usr/lib/python3.9/site-packages/blivet/populator/helpers/luks.py", line 46, in run
    parents = self._devicetree._add_parent_devices(self.data)
  File "/usr/lib/python3.9/site-packages/blivet/threads.py", line 53, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/blivet/populator/populator.py", line 116, in _add_parent_devices
    raise DeviceTreeError(msg)
blivet.errors.DeviceTreeError: unable to get udev info for sdd
------------------------------
  File "/usr/bin/blivet-gui", line 115, in <module>
    main()
  File "/usr/bin/blivet-gui", line 109, in main
    BlivetGUI(client)
  File "/usr/lib/python3.9/site-packages/blivetgui/blivetgui.py", line 106, in __init__
    self.blivet_init()
  File "/usr/lib/python3.9/site-packages/blivetgui/blivetgui.py", line 793, in blivet_init
    self._reraise_exception(ret.exception, ret.traceback, message,
  File "/usr/lib/python3.9/site-packages/blivetgui/blivetgui.py", line 236, in _reraise_exception
    raise type(exception)(message + "\n" + str(exception) + "\n" + traceback)

Fedora 33
blivet-gui-runtime-2.2.1-2.fc33

btrfs-progs v5.9
cryptsetup 2.3.4

[rugk]

Even though I had problems to report the bug (see https://github.com/storaged-project/blivet/issues/920), I was able top create a downstzream bug report, maybe only some attachments are missing: https://bugzilla.redhat.com/show_bug.cgi?id=1910947

[rugk]

Oh actually I have disconnected the LUKS2 device now, so it does not seem to have anything to do with that. I also had a VeraCrypt device connected and GNOME disks etc still lists the (loop?) devices that were used for decrypting some LUKS devices, so it may still be related:

The underlying disks have been removed now, however.

[vojtechtrefny]

It looks like there was some issue with your sdd drive: we see the sdd_crypt in UDev database and GNOME Disks (which uses UDisks which also uses UDev) also sees the /dev/mapper/sdd_crypt device but the sdd drive itself is not present in the system:

Last line in our logs:

ERROR:blivet: No device at '/sys/devices/pci0000:00/0000:00:14.0/usb3/3-9/3-9:1.0/host7/target7:0:0/7:0:0:0/block/sdd'

also lsblk output in the blivet-gui log attached to the bug report doesn't contain /dev/sdd.

So my theory is: the sdd drive was disconnected without closing the LUKS device first (either you disconnected it manually or this was a hardware issue and it got disconnected by accident, it can happen with removable devices sometimes).

The result is we see the sdd_crypt and fail to find its parent device and crash. This is unfortunately how blivet currently works -- if we can't "process" a device, we raise an exception. There are some work in progress changes to make it more stable, but there's nothing I can do about this now. Next version of blivet-gui is going to have an option to start with a subset of disks when running from terminal which can be also use as a workaround for this situation, but that's not released yet.

[rugk]

Well… ok, my point is just that it should never crash. If you can, show a useful error at least. Or just don't show this one drive. After all, e.g. GParted also started in the situation there.

[vojtechtrefny]

ok, my point is just that it should never crash

I agree and I hope will be able to not do that soon :-)