Description of problem: installing F32 Server, in phase when selecting partition for instalation (this machine was pre-made partitioning with some mdraid disks), anaconda crashes. Version-Release number of selected component: anaconda-32.24.7 The following was filed automatically by anaconda: anaconda 32.24.7 exception report Traceback (most recent call first): File "/usr/lib/python3.8/site-packages/dasbus/client/handler.py", line 496, in _handle_method_error raise exception from None File "/usr/lib/python3.8/site-packages/dasbus/client/handler.py", line 474, in _get_method_reply return self._handle_method_error(error) File "/usr/lib/python3.8/site-packages/dasbus/client/handler.py", line 442, in _call_method return self._get_method_reply( File "/usr/lib64/python3.8/site-packages/pyanaconda/ui/gui/spokes/custom_storage.py", line 257, in _get_permissions self._device_tree.GenerateDeviceFactoryPermissions( File "/usr/lib64/python3.8/site-packages/pyanaconda/ui/gui/spokes/custom_storage.py", line 253, in _update_permissions self._permissions = self._get_permissions(self._request) File "/usr/lib64/python3.8/site-packages/pyanaconda/ui/gui/spokes/custom_storage.py", line 757, in _populate_right_side self._update_permissions() File "/usr/lib64/python3.8/site-packages/pyanaconda/ui/gui/spokes/custom_storage.py", line 1402, in on_selector_clicked self._populate_right_side(self._accordion.current_selector) File "/usr/lib64/python3.8/site-packages/pyanaconda/ui/gui/spokes/lib/accordion.py", line 365, in process_event cb(old_selector, selector) pyanaconda.modules.common.errors.storage.UnknownDeviceError: 10 Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-32 quiet executable: /sbin/anaconda hashmarkername: anaconda hawkey.log: INFO Apr-05 19:13:36 === Started libdnf-0.45.0 === kernel: 5.6.6-300.fc32.x86_64 product: Fedora release: Fedora release 32 (Thirty Two) type: anaconda version: 32
Created attachment 1769311 [details] File: anaconda-tb
Created attachment 1769312 [details] File: anaconda.log
Created attachment 1769313 [details] File: dbus.log
Created attachment 1769314 [details] File: dnf.librepo.log
Created attachment 1769315 [details] File: environ
Created attachment 1769316 [details] File: lorax-packages.log
Created attachment 1769317 [details] File: lsblk_output
Created attachment 1769318 [details] File: nmcli_dev_list
Created attachment 1769319 [details] File: os_info
Created attachment 1769320 [details] File: program.log
Created attachment 1769321 [details] File: storage.log
Created attachment 1769322 [details] File: syslog
Created attachment 1769323 [details] File: packaging.log
From storage.log: DEBUG:blivet:failed to resolve '10' WARNING:dasbus.server.handler:The call org.fedoraproject.Anaconda.Modules.Storage.DeviceTree.Scheduler.GenerateDeviceFactoryPermissions has failed with an exception: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/dasbus/server/handler.py", line 409, in _method_callback result = self._handle_call( File "/usr/lib/python3.8/site-packages/dasbus/server/handler.py", line 234, in _handle_call return handler(*parameters) File "/usr/lib64/python3.8/site-packages/pyanaconda/modules/storage/partitioning/interactive/scheduler_interface.py", line 142, in GenerateDeviceFactoryPermissions permissions = self.implementation.generate_device_factory_permissions(request) File "/usr/lib64/python3.8/site-packages/pyanaconda/modules/storage/partitioning/interactive/scheduler_module.py", line 158, in generate_device_factory_permissions return utils.generate_device_factory_permissions(self.storage, request) File "/usr/lib64/python3.8/site-packages/pyanaconda/modules/storage/partitioning/interactive/utils.py", line 861, in generate_device_factory_permissions raise UnknownDeviceError(request.device_spec) pyanaconda.modules.common.errors.storage.UnknownDeviceError: 10 It looks like the blivet library is not able to resolve a RAID device by its name. Reassigning.
there was one slightly non-standard thing: two of pre-configured RAID1 had in device MD superblock same name (and different array UUID). E.g. "mdadm --examine --scan" print: ARRAY /dev/md/0 metadata=1.0 UUID=fc9dbbc2:3c580719:1903e0ec:5254d7a4 name=linfs.glp.cz:0 ARRAY /dev/md/1 metadata=1.0 UUID=75a89a6e:5cd7d37a:9dab2ae9:5eca0724 name=linfs.glp.cz:1 ARRAY /dev/md/2 metadata=1.0 UUID=7e0e0d50:be2ef901:364094a2:1d2fdaa8 name=linfs.glp.cz:2 ARRAY /dev/md/10 metadata=1.0 UUID=692bc575:4291d20f:757d46a5:ad64e797 name=linfs.glp.cz:10 ARRAY /dev/md/11 metadata=1.0 UUID=658a3ef2:db9cbf1c:b106d177:bf9db5ce name=linfs.glp.cz:11 ARRAY /dev/md/12 metadata=1.0 UUID=5590a2d5:48217f14:3a480aaf:1045d4ca name=linfs.glp.cz:12 ARRAY /dev/md/30 metadata=1.2 UUID=e2c0caa0:fc26ac86:f408b6b5:0da8c81b name=linfs.glp.cz:30 ARRAY /dev/md/2 metadata=1.0 UUID=39f20e19:4ae7d8a5:dca09003:2cb25c4f name=linfs.glp.cz:2 (RAID on third a last position has same name "linfs.glp.cz:2" in their superblocks) After I changed in superblock stored array name on one of them (command as: mdadm --assemble /dev/mdNN --update=name /dev/nvme{0,1}n1p1 where mdNN isn't in collision with other RAIDs names), then I was able to install Fedora 32 Server(*) (*) there was other problem with old storage manager, but with new (blivet or so called?) I was able to complete the installation. I'm not sure, if I should report this other error.
Can you test this with Fedora 33 (or 34 beta)? We did some fixes for MD RAID detection and name resolution in blivet 3.3.0[1] and I think this might fix your issue. [1] https://github.com/storaged-project/blivet/pull/888
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. 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 '32'. 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 32 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.
*** This bug has been marked as a duplicate of bug 1960798 ***