Thursday, April 9, 2020

2016 Latitude E7270 6600U Install

Safety: BitLocker (encryption), UEFI, Fingerprint. Uninstall packages:

# pacman -Rsn

NB:Headphones (also hands-free) Mijiaer/Langsdom JM26 3.5mm earbuds


Problem: your situation requires reliable Zoom (or other) teleconferencing but you're not a first responder, professional athlete, nor an investment banker. If you can carry one (2.74 lbs), 2016 carbon fiber, non-touch screen version Latitude E7270's are available on EBay for about $250 delivered. These are not display showoffs, w/ 12.5" screens, and only integrated Intel HD Graphics(520), but they are solid business grade: 16 GB DDR4, i7 6600U Skylake w/100Mhz FSB, and 1080P webcam: they will do the job reliably. Think 256G PCIe3 SSD, Arch Linux and IceWM: for that $250, one has a laptop which will teleconference, plus audio might be edited -- a single 3.5mm combined jack. Watching movies or editing pics on a 12.5" however, is suboptimal.

upgrade/replacement notes: Please scroll down to bottom for sections on replacement, esp batteries and SSD. The laptop takes an M.2 card style NVME SSD so its a little complicated.

Packaging appeared good, visual inspection was clean and the charger and battery tests went well (1 hr). The subsequent Arch installation was an additional 4 hours.

bootable USB :: 20 mins

  1. Download the latest ISO. Necessary or the signature keys might error during install.
  2. # fdisk -l find the drive name, eg /dev/sdc OR...
  3. $ lsblk | grep -i sd
  4. # cfdisk /dev/sdc, delete all partitions and write, exit
  5. # dd bs=4M if=/home/foo/Downloads/archlinux-2020.03.01-x86_64.iso of=/dev/sdc oflag=sync The sync flag takes a little longer but you can be sure it will be properly on the usb.

BIOS shifts :: 15 mins

Two equally important adjustments must be made in BIOS: 1) booting from USB for install and, 2) when booting from HDD, non-windows, non-secure, booting and no disk encryption.
  • Enter BIOS, press F12 repetitively during power up.
  • Secure Boot Enable -> "Disabled"
  • General -> Advanced Boot Options -> "Enable Legacy ROM's"
  • General -> Boot Sequence -> Enable "Legacy"
Also, I noted I luckily had the latest BIOS version 1.20.3 (7/2016) but there's a process if not. Link: configure BIOS for USB boot :: update the BIOS

GRUB/safety problem :: 15 mins

Currently (2020) however, GRUB seems finnicky when using a GPT ("globally unique identifier partition table") disk. So, in addition to eliminating EFI, I convert all GPT to MBR. This requires three applications: cfdisk (delete all partions), gdisk (to detect GPT and revert to MBR) and fdisk ("fdisk -t" to create an MBR. 0x04.)
  1. # fdisk -l determine the drive name, eg /dev/nvme1
  2. # cfdisk /dev/nvme1, delete all partitions, which eliminates EFI. Write this partitionless drive and exit
  3. # gdisk /dev/nvme1 note whether GPT is present and MBR protected. Mine notes both and that "using GPT". I selected "x" for "expert command", then "z" to zap the entire GPT structure, which was confirmed. Then it asked if I want to "Blank out MBR"?, to which I replied "yes". When i then retried # gdisk /dev/nvme1, all (MBR, BSD, APM, and GPT) were not present. This is correct, but "x,z,y" again to be sure.
  4. # cfdisk /dev/nvme1, select DOS label, and proceed. The main is a linux (83) nvme1p1 and a linux swap (82) nvme1p2,
The only real question is whether to make multiple partitions for different parts of the OS. For this example, I've put them all in a single partition.

base CLI (runlevel 2) configuration :: 20 mins

# mkswap /dev/nvme1p2
# swapon /dev/nvme1p2
# free -m [check swap is on]
# mke2fs /dev/nvme1p1
# mount -rw -t ext2 /dev/nvme1p1 /mnt
# mkdir /mnt/etc
# genfstab -p /mnt >> /mnt/etc/fstab
# pacstrap /mnt base base-devel linux linux-firmware
# arch-chroot /mnt
# ln -s /usr/share/zoneinfo/US/[zone] /etc/localtime
# mkinitcpio -p linux
# passwd
# pacman -Syu grub dhcpcd
# mkdir /boot/grub
# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sda [no partition]
# exit
# reboot

go back to install disk

Let's say I forget to # pacman dhcpcd after pacstrap, and now I'm booting straight off the drive. It's extremely difficult to setup even a wired connection, let alone WiFi with just the tools in # So go back to arch-chroot and install from there.
# mount -rw -t ext2 /dev/nvme1p1 /mnt
# arch-chroot /mnt
# pacman -Syu dhcpcd wireless-tools
# exit
# reboot
Similarly, you want to pull window manager menus and so on prior to starting X the first time...
$ mkdir media
# mount -rw -t ext2 /dev/nvme1p1 /media
$ cd media
[do whatever operations]
# umount /dev/nvme1p1

locale :: 0 mins

I don't set a locale, but here's some information if interested.

useradd :: 5 mins

User 500, name "foo", home directory of "foo", using bash shell.
# useradd -G wheel,lp,audio -u 500 -s /bin/bash -m foo

aur :: 30 mins

Used to be so simple with yaourt, however it hasn't been maintained since 2018. The best option now is yay, built on the 300Mb behomoth go dependency. This first part is the same:
# nano /etc/pacman.conf
[archlinuxfr]
SigLevel = Never
Server = http://repo.archlinux.fr/$arch

# pacman -S go wget git base-devel
$ git clone https://aur.archlinux.org/yay.git
To build and install they do it through fakeroot, which looks at the god-damned sudoers file. Unfortunately, editing sudoers is done through the visudo command, which every stinking website tells users not to circumvent, and which uses the ridiculous VIM editor. Here's the workaround...
# nano /etc/sudoers
foo ALL=(ALL) ALL
... and once that's done...
$ cd yay
$ makepkg -si
If you have to hand install the TAR.XZ, use pacman with a "U" flag. The "U" flag has pacman looking into the current directory instead of out over the Net. Prior to building any AUR helper (yaourt, aurman), you'll need to first build "package-query", also from the AUR.
# pacman -U package-query[version]tar.xz
And then the same with yaourt thereafter.

limit journalctl size :: 5 mins

Systemd will log GB's and GB's of data if not limited
# nano /etc/systemd/journald.conf
SystemMaxUse=200K

X install :: 20 mins

These Dells have the Intel integrated graphics 945GM; the correct xf86 driver is the Intel VA driver.
# pacman -S xf86-video-intel
This driver now uses DRI3 as the default Direct Rendering
Infrastructure. You can try falling back to DRI2 if you run
into trouble. To do so, save a file with the following
content as /etc/X11/xorg.conf.d/20-intel.conf :
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "DRI" "2" # DRI3 is now default
#Option "AccelMethod" "sna" # default
#Option "AccelMethod" "uxa" # fallback
EndSection
# pacman -S xorg-server xorg-apps xorg-xinit xorg-xrandr
If you scroll down this Arch page discussing Xorg, we can see that we'll want the mesa for Open GL and lib32-mesa for older apps. Also, Intel chips, as we know (scroll down to about item 13), do not support VDPAU, viz:
"Intel Embedded Graphics Drivers do not support VDPAU. VDPAU stands for video decode and presentation API for UNIX*. VDPAU is an open source library and API originally designed by NVIDIA that provides an interface to support hardware-accelerated video decode."
... and so Intel sez libVA is correct. More specific to Arch, there's additional information in their video acceleration page, if you like to read. The only problem with the VA-API is it can't decode MP4 and FLASH containers, but it does all other common formats, and all codecs, including H264 and the new VP8 and 9. I just use MKV and AVI containers and set the VLC codec to VA (instead of its default VDPAU). In spite of inefficiencies on the Intel hardware, some may wish to overlay VDPAU functionality onto their Intel chip, which is an installation beyond this post. If a person does that, any mistakes will defeat X working properly -- no harm, just revert to runlevel 2 and reconfigure until Xorg is working well. FYI, one of the tweaks I've seen for VIDPAU overlaid onto VA, is adding "export VDPAU_DRIVER=r600"in one's ~/.xinitrc file. Anyway, back to pure libVA...
# pacman -S libva libva-intel-driver libva-utils libva-mesa-driver
... then check the install with "$ vainfo".

window manager :: 10 mins

On an old system, I don't waste memory with display managers, instead I login and "startx" from runlevel 2. I like Ice Window Manager, a light interface with simple text configuration, wallpaper, and menu files (look inside ~/.icewm ). Efficient on older systems: perhaps 150M usage after logging-in, connecting to network, and starting X. In Arch, the template files are inside /usr/share/icewm/, including the themes. See the main Arch file.
# pacman -S icewm
$ cp /etc/X11/xinit/xinitrc .xinitrc
$ nano .xinitrc
exec dbus-launch icewm-session
$ startx
I also looked here to get the names of additional drivers, for example to solve the pesky touchpad problem. I couldn't stop the Dell touchpad with synclient TouchPadOff=1 until I # pacman -S xf86-input-synaptics.

QT or Gtk

I used to stick with one or the other to keep a smaller install and shorter update. Nowadays both seem necessary. I prefer GTK (except gvfs), but VLC requires QT. QT is about 400MB, and typically pulls in PyQT. But since I'm a fan of VLC ... QT became my baseline API.
# pacman -S qt4
However, you're going to see that udiskie (to avoid gvfs) brings in about 80MB of shit, including basic Gtk.

sound

I avoid PulseAudio as much as I can. See my post from 2016. ALSA is now built-in, so that all that's required is alsamixer in order to control the sound levels (unmute, etc)
# pacman -S alsa-utils
Done.

rc.local

A consolidated place for random startup shit too lazy to configure individually. It's like an initrc in X, but for runlevel 3.
# nano /etc/rc.local
#!/bin/bash
wpa_supplicant etc
dhcpd etc
exit 0
# systemctl enable rc-local.service should make it happen next boot, but you also have to create the service file before enabling it.
# nano /etc/systemd/system/rc-local.service

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.

[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

replacement info

batteries - 55wh(4 Cell) LPD-J60J5 $30

Li-Ion, power is 7.6VDC. These go bad. When I first opened the case, the battery was swollen and pushing against the case cover. The charging circuit is built-in, which might have failed. Or the battery has a place for heat paste on the bottom, which might not have been seated. If only there were a LiPo which fit it for less than $100. Replacement Li-Ion J60J5 costs $25 (2022) but 2.5 bucks tax, then thermal paste and cleaner another $15. We're looking at $40+.

After install, there are several ways to check the battery, but this is perhaps the easiest way:

$ upower -i /org/freedesktop/UPower/devices/battery_BAT0

Thermal paste application (8:48) Laptop Performance Tricks, 2019. Appears this is solution video with all relevant tips. Vid is for a Dell G7 rather than the Dell E7270.

storage: ssd pcie $30

Nowadays, we're not dealing with 2.5" SATA HDD's that spin-up. The installed card is a 256Gb NVMe PCIe Gen3 x 4, so 2 lanes are not used. That's because PCIe bus (FSB) is standard 100Mhz, but is discount model with 2 lanes. It's upgradeable to 1TB for probably $70, and to simply replace the 256Gb Gen3 about $30.

No comments: