Installing Slackware on a Dell Inspiron i3162-2040
Wed 15 Nov 2017 by mskala Tags used: linux, hardware, referenceMy venerable Asus eeePC netbook finally gave up the ghost, and I replaced it with a Dell Inspiron i3162-2040. Here are some notes on what I had to do to get it up and running with Slackware Linux, both for my own future reference if I ever have to reinstall from scratch, and to help others who may be facing a similar adventure.
First, on operating system selection: I wanted a Linux distribution without systemd. For many years Slackware has been my first choice, but now that Devuan is available I thought it would be fun to try that. Devuan didn't work. I was able to boot its installer, but the installer kernel couldn't see the Inspiron's eMMC drive. Apparently this is due to a relatively old kernel included in the current "Jessie" version of Devuan, and the next version, called "Ascii," is supposed to have a more recent kernel that probably could see it. However, at the moment most recommended ways of installing Ascii entail installing Jessie first and then upgrading - Ascii install images with Ascii kernels exist only in ad hoc experimental form - and the suggestions and various experimental install images I got from Devuan users I talked to mostly failed with the black-screen problem due to "Load Legacy Option Rom" (described below). By the time I figured out how to resolve that, through experiments with Slackware, I had little enthusiasm for going back to try Devuan again given that my real goal was just to have it work with some non-systemd Linux and I'm more confident of my skills with Slackware.
BIOS issues
To get into the BIOS config menu: press F2 repeatedly while booting up.
Recommended BIOS configuration: "Boot List Option" set to "UEFI"; "Secure Boot" disabled; "Load Legacy Option Rom" disabled.
To get a boot-media menu (at least, when in UEFI mode): press F12 repeatedly while booting up.
Hard (or at least firm) power off: hold down the power button for about five to ten seconds. Note that there seems to be no true hard power or reset control and you can't cut power because the battery is internal and permanently connected; but the power button hold at least works after a kernel panic when nothing else seems to.
UEFI has a bad reputation and my first impulse was to go with "Legacy," but it's not clear that in that mode the machine can really boot properly from its internal eMMC drive. Modern Linux distributions work pretty well with (U)EFI and that seems to be the path of least resistance. There are important boot-loader issues discussed below. You do want to turn off "Secure Boot," which is the really evil part of UEFI; on this machine, doing that is easy, just an item in the BIOS menu. I have heard tell of other machines where it is much more difficult to turn off "Secure Boot."
It is also important to turn off "Load Legacy Option Rom." If this option is enabled, then with most but not all recent Linux kernels in their default configuration, about four seconds into the kernel boot (when the kernel tries to set the video mode) the screen goes blank and the machine becomes unresponsive - seemingly powered down but not really, and only recoverable with the hold-down-power-button reset procedure. (This is what happened to me with most of the Devuan installers.) This won't happen if you pass the "nomodeset" kernel command line option, but that may or may not be easy to do depending on the circumstances of the boot, and after booting with "nomodeset," X can't start should you want to use X. Better to turn off "Load Legacy Option Rom" in the BIOS.
Partitioning
The eMMC drive is /dev/mmcblk0 and its primary partitions (up to four of them) are /dev/mmcblk0p1, /dev/mmcblk0p2, /dev/mmcblk0p3, and /dev/mmcblk0p4. I think this is a traditional DOS disklabel/partition table, so presumably if you wanted more than four partitions you'd designate one of the primaries as an extended partition and then create /dev/mmcblk0p5 and on up inside the extended partition.
The 0.5G VFAT partition /dev/mmcblk0p1 is the "EFI partition" sacred to the boot BIOS and you shouldn't mess with it too much (for instance, no trying to change its size), though it will be necessary to write to it to install the Linux boot loader. I think if absolutely necessary it's possible to delete and recreate this partition in a way that the BIOS will accept using Linux-based tools, but I haven't explored that.
The remainder of the drive can be partitioned as desired, but to do hibernation (suspend to disk) it's important to have a swap partition at least as big as the computer's RAM, 2G in my case; I defined that as /dev/mmcblk0p3 at the tail end of the drive and everything in between as /dev/mmcblk0p2 to hold my Linux installation.
Slackware install and chrooting into the live system
The Slackware installer ("setup") can install a live Slackware system on the eMMC drive once the partitioning is done, but it cannot install a boot loader that works. To do that it's necessary to get into the installed system with chroot, after mounting the /proc and /sys filesystems in a way the chrooted system can see. It's also necessary to copy over the /dev nodes for the eMMC drive from the installation environment to the installed system (because that doesn't seem to happen automatically) and mount the EFI partition on /boot/efi after chrooting (because the boot loader installer needs to see that mount mentioned in /etc/mtab inside the chrooted environment).
Assuming the live system is already mounted on /mnt, which is how the Slackware installer leaves matters:
cp -av /dev/* /mnt/dev/ mount --bind /sys /mnt/sys mount --bind /proc /mnt/proc chroot /mnt mount /dev/mmcblk0p1 /boot/efi
Initial ramdisk and ELILO
ELILO, the preferred boot loader for Slackware on UEFI systems, takes a bit of getting used to if you're an old-time LILO user like myself. It appears that the boot BIOS is now smart enough to actually read a filesystem, so instead of using a special utility to tell the BIOS where the boot loader is by raw sector numbers and write the configuration information into the boot loader (as with LILO), on UEFI systems you just copy the boot loader and the things it needs into the right paths of the EFI partition and go through the BIOS menu to tell the BIOS the paths. If you reinstall the boot loader to the same paths, you don't need to notify the BIOS of the change, because it's using the filesystem, not the raw location on disk.
First, it's important to have an initial ramdisk image that works. The default one installed by Slackware will not, because it lacks the modules for connecting to the eMMC drive. The kernel can't mount its root filesystem and panics. So, inside the chrooted system, it's necessary to run mkinitrd with the proper command-line parameters (not covered here; see its man page) to create a new /boot/initrd.gz file. Most of the parameters can be set by creating an /etc/mkinitrd.conf file and that's advisable so that their values will be saved for reference purposes. I copied over the sample one (/etc/mkinitrd.conf.sample), which has every line commented out, and then uncommented and set the following lines.
KERNEL_VERSION="$(uname -r)" MODULE_LIST="ext4:sdhci_acpi:sdhci:mmc_block:mmc_core" ROOTDEV="/dev/mmcblk0p2" ROOTFS="ext4" RESUMEDEV="/dev/mmcblk0p3"
I think mkinitrd is supposed to automatically add any dependencies of modules on the MODULE_LIST, so it might be sufficient to just list ext4 (filesystem for the root partition) and sdhci_acpi (most-specific driver needed for the eMMC drive) and have it automatically import the others, which are required by sdhci_acpi. However, I wanted to err on the side of caution.
Note that although setting RESUMEDEV to the swap partition seems to be necessary for resuming from hibernation to work, it seems not to be sufficient; I also had to put this in the kernel command line, as described below.
After there is a valid initrd (and kernel, but the Slackware installer will have installed that), it's possible to run Slackware's boot loader installer, which only partially works, but gets us a step closer. Make sure the EFI partition is mounted at /boot/efi and then run eliloconfig. It copies the boot loader (ELILO), the kernel, and the initial ramdisk to the directory "/EFI/Slackware" on the EFI partition, creating that directory if necessary. It also writes a config file for ELILO there. Then it offers to create a boot menu entry, and fails to do so; we have to fix that using the BIOS menu.
When the eliloconfig script runs, it writes from scratch an elilo.conf file to /boot/efi/EFI/Slackware/elilo.conf. This file has a syntax that looks like that of /etc/lilo.conf, and it includes an "append" with a hardcoded kernel command line. If you want to change the kernel command line, in particular to enable resume from hibernation, then you must edit this file after running eliloconfig. I edited mine to add "resume=/dev/mmcblk0p3." This would also be the place to put in "nomodeset" if you are using it, though (as mentioned) that's probably a bad idea because it interferes with X. Note that this editing step must be repeated if you ever run eliloconfig again.
Depending on confidence level, it might make sense to dispense with eliloconfig entirely and just copy the files over by hand; I wanted to stick as close as possible to the Slackware recommended way of doing things, but it's clear from reading the script that nothing really mysterious is going on. The script just copies the files over and then fails when the utility for configuring the BIOS boot menu fails.
I also installed LILO (no E) to the MBR on the eMMC drive, by the usual procedure; that is probably not necessary, and it may not actually be usable, but it seems to be harmless and may provide a last-ditch backup plan if at some point I experience a problem with the UEFI boot and have the chance to attempt a legacy boot instead.
Putting ELILO on the BIOS boot menu
Once ELILO is installed on the EFI partition, reboot and enter the BIOS setup by pressing F2 during the boot process. On the "Boot" page there should be an option for "File Browser Add Boot Option"; after choosing that, navigate to the eMMC drive identified by its UUID (should be the only option other than aborting), and then the path EFI/Slackware/elilo.efi. Then you are prompted for what is referred to as a "filename" but it's really the name under which the new option will appear on the boot menu (I used "SLACKWARE"; it appears that only all-caps entries are accepted even though the existing one for Windows is mixed case). Other settings on the "Boot" page allow setting the priority of the boot-menu entries to put SLACKWARE first. I didn't attempt to remove the Windows entry even though it's unlikely to work now that all the Windows partitions have been erased.
At this point the netbook should be able to boot, without the assistence of an install key, into the live Slackware system and even resume from hibernation if it previously hibernated successfully.
Hibernation
I wanted the power button to put the system into hibernation (suspend to disk) when I'm in an unprivileged XFCE session, and that required a bit of tweaking.
First of all, apparently Javascript is required for the power button to work (!). I had not installed the "js185" package, thinking I had no need for a command-line Javascript interpreter, but it seems that the back end of the system that authorizes ordinary users to be able to control power-down when they are logged in from the console, actually does require this package.
While attempting to debug the Javascript problem I also ended up adding my ordinary-user account to the "power" and "plugdev" groups; that is frequently recommended as a way to solve "Help, I can't control power-down as an ordinary user!" problems and I don't know if it was also necessary.
Once I had XFCE's power manager working and treating me as "authorized" I was able to configure it with the graphical settings manager to hibernate when the power button was pressed. However, that put me in a strange situation where pressing the power button would initiate hibernation and full shutdown simultaneously. The hibernation would finish first, so the system would end up hibernated; but then on subsequent power-up, it would come out of hibernation and immediately proceed to finish the full shutdown that had been in progress! This took some debugging, but it turned out that the power button press was activating both XFCE's power manager and something called "acpid" which was configured to power down on that button press. I edited the file /etc/acpi/acpi_handler.sh to comment out the lines that recognise power button events.
#!/bin/sh
# Default acpi script that takes an entry for all actions
IFS=${IFS}/
set $@
case "$1" in
button)
case "$2" in
# power) /sbin/init 0
# ;;
*) logger "ACPI action $2 is not defined"
;;
esac
;;
*)
logger "ACPI group $1 / action $2 is not defined"
;;
esacWith that change, hibernation basically works. It is still the case that when hibernation goes into effect, xscreensaver locks the screen but takes long enough to do so that the system hibernates first. Upon return from hibernation, it comes up with an unlocked screen and then about a second later the screen locks. This seems suboptimal, and it probably can and should be changed in some way. However, I hadn't yet figured out how to make it better.
0 comments
