In Part I, I talked about installing Fedora 21 on a new Dell desktop, and promised a Part II, somewhat tongue-in-cheek. But wait folks, I was serious. 🙂
I have an Acer Aspire One which I received new out of the factory sealed box as a birthday present in 2009, and immediately converted it to linux after receiving it – Fedora 11, to be exact. It has used, as I recall, Fedora 11, 12, 14, 15, possibly 16, 17, and 19, all without any trouble. Well, ok, none that can’t be attributed to “whaddya expect out of a notebook vs. a full horsepower machine” and errors stemming from somewhere between the keyboard and the chair. ?
However, time is starting to march on with this machine, and while it was great under roughly 18 months of Fedora 19, it was clearly starting to slow down a bit, but … well, Fedora keeps releasing new versions, and, well, while CentOS 7, which is based on Fedora 19 and which I’d be happy to install on my netbook, unfortunately is only available under 64bit while my netbook is only 32bit. So my options were to either keep Fedora 19 unpatched, upgrade to Fedora 21 workstation, which I wanted to do, upgrade to Fedora 21 with XFCE, which would probably make it peppier, or explore other distros, which I don’t wish to do.
When Fedora 21 Workstation came out in December 2014, I downloaded the 32 bit version, and the fun began. Within a couple of minutes of booting up the live DVD and before the desktop loaded up, the machine went into hibernation. This didn’t feel right, but I hit a key and things came back to life. Then, within about a minute, the machine went into hibernation again. I hit a key again, got a minute of performance, and it hibernated again, ad nauseum, and ad infinitum, literally.
Despite this, I decided to continue with the F21 Workstation installation anyway, and I ended up babysitting the install, hitting a key to wake up the system every minute or so during the installation. On a single core atom processor running at 1.5 GHz, this took a good long while and a lot of keyboard wakeups. Finally, the system was installed, but it kept on hibernating after roughly a minute.
As a reference, I proceeded to install Fedora 21 XFCE Spin, and, except for hibernating once during the initial booting up of the liveDVD, it worked like a charm.
One solution I tried was to do a “yum install fedora-release-workstation” or somesuch from an installed XFCE spin, hoping to then do a “yum groupremove XFCE” and repeat “yum install fedora-release-workstation” just to reinstall any packages which may have gotten removed, but it bricked the install and I had to reinstall XFCE yet again.
For a variety of reasons which are now lost in the winds but which probably included having gone through the following suggestions from ask.fedoraproject.org, I managed to install and re-install the XFCE spin several times again after probably having reinstalled the Workstation a few times in between.
The first response I got was:
“You can do tests and get logs without interference with systemd-inhibit – ie sudo systemd-inhibit bash. The system won’t suspend or hibernate until you end the process invoked with systemd-inhibit.” This didn’t work; hibernation continued as before.
The next response was “I’m just guessing, but it feels like the system thinks that the battery is almost empty and because of that does the right thing in that situation. I’m not sure which software component is handling this situation but anyway, there seems to be a bug that happens to manifest on your particular environment.” This could have been ruled out immediately – mostly – because at the time the battery was physically out of the machine when I tested, and I was running on mains electricity out of the wall. Nonetheless, I did check, with a fully charged battery in, to be sure I wasn’t being a fool; no such luck, under both cases, the machine kept on hibernating every minute or so.
All through this, I learned that at least one user with a Toshiba Satellite Pro without a CD player had this same problem, and worked just fine up till Fedora 20.
My “brother in the know” helped me with some research, and we found something: In the Arch Linux forums, the problem is described, and the user “Scimmia” comes up with the following workaround (here’s my archive):
“Try setting ‘HandleSuspendKey’ and ‘HandleLidSwitch’ to ignore in /etc/systemd/logind.conf” “Scimmia” further claims that this problem appears to be caused by systemd/logind. This all means that somewhere, signals are being sent out, rightly or wrongly or otherwise, that are being interpreted as “the clamshell lid is being closed, so it’s time to hibernate.”
To wit, my brother and I, after I’d installed Fedora 21 Workstation for the probably at least third time, then boot up an XFCE liveDVD (but do not install it), and through some of my brother’s linux kung-foo, he mounts the hard drive, using Thunar in the XFCE spin as a facilitator, and we edited the appropriate file.
… And Bingo was his name-OH. (Translation: Yup, that worked and the machine now works.)
Here are the instructions to correct the problem, at least for an Acer Aspire One, and which are also findable through ask.fedoraproject.org:
1) install F21 32bit workstation, by babysitting the system throughout the whole install to keep waking it up every minute or so (literally!)
2) reboot using a live-dvd that works on the system, such as the F21 XFCE live-DVD
3) mount the hard drive (not really sure specifically how my brother did it but using Thunar seemed to help out a lot)
4)open a terminal session and make sure the hard drive is mounted
5) edit the file /etc/systemd/logind.conf (such as using nano)
6) uncomment the settings for “HandleSuspendKey” and “HandleLidSwitch”
7) set the “HandleSuspendKey” and “HandleLidSwitch” options to “ignore”
8) save the file
… and, it seems, my instructions, posted on ask.fedoraproject.org, helped at least one other user with an Acer Aspire one. I’m pleased. ?
Now, as for what I think of it … well I like F21 Workstation. On my laptop, it’s a slightly sluggish, but still working well.