Hide Forgot
In Fedora-Rawhide-20190403.n.1 testing, several of the installer blivet-gui ("advanced custom") tests failed because, when they went to create a partition in the blivet-gui interface, a dialog appeared (titled "No partition table found on disk") and asked them to pick between GPT or msdos disk label. This has, AFAICS, never happened before. Neither python-blivet nor blivet-gui has changed for weeks in Rawhide, so I can only think the new anaconda is causing this somehow. Presumably it was previously creating a boot label or at least communicating to blivet-gui what type of disk label to create, but now it isn't? Interestingly, this didn't happen on *every* test, it seems to be slightly random. On the production instance, it looks like 3 blivet-gui tests ran into this; about 10 did not. There may be some sort of race involved? I do not yet know if this also affects F30, we should find out with the next compose.
Created attachment 1552150 [details] anaconda.log from an affected test
Created attachment 1552151 [details] dbus.log from an affected test
Created attachment 1552152 [details] progam.log from an affected test
Created attachment 1552153 [details] storage.log from an affected test
Created attachment 1552154 [details] syslog from an affected test
Vojta please look on this if this have to be adjusted because of some changes in Anaconda or it needs polishing from the blivet-gui side. Thanks
So this is affecting F30 too, the openQA tests of the latest F30 compose confirm it. One small note - the default selection in the dialog differs depending on whether the system is booted BIOS or UEFI, defaulting to msdos for BIOS and gpt for UEFI. So the system does 'know' on some level what type of label it should probably be using.
*** Bug 1696484 has been marked as a duplicate of this bug. ***
I'm changing component to anaconda, blivet-gui is working "as expected" -- there is no partition table on the disk so it will show you a dialog to create it. Anaconda should "initialize" all selected disks, meaning it should schedule actions to create the partition table. I've tested this with two empty disks (without partition tables) and when (de)selecting the disks and switching from blivet-gui to custom partitioning and back, sometimes the disks are initialized, sometimes not and sometimes only one is initialized so it looks like a race condition.
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/1942
anaconda-30.25.6-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6ae44e47fb
anaconda-30.25.6-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6ae44e47fb
anaconda-30.25.6-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
This is fixed for F30 indeed, but it seems the fix has yet to reach Rawhide. Can you please cut a new release on the 31.x branch and send this fix to Rawhide too? Thanks.
It should be in the Rawhide automatically. Martin could you please take a look on this?
Jiri: there just hasn't been a release/package build for Rawhide since this was fixed. The most recent build on Rawhide is anaconda-31.8-1.fc31 from 2019-04-09. The fix was merged on 2019-04-11. anaconda-30.25.6-1.fc30 was built shortly after, but no build was done for Rawhide.
Looks like I forgot to trigger the Rawhide build back when I did the F30 one. Rawhide build running now: https://koji.fedoraproject.org/koji/taskinfo?taskID=34254177
Thanks Martin :)
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.