Beware in Google searches: This model is the E5-573G. There is also a V5-573G and Google will return items mentioning this model. It is a completely different, older machine, and you need to filter out such false positive hits.
To do upon receipt:
The goal here is to make it possible to reinstall Windows on the SSD if I need it, but I hope to completely delete Windows from my machine. The Windows 10 Specifications page says 20Gb is required for the 64bit OS. I'm sure you need more to actually do something. I ended up allowing 50Gb.
In this I'm following the review by TekSyndicus (2015-09-01) on the Amazon product page.
Need to create a USB, DVD or ISO?Check the prerequisites (Before You Begin).
Outcome of the quick checkout, combining both Windows and Linux:
Size is 1920x1080px. Assessing viewing angles: Vertical: there is not really a range where the display colors are constant. Decent rendition +30deg to -20deg. Legible: +45deg to -35deg. (+ is above.) Horizontal: Colors are reasonably constant in ±20deg. Legible in ±60deg.
Other laptop, mobile and desktop displays have
colors. My judgment isn't quantitative, but it looks like the lightness
component (in CIELUV and friends) is turned up a little, which
necessarily turns down the saturation. For example, suppose you
displayed green = rgb:0/100/0. You would see something more like
rgb:20/100/20. I would want to get into CMS and tweak this display's
colors. The reduced saturation is seen on both OS's. Tweaking
apparently is on Linux only; on Windows the color tweaker just tells
you how to do it on a well-equipped separate display.
You won't do digital artwork on this screen. An IPS screen would be a lot nicer. But for my mode of use I think the screen is going to be acceptable.
Keys are acceptable in feel. But they are far from silent and I think my wife is going to complain. It's like something in the keyboard structure is rattling when I tap the key. In a short test using Windows Notepad I didn't get any failures to activate, There was one double strike but it's probably my fault. On Linux I did a formal test, typing 100 words of sample text on both the Acer and the Vaio. They are equivalently responsive and acceptable in feel. Again, no failures to activate, and no double strikes. The text was byte for byte identical except for whitespace and for one typo which was my fault.
Does it feel
flimsy? Definitely not; it feels
normal. Is it really twitchy like some reviewers say? Out of the box
in Windows 10, I do not get the swoopy behavior one reviewer complained
about. A quick swipe corner to corner on the pad moves the cursor from
corner to corner of the display with room on the pad to spare. Slow
motion across the pad takes you corner to center: acceleration
apparently is set for 2.5 to 3.0. This is pretty much how I normally
set up a touchpad, but you can configure it to your own taste.
Using a GUI text editor to test both the pad and how well the OS's graphic libraries use it -- Notepad on Windows and Teddy on Linux. Click and drag works as expected, selecting a range of text. A two finger gesture scrolls the text, but in Windows the metaphor is grabbing the text: move your two fingers up to see text that is lower. In Linux the metaphor is moving the viewport: move fingers down to see text that is lower. The pad (in both OS's) is very resistant to palm hits (explicitly tested). You need to actually touch the pad to be recognized; nails usually don't count, as they do on the Vaio's pad. In a modest test on Notepad I had no false activations due to stray touches, while I had quite a lot on the Vaio during the same time, taking notes on this outcome. During a lot of typing on Linux I got a few stray touches, but way fewer than on the Vaio's pad.
To adjust the touchpad properties in Windows: Right click on the
display background. Pick Personalize, Themes, Mouse Pointer. Switch
to the Pointer Options tab. Set the (fast motion) speed to your taste;
default is in the middle of the scale and it will take you across the
screen with some spare room on the pad. Turn on
Precision (on by default), which reduces mouse motion when you move
slow. You can't choose how much it slows down, but like I said, the
values out of the box are reasonable. The reviewer who was constantly
bothered by fast pointer motion should have done this.
The only nasty issue is, there is a pair (at least) of bugs in the
pad's firmware, which surface from time to time and prevent multitouch
mode. Reported fixed in kernel 4.0.8, not working for me in 4.1.5 and
4.1.12, reported failing in 4.4-rc4, fixed (and working for me) in
4.4.0, still working in 4.4.3. Simplify your life: in BIOS set it for
Basic mode and it will work in 4.1.x (and likely all the rest),
including acceleration and scroll gestures.
In Windows, both of them can get the machine's assigned IPv4 and IPv6 addresses. Wired Ethernet could download Windows updates and do other off-site activities (including web browsing), once the machine was registered with the gateway's firewall. (Later, web browsing stopped working.)
But Wi-Fi could not connect to any site, on or beyond the local LAN. The gateway's firewall is not rejecting packets. See below for imprecations about McAfee Personal Firewall, which is to blame.
On Linux, wired and wireless networking worked in the normal way,
due to some preliminary research on what kernel version has a
ath10k_pci driver that supports the Qualcomm-Atheros QCA9377 wireless
NIC -- kernel 4.4.0 and above, for SuSE, though Ubuntu 15.04
Vervet supposedly has the driver backported to whatever
back-version kernel they're using. There is also a
firmware file needed.
I found the civilized way to discover the MAC address in Windows:
Settings, Network+Internet, Wi-Fi, Advanced Options, the MAC address is
on that page. For wired Ethernet, click on the
A USB flash drive with FAT-32, inserted into any of the three USB ports, was mounted successfully. On Windows, McAfee offered to scan the drive each time (which I declined).
On Windows, the firewall service is being handled by
McAfee Personal Firewall. It blocks
the user from all network access on the local and global network. (Windows
Update can get through though.) This applies apparently both on wired and
Wi-Fi. I found that it was on the
Private profile but I couldn't figure
out how to change the access mode. I tried various settings pages which have
worked on previous versions of Windows, to no effect. I'm sure an experienced
Windows sysadmin would know what to do, but I'm a Linux guru, not Windows, I
need to download the Media Creation Tool a lot more than I need to protect
Windows. My gateway machine has a very
aggressive firewall and should be able to keep the global hacking community out
of the Windows machine. So I just turned off the McAfee firewall, hiss, boo!
That took care of it.
For the ath10k_pci driver for Qualcomm/Atheros QCA9377 Wi-fi NIC, in the likely case that you're using a kernel earlier than 4.4.0 and want to continue to do so, see this wiki page for ath10k backports. However, I tried to make the backported driver work in my distro's kernel 4.1.12, . Details here on the ath10k backport (failed).
To get into BIOS setup, press the power button and immediately press F2 (suggested: several times). You need to hit it in the about 2 second interval while the Acer splash screen is showing. It promptly drops into Setup.
Various forum posts give a procedure if you've already booted Windows and don't want to power cycle (this one is for Win-8.1): open the Settings Charm (Windows-I key combination), pick Change PC Settings, pick Update and Recovery, pick Recovery in the left pane and Advanced Startup + Restart Now on the right. Give it a few seconds. On this screen pick Troubleshoot, then Advanced Options, then UEFI Firmware Settings. Hit Restart. It will shut down Windows and boot directly into Setup. (Wouldn't it have been easier to just power cycle the machine?)
BIOS settings on initial receipt:
If the BIOS is before 1.31, i.e. 1.25 or 1.15, I will unconditionally upgrade it to 1.35, to avoid a bug reading the partition table if it includes Linux types. Suppose I got 1.31; should I upgrade to 1.35? Probably yes. I should do my best to upgrade without involving Windows.
See the Selection page for how to find the BIOS updates. Expand the BIOS/Firmware tab and pick the latest update, currently version 1.35. Click on Download. Use unzip to unzip it (in the current directory); you get a very short README file and the payload, called ZRT_135.exe . The readme says to execute (click on) it in Windows. I'm going to try to avoid that.
How to boot the USB drive, which will be needed to run the Linux installer: see this article on HowToGeek about UEFI by Chris Hoffman (2013-11-16, updated for Win10).
boot from USBoption. What I really need is to have Grub already installed, and to chain-load the USB drive. One possible issue: this USB stick assumes MBR/BIOS booting, no UEFI support.
Modern CPUs contain microcode, that is, tables settable at boot time to control complex instructions. Frequently the microcode has to be updated due to errors (errata) in the hardwired defaults. The BIOS generally contains a copy of the microcode, but there may be a more recent version, which you need to load every time you boot.
Spoiler alert: BIOS 1.35 apparently contains the latest available microcode, judging from the code's publication date. However, I did the research to (not) install it, so I'm recording the steps here. Interesting tidbit: Iris (my new NUC) has CPU 06-3d-04, same as the Acer, but revision 0x21. So in principle I could dig on Intel's site and maybe come up with this revision, and put it on the Acer.
On OpenSuSE 42.1 all you need to do is install the most recent version
of the ucode-intel package. For an AMD CPU it would be ucode-amd. The
package's post-install script will rebuild your initrd and the microcode
(for the specific machine where it's running) will be included.
Or you, or other package installations, can run
To determine if you have a microcode patch (for Intel), look in /proc/cpuinfo and find your CPU family, model and stepping. Convert them to 2 digit hex numbers; the result for my CPU (Intel Core i5-5200U) is 06-3d-04, Then within /lib/firmware/intel-ucode look for a file with that name.
To determine the currently used firmware version, look at the
microcode item(s) in /proc/cpuinfo; it will say something like
revision=0x1f. To determine if an update happened, look at /var/log/boot.msg;
there will most likely be a note in the first few lines, or if not, search
for the word
microcode; the driver announces when it applies an update.
However, the driver is silent when the CPU already has a revision equal to
or greater than the available patch, or if there is no patch for your CPU.
So it' hard to be sure if the update procedure is potentially working.
Different distros use a range of techniques to get the microcode into the initrd. SuSE concatenates one initrd containing only the firmware file, followed by the real initrd. Other distros use two initrd commands to Grub, or one command listing both files. Adapt to the style that your distro uses.
The initrd is a mini installation, which the booter (Grub) preloads into memory, containing just enough kernel modules and utilities (and firmware) to mount the real root filesystem, after which service daemons can be started.
The initial plan was to install a minimal Linux system, then install the additional memory and SSD, and finally install the production Linux system. It didn't quite work out that way, and there will be only one Linux installation. But before that, I need to decide on some policy issues.
When I install Linux the first issue is going to be partitioning. Almost
certainly the machine will have a GPT (GUID Partition Table, versus BIOS/MBR)
and the BIOS will be configured for UEFI (Unified Extensible Firmware
Interface) booting. As a holdover from the Jurassic era, normally I use the
MBR partition table and what they call
legacy booting. Is it time to
evolve into the Cenozoic, on these issues?
As a partition table the MBR is a multi-layer kludge. One forum poster
pointed out that Grub code is spread among the MBR code area, the unallocated
space after the MBR, and the Linux boot/root partition,
thrown by a baby. Also for people with huge RAID arrays, the MBR has an
addressing limit of 232 blocks or 2 terabytes (2e12 bytes).
On machines whose BIOS is capable of reading a GPT,
my policy is now to use the GPT, not the MBR partition table.
With non-UEFI (legacy) booting and a GPT, the first partition needs to extend from the end of the GPT header to at least the first cylinder boundary (1Mb is recommended in Grub docs), and its type needs to be 0x00 bios_grub. The filesystem type is irrelevant (don't format, or use FAT32). With UEFI booting you need a EFI partition. It should be the first partition (the Acer's BIOS will find it even if not first), it needs an actual FAT32 filesystem, and it needs the boot and ESP flags (gparted flag names). Windows installs it with a legacy (MBR) partition type of 0xef (and it boots), whereas SuSE gives it a type of 0x00 (and it doesn't boot). Given that the new machine has Windows pre-installed, the rotating disc is going to already have a big enough EFI partition. But I'm going to have to create it on the SSD.
How big does the EFI partition really have to be? While the relevant Grub files should fit in 1Mbyte, if you're going to dual-boot Windows. the pre-installed Windows allows 100Mb, and 150Mb in a new installation, and the reference given below recommends 200Mb. I provided 150Mb. But actual usage ended up like this: Boot 1.13Mb; OpenSuSE (grub) 0.12Mb; Microsoft Boot Manager 18.7Mb, total 20.0Mb. Next time around I'll give it 30Mb.
Assuming that dual booting is going to be necessary, for a procedure see this AskUbuntu forum thread, O.P. GhostMotleyX (2014-07-20) and particularly the reply by Rod Smith. He recommends using efibootmgr (package efibootmgr on SuSE and Ubuntu) to clean up cruft (avoid deleting important entries though) and particularly to change your boot order so Grub boots first.
UEFI includes integrity management, referred to as
The kernel must be signed with a key
known to the BIOS, and a fraudulently altered kernel cannot be booted,
including a kernel created from scratch by the user. Microsoft Windows, and
modern Linux distros, have access to a pre-installed acceptable key, but
ordinary users need to forge a key and register it with the BIOS. This is
feasible (in theory), but I really don't want to get tangled up with that
kind of security, so I am going to turn off Secure Boot. However, if you
run a public computer lab, or otherwise are likely to get malware installed
on your machine, or if the KGB, Peoples' Liberation Army or NSA would be
interested in monitoring your activities, and if you always run the distro's
unmodified kernel, you are advised to use this security feature.
Assuming I can turn off Secure Boot, I am going to use UEFI, whether or not I'm also dual-booting Windows. Yeah, sure. How am I going to boot the installer if I have UEFI? I need installation media with a EFI partition -- and I have it, the OpenSuSE installation DVD on USB.
On a related topic, what filesystem type should I use? The contenders are ext4 and btrfs, which is now the default for OpenSuSE's root partition. They use XFS for /home, though, and I've had bad experiences with XFS. Btrfs has a lot of great features like copy on write, snapshots, and de-duplication (identical blocks in different files are stored only once). However, it has two disadvantages: I would need to learn a lot about its care and feeding, and it is slightly slower than ext4, which I am familiar with. I think I'm going to defer the transition to btrfs to the next machine, and stick with ext4.
The production Linux system, OpenSuSE
Leap 42.1, is being installed
on the rotating disc.
OpenSuSE ISO image here.
do not formatand pick the bios_grub partition type.
do not formatwith partition ID (type) 0x00 EFI Boot. Then change back to yes format, with a FAT filesystem, and mount it on /boot/efi.
Vivid Vervetis said to have this driver backported. You also need firmware.
Make sure the I2C driver is loaded, otherwise a touchpad set to advanced will not work.(It's loaded, but take their advice anyway.) After rebooting, the touchpad has come alive, probably because kernel 4.4.0 was installed and is now in use.
Machine Stuck. [Update: S3 becomes reliable if you leave it asleep or awake for at least 5 mins between state transitions.]
Even on kernel 4.4.0 which supports the wireless NIC, syslog reports
Firmware upload failed!
The driver looks for several files (alternate names or versions for two
firmware files, I think) in /lib/firmware/ath10k/QCA9377/hw1.0 , not found.
forum post on Ubuntu about QCA9377,
Get firmware for hw1.0 from the
ath10k firmware site on Github. Change directories through
ath10k-firmware/QCA9377/hw1.0 and you will find a set of 3 files:
board.bin , firmware-5.bin_WLAN.TF.1.0-00267-1 , and
notice.txt_WLAN.TF.1.0-00267-1 (a license file). Click on the first
two links and on each page at the bottom is a button titled
View Raw. Click on it. The browser should offer to save the
binary file. I didn't figure out how to snarf the license file.
Make the directory tree /lib/firmware/ath10k/QCA9377/hw1.0 (mkdir -p).
Now copy the firmware files into this dir.
Also do: ln -s firmware-5.bin_WLAN.TF.1.0-00267-1 firmware-5.bin
Now: modprobe -v -r ath10k_pci (it also removes 4 dependent modules),
And: modprobe -v ath10k_pci (reloads the same 5 modules).
It tries to load 2 nonexistent firmware file names, but apparently is satisfied with the ones it was given, and /sys/class/net/wlan0 appears.
The Ubuntu post linked above mentions that there as many as 11 variants of the QCA9377 chip sharing the same PCI ID (168c:0042), A major transition is said to have occurred about 2015-08-xx (my manufacture date is 2015-08-19). However, I don't see any evidence of alternative firmware files, or of people complaining that the hw1.0 files don't work on their machines.
I tried various ways to install Linux and to have it booted via UEFI. The installation DVD will UEFI boot; why won't the installed system?
Do Not formatwith partition ID (type) 0x00 EFI Boot. Then change back to yes format, with a FAT filesystem, and mount it on /boot/efi.
Microsoft Basic Data. I set all of them according to their proper roles. Even so, Linux would not UEFI boot.
Various steps, presented separately in this document, were actually performed in parallel, and a key step in diagnosing issues with S3 (suspend to RAM) reliability was to reinstall Windows and test S3 there. Also I want to take the time to at least attempt to activate UEFI booting. Here's what I did:
Microsoft Basic Data.
opensuseand this entry is first in the boot order.
The next step in the plan is to replace the rotating disc with the SSD, and add the second stick of memory. The first sub-step is to disassemble the laptop to gain access to the memory sockets and the drive bay. It would be a good idea to review the procedure, before purchasing the memory and SSD.
I was not able to disassemble the laptop. Thanks to my friend Charlie Chen, who knows a lot more about the insides of laptops and was able to make it work. Here is a summary of the procedure (from memory):
While I was exchanging Xena and Orion, i.e. moving into the new laptop, editing these notes was not possible. Basically I did these steps:
Nasty fly in ointment: I'm using LightDM's webkit greater, which has
advantages in my situation but which is not as idiotproof as I would like.
When I logged in the greeter said
Logging in jimc and just sat there.
It turned out that if you auto pick the session type, it picks something
(I think icewm) that isn't installed, and things go downhill from there.
If I picked the session type explicitly the first time, it let me on and I
got a correct ~/.dmrc so I don't have to pick the session type on subsequent
logins. Various stuff on my system, including X session startup and package
management, are customized, and I'll bet this wouldn't have happened on a
showroom stock SuSE installation.
items that need to be finished:
Cheese gets a segfault when opening the webcam. I'm
currently blaming it on some kind of version skew in GStreamer. Fix it,
or get positive confirmation that the software is not hosed and the
webcam is to blame, i.e. sets off a bug in GStreamer. Skype (using
32bit GStreamer) can open the webcam and show video, so it's got to be
Color management. Make a color correction file that makes the colors look decent. Arrange for it to be loaded whenever the X-server is started.
Make the network bridge work. The virtual machines are configured
for bridged networking, and operating without the bridge is very
inconvenient. But there's a recent policy for wireless drivers that
the 802.11 spec supposedly forbids bridging, so
supported when you try to add wlan0 to the bridge.
Remove the annoying product hype labels from the machine. [Done.]
Ready to Talk (tm) to Cortana, my ass.
Test suspend modes:
Machine Stuckfor details.
systemctl suspend, you need to do
systemctl suspend -i. The logout menu item includes -i. No PolicyKit check on this. Resuming on lid open: works, if enabled in BIOS. Resuming on power button press: works.
systemctl hibernate -i, and there is a PolicyKit check for which you need to give the root password. Including from the logout menu item. S4 has been reliable so far.
Get my monitoring script working again so I can keep track of
the battery level. [Done.] Key items discovered: All files are in
/sys/class/power_supply/BAT1 . Composite from several files:
SANYO model AL15A32 Li-ion serial_number 9912.
These are individual files:
Voltage went down to 14.39v, charge to 0.507Ah, and it did not yet do pre-emptive hibernation.
Before doing battery life tests, do their procedure of cycling the battery 3 times, which allegedly will get the battery into shape for maximum charging. When the battery is fully charged it reports having about 2.47Ah in it, at a voltage of 17.37V. Took about 3 hours to charge fully. Voltage when started to discharge was 16.98V.
Battery life test, in 3 conditions:
Best laid plans: Whatever SSH keys I ended up with, they're mixed up. Either get the correct key on Xena/Orion, or accept the keys currently being used and get them into known_hosts on all hosts. [Done, correct keys on correct machines.]
Remaining checkout.sh discrepancies: IPv6 is up and functioning (locally), but it didn't get the default route as it should. This self-healed. grub-once got enabled, probably when I hibernated, and audit-scripts is complaining. Will disable itself on the next reboot.
Copy remaining backup.pln files from Orion to Xena, and get them into the post_jump storage area. Evidently some are not there as they should be. [Done.]
One remaining key power measurement: when playing MPEG-4. While I'm at it, put together an iterator script that will run the test repeatedly until the battery runs down. [Both done.]
XFCE desktop setup: missing the battery level applet, and missing workrave which isn't installed. [Downloaded workrave again. Battery applet lost its icon.]
Obtain and install the microcode patch mentioned on the Arch wiki. See if it improves suspend behavior. It doesn't; our BIOS already includes the latest microcode.
Check, and if necessary install, certificates in Firefox. The trust storage should have been copied with the rest of my homedir. [OK]
Test the SelenAP Wi-fi connection. With VPNs. [OK]
Test and (if necessary) fix the VPNs.
|Host||OpenVPN 1194||OpenVPN 443||IPSec|
|jfcarter.net||IPv6 only||IPv6 only||IPv4 only|
|sunset.math.ucla.edu||Both||Both (lossy)||IPv4 only|
|diamond||IPv4 only||IPv4 only||IPv4 only|
These outcomes are as expected given the design and current state of the VPNs. Listed issues are not the fault of the Acer.
NetworkManager, when you're connected to Wi-fi, shows a
blocked icon rather than signal bars as does the same version on
the Vaio. Oops, lost its icons. Reindexed and fixed.
Set up adaptive brightness control, and learn how to set it to fixed 50% for the battery life tests. The Vaio did adaptive brightness control in the BIOS. It seems to be happening on the Acer as well. The target was a very short webpage with mostly white background. I pointed my cellphone at it and watched the reported brightness (in lux). In the afternoon it put out 145 lux; in the evening under artificial light it was at 78 lux. Subjectively the screen brightness matches the room lighting. So apparently the BIOS is doing adaptive brightness and not telling us.
Testing the microphone and internal speakers: it records and plays
back. Not audiophile quality. Simple command lines to test this:
alsamixer -- make sure the mic and speaker are not muted.
arecord -l -- list devices.
arecord -t wav -f S16_LE -c 2 -D hw:1,0 mic.wav
aplay -D hw:1,0 mic.wav
Testing the card slot. It's a full size slot. You just stick the card in and pull it out, no locking mechanism. The card sticks out a bit; be careful not to hit it. MMC and SD cards were mounted successfully. XFCE's volume manager mounted them automatically.
Investigate the Acer BMA150 accelerometer. People report getting readings from the accelerometer on other machines, but it's through ACPI, and getting contact with it looks like more trouble than it's worth. It's for recognizing when the laptop is being dropped, and shutting down the disc, which can be done before the laptop hits the floor.
The load average is always 1 or 2. Find out what's running, probably some kernel thread that's new in kernel 4.4.0. CPU and I/O are not actually being used. See if I can get the load to be 0 on an idle machine.
I was actually able to track this one down, at least partially.
There are two kernel threads which are always in D state, i.e.
uninterruptible waiting. Most commonly D state involves I/O, but not in
these cases. One thread is named rtsx_usb_ms_1 and is produced by
the rtsx_usb_ms module, which is the Realtek USB Memstick Card
Interface Driver, i.e. the card slot driver. It appears to be polling
the state of the card slot, and its WCHAN (wait channel) is identified
as msleep, which is an uninterruptible wait for a specified duration.
If this module is unloaded
or is never loaded, the load average goes down by 1. I blacklisted it
by adding the line
blacklist rtsx_usb_ms to a conf file in
/etc/modprobe.d (I used 99-local.conf). Of course this means that the
card slot cannot be used, until the driver is loaded by hand.
There is also a kworker kernel thread which is not always running. Its WCHAN is ec_guard, which is defined and used in ./drivers/acpi/ec.c in kernel 4.4.x. It polls for an ACPI EC event to finish, with waiting between polls. EC means embedded controller. I have not definitively tracked down what causes this kworker to start up, but there's a coincidental but seemingly irrelevant syslog message from NetworkManager.