Zen Installer: Installing Arch Linux and the Subsequently Confusing FSCK Issue

So, I recently installed Arch Linux (via the Zen Installer) and all went well. Well, until I removed the USB the OS was installed from and rebooted, that is…

systemd_fsck_dependency_failure

Plug the USB stick back in and the system would boot normally. Checked FSTAB and it looked entirely valid and was, since the system was in running state when I did.

Markering_001

O.k., let’s try this again but this time check the journal (journalctl -xb) to see what’s happening.

jul 14 21:37:42 [REDACTED] systemd[1]: Starting File System Check on /dev/sdb1…
jul 14 21:37:42 [REDACTED] systemd-fsck[463]: /dev/sdb1: 17 files, 12139/130807 clusters
jul 14 21:37:42 [REDACTED] systemd[1]: Started File System Check on /dev/sdb1.
jul 14 21:37:42 [REDACTED] audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 21:37:42 [REDACTED] kernel: audit: type=1130 audit(1563133062.173:11): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:19:49 [REDACTED] systemd[1]: [email protected]: Succeeded.
jul 14 22:19:49 [REDACTED] systemd[1]: Stopped File System Check on /dev/sdb1.
jul 14 22:19:49 [REDACTED] audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:19:49 [REDACTED] kernel: audit: type=1131 audit(1563135589.643:55): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:21:44 [REDACTED] systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
jul 14 22:21:44 [REDACTED] systemd[1]: Timed out waiting for device /dev/sdb1.
jul 14 22:21:44 [REDACTED] systemd[1]: Dependency failed for File System Check on /dev/sdb1.
jul 14 22:21:44 [REDACTED] systemd[1]: [email protected]: Job [email protected]/start failed with result ‘dependency’.
jul 14 22:21:44 [REDACTED] systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start failed with result ‘timeout’.

Well, that didn’t help too much, save to tell me that fsck can’t load a dependency. Wait a minute… It can’t be… Can it?

Ctrl+Alt+F1 to open the terminal. Nano’ed fstab. Changed all of the sdb to sda (since the usb was no longer plugged in) and rebooted. It worked.

So, here’s what was happening:

When the USB drive was plugged in, the HDD drive was /dev/sdb. When the USB was not plugged in, it was no longer /dev/sda but the HDD was now /dev/sda.

The ultimate work-around to prevent this from happening again? Use the UUIDs instead of the non-static drive assignments, as the kernel’s name descriptors are not persistent. (See the Arch Linux Wiki for more details.)

Obligatory desktop screenshot? Obligatory desktop screenshot.

Markering_004

 

 

Ubuntu 18.04LTS: Auto-Locking When YubiKey is Removed

It took me a while to piece this together, so I figured that I would write a handy “how-to”, in order to prevent someone else from losing the man-hours that it took to piecemeal this together.

The first thing that we’ll need to do is to create the monitoring rule. This rule is specifically used to key-off of the event that is trigged when the YubiKey is removed; however, we’ll need some information for that before we can write the rule.

You can use the below command to obtain the device-specific information:

udevadm monitor --environment --udev

With the command running, remove the YubiKey device from the system. I would suggest copying all of the properties that you see in the output to a text file. We’ll use some of these to define your rule.

Right. So, let’s create the rule. Run this command to start the text editor:

sudo nano /etc/udev/rules.d/85-yubikey.rules

In the text editor, you’ll add the rule. Below is mine, for an example:

# Yubikey Udev Rule: running a bash script in case your Yubikey is removed 
ACTION=="remove", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0401", RUN+="/usr/local/bin/gnome-screensaver-lock"

The most specific piece that you’ll copy, verbatum, is the overloaded “Run” section.

Press Ctrl+X in the text editor window, when you’re done. Press your key for confirmation (‘Y’ in English, ‘J’ in Swedish, etc.). Then press ‘Enter’ (a.k.a.: carriage return) to confirm the path we specified when we started the text editor.

You should now be back at the terminal.

Now that the rule is in place, we need to define the action. We’ve already declared where it will go to fetch the action definition (see the overloaded “Run” declaration above) and now we need to create that file.

Run this command to start the text editor:

sudo nano /usr/local/bin/gnome-screensaver-lock

Add the following code in the editor:

#!/bin/bash 
# Double checking if the Yubikey is actually removed
if [ -z "$(lsusb | grep Yubico)" ]
then
        logger "YubiKey Removed or Changed"
        sessionids=`/bin/loginctl list-sessions | grep <userAccount> | awk '{print $1}'`
        for id in $sessionids
                do
                        logger "Locking session id:" $id
                        /bin/loginctl lock-session $id
                done
fi

(Be sure to change <userAccount> to your actual user account.)

Again, press Ctrl+X to start exiting the text editor. Press the confirmation key. Press the enter key to confirm the path.

The script that we just made must be made an executable for udev to be able to leverage it:

sudo chmod +x /usr/local/bin/gnome-screensaver-lock

Now that we have the rule and the actions defined, we need to tell the udevd service to reload the rules, so it’ll work. Run the following in the terminal:

sudo udevadm control --reload-rules
sudo service udev reload

Now, we should be able to remove the YubiKey device and Ubuntu should auto-lock.

If it doesn’t, you can try to monitor the udev service:

sudo service udev status
 systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor preset: enabled)
   Active: active (running) since Mon 2019-02-25 23:11:28 CET; 4 days ago
     Docs: man:systemd-udevd.service(8)
           man:udev(7)
 Main PID: 482 (systemd-udevd)
   Status: "Processing with 24 children at max"
    Tasks: 1
   CGroup: /system.slice/systemd-udevd.service
           └─482 /lib/systemd/systemd-udevd

mar 02 22:39:58 Tradgardsforeningen mtp-probe[15598]: checking bus 1, device 30: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:39:58 Tradgardsforeningen mtp-probe[15598]: bus: 1, device: 30 was not an MTP device
mar 02 22:43:17 Tradgardsforeningen systemd-udevd[15742]: Process '/usr/local/bin/gnome-screensaver-lock' failed with exit code 2.
mar 02 22:43:17 Tradgardsforeningen systemd-udevd[15749]: Process '/usr/local/bin/gnome-screensaver-lock' failed with exit code 2.
mar 02 22:43:20 Tradgardsforeningen mtp-probe[15759]: checking bus 1, device 31: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:43:20 Tradgardsforeningen mtp-probe[15759]: bus: 1, device: 31 was not an MTP device
mar 02 22:48:00 Tradgardsforeningen mtp-probe[15901]: checking bus 1, device 32: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:48:00 Tradgardsforeningen mtp-probe[15901]: bus: 1, device: 32 was not an MTP device
mar 02 22:49:26 Tradgardsforeningen mtp-probe[16019]: checking bus 1, device 33: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:49:26 Tradgardsforeningen mtp-probe[16019]: bus: 1, device: 33 was not an MTP device

The above snippet is from when the executing script looked quite different and, thus, it was failing to execute. Keep in mind that you may need to define different parameters in your monitoring rule, for example, if your device has a different vendor or model id and the removal isn’t creating the logging event:

mar 02 23:00:15 Tradgardsforeningen root[16941]: YubiKey Removed or Changed

If you can see the event being logged, then verify that you specified the correct username in the script.

If all else fails, there’s Ask Ubuntu. 🙂

Thanks for coming to this TEDTalk and I hope that it helps prevent someone losing the hours that I lost. 🙂