If it is a live image, my guess is that it is something to do with squashfs. I found the following note about recent changes to the default squashfs configuration that sound like they might be related to your problem (“high latency” == “not responses immediately”):
Decreasing the installation image size will reduce cost of mirroring and storing Fedora installation images.
Decreasing the installation image size will reduce the download time.
Increasing the block size on the current configuration with EXT4 file system, should increase latency while accessing the EXT4 filesystem. The exact impact is to be evaluated.
The impact of latency will be reduced, if the plain SquashFS option is be choosen.
I’m not sure if the above change was actually made. Following some of the links leads to a confirmation that a different squashfs-related change was made recently:
I don’t know what, if any, impact the above changes might have had on your experience with Fedora Media Writer, but it seems at least feasible that something along those lines might be responcible for the high latency you are seeing.
Also, squashfs has been known to stall out with some kernel configurations:
It is very complicated. Hopefully the above reading might help you to trace down the exact problem.
Thanks for answering, it is not a live image. Both are installations on SSD drives. And on both let make fedora the partitioning. One was testing and the other was beta when in installed. Both where Mate spins.
And as @sampsonf understood correct it is just the browsing process to choose the image.
On my Fedora 32 on same computer i not had this delay to open files.
The images where locally stored where i wanted to choose.
Try running from the command line with sudo. My extremely unscientific findings are that if you use sudo mediawriter the application works as expected with regard to browsing the local machine for previously downloaded images.
I verified this by then trying the same thing without sudo. Slowed right down again.
Although this doesn’t solve the issue I felt that these findings were somehow indicative of a bigger issue.
Probably, one can find a tool here to troubleshoot the issue? https://github.com/iovisor
Otherwise, there are a couple of alternative installation methods listed in the docs.
Since media-writer is supposed to be run under root or sudo priviledges in order to do its job properly I don’t really feel that is a problem, although it does seem strange that browsing would take longer when not run as root.
I have never tried using it except as root so had not seen the problem reported. I just tried it as my regular user and it did the browsing in fractions of a second locally and only a couple seconds to update the links from F33 when I last used it to the current F34 images online. Since it is linking to the images online I wonder if the delay is network related and not actually mediawriter related. Note that I ran it from a terminal so I was able to watch as it gave the messages about updating the links. I also was using an F33 host.
Not really, i tested with F32 and there everything works as expected also as normal user alias without sudo. The errors about the changed links i get also.
I do agree that this is also a security issue, that an user without privileges can create a boot system to bypass security and access a computers filesystem.
Then at least wen someone starts the program with the normal link, it should pop up a login for sudo credentials.
I don’t see a security issue. It allows browsing of the download site and the actual download as the regular user. When you select to write to the USB it asks for sudo password, so that does not appear to be a security issue.