Jaguar: Portrait of Xena
Valid HTML 4.01 Transitional

Asus VivoBook S15 S532FA (2020)
Setup

Jim Carter, 2020-09-30

Table of Contents

In the Box

To do upon receipt:

Colors

The top cover color, according to ASUS, is Moss Green. Seen under indirect south daylight, I'm calling it PantoneĀ® 18-0629 Lizard (p.129). (How appropriate for installing OpenSuSE on it.) The very narrow border around the display is black, with an orange line between it and the Lizard top cover. The keyboard deck and the bottom cover are PantoneĀ® 12-0811 Dawn (p.39), kind of a light bronze-ish color. The keys are silver, with a transparent inlay for the labels, which is dark when the backlight is off. But when it's on, it shines through the labels, which is cool, but the contrast is low with the silver key bodies, so you have to look carefully to see which key you're pressing. Other available color schemes are Punk Pink and Silver Transparent.

BIOS Setup

I will first review and record the settings, then boot Windows and check it out, and finally change them as noted before installing Linux.

So the only things that will actually be changed (after Windows checkout, before installing Linux) are:

Windows Checkout

Boot into Windows. Here are the steps in Windows Setup.

Very quick checkout of features in Windows.

Windows 10 Media Creation Tool

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 Acer E5-573G.

Installing Linux

This installation will be the second 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.

Disc Partition Table

When I install Linux the first issue is going to be partitioning. 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 next partition (the BIOS from both Acer and ASUS 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 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).

For the final result, skip ahead to the Partition Table.

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.

Partition Labels

I frequently need to take the disc out of one machine and mount it on another, particularly for the Raspberry Pi's. If you use the hardware device name, e.g. /dev/sdd3, this is error-prone if done manually, and the major device number can change randomly from one boot to the next, so the device name shouldn't be used in /etc/fstab. The partition table includes a UUID which is used in a set of symlinks in /dev/disk/by-uuid, but UUIDs are semantically meaningless and are impossible to type by hand. So I give a label to each partition (except bios_grub), which appears as the name of a symlink in /dev/disk/by-label. I assign a number to each machine (or each incarnation, where relevant). On the old Xena (Acer A515-54), /dev/disk/by-label contains ROOT-09, HOME-09, SWAP-09, EFI-09 while the new one Xena (ASUS S532FA) will contain ROOT-10, HOME-10, SWAP-10, EFI-10, so they can coexist when I copy home directories onto the new machine.

Download the Network Installer

First step is to download the Network Image for x86_64 from the Tumbleweed installation page plus the checksum and GPG signature. See this help page, the section about verifying checksums, and follow the example. Yes the checksum and signature came out correct. Then write the image to a USB memory device; the next section has several options.

Oops, my Ethernet adapter is in use for the default route to my ISP. It's supposed to be possible to set up Wi-Fi after booting the installer, but I couldn't make that work. I repeated the above steps with the installation DVD. Similar filenames/URLs but replace NET with DVD.

RAID vs. AHCI Mode

The following was seen on the Acer A515-54 and the ASUS S532FA has the same issue, but fixable.

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. But it is on the ASUS S532FA, and when I followed the message's instruction, I was able to put Linux on the NVMe disc.

BIOS Alterations

Linux Installation Begins

Procedure, once the installer is booted. Since my Ethernet adapter is pre-empted, I'm actually using the installation DVD.

There was an emergency issue that diverted me for over 3 weeks. Returning to my new laptop. I left it with post_jump finished, and booting with no drama into the production OS. I'm going to move my homedir into the new laptop, then do checkout activities. Here's a more detailed list of steps.

Details of regressing to an old kernel: As this is written, kernel-default-5.8.14-1.2.x86_64 is the latest version. It gives two problems: starting with the update to 5.6.14, the host of a VM runs for a variable time from 5 minutes to a day or so, then mysteriously crashes with no error messages in syslog nor visible on the screen. Second, unbound (the DNS server) drops privileges, and apparently our version of libcap-ng is using a back-version linux-api-headers, and barfs when the process potentially has capabilities with a higher number than it knows about. So unbound cannot start. For the unbound problem, per SuSE bug 1177715 (2020-10-14 ), it is apparently sufficient to revert to kernel 5.7.1. I tried reverting to old kernels, but could not get the RPMs. I succeeded by installing kernel 5.3.18-lp152.47.2 from Leap 15.2, and now unbound is running. [Update: on about 2021-02-23 Tumbleweed got util-linux-2.36.1-3.2.x86_64 and this fixes the problem.] Arch Linux bug 67781 (2020-08-31) describes this issue, and the developer indicates what he did to fix it.

Reviving the Laptop's Networking

I thought Xena would just join the net normally once connection configurations were restored, but it didn't work out that way. After much of a day of thrashing around with skimpy notes, I tried these interventions:

Hibernation Quirks and Fixes

When I first installed Linux, after the laptop hibernated (S4 state) and was awakened by pressing the power button, it would do a full reboot, not restoring the saved hibernation image. That was not good.

See this forum post on Stackexchange.com, OP user1337, 2020-07-04. He had the same symptom, and fixed it. The issue was, the Dracut configuration lacked an instruction to include the resume module; adding it made the initrd look for and restore the saved hibernation image.

Here is how I adjusted his procedure for OpenSuSE Tumbleweed:

Strange: 6 of my machines had the resume module in the initrd despite no configuration adding it.

Jaguar: Portrait of Xena