Sometimes udev's data becomes inconsistent with the actual state of the system. The invalid data is then reported by lsblk and blkid until something triggers the udev db to correct its view. In the meantime, blivet has problems because of the faulty reporting. The purpose of this issue is to discuss options for mitigation within blivet and, hopefully, come up with a plan.
I'll briefly describe a couple of options to start the discussion:
- stop using udev for identification of data format (aka: file system type)
- fallback data sources (eg: if no data in udev call libblkid directly, bypassing udev)
In general, it would make sense to structure the data sources we use when populating the device tree such that they can change without much disruption. A data-source interface could have implementations for udev, blkid, mdadm, lvm, et al. Then a mechanism could be used to dictate the order in which to query sources for a particular piece of information based on some criteria. It seems to me that such an approach would enable either of the specific options mentioned above. Perhaps it's more disruptive than is warranted, though.
Thoughts?
Sometimes udev's data becomes inconsistent with the actual state of the system. The invalid data is then reported by
lsblkandblkiduntil something triggers the udev db to correct its view. In the meantime, blivet has problems because of the faulty reporting. The purpose of this issue is to discuss options for mitigation within blivet and, hopefully, come up with a plan.I'll briefly describe a couple of options to start the discussion:
In general, it would make sense to structure the data sources we use when populating the device tree such that they can change without much disruption. A data-source interface could have implementations for udev, blkid, mdadm, lvm, et al. Then a mechanism could be used to dictate the order in which to query sources for a particular piece of information based on some criteria. It seems to me that such an approach would enable either of the specific options mentioned above. Perhaps it's more disruptive than is warranted, though.
Thoughts?