Acer Aspire 5, A515-54-51DJ (2019)
Setup
Table of Contents
See also:
- Laptop: Acer Aspire 5, A515-54-51DJ
- Power brick, nominally 45W, 19V x 2.37A (45W),
100V to 240V up to 1.2A, 50-60Hz.
- Power cord, NEMA 5-15P (North American, 2 parallel flat blades with
grounding pin). Total length of the cord plus the brick's cable is
about 2.2 meters. It ends with a barrel connector, about 2.5mm
diameter (skinnier than the E5-573G).
- Rails, and a package of screws, for installing a 2.5in disc. It's a
sheet metal rectangle going around three sides of the disc with a
plastic film insulator covering the bottom.
- Setup guide (English, French and Spanish)
- Warranty and other documentation. Warranty is region locked; when
service may be needed elsewhere, take with you the provided
Traveller's Warranty
document and your proof of purchase.
- The product page lists the Li-Ion battery as a separate item, but
it is preinstalled and not intended to be removed/replaced by the
user. However, if you did procure a replacement battery, swapping it
would be a piece of cake.
- The Acer
Green Pack
is 100% cardboard and/or carton. The
machine itself is wrapped in a nice spun-bonded polyolefin bag, with
a screen-keyboard separator of similar material.
To do upon receipt:
- Inspect for shipping damage. All OK.
- Reading labels:
- This device contains WLAN and Bluetooth module QCQCNFA344A
(whatever that is; try to find the actual chip number).
- Acer Aspire A515-54 Series, model N18Q13, 19V 2.37A.
Made in China. Acer is a Taiwanese company.
- Model: A515-54-51DJ
- Mfg. Date: 2019-05-20
- S/N and SNID: copy these down.
- Plug it in so it can charge. Connect the Kill-a-Watt power meter for
power measurements. The instructions
(for the E5-573G) say to charge fully, then use up the battery
completely, 3 times, as the first thing you do. Other sources,
possibly more recent, claim that this is an urban legend, and the
solid-electrolyte interphase layer is fully developed after the
first charge. I"m
going to do normal activities such as setup and power measurements, on
battery power through three charge-discharge cycles, whether needed or
not. Then I will do the battery life tests.
- The M.2 NVMe SSD is assumed to be installed already and functional,
with Microsoft Windows-10 Home preinstalled. [Confirmed.]
- Connect wired Ethernet. Boot into Windows. Here are the steps in
Windows Setup.
- It runs Setup with Cortana as its mouthpiece.
- Click the microphone icon (lower left corner) to shut up Cortana.
- It now insists that you log into, or create, a Microsoft account.
Because the MAC address is not registered, it could not have
logged in. The firewall did not complain, though. This will
have to be investigated.
- Fingerprint setup: I tried it. The sensor is a little black
square at the upper left corner of the touchpad. You give it about
20 images of one of your fingers. The Microsoft instrructions
don't say so, but on an iPhone you can use more than one finger.
- Next, create a PIN: No guidance on what alpahabet or length.
If you check a box, it can have letters and symbols.
- Setting up services. Basically I'm declining everything.
- Link your Android device with this PC. It knew my Android phone
number. How? I did not do the linking.
- Backup to OneDrive. I picked "Only save files to this PC".
- Free Office 365 Home trial declined.
- Make Cortana your personal assistant? (yap, yap, it says).
Declined.
- Activity History: Decline.
- Privacy settings: Default is to allow everything; I set to decline
everything.
- Cloud based voice recognition;
- Find my device, send its location to the mother ship;
- Share typing data (to improve language recognition and
suggestions);
- Advertising ID so advertisers can personalize their spam
for you;
- Location-based experiences like directions and weather;
- Diagnostic data (including websites visited);
- Personalized ads based on diagnostic data.
- Register your product (I think this is with Acer).
Again it knows my name; how? How do you set
the region? This means the country. The dropdown list closes
when you try to pick a country. Cursor in the closed listbox
(which opens, ignore it). Take the first letter of your desired
country and add 1, e.g. for United States type 'V'. Probably there
has to actually be such a country, like Vanuatu; I hope you know
your geography. Then you can
use the mouse to move up to the one you want. Then on the welcome
screen, be sure to opt out of Acer spam.
- At last, Windows Setup is done.
- Very quick checkout of features (detailed
below).
- Power measurements with Windows out of the box, crapware included.
Default screen brightness and all other settings. Except speakers at
20% (default is 73%). Windows idle with the screen on: 10W. Windows
playing
Big Buck Bunny
(same codecs as for battery test): Edge
is playing it. It downloads the whole thing first. Mostly 11-12W with
occasional excursions up to 19W. Showing a photo but screen off due to
DPMS: 3W. (I don't know what the CPU is doing; it might be in S2 or S3
but I wouldn't know.)
- Download and execute the Windows Media Creation
Tool (details below).
- Update the BIOS (details below). Don't skip
this step: the machine ships with BIOS version 1.00 and the current
one (as this is written) is 1.12. It's a lot easier to do this in
Windows, meaning you need to do it now, not after you have wiped
Windows and installed Linux.
- With luck, we'll have the MAC addresses. Register the new machine on
my firewall. Actually do the whole IP address procedure including
updating dhcp.conf. Use the name of Orion.
- Windows storage requirements: There is 19Gb used by a hidden
partition, probably Windows restore points and archive files for
on-the-fly installation of certain features. The C: drive has 237Gb
total and 207Gb free, meaning 30Gb occupied. But this definitely
includes bloatware like Candy Crush which I wouldn't be caught dead
running, plus the Big Buck Bunny download (0.7Gb) which I forgot to
delete. Per
this article on GHacks, Microsoft's official minimum is 32Gb.
Let's pre-allocate a partition of 50Gb, at the end of the disc, if I
ever have to reinstall Windows, God forbid. I'll use it for temporary
storage of big tables for special projects. I did the same thing on
the E5-573G.
- We're done with Windows; time to install Linux.
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 (in
2019 it's raised to 32Gb). 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 for the E5-573G.
- Do this from the laptop when it's running the instance of Windows that
you are going to reinstall, or a predecessor version, e.g. Win-7, which
you either are able to upgrade for free or have bought a Win-10 license
key for.
- The USB drive needs to be mountable by Windows, i.e. formatted, and
with at least one partition with a valid Microsoftish filesystem on it.
I cleared the first 10Mb of a drive that I was recycling, then ran
parted (on another Linux machine) (parted /dev/sdb ; print ; make very
sure you have the correct drive) to put a MBR on it (mklabel msdos),
and a partition (mkpart primary fat32 0 -1) (quit to get out). Then
format it (mkdosfs -F 32 /dev/sdb1).
- First insert the USB drive where you're going to put the resulting
ISO image. It needs to be mounted; don't eject it (like I did).
The ISO image is around 3Gb in size, so they say, so the USB stick
needs to be bigger: 4Gb is enough. (Update for 2019: needs 8Gb.)
The USB stick will
be reformatted (all data lost) and turned into a bootable DVD. It is
also possible to burn the ISO image to DVD media (if one has a drive).
- Go to the page for
downloading the Windows 10 ISO. If you're on the target machine
(vs. a Linux box) it automatically redirects to the Get
Windows 10 page.
- Scroll down to
Need to create a USB, DVD or ISO?
Check the prerequisites (Before You Begin).
- When you have the prerequisites taken care of, hit Download Tool Now.
It downloads slowly.
- The first step is to run it; there is a Run button on the download
progress box when it finishes. Give it time to start; it isn't swift.
- Agree to the Microsoft EULA.
- Main activity: Create installation media for another PC.
- Choose the language, architecture and edition (Windows 10 covers both
Home and Pro). It will pre-fill these. Don't try to install a
different language, architecture or edition than the one already
installed; they say it won't work.
- Tell it to stuff a USB flash drive. You could also save the ISO image
and subsequently burn it on a DVD.
- Pick your drive; if there's only one, it will be preselected. It has
to be mounted, or at least not ejected.
- For me, the download proceeded glacially. Looks like it's going to run
overnight. Not really; it started very slowly, but speeded up and
finished in only one hour. The ISO is about 3Gb in size, which
translates to 6.7e6 bits/sec: limited by the server, not my FIOS
speed. Update for 2019: the ISO is bigger but I'm not sure exactly
how big. 8Gb should be enough space. Also the download steps are
faster.
- Then it does a checksum, and finally writes on the media.
This takes about 6 minutes with my USB stick, not particularly fast.
- When the program finishes, eject the USB stick using Windows Explorer,
remove it, and put a label sticker on it.
- Later I was able to install Windows from this image (on the E5-573G).
Outcome of the quick checkout, combining both Windows and Linux:
- Display
Size is 1920x1080px.
It's a beautiful IPS screen. Colors are uniform
no matter what direction you look from: ±90° vertical and
horizontal. The brightness seems focused toward perpendicular viewing,
but there's plenty of light for co-viewers around you at quite broad
viewing angles. While it's hard to assess color accuracy without a
spectrometer, the colors look accurate and bright. I wanted to
immediately start editing photos.
Compare to the TFT screen on the E5-573G: colors vary a lot depending
on look direction, particularly with vertical tilt. Brightness (set
to the default) looked darker compared to the light borders. Comparing
the two screens' color rendition, the TFT screen (viewed perpendicular)
clearly had less lightness and less saturation. When viewed off-axis
even 20° the color was even worse, including hue errors due to
different loss of lightness in different primary colors.
- Keyboard
Keys are acceptable in feel. However, in fast typing
I occasionally (maybe 0.3%) pressed too lightly and got a failure to
activate. There were no cases where I had to whack the key hard to
get it to register.
On Linux I did a formal test, typing 134 words of sample HTML (one
of the paragraphs from this writeup) and pushing on speed. As noted
above, I have a habit of pressing too lightly, but there were no real
failures to activate, and no double strikes. The text was byte for
byte identical except for whitespace and for one transposed pair of
letters which was my fault.
- Touchpad
With the default settings, a quick swipe corner to
corner on the pad moves the cursor from corner to corner of the
display; however, it needs to be quick, and the old laptop when
reaching the opposite corner would still have room on the pad. I plan
to tweak the acceleration parameters to start accelerating at about 70%
slower speed and to accelerate about 1.5x more. Slow motion across the
pad takes you corner to center. This is how I normally set up a
touchpad.
Next I used 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.
- A two-finger tap fairly reliably produces a right mouse click,
and (on Linux) a 3 finger tap produces middle mouse.
- The pad (in both OS's) resists palm hits (explicitly tested), but
not as well as the E5-573G.
- You need to actually touch the pad to be recognized reliably;
nails usually don't count. But again, the E5-573G had a lower
probability of recognizing a nail tap. (I wonder how long my
fingernails were when I tested the E5-573G; today they're quite
short.)
- In a modest test on Notepad I had no false activations due to
stray touches. During a lot of typing on Linux I got no stray
touches at all.
- Wired and Wireless Network
In Windows, I never did test Wi-Fi, but with wired Ethernet (IEEE
802.3) it can get the machine's assigned IPv4 and IPv6 addresses,
download Windows updates and do other off-site activities
(including web browsing wih IPv4 or 6).
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 Connected
line.
On Linux, wired and wireless networking worked in the normal way,
because I already had the firmware file installed for the QCA6174
Wi-Fi chip, from package kernel-firmware-ath10k.
To find the Driver Download Page:
- Start at Acer's front page.
- Open the hamburger (3 lines, upper left corner).
Expand
Support
. Click on Drivers and Manuals
, the
first item.
- Tell it your device: serial number, SNID, or model number. All of
these are on a sticker on the bottom of the machine and you should
have copied them down. The SNID is shortest; it appears to be an
abbreviated serial number. Hit
Find
.
- The page for your model appears. Expand
Menu
. Click on
Drivers and Manuals
.
- Expand
BIOS/Firmware
.
- The available BIOS packages are listed, most recent first. Hit
Download
on the first one. As this is written (2019-10-18) the
most recent is 1.12 dated 2019-09-24 (13.7Mb).
Procedure to install the BIOS:
- Either copy the downloaded BIOS onto the Windows machine or
download it afresh (per the instructions above).
- Open it with Windows Explorer which should unzip it into a folder.
- As this is written, the package for the A515-54 (2019) is
ZAW_112.exe . Double click to execute it. Blow off various warnings
about running code from an unknown publisher.
- It goes through the update procedure with no confirmation prompts etc.
- After it copies the payload into a mysterious location (somewhere in
the NVRAM where the BIOS itself resides), it reboots
into the flasher (part of BIOS) which copies the new BIOS overwriting
the old one.
- Then it reboots. It turns the display lamp on and off several times,
then shows the Acer logo, on and off several times, giving the
impression of a boot loop. There was a fairly long period when it was
using around 20W of power with the screen off. Not to worry.
- It eventually reboots into Windows, and the process is finished.
To get into BIOS Setup, reboot or turn on power (press the power button).
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 reboot or 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 reboot the machine?)
BIOS settings on initial receipt:
- Once you boot Windows for the first time, it sets the system date
to the local timezone. I didn't switch to UTC; the Linux installer
will do this itself. On the E5-573G the
system date was in timezone +10 (China).
- F12 Boot Menu was disabled, changed to enabled.
- Wake on LAN was disabled, and I left it because this is irrelevant
for a laptop.
- Passwords: None. I set the Supervisor Password (only). This is
required to (try to) turn off Secure Boot.
- TPM (Trusted Platform Module) is enabled by default; I left it on.
- Leave Secure Boot settings alone, on the Security page.
- On the boot page you can change the boot order. I was doing this
just before installing Linux, so I put the USB stick before Windows
Boot Manager.
- Secure Boot: I could find no way to disable it, nor to switch to
Legacy Boot
. Watch for the consequences further on.
- Save and exit (F10).
- The MAC addresses are not published in Setup.
Later when installing Linux I made these tweaks to the BIOS:
- Main page - Function keys: Default is media keys, change to
function keys. This setting tells which keycodes should be
produced when you press one of the top row keys; to get the other
keycodes you hold down the Fn shift key while pressing the
media/function key.
- Main page - D2D Recovery: turn off.
- Security - There is no supervisor password, and you can't do
anything on this page until you set one. We're in
Standard
Secure Boot mode. I left this alone.
- Boot - Order: Windows of course is first. Switch temporarily
to the USB stick. Hit Esc, and tell it to save changes (for just
this item).
It should also be possible to use the F12 boot menu, but I'm sure
this way will be a lot less hassle.
- Exit - Save Changes. The machine will reboot, and start the
network installer rather than Windows.
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 that's not in
the available BIOS, which you need to load every time you boot.
Spoiler alert: BIOS 1.12 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.
On OpenSuSE 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 post-install scripts, can run mkinitrd
.
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-8265U) is 06-8e-0b,
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 wipe the NVMe disc (with Windows) and to overwrite
it with the production Linux system. It didn't quite work out that way: the
NVMe disc is not visible to the Linux kernel. This general symptom is seen on
quite a lot of machines, and the finger of blame points to a BIOS
bug feature. I recovered
by installing a SATA SSD.
This installation will be the first time I have attempted booting by UEFI
(Unified Extensible Firmware Interface). Although SuSE has supported UEFI
for several years, on both x86_64 and ARM architectures, I'm expecting
a lot of trouble in this area.
But first I need to make some policy decisions.
When I install Linux the first issue is going to be partitioning. The
A515-54 comes with a GPT (GUID Partition Table, versus BIOS/MBR).
On a MSDOS-type operating system, the disc begins with a Master Boot Record
(MBR), which includes a code area for the booter, and a table giving the
boundaries of the partitions. Of course the complete booter won't fit, so
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, like spaghetti
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).
The more modern partition table is called the GUID Partition Table (GPT)
where GUID (Globally Unique IDentifier) refers to a field in each row that
designates the role of the partition, which is ignored in Linux. Basically
it replaces the partition table in the MBR.
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,
whereas SuSE gives it a type of 0x00.
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. On the old E5-573G 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. On the A515-54 (new) I gave it
30Mb, successfully. While SuSE puts the kernel(s) in /boot, other distros like
Gentoo and Raspbian put them in the EFI partition, and you will need more than
30Mb. For my experiments with Gentoo on ARM I gave it 64Mb (with only one
kernel and initrd at a time).
I never dual boot because one of the operating systems becomes the favorite
and the other one ends up not getting security updates. However, if other
users need dual booting, 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.
After a clean installation of OpenSuSE Tumbleseed, and presumably recent Leap
and SLES versions, the boot order is preset in this way.
UEFI includes integrity management, referred to as Secure Boot
. 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 [try 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 or net installer 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.
Gakk, the Linux (OpenSuSE Tumbleweed) installer cannot see the NVMe SSD,
and neither can the rescue system. There is a mysterious item in boot
messages: ahci 0000:00:17.0 Found 1 remapped NVMe device. Switch your BIOS
from RAID to AHCI mode to use them.
However, this setting is not available
on the Acer A515-54.
Some web research looking for related symptoms.
-
Can't See NVME M.2 Drive for Fresh Install
,
OP MikeyBee, 2018-12-xx. Responder Steven said, in BIOS Setup
find SATA Operation and change it to AHCI. MikeyBee discovered an item
on the web saying add to your kernel command line:
pcie_aspm.policy=powersave . No confirmation whether either of these
was helpful. I didn't see the SATA Operation item in BIOS Setup,
maybe because I have no SATA devices.
-
Linux Novice Struggling With Ubuntu Install NVME Drive Partition Not Detected
,
OP dfleis, 2019-03-20. His Ubuntu installer does not see the NVMe disc
(or any of its partitions); in Windows he created one for Ubuntu to
use. He tried these: AHCI was already enabled. With or without
secure boot. Unplug rotating disc. Disable Windows fast startup.
Dis/enable virtualization in BIOS. It turned out that a back version
nVidia driver was part of the problem. 2 possible leads:
-
Solved Installing Linux on an M.2 SSD
,
OP Vitalius, 2016-12-xx. Responder Ctrl_Null suggests disabling
Secure Boot and Fast Startup. He says, Secure Boot usually has the
issue of not showing drives. But for the OP, Secure Boot was already
off. As was Fast Boot. (But it's worth a try for me.)
- In BIOS Setup - Security - Set Supervisor Password. It's recorded
in the Appropriate Location.
This password will be required when you run BIOS Setup.
Erase all Secure Boot Setting: Did not have any visible effect.
Restore Secure Boot to factory default:
There doesn't seem to be any way tp turn off Secure Boot.
- Booting the rescue system. (Hit More on the installer screen.)
The loginID is root, no password. It takes a while but eventually
lets you on.
- The chipset is Cannon Point.
- lspci reveals: Wi-Fi NIC Qualcomm/Atheros is QCA6174.
Ethernet is Realtek RTL8111/8168/8411 (PCIe). Graphics is
Intel UHD Graphics 620
Whiskey Lake
. There is no sign
of anything involving NVMe.
- lsusb reveals: besides hubs, we have 04f3:0c03 Elan Microelectronics
Corp, 0408:a061 Quanta Computer Inc, 04ca:3016 Lite-On Technology
Corp.
- We have /usr/sbin/nvme and /usr/sbin/nvme-det-hostnqn (from
package nvme-cli).
nvme list
lists all NVMe devices, i.e.
none.
- The way forward: I need a disc in the new machine. This disc has to
be accessible to the LInux kernel. A BIOS bug (pervasive in the
industry) is blamed for making the NVME disc invisible to Linux. Here
are the choices:
- The existing NVMe disc. Technically it is superior to all the
alternatives. But if I fixate on it, I have to wait, before
installing Linux, until the BIOS bug is fixed, which will take
years just to get the attention of the OEMs.
- The SSD in the old laptop. My original plan was to just
transplant it. But it is installed for
legacy
boot, and
this BIOS is incapable of booting it.
- Wipe the old SSD and reinstall. This plan is moderately
attractive, but I have to trust my backups a whole lot, or I need
to come up with space to hold a copy, and if anything goes wrong
I'm without a laptop until it is fixed. Also, getting the covers
off the old laptop is a horrendous task. I do trust my backups
a fair amount, and I do have the space, but I'm just a little too
cautious to take this flying leap.
- Install a rotating disc from my inventory. This is very feasible,
but the SSD has so many advantages that I'm willing to
solve the problem by…
- Throw money at the problem: buy a new SATA SSD. It will be the
current model of the Samsung 850 EVO 250GB 2.5-Inch SATA III
Internal SSD (MZ-75E250B/AM), $87.99 in 2016.
Selecting and Installing a SATA SSD
Selecting the drive:
- The Samsung 850 and 860 product lines look like what's current.
What is the difference between them? Why is the Pro V-NAND variant
worth 1.5x more?
-
The Best SSDs of 2019 by Brad Chacos, PCWorld (2019-03-11).
Conclusion (at the top of the article):
Samsung 860 EVO is best for most people,
Samsung 860 QVO is the best budget SSD (if you're buying a gigantic
drive which I'm not), others exceed in particular
dimensions like blinding speed. The 860 Pro is only slightly faster
than the 860 EVO.
- I'm following their advice to get the 860 EVO. Now, how big?
- Samsung SSD 860 EVO 250GB 2.5 Inch SATA III Internal SSD
(MZ-76E250B/AM) $55 SBSF Amazon
- Samsung SSD 860 EVO 500GB 2.5 Inch SATA III Internal SSD
(MZ-76E500B/AM) $75 SBSF Amazon.
- Samsung SSD 860 EVO 1TB 2.5 Inch SATA III Internal SSD
(MZ-76E1T0B/AM) $130 SBSF Amazon
- Given the size vs. price curve, 500Gb looks like the sweet
spot in 2019.
- Characteristics from the product page:
Sequential read/write:
up to
550/520Mby/sec. Warranty to 5yr
or 2.4e15 bytes written. (Jimc calculation: that many
bytes could be written in 4.62e6sec or 53 days. But most disc
operations are reading.) First on Amazon: 2018-01-10. Reviews
(probably all sizes together): 4-5* 94%, lower 6%. Lots of reviews
in just 1 week, i.e. people buy this, and most love their drive.
There are a few which sound like actual failures: fewer clueless
users than with other products. Remember that a disappointed user
is more likely to write a bad review, than a happy one to write a
good review.
- I ordered this drive.
Installing the SSD.
- Read the labels:
- Made in Korea.
- Production date: 2019-05-12
- Model: MZ-76E500 ; Model Code: MZ-76E500B/AM
- Serial number: S3Z1 NY0M 5427 84
- Retrieve the set of rails provided with the laptop.
- Take off the bottom cover.
- The bottom is plastic, labelled as polycarbonate and ABS (a
mixture, maybe?), sprayed with conductive paint involving copper.
- Remove the bottom cover, 11 screws, all same size. The one near
the middle of the hinge is rather far below the surface. I used a
flat blade mini screwdriver to lift the head up so I could grab it.
- It uses grabbers. I succeeded by starting my attack at the front
right corner (hinge away from me). Alternating screwdrivers prying
upward got the grabbers to let go without a lot of stress. I worked
toward (but not beyond) the RJ-45, then across the front and along
the left side. The left rear corner came loose easily, and then
the right rear corner was free to lift off.
- Disconnect the battery cable at the motherboard: the 8 wire
multicolored one.
- Assemble the SSD in the rails.
Up
means the side away from
the keyboard and screen (which will be Down when you're using the
laptop). The plastic insulator goes down, with the drive's bottom
label also down, and the connector toward the open end of the rails.
You have 4 screws with big studs and small heads; use those to
attach the rails to the drive.
- Connect the SATA cable to the drive. (It only fits one way.)
- Slide the drive under the cable to the USB and audio connectors.
(There is a Youtube video for the A515-54 family showing the drive
on top of this cable, but it's clearly showing a different and
probably older motherboard.) 2 of the mounting holes fit over pins
in the chassis. Attach the rails with the remaining 4 screws with
small studs and big heads. The holes are sticky as if pretreated
with Loctite®; don't worry. One mounting hole in the rail
remains unoccupied.
- The SATA cable connector is under the Wi-Fi (Qualcomm Atheros)
chip, which is in the way. It's a 22mm M.2 form factor. Don't
disconnect the antenna co-ax. Remove the screw that holds it down;
it will pop up (throwing the screw if you aren't careful) similar
to a memory card. Pull it out of the socket and push it out of
the way.
- Seen on the card: Wi-Fi MAC is 3c:91:80:ba:92:4f, Qualcomm Atheros
Model QCNFA344A.
- The SATA cable is pre-folded so it reaches right to the
connector. Lift the cable latch (the white thingy), slide the
cable under it, and push the cable latch down flat. The connector has
two rows of pins, and I think I once managed to get the cable under the
lower row, which is wrong; you want it between the rows.
- I'm an idiot! I managed to damage the cable latch. Fortunately
I got it back together. In the photo see the square of red duct
tape that I hope will retain the cable latch.
- Similar to stuffing memory, put the Wi-Fi chip in its socket at an
angle and push it in all the way. Tilt it down flat and screw it
in place. The notch at the end of the card should go around its
support stud, same as when you removed the card. If it's up on top
(blocking the screw hole), you didn't push the card in far enough;
do it over.
- Reconnect the battery.
- Close up the bottom cover. I did it in the reverse order from
opening, i.e. rear right corner first, then the left side, across
the front, and finally the right side. There's also a grabber
somewhere in the middle of the cover; I couldn't identify what
it's for.
- The battery is very flat. It is Acer branded. The label appears
to say that the minimum voltage is 15.2V, maximum 17.2V, typical
3220mAhr = 48Whr, minimum capacity 3090mAr = 46Whr. Made in China.
It is not screwed down to the chassis. Li-ion batteries are
notorious for swelling, not too much but enough to make trouble if
their surroundings are tight.
Did that help?
- Setup info page shows no model or serial number on HDD0, and the
NVMe drive on HDD1. This is not promising. Booting the Installer
anyway.
- It booted Windows. I rebooted and used F12 to boot the installer,
then started the rescue system.
- lspci still shows nothing looking like a disc controller.
- /var/log/messages (boot time): reserving Intel graphics memory at
0x8b800000 - 0x8f7fffff (size 0x2000000 = 2^25by = 32Mb only)
- A promising message (at line 692 or earlier): ahci 0000:00:17.0
Found 1 remapped NVMe device. Switch your BIOS from RAID to AHCI
mode to use them.
- (But the BIOS Setup has no submenu for switching to AHCI mode, nor
does it say anything about RAID mode.)
- I re-connected the SATA cable; evidently it was not making good
contact with its connector after the damage. Now it's in much better
shape. The rescue system and the installer recognize that the SSD
exists.
For me the current production Linux system is Tumbleweed. It is being
installed on the provided 256Gb NVMe SSD. (Dreamer!) I will need to prepare a
USB memory stick with the net installer's ISO image. I have a Squid proxy. In
this installation most of the files will be downloaded only once; but I'm going
to (try to) use the proxy anyway, in case that is overly optimistic.
- How to find the network installer:
- You will be doing these steps on another computer (or if you're
a masochist, on Windows of the new machine). Insert the USB stick,
that's going to receive the network installer, in a USB port.
- Start at OpenSuSE's front
page. Follow the link to install Tumbleweed (or Leap).
- The Metalink paradigm downloads from multiple sources
simultaneously, which in favorable conditions can speed up the
process. There is a Firefox plugin for this called
DownThemAll!
, which also will verify the checksum by itself.
But the network installer is too small for metalink to be worth
the effort to make it work. It might be different if you were
downloading the DVD.
- Skip down to your main activity (Installation) and architecture.
The Network Installer is right for me, but some people may prefer
to download and burn the DVD. Unless you have a Metalink
downloader, Pick Mirror. And also download the checksum.
- Download size: 136Mb.
- Be paranoid; check the signature. You can use any
convenient identity; I'm using root's default keyring. (This is
different from the one Zypper uses.)
- If you don't have the openSUSE Project Signing Key on your
keyring already, you can import if from your OpenSuSE DVD, or if
you don't have one, you can download it from the keyservers.
> gpg --import gpg-pubkey-3dbdc284-53674dd4.asc #--or--
> gpg --receive-keys 0xB88B2FD43DBDC284
- Since you are on a first-name basis with the SuSE developers, you
can trust that this key really belongs to them and that they are
not sneaking onto your system sendings from our geopolitical
enemies. Edit it like this:
> gpg --edit-key 0xB88B2FD43DBDC284
>> sign
>> trust #at level 3 or 4
>> save
- The file with the .sha256 extension is a message, with an attached
signature, whose body is one line, the SHA-256 checksum of the
payload. In the future other hash algorithms might be used
instead. First check the signature in the message file.
> gpg --verify image-180905.sha256
Says: Good signature from openSUSE Project Signing Key
, etc. etc.
- Copy to the clipboard the SHA-256 checksum in the message,
This is the 64 byte hex string making up the entire message body,
on the fourth line. Then…
- > echo "7238e1dbfbef/64bytes image-180905.xz" | sha256sum -c
(Substitute the filename of the payload file.) It should say:
image-180905.xz: OK.
You need TWO blanks between the hash and the
filename.
- Copy the ISO image to the USB stick. Be very sure you have the
correct device; you don't want to convert your boot disc to an ISO
image.
dd if=openSUSE-Tumbleweed-NET-….iso of=/dev/sdb bs=1M
Later when you want to put a normal disc filesystem on the USB
stick, you will need to first overwrite the beginning of the ISO
image with zeroes, like this:
dd if=/dev/zero of=/dev/sdb bs=1M count=1
- Simplify your life; use wired Ethernet for the new machine. I'm sure
that setting up Wi-Fi in the installer will be a hassle and will be
less reliable than 802.3 Ethernet.
- Insert the USB stick with the network installer in one of the
new machine's USB connectors. It doesn't really matter which one.
- See the BIOS Setup page for some tweaks
to the BIOS configuration.
- Booting the network installer: It asks you if you're willing to trust
the OpenSuSE cert for signing boot images (tell it yes), then it
boots right up. Use an arrow key immediately to stop the auto action
(boot from hard disc).
- Use arrow keys to navigate to Installation. Hit E to edit the entry.
You need this for Tumbleweed because the kernel and the ISO images are
constantly being updated, usually at different times. I never needed
this maneuver for Leap.
To the
linuxefi
command, append kexec=1
which is the
magic incantation to get it to use the kernel off the installation
repo, rather than the net installer's kernel, which is probably back
version and which will make the installer refuse to install the
wrong
version distro. Hit F10 to boot.
- When the Plymouth progress screen obscures boot messages, hit Esc to
turn it off.
- After downloading the kernel and the huge initrd, it reboots. Go
through the same steps again (hit Esc when Plymouth comes on).
- Be sure to let it add the online repositories because you don't have
the DVD.
- On the page to select your desktop environment (KDE, Gnome, etc),
pick Generic Desktop. I have a script to
install the software I actually want, later.
- Partitioning: Well, isn't that cute? It doesn't even let you look
at the Windows disc, proposing to squeeze everything onto the installer
USB stick. What to do now? Hit Cancel, then Abort. It drops you
into the NCurses shell-oid. Trying Expert - Shell: there is only
/dev/sda and its partitions (the USB stick). In /sys/class/ there is
a class for nvme (and nvme-subsystem), but with no occupants.
- Various interventions including the rescue system did not improve the
situation. Cancel, abort, and turn off power while figuring out what
to do.
Installing Linux, continued.
- The NVMe SSD is not going to materialize unless a miracle
occurs. See the section above on installing a
different SSD. Then repeat the above steps and continue here.
- Partitioning: I'm trying to get a system that can be used with both
legacy and UEFI booting. Each partition (except bios_grub) should have
a label and should be mounted by label, to avoid confusion during
experiments with UEFI vs. legacy booting. Set this in fstab options.
The partition order shown below is best for my use case. All
Linux filesystems are ext4 (not btrfs or XFS which are the current
defaults in SuSE).
- Delete everything first, try to get it to do UEFI.
- 1. Bios_grub, 7.8Mb (tell it 8Mb) which is the smallest that
parted will allocate on this big disc. Presumably that's the
end of the first cylinder. Tell it
do not format
and pick
the bios_grub partition type.
- 2. EFI, 30Mb (see above for why I'm picking that size). First
tell YaST
do not format
with partition ID (type) 0x00 EFI Boot. Then change back to
yes format, with a FAT filesystem, and mount it on /boot/efi.
- 3. Root, 20Gb. In SuSE 13.1 you need to ask for 5% less and your
request will be expanded 5%, but in 42.1 it gives you the size
you request.
- 4. Swap, 24Gb. Yes, a label is allowed and you can swapon
by label.
- 5. Home, 30Gb. Eventually occupied: 2.5Gb, 9%.
- 6. /s1 (scratch and special projects), the rest of the space,
minus Windows if present.
- 7. Windows, 50Gb. If Windows is required, put it at the end so
it can easily be merged later with /s1. Format it as FAT32 and
let Windows upgrade it to NTFS, because Linux NTFS tools may
not be bug-for-bug compatible with the real Windows formatter.
- New feature: If root's SSH key were on a drive (normally USB) it
could have been imported. Is this authorized_keys, or the actual
private key, which my root doesn't have?
- Turn off the apparmor pattern. Turn on these individual packages.
post_jump will install them if missing, but better to do it now to
bypass sleeping dragons.
*rsync *curl +m4 +expect +pam_ssh +pam_krb5 +krb5-client
(* = already selected, + = needed to add.) Estimated 829MiB to
download, 2.5GiB installed.
- If the firewall is disabled you don't get SSH, so enable the firewall.
Enable SSH. Tell it to configure the SSH port to be open. You have
to set all three of these, unlike in SuSE 13.1.
- Switch to NetworkManager, since this is a laptop.
- Start installation. It goes very fast.
About 1330 packages to install, taking 14 minutes this time, followed
by about 2 minutes of non-package installation (e.g. copying the
network configuration and indexing the kernel modules), after which
the machine rebooted successfully into the production operating system.
- It drops you into a lightdm greeter with SuSE branding (blueprint with
Geeko the lizard). It got its proper IPv4+6 addresses by DHCP.
- Security on SSH has been tightened up: you can't log in to SSH as root
by giving the password. (/etc/ssh/sshd_config says PermitRootLogin
yes, so I should have been able to get on. I never found out what was
wrong.) Steps in gaining trans-net access to the machine:
- I made a TGZ file of Xena's /root/.ssh, putting it on a USB
memory stick, and transferred it physically to Orion.
- If on Orion I switch to VT1 and log in as root giving the
password, it does not let me on.
- Rebooting: the boot order is openSUSE; USB HDD (the net
installer); Windows Boot Manager; opensuse-secureboot. I'm really
curious what that latter one is. Maybe the transfer stick, which
is formatted with FAT32 for flashing BIOS on Intel.
- Booting the rescue system. Again.
- Well, it has PermitRootLogin yes, as usual. Should have let
me on.
- I unpacked the saved /root/.ssh successfully
- Rebooting into the production system. Note, there's a new
behavior, resetting the system, which can get loopy.
- OK, now that authorized_keys is present, root@xena can do
ssh orion uname -a
and it works without a password.
Similarly for a remote xterm (xterm -e ssh -X orion
).
- Remember to shred the TGZ file. [Done.]
- Run post_jump. CouchNet has a list of packages wanted on the machine,
such as desktop packages and service daemons.
Post_jump installs them (using the local Squid caching proxy to get
to the SuSE repos), tosses unwanted packages, runs online
update, and installs locally hacked configuration files.
- Major post_jump events:
- Installing 364 keystone packages, 2223 packages total.
- libgstcodecparsers-1_0-0-1.16.1-5.3.x86_64.rpm not on Packman,
killed installation after 2284 packages installed.
- Removing 628 unwanted packages including a lot of vendor firmware.
Including some that I think we need.
- Updating 69 packages (includes installing 32
vendor-specific firmware packages that were removed earlier).
- Service units: enabled 45 reenabled 17, turned off 19.
- Kerberos host key: Looks like it was installed, but test failed.
- exportfs: config error at /etc/nfs.conf:12: error loading included config
- $pj/all/root/.ssh/known_hosts lacks key for orion.
- Cleanup items, beginning with package installation issues:
- Nothing provides libGLEW.so.1.13()(64bit) needed by
Mesa-demos-9.0.99~git20160303-2.13.x86_64 -- Break Mesa-demos by
ignoring this dependency.
- systemd-logger-243-2.1.x86_64 conflicts with rsyslog. Toss
systemd-logger.
- Nothing provides libdvdread.so.4()(64bit) needed by
gstreamer-plugins-bad-orig-addon-1.16.1-5.3.x86_64 -- Skip
gstreamer-plugins-bad-orig-addon (for playing DVD movies).
- Nothing provides libdvdread.so.4()(64bit) needed by
vlc-noX-3.0.8-5.6.x86_64 -- Break VLC by ignoring this dependency.
- Installed kernel-firmware-all-20190909-1.1.noarch obsoletes
kernel-firmware <= 20190909 provided by
kernel-firmware-20190909-1.1.noarch -- kernel-firmware-all-20190909
is supposedly
better
than the non-all version, which should
not be installed. Most likely, kernel-firmware (non-all) is in
/m1/custom/couchnet.sel, but has been superceded by the
kernel-firmware-all. Either change couchnet.sel, or replace with
the vendor-specific packages we actually need.
- Nothing provides this-is-only-for-build-envs needed by
libunbound-devel-mini-1.9.4-1.1.x86_64 -- Why are we installing
libunbound-devel-mini, when
unbound
is blacklisted?
Break it by ignoring the dependency.
- 169 packages to install.
- libgstcodecparsers-1_0-0-1.16.1-5.3.x86_64.rpm not on Packman.
Ignore (rather than aborting). There were a lot of these including
VLC. Probably there was a batch of updates, and the repo metadata
needs to be refreshed with the --force option. Done.
And then the affected packages were installed successfully.
- There are about 70 packages, including NetworkManager plugins,
that audit-pkgs -e proposes to remove. These should be gone over
carefully.
- With extra.sel copied from Xena, 130 more packages are wanted,
such as
cheese
. (No change in the set proposed to be
removed.)
- No ldap.service unit, can't enable. Why isn't it installed?
- Kerberos host key installation was botched; I'm not sure what
it's complaining about since it did assemble and install the
file. krb-client.J passed. Ignore this complaint.
- New item: kernel-firmware is broken up into packages by vendor. Make
sure the needed firmware stays installed.
- Reboot, and run checkout.sh. Fix discrepancies. Growl, failed to
boot the kernel or its backup.
Recovering from failure to reboot.
This is going nowhere. I'm going to do a fresh install, not run post_jump,
save SuSE's grub.cfg for forensics, and see if the newly installed OS can
reboot.
- I'll save the host keys on a USB drive, for easier reinstallation.
- Starting from the top: boot net installer, do installation with
kexec=1, format all partitions. When it's done, reboot, install
host keys, then reboot again.
- Installation went OK. Reboot after installation was OK.
Second reboot also was OK.
- Something that needs investigation: The grub menu appears. I hit
enter for the normal kernel. Like with Windows, Plymouth (I think)
snatches the
Acer
spash screen and overlays it with the
Tumbleweed logo and a throbber. Within 2 secs the greeter is on the
screen. VT1 is cleared and has a getty. What happened to the boot
messages etc? If you hit ESC promptly as soon as the Plymouth splash
screen appears, you can see the boot messages. They are executed very
fast. I think SuSE is using systemd as Lennart Poettering says to do
it: launch everything at once, with very few dependencies between
daemons. In particular, display-manager does not wait for the network
to be ready (as it does on my systems).
- Logging in as root on VT1 with password: it let me on.
- Copying the host keys onto Orion from the USB stick. Apparently
copying succeeded. systemctl restart sshd. (Could I have gotten away
with just reload?) Xena can do ssh to Orion successfully.
- grub2-emu: Once again
ls
displays just (proc) (host), no disc
drives, and particularly, the root drive (hd0,gpt3) is not visible.
Whereas on Xena, which is not in EFI mode, grub2-emu ls
displays
the boot disc and its partitions.
- If I do
echo '(hd0) /dev/sda' > /boot/grub2/device.map
and
then run grub2-emu, ls
now lists (hd0) and its partitions, and
commands that take a filename can access that file (and when the name
of a nonexistent file is given, the command says so). However,
insmod
claims to have installed lsefi.mod but the lsefi command
is not available. In the presence of the device.map, grub boots
the pristine installation of Tumbleweed, which is neither better nor
worse than it did before.
- Next step in tempting fate: grub2-install with the device.map.
Claims to have installed without error. Rebooting: In a grub command
shell,
ls
still lists nothing. But it reboots the pristine
image successfully.
- Next step: grub2-mkconfig -o grub.cfg . Differences from
grub.cfg.pristine involved an extra hint in search commands, and a new
language setting (to POSIX), neither of which should be relevant in
booting. On reboot: it rebooted.
- Next step: install jimc's standard /etc/default/grub and rebuild the
config file. The one from the grub RPM package is still there.
YaST additions (ignoring spacing in comments) are mainly to specify
the theme, and GRUB_USE_LINUXEFI="true", and to fill in the actual
swap device to resume from S4 (hibernation).
- Major differences between the successful YaST-modified grub and the
pristine
one installed during post_jump:
- Pristine kernel command line says resume=/dev/disk/by-label/SWAP-09
mitigations=auto etc. while Xena's has resume=/dev/sda5 .
Coordination in pristine one between GRUB_CMDLINE_LINUX and
GRUB_CMDLINE_LINUX_DEFAULT is not so good.
- Xena's has GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png
(which doesn't seem to do much).
- Pristine one has GRUB_USE_LINUXEFI="true" and Xena's doesn't.
Smoking gun!
- Merging these two files as grub.orion , which also becomes
grub.m4, and ./grub itself, and both are copied to
/m1/custom/conffiles/etc/default/grub* .
Doing grub2-mkconfig -o /boot/grub2/grub.cfg .
- Reboot: Success! (And no Plymouth splash screen, so you can see the
boot messages.)
- Even so, in the grub shell, ls(tab) lists about 10 ls* commands, but
each of them lists nothing at all, except lsmod lists more than a
screenful of relevant-looking modules.
Re-doing post_jump. I'm doing this phase by phase, with package
installation in manual mode. First -P 6 to stop before installing wanted
packages. Then zypper refresh and audit-pkgs -I. Then -p 8, picking up
by removing unwanted packages. The major item that couldn't be installed
was rsyslog -- fake news, it did get installed but was wrongly identified
as botched. Removing 551 unwanted packages including
kernel-firmware-$VENDOR (various, many are clearly irrelevant but maybe
not all). Actually removed 549 packages. And we're going to upgrade
to kernel-default-5.3.7-1.2. Grub2 was (re)installed as the bootloader
(no errors reported). Service daemons: 46 turned on, 19 turned off,
17 reenabled. conffiles.J changed the resume device from /dev
/disk/by-label/SWAP-09 to /dev/sda4 (currently the same device).
post_jump is supposedly successful. Rebooting: UEFI boot succeeded.
startup is reasonably normal except it's using wicked when NetworkManager
was wanted. Net did not come up.
checkout.sh discrepancies:
- Summary says passed all tests, but this is a lie: many failed.
(A recent change in the script obviously has a bug.)
- Service dontenable is disabled (failed). Bogus report.
- NetworkManager finds orion IPv6 adr
is on no interfaces (it has a DHCP address).
- NetworkManager is not wanted, is enabled and running. Wicked is
wanted, disabled, dead. Need to install extra.sel.
- ldap is wanted, disabled, dead. (No unit file?)
- autofs: orion failed to automount anything.
- display-manager: failed to connect to port 5900 causing display-manager
to be restarted, kicking me off!
- avahi-daemon: the usual mess, diagnose later when network is sane.
- dns-forward.J: wanted, enabled, failed
- kpropd: wanted, enabled, died.
- krb-client: orion is offline, skipping Kerberos client test
- krb5kdc is wanted, enabled, failed/failed (not sure why)
- postfix: 1 message waiting to go out (bad).
- apache2: not running. No configuration?
- chrony.J: looks synced, but failed test.
- named is wierded out. Probably won't be solved until changeover
to Xena.
- systemd-resolved: Can't exec systemd-resolve (why, not installed?)
- alsa-restore: dead (no conf file?)
- firewall: Probably won't be solved until changeover to Xena.
- nfs-server: Diamond failed to mount some (but not all?) orion exports.
- vsftpd.socket: can't connect to 2600:3c01:e000:306::ca:21 (has DHCP
address), cannot load RSA certificate.
Activating Xena
Basically the new laptop is functioning, but a lot of non-working services
aren't going to revive until it has Xena's hostname and host keys. So what
is the next step? Here are my goals:
- Move the new laptop into the Xena role promptly so I can start
using it.
- Test my backup procedure: pretend that Xena was trashed, and restore
it onto new hardware. Then see how much hand labor is going to be
needed to really restore it, importing non-backed-up material from
the old laptop. And then fix up the backup procedure so it's backing
up everything that's necessary (and not backing up unnecessary files).
To do the backup test, I will first need to move the old laptop out of the
Xena slot. Aurora is an unoccupied hostname. At the same time I will
reconfigure the new laptop to become Xena, before it gets its full content.
The VM Petra is going to have to go offline until its (new) host, Xena,
becomes operational.
VPN check: from Northridge Hospital, which may or may not allow VPNs.
- HTTP connection to Wikipedia: works.
- org.freedesktop.NetworkManager.openvpn was not installed. Let's find
what they're looking for. Package name is NetworkManager-openvpn.
Installatinn issue: repo definitions use my proxy, which is not
accessible because no VPN. So I just downloaded the package. No
unusual dependencies. You have to restart NetworkManager after
installing, to recognize the plugin; reload is not enough.
- StrongS/WAN to CFT: VPN agent not installed. Package is
NetworkManager-strongswan .
Also requires NetworkManager-strongswan-gnome . Downloaded, installed.
Requires strongswan-nm >= 5.6.2. Let's give this up, do on CouchNet.
- CFT-ovpn443: trying to connect to www.jfcarter.net (Surya(wild)) by
IPv6, and this net doesn't have IPv6. But it falls back to IPv4.
Makes TLS connection. Server cert verify failed. Cellphone can
connect (on the same foreign net), so finger of blame points to Xena.
To edit the conn, the plugin looks generic, no place to edit the
server cert. Reason: you need NetworkManager-openvpn-gnome in
addition.
- Snooping in /etc/NetworkManager/system-connections/CFT-ovpn443
(../VPN is empty): ca=/etc/openvpn/ca-le-2021.pth
cert=/home/jimc/admin/certs/jimc-cft.crt
key=/home/jimc/admin/certs/jimc-cft-ue.key
All of these are readable.
After installation:
- Re-run the quick checkout. Don't try to
improve anything. The outcome was very similar to that seen in Windows,
and is reported jointly above.
- Run jimc's standard speed test. Remember that this test is simple,
actually oversimplified, and it's portable so it can run on Android
too.
| Test | Weight | E5-573G | A515-54 | Ratio
|
|---|
| SHA-512 sums, 1 core | 0.375 | 140775 | 269488 | 1.91
|
| SHA-512 sums, 4 cores | 0.125 | 281550 | 1077952 | 3.83
|
| Reading files | 0.5 | 29172 | 24997 | 0.86
|
| Weighted average score | | 102570 | 248300 | 2.42
|
- Make power measurements.
- Save the SSH key on the master site.
- Normally I would run memtest86+, but it requires
real mode
which is not compatible with UEFI booting, and the A515-54's BIOS
can only do UEFI.
- Tame the touchpad's speed and acceleration. Set up button zones.
Actually it was fine out of the box, except 2 buttons, and I just copied
/etc/X11/xorg.conf.d/60-synaptics-J.conf from Aurora(old) to get
3 buttons.
- Check that S3 (suspend to RAM) and S4 (hibernate) are working right.
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.
See this
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?
- In BIOS setup, for the quick check it's set for legacy boot.
Change to UEFI but disable Secure Boot.
To do this, the BIOS requires a supervisor password.
- Use wired Ethernet. Use the DVD on USB, which is UEFI
bootable. Add the update repo.
Install their minimal X-Windows pattern and as little as possible
beyond that.
- Partitioning: (See Installing Linux for the partitions finally
decided on.) All filesystems are ext4 (not btrfs which is the current
default in SuSE).
- Delete everything first, try to get it to do UEFI.
- EFI partition first, 100Mb, FAT32 filesystem. This is what
Windows uses, probably way more than needed, but suppose I have to
reinstall Windows later? In gparted, pick
Do Not format
with partition ID (type) 0x00 EFI Boot. Then change back to
yes format, with a FAT filesystem, and mount it on /boot/efi.
- 1. Root, 20Gb (ask for 19Gb and it will be expanded).
- 2. Swap, 24Gb
- 3. Home, 30Gb (ask for 28.5Gb)
- 4. If Windows is required, put it here. Best to format it as FAT32
and let Windows upgrade it to NTFS, because Linux NTFS tools may
not be bug-for-bug compatible with the real windows formatter.
- 5. /s1 (scratch and special projects), the rest (about 176Gb)
- The EFI partition was not accepted; BIOS claimed no bootable device.
I wiped the disc including the entire former EFI partition:
dd if=/dev/zero of=/dev/sda blksize=1M count=150
Then I reinstalled SuSE. The default partitions allowed
156.88MiB (probably 150MiB rounded up) for the EFI partition. I left
that entry untouched, and re-made the rest of my partitions.
- Even with the totally default EFI partition, it was not accepted.
- Use the rescue system to run the installed Linux, and use fdisk to
set the type of each partition ('t' command).
If you legacy booted, you will be offered hex numbers, and the correct
value for an EFI partition (as snooped on the installation DVD) is
'ef'. Setting this did not help.
- If you UEFI booted, you will be offered GUIDs (in a numbered
list). After creating the partitions with YaST (SuSE), I found that
every partition had the GUID for
Microsoft Basic Data
.
I set all of them according to their proper roles.
Even so, Linux would not UEFI boot.
- When Windows was installed in these partitions, it used the
appropriate ones and could be UEFI booted. It turned Secure Boot
back on, and put itself first in the boot order, of course.
- I UEFI booted the rescue system and re-ran grub2-install /dev/sda;
it installed the UEFI booter files in /boot/efi/EFI/opensuse/ and
put opensuse first in the boot order.
I used efibootmgr to verify this. Even so, opensuse was not on the
Boot Options Screen. In other words, the BIOS has been finding the
EFI partition all along, but does not recognize the SuSE boot code
as being real.
- Giving up for now, going back to legacy 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:
- Get rid of the Phoronix benchmarks, to save space.
- Install efibootmgr and grub2-x86_64-efi .
- Save the entire content of the machine to TGZ files on another machine (Iris).
- Unmount /s1 (partition #5) (big partition at the end of the disc).
Use gparted to make these alterations:
- Shrink #5 as small as possible. There is 250Mb of stuff in it,
but the minimum size was 11Gb, probably inode storage.
- Move #5 up 150Mb.
- Create #6 in the vacated space. FAT32 filesystem. This will be
the EFI partition.
- Create #7, 50Gb at the end of the disc. FAT32 filesystem, let
Windows upgrade it to NTFS later.
- Expand #5 to fill the remaining space.
- Actually it would have been neater and less work if I had just
shrunk #5 by 50Gb, then put #6 after it, and #7 in the remaining
space.
- Use fdisk to change the partition type (GUID) of all partitions
according to their various roles.
They all started out as
Microsoft Basic Data
.
- Edit /etc/fstab to mount /dev/sda6 (by label) on /boot/efi.
- Reboot into setup. Turn on UEFI booting (but not Secure Boot).
- The Windows installer is going to need an internet connection; use
wired ethernet (802.3).
- Boot the USB stick produced by the Windows Media Creation Tool. Tell
the installer to put Windows in partition #7. It found the EFI
partition by itself.
- It took only 25 mins to install Windows including downloading and
installing updates, and it worked afterward.
- Do the tests.
- Power measurements: idle 9W.
- Playing MSMP4 (MPEG4 + MP3 in AVI, 1080p, display at 50%): 13W
- Suspend to RAM, on line power, lid open and close:
30 times in succession, no errors.
I was too lazy to repeat it on battery power.
- Shut down Windows.
- Boot the SuSE DVD, rescue system. Mount partition #2 (Linux root) on /mnt.
Mount (-o bind) /proc /dev /sys from the rescue system onto /mnt/proc etc.
- chroot /mnt . Mount partition #6 on /boot/efi.
- Execute: grub2-install /dev/sda
- Execute: efibootmgr (no command line arguments). It shows a boot
entry for
opensuse
and this entry is first in the boot order.
- Unwind all the mounts and the chroot. Reboot -f.
- It boots Windows, hiss, boo! Various interventions had no effect.
- Back to legacy boot. Whatever it did to make the MBR protective,
fortunately you can still boot off it.
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):
- Remember that you are going to have to reassemble the laptop.
Remember what you removed and in what order.
- A small cup, or a magnet, is helpful to avoid losing screws. Most are
one size but three are shorter.
- Work on the laptop with the bottom up.
- Remove all 18 visible screws on the bottom. These hold the keyboard
deck firmly to the bottom cover with the motherboard and keyboard
gripped between them.
- The central screw fastens the optical drive. Slide it out. The
E5-573G just has a space filler, not an actual drive.
- Three more short screws were hidden by the optical drive. Remove them.
- The bottom still hangs onto the deck with interlocking grabbers.
You remember how to loid a door, don't you? A credit card in the crack
between them can help separate them. The bottom needs to bend outward
and the deck inward. Do last the side with the VGA and headphone
connectors because the bottom cover encircles them.
- The speakers, on the bottom cover, are connected to the motherboard
by one wire. Disconnect it.
- Wonder of wonders, the drive cage, memory sockets and BIOS battery
are right there on the underside of the motherboard. Install the
additional memory and/or the new BIOS battery.
- The drive just pulls out of the SATA socket. It's not attached to
the cage so don't drop it. Replace with the SSD and reinstall it.
One of the ribs of the bottom cover prevents the drive from leaving
the SATA socket when assembled.
- It's a good idea to carefully turn the machine over, open the display,
power it up, hit F2 to get into setup, and see if it recognizes the
memory and the SSD.
- Just turn off power; you don't have to actually exit from setup.
- When you close the display, the hinges will put torque on the deck,
and some downward force to counteract that torque is advisable.
- Reassembly is basically in the reverse order. One key trick is to
tilt the bottom cover and fit it over the VGA and headphone connectors,
as the first step.
- Put in the optical drive's deck screws first, then slide the optical
drive into place, and put in the central screw that holds it. Then the
other 17 screws.
- You're done. Thanks, Charlie!
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:
- Copied all of /home including my home directory to the Acer.
- Copied /etc and /var/lib to a scratch area on the Acer.
- Did a giant diff -r between the scratch area and the production files.
- Selectively copied files that needed copying. Of particular interest:
- LDAP and Kerberos databases (Xena is a directory server so I can
use it when not connected to the CouchNet.)
- Apache configuration, turn off Orion and turn on Xena
- /etc/NetworkManager/system-connections -- toss cruft.
- /etc/openvpn , also StrongSwan configuration
- /etc/ssl, specifically Xena's host key
- /etc/krb5.keytab (Xena's host key)
- /etc/X11/xorg.conf.d/60-synaptics.J.conf -- All the directives use
percent sizes, so I was able to just copy it, and now I'm set up for
three button operation, same as on the Vaio.
- Get off the wired Ethernet and onto wireless. Piece of cake.
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
version skew.
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 operation not
supported
when you try to add wlan0 to the bridge.
Finished items:
Remove the annoying product hype labels from the machine. [Done.]
Ready to Talk (tm) to Cortana
, my ass.
Test suspend modes:
- There are reliability issues with S3 (workaround discovered),
and a BIOS bug for S3 and S4 if you're on AC power (and another
workaround); see
Machine Stuck
for details.
- S3 (suspend to RAM): Less than 2 secs to go down, less than 1 sec
to resume. Suspending on lid close: works. If another user is
logged on (like root) and you try
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.
- S4 (hibernate, suspend to disc): Takes about 7 secs to go down,
and 22 secs to resume. If another user is logged on (like root),
you need to do
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:
- charge_full_design 2500000
- charge_full 2475000
- charge_now 2009000
- voltage_now 16112000
- voltage_min_design 14800000
- current_now 792000
- status Discharging
./uevent has multiple lines; interesting ones are:
- POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000 = 14.3V (to stop battery test)
- POWER_SUPPLY_VOLTAGE_NOW=16112000 = 16.1V
- POWER_SUPPLY_CURRENT_NOW=792000 = 0.79A
- POWER_SUPPLY_CHARGE_FULL_DESIGN=2500000 = 2.5Ah
- POWER_SUPPLY_CHARGE_FULL=2475000 = 2.48Ah
- POWER_SUPPLY_CHARGE_NOW=2009000 = 2.0Ah
- POWER_SUPPLY_STATUS=Discharging
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:
- Typical use, i.e. editing, software development, web browsing.
- Gaming, OpenArena.
- Playing MPEG-4, replicating
PC Magazine's battery test. They claim
8 hours; there's no way this machine will run 8 hours in any
condition. Can Windows do things Linux doesn't know about? That's
very likely.
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.
I have had several laptops whose touchpads were compatible with the
Synaptics driver, and I have made a file
/etc/X11/xorg.conf.d/80-synaptics-J.conf
which works almost unchanged on all of them.
