(F42) Unusably slow liveUSB performance on two older systems

Hey everyone,

I’m running into a problem when trying to clean install F42 on a couple of old systems.

System One:
Acer Chromebook C720
Celeron 2957U 1.40 DC
2GB RAM
240GB SSD
Intel graphics
Atheros wifi
Amtel maXtouch touchscreen

System Two:
Linx 1010B Tablet
Intel Atom Z3735F 1.33 DC
2GB RAM
32GB eMMC
Intel graphics
Intel audio
Realtek RTL8723BS Wifi/Bluetooth
Goodix touchscreen

Now, I do realize these are positively ancient computers with very limited modern uses. However Fedora runs beautifully on both of them and they’re useful from time to time, so I like to keep them around.

I’ve run Fedora on them from somewhere around version early 30-something, and no problems at all. Every upgrade has been smooth sailing. But, after 41, I borrowed them to run a different OS for a brief period, with the intention of restoring 42 on them when I was done.

And that’s where the problems started. Booting from the live USB was considerably slower than usual. Once it finally got to the desktop, it took a couple of minutes to load the welcome “do you want to install / test” window. Choosing install opens the installer (after another couple of minutes) but it never fully loads. It just sits with a spinning circle. I even left it overnight once and it was in the same state when I got back to it. And once it gets to that state, it’s unusable. Can’t get a terminal up to do a graceful shutdown, just gotta hard power off.

One thing I noticed was the indicator LED on the USB drive NEVER stops flashing, even when a system has been left for a good couple of hours. I did suspect the USB drive, so I tested it on two other systems; a late Core2Duo laptop, and a 4th gen i7. It worked great on both.

So my next step was to try an earlier version and other distros. Tried F41, booted fine, installed fine, dnf upgraded to 42, everything ran exactly as expected. Installed Linux Mint 22, no problem. It’s just F42 that has this problem. It runs fine on everything else I’ve tried it on, including other systems of similarly awful specification.

Rather than me upload loads of potentially incorrect logs, if you guys can tell me what you need, I will go get it and upload.

Many thanks in advance!

I do have a low end laptop and the new installer is so slow that I thought it crashed and I restarted it like three times. At the end it worked then. I guess Fedora KDE still uses the old installer.

1 Like

A little further testing. The MATE-Compiz spin installs perfectly with no problems.

In some desperation, I booted up off the regular F42 install USB, and once it had reached desktop, opened terminal and ran

systemd stop thermald.service

I then kept the terminal open while I opened the installer. Choosing a language took a LONG time. I couldn’t use the search bar at all - clicking in it did nothing. Switching from Firefox to the terminal would take around 20-30 seconds.

To get from power on to the point where I could choose a different language other than English (US) took an incredible TWO hours, with Firefox occasionally hanging.

I was switching back to the terminal to keep an eye on top, and saw it reporting CPU loads of up to 5 6 5, with Firefox hitting CPU loads of 170% and python hanging out at around 85%.

Right now I’m waiting for it to acknowledge my language choice and move on…

Update. That previous install attempt never made it past the language selection screen. Gave up on it after a further half hour. Instead, I did a clean install using the netinstall ISO. As expected, everything worked just fine, and the system performs as expected.

So it looks like the problem is specifically with the main GNOME installer; it seems to be somewhat heavy on resources and just doesn’t play nicely with these older, lower spec systems. I’ve always considered Fedora to be my go-to jack of all trades distro, that works on pretty much anything you can get it to install on. But it may be that from 42 on, it’s just not the right disto for the older/lowest spec systems any more. While it runs ok on said systems, it’s really not worth installing 41 then dnf systemupgrading to 42, or doing a netinstall each time.

Hopefully despite the lack of feedback, a dev or someone who has some input in this reads this thread, and can see if this behavior is by design or an unintended side effect of moving to the new installer. It would be good to be able to use the “regular” GNOME again from 43!

See, Fedora “spins” still use the old installer.
Which was perfectly fine for me and I don’t really know why we need a new one.
Fedora Gnome or “Workstation” uses the new installer.
I don’t know the details but when I used it for the last Fedora it looked like it is a Firefox session with some HTML/JS runtime, you know those development tools for Web applications.
It is slow and heavy on resources by default, think about launching the whole browser just to display a more or less static window with some options to select and then a rotating “thingy”, not exactly the most efficient thing ever.
Of course even in the ideal conditions, excluding some memory leak in the JS code and whatever is under it.

There is a philosophical issue, besides using Firefox for the GUI being strange.
Fedora aims to be a “bleeding edge” distro, so again by default it is more thought for “recent” hardware and high end than "old hardware and low end.

Despite some difficulties with the new installer I managed with Fedora 42. Next time it could fail. At that point I would have to decide between new hardware or a different distro.

Assuming the old system hasn’t suffered a hardware failure. There are some factors that contribute to problems with older systems:

  • developers generally work with recent systems, which has the advantage that newer hardware gets attention when there are issues
  • older systems are prone to hardware failures/glitches, with increasing frequency of “random” crashes, so place higher demands on support forums as well as lost time for their users
  • the linux community benefits from users testing a wide range of use cases on newer kernels and libraries

In my career, I’ve worked with many users, mostly scientists from developing countries, who needed specialized software that required a POSIX platform. I used to advise them to check the storage rooms at their home institute for old “unloved and unwanted” systems cast off by people in high pay grades that could be used to run linux. There are currently lots of robust systems sold with Windows 10 that won’t readily run Windows 11 in “enterprise” environments but should provide roughly 5 more years of reliable operation.

Hardware failure kill new sytems as well. I bought a new laptop and I had to change the RAM blocks because they were defective. In my own experience the new installer is so slow it is barely usable. The point is I don’t see the reason why some installer must be much slower than another, given they do the same things and I don’t get the need to reinvent the wheel but this time make it squared.

Once installed, is performance reasonable? Unlike Windows, Linux issues can usually be fixed without reinstalling. I find many users coming from Windows reinstall before making the effort to find the cause of an issue – often they end up with the same issue.

I haven’t looked at the installer code, but before retiring, a key part of my job for over 30 years dealt with performance problems in scientific programs. There are always tradeoffs between performance and other goals:

  • portability – how hard will it be to move the program to new platforms?
  • maintainability – how easy is it to understand the code in order to make changes?
  • resource requirements – there are often tradeoffs between size and speed

For Linux, developers and testers are scarce resources, so portability and maintainability often outweigh resource requirements. This can affect performance on older or low-end systems.

I have seen cases where new implimentations suffered from poor performance on some “production” systems due to inefficiencies that wasn’t noticeable using a high spec system for testing. The advantage is that testing goes quickly, so those involved can go on to the next task.

Once installed Fedora 42 is almost the same as Fedora 41.
I wrote only about the new installer being much slower than the old installer.
I don’t know the details but it seems the new installer interface is actually a Firefox session and my guess is opening the browser and running the underlying code is not very efficient. I am not optimistic about the whole thing becoming much better because it is about the architecture.

Leveraging Firefox must greatly reduce the GUI code in the installer, so allows the developers to focus on improving other aspect of the installer. I usually start an installer and go off to do other things, sometimes leaving it overnight. It has always been 1 and done. Do you find the new installer slow while choosing options, or slow to implement them?

Nope, the new installer takes for ever to start and to reach the point where you can actually select some options, then it is probably slower in the actually installation once you commit but I am not sure of it. What I know for sure it is so slow in the first part that it took me three reboots to understand it had not crashed, it was just taking its time. BTW the “spinner” is both useless and annoying.

Since I am just “an user” I would not criticize whoever decided to use Firefox for the installer GUI. From here it does not look like a smart move, it is like running a nuclear reactor to light your christmas three, given the size and complexity of Firefox in itself, plus the FirefoxOS sad story. My guess the idea behind it is to make the GUI “agnostic”, meaning it works where ever you can run Firefox.

See my original posts above. It took TWO HOURS to get to the language selection screen, and I couldn’t get past that. Now, I do grant that I’m running on some pretty ancient hardware, but the old installer on F41 works flawlessly, as do the other installers on F42 (netinst, MATE spin).

I do agree with Lorenzo that there’s something really not right with this new installer. It seems to break something that really didn’t need to be touched; the old installer worked just fine.

On older Intel hardware, but linux has been adding support for new processors and other hardware innovations, so write once, run anywhere design may reduce effort needed to support new hardware.

George, the nonsense is that Fedora Workstation, once installed, works fine with the same hardware the installer cannot digest. Here we are saying that opening the first installer window requires more hardware power than the whole OS with the same browser playing videos on youtube and writing email on gmail. I think it is a bit ironic considering the installer could be text-based and do exactly the same things.

1 Like