"Save old hardware and install Linux on it." That's my response to the ridiculous requirements from Microsoft. But first things first: I got a notebook from a friend, an Acer Aspire ES 17 ES-732, with Windows 10 on an HDD. The request was: "could you do something about its speed?" I was like: "yeah, sure, I'll see what I can do." That was before I knew what I had gotten myself into.
The Hardware Upgrade
Usually, the method is straightforward for almost all devices: upgrade to an SSD and install a lightweight Linux distribution, especially since the hardware is from 2017. Before that happened, I was assuming that this applies to all devices, but this one here proved me wrong. This will be a rather long story about what the issue was, what I did to fix it and what you need to recreate the result. So let's start with the nightmare that cost me 14 hours in total.
The first thing I did was check the hardware. Turns out there's a quad-core CPU installed, an Intel Pentium N4200. The CPU is a huge bottleneck, I won't lie, but it's totally fine for basic office tasks. You don't need much power and the 8 GiB RAM are also more than enough to perform some simple multimedia tasks in the web browser. The HDD made things worse, but the space was quite a lot with 1 TB.
My friend said it takes like 15 minutes to boot, so I grabbed my phone
and roughly tracked the time from pushing the power button to a Windows 10 that opens an Explorer window: 5 minutes. I reviewed all services that start with the OS, deactivated a few, defragmented the drive and did another test. I wasn't expecting miracles, but it did improve by 30 seconds which is 10 % of the initial boot time. Windows is quite resource-heavy, and since it’s reaching EOL anyway, there was no point in preserving it.
I ordered a new SSD, a 256 GB BIWIN M100, and a 2.5-inch hard drive enclosure with a USB-C plug. In the meantime, I disassembled the notebook and took a close look at the internals. To be honest, it didn't need a cleaning actually, there was just a thin layer of dust at the fan outtake. In short, nothing worth mentioning.
The motherboard itself is remarkably small compared to the massive housing. The heatsink was just a simple piece of sheet metal with a fan mounted on top, which I found quite amusing. I suspect it would be entirely possible to use a passive cooling system for this little Pentium without any loss in performance.The UEFI Boot Issues
Let's move on to the more interesting part. I originally intended to install the Fedora 43 LXQt spin, so I prepared my flash drive. Plugging it in, selecting the boot device and booting from it went quite smoothly. To enter the BIOS, use F2 after pressing the power switch. The boot menu on F12 was disabled by default.
In any case, I opened the Anaconda Web Installer and struggled for a moment to find an option to format my Linux partition to EXT4 instead of BTRFS. Why? Because I'm more familiar with EXT4 and I wasn't sure if BTRFS uses compression by default. This would have a negative impact on performance due to that puny Pentium. Turns out you need to create the partitions yourself, so I took a photo (I know, a screenshot would be cleaner and I was lazy) of the sizes.
Don't mind that the photo is German. So, sda3 was changed to EXT4 and the mount point was just the root directory (/). There's no need to add a mount point for /home. When entering the size of 2.15 GB for the boot partition, Anaconda will display an error message. Simply click on sda2 and then select the option to reduce the size to the recommended value. This will resolve the issue. I won't go into too much detail as this information is to find in forums.
In any case, with that settled, I started the installation process. This takes quite a while due to the bottleneck I couldn't swap: the CPU. In any normal scenario, this would have simply installed Fedora on the machine. But I wouldn't be writing this if that were the case. So, what happened next? Linux froze while writing the bootloader. That was rather strange I thought, but I guessed that was a fluke. After all, software isn't perfect. I turned the device off and on again. I did the exact same procedure a second time (don't judge me; this is perfectly normal behavior for a computer scientist 😂). The result was the very same (who would've guessed?).
For reference: this step takes about 15 minutes, so I just wasted 30 minutes of the eight hours it would ultimately take to figure out the actual issue and solution. Afterwards, I tried (nearly) everything: using another USB port, experimenting with boot flags for the Live Linux system, disabling Secure Boot, and testing four different distros in total (Fedora LXQt, Fedora KDE, Bodhi, Lubuntu). The result was always the same. I didn't try a different flash drive, though, because by that time, I had a hunch that the notebook itself was preventing me from writing the bootloader.
But first, I updated the BIOS to the newest version. To do that, I had to swap the SSD out and put the HDD back in, as Acer only provides a Windows executable for the update and my Live Linux didn't have Wi-Fi anyway. The BIOS flash was successful, but the update automatically reset and regenerated the Secure Boot keys. Since I didn't have access to the original email address the Windows account was set up with, I had reached a point of no return.
Yet, it still didn't work. I was about to give up and buy an older business-grade Dell laptop for her. However, I actually decided to consult a search engine and an AI and turns out that I was right about the hardware being a nightmare (much to my regret). I scoured several forums to see what other users had written specifically about the Acer Aspire ES series.
It turns out that the NVRAM cannot be overridden by Linux. It is far too restricted, and I am not even sure if Windows would be able to do it (likely not). While the InsydeH2O BIOS on some Acer Aspire ES models allowed users to switch to Legacy Boot to resolve this, this specific machine was UEFI-only, so that option was off the table. Other users had success by selecting a bootloader and marking it as "trusted" within the BIOS settings, but this device lacked that option entirely. To make matters worse, the AI was just as clueless as I was at this point. It wasn't being useful at all and this is the reason why the RAM prices skyrocketed? What a waste...
In the meantime, my brother joined me (an IT specialist) and asked me what was going with the device. After joining the troubleshooting, he immediately understood my pain. Now here's a joke for you: how many computer scientists does it take to install Linux on a device? Just one, but it might take him eight hours! 🤣
The Windows Boot Manager Solution for GRUB
Jokes aside: my brother went to bed and then an idea struck me: why not install Linux using a different device? I asked the AI: "Is that even possible?" (don't judge me; I was exhausted, it was 1 a.m., and I had already been hunting for a solution for seven hours 😅) The AI replied: "Yeah, that's certainly possible, just as you thought." My reasoning was simple: unlike Windows, Linux doesn't usually require device-specific (chipset) drivers for operation. This means you can actually perform the installation on a completely different machine and then simply swap the SSD back into the original notebook.
I got out my own laptop, put the new SSD into the enclosure I had bought and connected it via USB. I plugged in my flash drive with Fedora LXQt and booted the installer. The installation went off without a hitch. I double-checked the EFI partition, the fallback EFI path (EFI/BOOT/BOOTX64.EFI) was included, just like on the bootable flash drive. This simply had to work, right? I swapped the SSD back into the notebook, turned it on, and... nothing. "No bootable device."
With dark circles under my eyes, I asked for advice and received this reply from the AI: "Just try disguising your GRUB as the Windows Boot Manager." It's 2 a.m., the idea sounded insane. However, if there’s one thing I know for sure about software development, it’s that it can be a total mess sometimes. Power off. Remove the SSD. I put it back into the enclosure, connected it to my Live Linux and mounted the EFI partition.
Afterwards, I ran the following commands:
cp EFI/fedora/shimx64.efi EFI/Microsoft/Boot/bootmgfw.efi
cp EFI/fedora/grubx64.efi EFI/Microsoft/Boot/
I wasn't entirely sure if grubx64.efi was strictly necessary in that folder, but I copied it anyway, just in case (to be honest, I'm not intimately familiar with every detail of the UEFI Linux boot process).
After that, Live Linux seemed to rebel, it refused to unmount the partition. Even sudo umount -f wouldn't work. In
the end, I had to shut down my own laptop just to safely remove the
drive. It seemed my brain wasn't the only thing refusing to work
properly at that hour.
Another shot at turning the device on and... IT BOOTED! After eight hours, the major breakthrough. Afterwards, I immediately sent a photo of the booted system to my brother with the caption: "EAT THIS, ACER!" (No, I was totally calm... NOT!)
The next morning, his reply was: "What kind of black magic did you use?" To be honest, I could hardly believe I had actually pulled it off myself. But the "fun" didn't end there.
Wayland Issues in LXQt and the Alternative: KDE Plasma
The next day, I booted back into the OS only to find that my keyboard settings were completely off. I wanted to have a German QWERTZ layout, not the US QWERTY default. Had the installer messed up? I tinkered with the settings for about two hours, only to give up in frustration.
It appeared to be an issue with the ibus service. I didn't fully grasp the details, but it seems the Wayland session handles keyboard input differently than X11. The last time I used LXQt was in Lubuntu 22.04 LTS, which was still running on X11 and not Wayland. In any case, I ran a grep on the available languages in the ibus instance, looking for "ger" and found nothing. That was beyond odd. No LXQt then; I was done with it. Time to try something new.
So, I took out the drive once more, booted the other laptop with Fedora 43 KDE spin to evaluate it. I knew from experience that KDE handled layouts well, so I had high hopes. It was only then that I realized something: once you change the keyboard layout in the Anaconda installer, it should update the layout for the Live session as well. For some reason, this never happened with LXQt, but it worked flawlessly here.
I also noticed another major difference after installing the KDE spin: the Wi-Fi chip worked out of the box without needing the RPM Fusion repo. In LXQt, it didn't seem to have the correct drivers. I honestly can't explain why, but perhaps a reader can shed some light on it. I added the RPM Fusion repo anyway to install the essential and commercial multimedia codecs like H.264. To be honest, I was pleasantly surprised by how well KDE performed on this notebook; I had expected a lot of lag, but it was remarkably smooth.
Here are the resources to learn from:
UEFI Certificate Issues and the LVFS Solution
After setting everything up, I opened Discover and ran the system updates, which took about an hour. That’s when I noticed two pending UEFI certificate updates. By then, I had actually re-enabled Secure Boot. Now, let’s put it this way: these updates are crucial if you want a secure system, but I ultimately chose to disable them - and Secure Boot along with them.
Why? You guessed it: the laptop freezes the moment it tries to install those certificates. I tried to figure out where these updates were coming from and how to exclude them so my friend wouldn't accidentally trigger them later. It might not be the "cleanest" solution, but I went into /etc/fwupd/remotes.d/lvfs.conf and edited it so that the Linux Vendor Firmware Service (LVFS) is disabled. After a quick sudo systemctl restart fwupd.service, those two entries vanished from Discover. I disabled Secure Boot afterwards as the certificates are only valid until June.
Since GRUB still had entries from the other device it was installed on, I regenerated the configuration with:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
So, how’s the performance now? The boot time is roughly one minute, making it about five times faster than before. Mission accomplished! This actually marks the end of a long journey - and post. I truly hope this helps someone out there, as I haven't found this specific solution anywhere else on the internet yet.
Comments
Post a Comment