search

FedoraQt / MediaWriter

Fedora Media Writer - Write Fedora Images to Portable Media
GNU General Public License v2.0
708 stars 154 forks source link

Progress bar no longer updates on Fedora 39 #640

Closed kparal closed 11 months ago

kparal commented 11 months ago

On Fedora 39 the progress bar looks always to be at 0%:

writing

checking

It's only jumps to 100% after the whole process is finished.

mediawriter-5.0.6-3.fc39.x86_64

On Fedora 38, the progress bar is displayed as expected, it updates live. I suppose the F39 behavior might be related to this: https://pagure.io/fedora-workstation/issue/351

Only tested in a virtual machine, I don't have a bare metal around at the moment.

grulja commented 11 months ago

I cannot reproduce. Testing this with FMW 5.0.7 in F39 Toolbox container on Fedora 39 KDE (also tested in Weston).

And Adwaita-qt removel (not using it by default) shouldn't have any impact on Fedora Media Writer.

kparal commented 11 months ago

Yes, it looks fine in a Fedora 39 KDE VM. But it doesn't display in GNOME. I also tested 5.0.7, no change.

I see the following errors in the terminal:

W@11993ms: qrc:/qml/DownloadPage.qml:143: TypeError: Cannot read property 'name' of null (qrc:/qml/DownloadPage.qml:143)
W@11993ms: qrc:/qml/DownloadPage.qml:261: TypeError: Cannot read property 'progress' of null (qrc:/qml/DownloadPage.qml:261)
W@12001ms: qrc:/qml/DownloadPage.qml:143: TypeError: Cannot read property 'name' of null (qrc:/qml/DownloadPage.qml:143)
W@12001ms: qrc:/qml/DownloadPage.qml:261: TypeError: Cannot read property 'progress' of null (qrc:/qml/DownloadPage.qml:261)
W@12044ms: qrc:/qml/DownloadPage.qml:143: TypeError: Cannot read property 'name' of null (qrc:/qml/DownloadPage.qml:143)
W@12044ms: qrc:/qml/DownloadPage.qml:261: TypeError: Cannot read property 'progress' of null (qrc:/qml/DownloadPage.qml:261)
grulja commented 11 months ago

Does installing qgnomeplatform-qt6 and running mediawriter -platformtheme qgnomeplatform make any difference?

kparal commented 11 months ago

No improvement. In this case, the first line in output is:

W@116ms: Could not find color scheme  ""

not sure whether it's important or not. Either way, progress bars are still broken.

However, I just made a revelation! The progress bars are only broken the first time you write an image after a clean boot! If I keep FMW running and write the image again, suddenly, progress bars are updated properly. And even if I close FMW and start it again, the progress bars still work! And those Cannot read property errors are no longer displayed, so they are probably somehow relevant to this issue. (This last paragraph was tested in a default FMW experience, without qgnomeplatform-qt6 and -platformtheme qgnomeplatform).

kparal commented 11 months ago

If I log out from my user session and log back in, the progress bars are again broken on the first use of FMW.

grulja commented 11 months ago

I'm starting to suspect the issue here is also related to udisk2 as in https://github.com/FedoraQt/MediaWriter/issues/644. Any chance you can try to downgrade to udisks2-2.9.4-7.fc38 or make a scratch build of that older version for Fedora 39? I run Fedora Kinoite and it's harder to boot into GNOME with older udisks2.

geraldosimiao commented 11 months ago

tested here on a workstation iso from 2023/09/10 and the bar is working fine libudisks2-2.10.0-2.fc39.x86_64 udisks2-2.10.0-2.fc39.x86_64 udisks2-iscsi-2.10.0-2.fc39.x86_64 Screenshot_20230913_140451

geraldosimiao commented 11 months ago

I'll test now on today's Fedora-Workstation-Live-x86_64-39_Beta-1.1.iso Ok, on the beta 1.1 image I can reproduce the bug. So whats different from the 20230910 iso and the beta-1.1?

grulja commented 11 months ago

I'll test now on today's Fedora-Workstation-Live-x86_64-39_Beta-1.1.iso Ok, on the beta 1.1 image I can reproduce the bug. So whats different from the 20230910 iso and the beta-1.1?

What's udisks2 version there? There has been an update submitted to stable few days back

grulja commented 11 months ago

I can reproduce with both udisks2-2.10.1-1.fc39.x86_64 and with udisks2-2.10.0-2.fc39.x86_64 in GNOME.

kparal commented 11 months ago

Ok, a few more data points:

  1. It's not a race condition, I can reproduce it reliably, in specific use cases
  2. It's not related to VMs, I just reproduced it on bare metal (my colleague's laptop)
  3. It only happens once in a session, further uses are OK, even if you restart FMW. You need to re-log to trigger it again.
  4. You can avoid this bug if you a) restore the drive first (perhaps because it already displays a progress bar (an infinite one, which works), or b) if you cancel the authentication dialog on the first write attempt, and then hit Retry (and confirm the auth dialog).
  5. Ever time the bug happens, you see those TypeError: Cannot read property ... errors. They definitely seem related, they only happen when the bug happens.
kparal commented 11 months ago

tested here on a workstation iso from 2023/09/10 and the bar is working fine

I tested that image and I can reproduce it (right from the Live image).

kparal commented 11 months ago

The earliest image that I have locally is Fedora-Workstation-Live-x86_64-39-20230823.n.0.iso and that one is still broken.

As commented here, I wasn't successful in downgrading udisks2 in Fedora 39. But to my layman eye this looks like an UI problem to me, especially given that we get those TypeError messages exactly when it happens. Perhaps the first progress bar displayed is not initialized properly or something?

kparal commented 11 months ago

Oh, this is extremely interesting. This might be really caused by udisks2 or something related. Because after a fresh login when I first modify the drive in gnome-disks (e.g. just format it with a new MBR table) before starting FMW, then the progress bar doesn't happen (and those TypeError messages don't appear)! But when I don't touch the drive first, just start FMW and try to write it, then the progress bar bug is there.

So clearly, gnome-disks triggers something in the stack (udisks2 or similar) which then affects FMW later!

grulja commented 11 months ago

Oh, this is extremely interesting. This might be really caused by udisks2 or something related. Because after a fresh login when I first modify the drive in gnome-disks (e.g. just format it with a new MBR table) before starting FMW, then the progress bar doesn't happen (and those TypeError messages don't appear)! But when I don't touch the drive first, just start FMW and try to write it, then the progress bar bug is there.

So clearly, gnome-disks triggers something in the stack (udisks2 or similar) which than affects FMW later!

That's my guess. It doesn't happen on KDE, because possibly some deamon might already run something with Udisks2 in the background before we run FMW. That would also explain why it happens the first time you use it. It's definitely not an UI issue, because the progress bar will work when downloading an image. The errors it reports are caused by FMW not having information about the drive, that's why it doesn't report the progress.

kparal commented 11 months ago

With the build tested in #650 this now works correctly, thanks.