The new installer - It is not only me

From Distrowatch, Fedora 43 review.

Once I had clicked the installer’s icon nothing happened for about a minute. Then the installer’s window opened and it spent another minute just sitting while text in the window told me it was “initializing”.

The new installer has a blocky, flat look to it (much like openSUSE’s new installer). Each screen of the process is painfully slow. Button clicks take several seconds to register and menus are slow to respond. The installer begins by asking us to select our language and keyboard layout from lists. Then we are asked to pick our timezone.

The next stage of the installer covers disk partitioning. While the installer will allow the user to select on which disk to install the distribution I could not find any way to select which partition(s) the installer should use or a way to create new partitions. The only option appears to take over the entire disk. This may be an effort to streamline the installer or a sign the new installer does not detect existing disk layouts properly. In either case it feels like a huge step backwards in terms of what the installer is capable of doing with a disk.

The next screens offer to encrypt the hard drive and ask us to make up a username and password for our user. There is a checkbox to enable a root account and set a password on it too. The installer then goes to work, very slowly copying files to the hard drive.

I was curious about this lack of performance form the new installer and did some looking into it. The new system installer uses 100% of all available CPUs the whole time it is running, even when it is sitting idly in background waiting for input. This causes my laptop fan spin up and run hard the whole time the installer is on the screen. I think the installer must have a bug in it which causes it to refresh its window constantly in an unchecked loop because the installer causes the kwin_wayland process (the window manager) to always consume all available CPU resources across all cores.

This has been commented so often now… the Storage Editor is well hidden in the installer.
The author of that text is not the first one who can’t find it.

I read complains about the three-dot menu for a long time, and nothing has improved…

The problem here is ALL the above complaints are KNOWN.

It is why I post the rant here instead of other sections. I don’t expect any follow up.

I tried the new installer with the previous Fedora version. Back then it was so slow that I thought it had crashed but it was just loading. With current Fedora I knew what to expect. Yes, I guess with powerful enough hardware it is not a real concern but on my low end laptop it is almost unusable.

But, like in this thread title, it wasn’t only me, the person who wrote the review for Distrowatch also noted it is way too slow and I doubt she/he used a PC as old and unpowered as mine.

The thing I don’t understand is why to change a working piece of software like the old installer with a new piece of software that is much worse. I would expect the change when the new software is at least on par with the old one.

I don’t buy the idea of the redesign and the new workflow being worth the change, both things in my opinion are secondary simply because I have used the old installer for ages and despite it not being perfect, it worked good enough, while the new one is a pain in the …

Now the other usual big issue. Once the change is committed, there isn’t any way back or out. In fact the same installer that was limited to Gnome Fedora has been spread across all Fedoras. Since, you know, it is such a success.

It is not directly Fedoras problem, the speed. The installer is Web based and when you look carefully, for example clicking a second time to open installer, then you get the information that there is already a Firefox session open.

I guess the speed will just change, when we do have a simple and easy browser on hand, which works on all environments as expected.

I do hope that ladybird will be such a solution? Free of garbage and a code base which means a start over,
what web surfing means. With simple and clear rules for a save experience.

It is to support the screen reader also for installation >> https://orca.gnome.org/ on all desktops. It is not about “us” it is about “them” which need a audible assistance for installation.

This is indeed a problem, as it is not barrier free.

That has changed - I can’t remember what the webengine the anaconda is using is called, but it’s not firefox anymore.

1 Like

Wit the F43 Live Iso I can not confirm that it is not Firefox. While opening top command, I see till up to 73% of usage from Firefox.

With pkill firefox it closes the installer when I execute. So hope we see some improvements soon.

I have to confess, it is a bit faster as it was with F42.

1 Like

Sorry, I was wrong then. Maybe it was only some other spin (KDE?) that adopted another web engine.

1 Like

Ok I must admit I am dumb because I thought when Fedora provides its own istaller and it doesn’t work properly that could be Fedoras problem.

Now I find it is somebody’s else problem.

Yes, indeed, it is my problem because I must add the installer to the long list of things I must fight when it should make my life easier.

Just be patient. For new installs you can still use the everything ISO and use the old Installer.
Imagine how it must be for visually impaired users. Announcing a new installer and then it is soo slow and some functions are hidden behind three dots.

If you want to participate to make it better, have a look here:

Source: Anaconda WebUI: Progress Update and Roadmap

2 Likes

You are not wrong, the limited Installer I tested is an exception (I saw it today digging in the code):

Just be patient makes no sense because here we aren’t speaking of those facts of life you cannot do anything about, like getting old, sick, the rain failling, the sun being hot. Here we are speaking of some people in Fedora who see the “new installer” sucks and then they force it over “the user” with the same idea of those crazy surgeons who make esperiments on people, transplating a pig leg on somebody. Be patient and collaborate, it is for the sake of science, no?

I would consider to participate to a testing phase, not “to make it better” after it has pushed as “default” over everybody. That upsets me and, with all the “beta testing” we are already doing on Fedora, only makes me consider to switch to another distro.

Another annoying thing is you cannot complain because that offends whoever worked on the said software or whoever made the decisions. Like anybody cares of what offends me. I must be patient. Like a patient sheep.

Hi, I am currently a PO of the Anaconda team. Here are some comments:

This three-dot menu was done on explicit request from FESCo. We are working with multiple target audiences - both experienced and not. And we need to provide an interface which is straightforward for a user to not bother with complex scenarios, but which allows advanced configuration when it is required. In previous iterations we had users going straight to advanced storage settings even when they would not need it. Just on reflex. In this iteration we changed that.

It probably could be done differently, you can open a discussion about it. Just know that the previous outcome of that public discussion is what is currently implemented, and therefore changing it will require some effort.

Please add a link to the bugreport.

FIrst, if you check other sources (even Reddit), you will see how new redesign does make an impact on newcomers trying Fedora for the first time. Secondly, of course that was not the only reason. And we talked about the reasoning quite a lot, publicly, in Flock presentations and blog articles. GTK3 used by the Anaconda GTK UI being one of them, for example.

This is simply not true. The rollout of Anaconda changes is done via Fedora Change process, each step is done with a FESCo oversight and Fedora QA help.

In Fedora 42 it was Releases/42/ChangeSet - Fedora Project Wiki

In Fedora 43 it was Releases/43/ChangeSet - Fedora Project Wiki

Each time FESCo does public round of discussions and votes on the Change. If you have feedback on the incoming change you should provide it.

After the change is voted in by FESCo, the implementation of the Change starts. If the implementation does not work as intended by the Change Completion deadline, there is still a possibility to revert the change using the Contingency plan (each Fedora Change has it).

Additionally to test the Change before the final freeze the team has organized the Test Day dedicated to that particular switch: Anaconda installer WebUI for Fedora Spins and KDE

None of the bugs reported then has talked about interface being slow on KDE.

And of course the previous commenter is right, KDE and GNOME are significantly different desktop environments, with different set of issues within the Wayland/NVIDIA/Browser triangle, thus the claim that slow interface you experienced on Gnome in Fedora 42 and what the distrowatch folks experience on KDE is the same bug is most likely not true and at least requires in depth investigation.


To conclude,

if you want to have an impact on Fedora decisions and on Anaconda development decisions, you have plenty of opportunities: Test Days, Change discussions, bug reports, and Blocker Review meetings.. We are listening and we are open to the constructive feedback and constructive criticism.

And please do not jump to conclusions without at least trying to verify the information.

4 Likes

I don’t need much “information” to see the installer at work.

I would not argue the partitioning tool makes sense, somebody could believe a small percentage of the users need to manually configure the “storage” (a bit misleading) and those can study the thing in order to overcome.

I say everybody knows the Web Application - non native idea for the GUI meets the same issues ANY other Web Application met since ever and it is another iteration of reinventing the wheel. Firefox OS anyone? Once you make the wheel squared, another time you make it triangular, who knows why it doesn’t roll.

Then please, the impact I can have on Fedora decisions. Lets see what impact the Distrowatch review is going to have. I bet none. It is a game as old as the world.

Edit: I don’t want to think the guys testing the installer and asking for feedback DID NOT SEE all the issues that are being reported. Because that means they and the people providing feedback aren’t testing in realistic conditions, that is the point of testing. I prefer to think they do know the issues but they decide to push the installer anyway because it is not a bug it is a feature. Again same ol same ol

You still has not provided the link to the report on the issue, which you think we missed.

Impact of Distrowatch on Fedora is quite low, yes, for good reasons. One being we need data (logs, bug description..) to analyze and address issues reported, and comment thread on random network resources is not the good way to get this data. And that is why Distrowatch is not on that list of opportunities I offered.

But in the end, it is your personal choice - to be part of the community or to be part of the bystander crowd. I have no intent to force the choice on you, I only point out that there is no external barriers for that in the Fedora Project. Our development, our testing and our decision making is all open and accessible for anyone who wish to participate in it.

2 Likes

Yes exactly. Those complaining here, unfortunately are missing in mostly all of this processes.

@bookwar thanks for all your hard work you do for Fedora. I also appreciate that you clarified how things work to be a part of the community.

p.s.
I like to give feedback about the speed issues I observed on my hardware and in Virtual environments,
while installing F42/43. I will try to reproduce with newest ISO’s from Index of /pub/alt/live-respins to get the as is status.

I guess it is best to report in the git repository of the anaconda-webui right? I use the Workstation Image. Would be grateful, to get some proposals, how and with which apps I could gather adequate information’s you could reuse for debug the issue.

As mentioned I used the top command to see what is going on. Firefox appeared ad disappeared several times.

If this helps, I do the installs from Brazil. Because of slow connections (no more mirrors in Brazil) I sometimes use VPN to get more direct connection.

1 Like

For Fedora bugs we still use Fedora Bugzilla https://bugzilla.redhat.com/buglist.cgi?quicksearch=anaconda-webui

The development work happens indeed on GitHub, but we do not have an issue tracker open there, only discussions.

The upstream development work happens also on Jira in https://issues.redhat.com/projects/INSTALLER/issues But is not as easy for community members to find us there indeed. :slight_smile:

1 Like

That is why I asked.
However if it is still this then then the discussions became less heated.

Anyway if I have to use Bugzilla, I will do so.

Distrowatch values like me or any other “user” who tries the installer and find it almost unusable. The installer, I mean, we are installing stuff since ever. The difference is I am nobody while the Distrowatch review gets some publicity so ignoring it because it does not provide “data to analyze” is something.

So you mean the new installer takes for ever because I did not report the ovious everybody sees?

I will repeat: I am a PO of the Installer team, and no, I do not know which specific issue you are referring to with respect to Gnome Workstation installation being slow in Fedora 42. I asked you twice to find a link to it.

So 1) it is not obvious; 2) you should have reported it; 3) and yes, if you reported it, I would have seen it by now and talked to the team about it. That would be your real impact.

And generally, for any developer who works in FOSS, bugreport with logs and ability to ask a reporter follow-up questions has significantly more impact than a comment on social networks or forums. Distrowatch, Phoronix, or Reddit included.

A user who made an extra step to reach out to the project bugtracker is already not just “any user”.


For the KDE load issue - it is most likely this one: 2404262 – slitherer causes very high CPU usage without 3D acceleration support (qemu VM with no 3D passthrough, bare metal with nomodeset) (obviously coming from Fedora QA and not Distrowatch). It shows up only under specific circumstances (KWin + Wayland + nomodeset), can not be related to Gnome, and its fix seems to be on its way, but needs verification.

3 Likes