power outage catch-22

Throughout my lifetime, unexpected power outages would lead Arch to do a disk check during repowering. Following this, a reboot would lead to a customary level 3 login.

The latest way Linux denies a person access to their own system is via systemd. Unless a person has pre-configured and installed (via mkinitcpio) an elaborate etc/systemd/system/rescue.service and/or etc/systemd/system/emergency.service, systemd locks root and withholds error information. Locked root, minus error information, produces perhaps the worst imaginable Catch-22. Initially, a person believes it's easy to fix. It looks normal:

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, or "exit" to continue bootup.

"No problem", one thinks, "this is an easy fix via the emergency command line in a (VGA) console." Wrong. Because next...

Cannot open access to console, the root account is locked. See sulogin(8) man page for more details

Thus we can't enter commands, unlike typical emergency mode. What is the solution?

The disk must be fsck'd. Trial and error took days until I recalled fsck might be needed.

At the bottom of this post, solutions from Reddit, Archwiki, StackExchange, etc, are given, in case they inform someone else. I found them all to be useless and misleading. All involved chrooting and then, eg mkinitcpio, fstab updates, and even grub reinstallation. Some of these may work if a person can run "fsck" at the emergency command line. But this was never suggested.

some other horrible requirements

A VGA cable, a monitor with a VGA connection, a box/laptop with an unlocked system, and an expendable USB. If no internet connection, a saved arch iso somewhere. You need a VGA cable and monitor if your box doesn't have native HDMI on its graphic card. This is because emergency mode only has initramfs, with a limited set of commands -- it doesn't include HDMI handshaking.

1. setting-up for the unlock

• Connect the VGA stuff to the locked system, if your system doesn't have native HDMI
• Power it up and exit into BIOS, typically "F2". Otherwise, F2, pause a second, then F10, pause, F2, F10 etc.
• Inside BIOS, change the boot order to USB first, and save/apply the change.
• Exit BIOS, and power down the locked system.

2. create boot USB

• On an unlocked system (yes you will need that too) download an Arch ISO and verify its checksum. Having an old saved arch ISO avoids the download.
• Insert a USB stick into the unlocked system, and find its /dev designator.

  $ lsblk

  Let's say this one is /dev/sda, for our purposes here.
• Wipe the USB file system

  # wipefs --all /dev/sda

• Burn the ISO onto the bootable USB. Be certain it has completed burning before removing it.

  # dd bs=4M if=[hardpath/isoname.iso] of=/dev/sda conv=fsync oflag=direct status=progress

3. unlocking root

• insert the install USB in the locked system and power it up
• once linux loads from the USB, you'll be running a root prompt. You can find the disk designator for the locked disk drive using lsblk, then just fsck it. Let's say ours was sda.

# lsblk
# fsck /dev/sda
[answer "y" to any repair requests]
# exit

• power-down the locked system and remove the USB
• power up the locked system

The system should boot normally now. If desired, re-enter BIOS and remove the USB boot option.

partial fixes and related (useless)

linux command appends

Requires accessing the linux kernel load line during GRUB's install. Pick one of the linux kernels in the GRUB menu, and use the "e" key. This brings us to the kernel parameters, which we will need to edit. After adding the suffix (see below), "F10" to load the kernel with the added parameters.

partial fix 01

This stack exchange post provided me with a kernel parameter which successfully got me as far as the emergency access prompt.

SYSTEMD_SULOGIN_FORCE=1 init=/sbin/sulogin

The solution is only partial, because necessary commands to unlock root eg, passwd, mkinitcpio, nano, etc, were not available at this prompt. This emergency prompt was running entirely within initramfs.

At reboot I was right back where I started, at a locked console, unless as noted at top, I had a configured emergency.service already installed into systemd.

creation of emergency.service

helpful, but not a fix

Linuxconfig.org. Setting kernel boot parameters.

nope 1

Kali solution. Well documented kernel parameter addition. GRUB ignores.

single init=/bin/bash

nope 2

Well documented kernel parameter addition. GRUB ignores.

break

# mount -rw /dev/sda1 /mnt
# genfstab -p /mnt >> /mnt/etc/fstab
# arch-chroot /mnt
# passwd
# mkinitcpio -p linux
# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sda [no partition]
# exit

home devices and related

One way to view requirements for a network is by functional groups, connections, and security levels.

groups, connections, security/safety

• guests: LAN parties, family, push devices (weather smart mirror). internet, multiple WAP's, loose firewall, exception reports
• office active: browsing, file sharing, editing, backup. expandable CAT-5, internet firewalled strongest security and devices limited by physical ID
• office archive: SSD's or HDD array. No internet or OS. Photos, scans, texts, docs, receipts, tax, possible some cloud
• media playback: PON or GPON. No internet, OS update server by USB tethered phone. One or two terminals with one server to many displays and speakers.
• security/safety: blend PON, CAT-6 PoE, possibly CAT-5. No internet, OS update server by USB tethered phone. Device ID only, cams, device logging, dedicated storage and backup.
• smart home network: No internet, update server by USB tethered phone. CAT-5,6, or PON. Device ID only, some storage, database
• expansion: possible home business dedicated

For OS, Linux is desirable in all of these, although some gaming devices will obviously not be partial. In all cases, we seek to minimize the the use of WiFi (data security) and internet access. For any outdoor nodes (security cams, sensors), we'd prefer fiber-optic (lightning surge, physical security).

sample vid (sample) sample, 2026.

Motorola PCS XT1541 (Moto G, 3rd Gen) -- usb-c to hdmi TV monitor?

Sitting on a couch, a person occasionally wants to mirror their Android phone to their (larger) TV display. We don't want WiFi, Bluetooth, or any other configuration garbage. We just want to plug the phone into an adapter (which charges our phone), and mirror the phone's screen to the TV while we continue to use the phone. Use our phone, see it on the TV, and the phone charges. Can this be done with an older XT1541 phone?

Not easily. Two main roadblocks:

• not all phone usb-c ports have physical capacity to transmit video. USB-C 2.0 supposedly cannot. USB-C 3.1/2 supposedly can. The XT1541 unfortunately only has USB 2.0.
• not all phones with 3.1 USB's have the Display Port (DP) alt-mode firmware to seamlessly screencast via the USB charging port. Motorola phones that had both were manufactured with Motorola's proprietary "Ready For" configuration. Ready For was short-lived, probably only 2017-2022, possibly due to DCMA overreach. Current Motorola phones lock screencasting to WiFi-only Google Chromecast (now "Google Streaming").

XT1541 is a mixed bag

The 2022 XT1541 lies on middle ground. It was produced during Motorola's "Ready For" years, but did not receive a 3.1 USB-C port or the DP alt-mode firmware. It can screencast nevertheless. The options (ethernet, wifi) are found in the settings icon circled below, or as described in this video.

Note the phone's icon displays "Ethernet", which is part of a longer scrolling message, "No Wi-Fi or Ethernet connection". Ethernet can only occur via the USB-C port; can the XT1541's supposedly 'too slow' 480Mbs USB-C 2.0 handle screen mirroring? Easily. HD 1080p video requires 5-10Mbs, nowhere near 480Mbs. The supposed need for a USB-C 3.1 to transmit video is a myth.

Accordingly, we should have both wired (Ethernet) and WiFi screen-sharing solutions for the XT1541.

solutions

1. WiFi, with or without Google Streaming $80. WiFi dongles such as Miracast or similar, run $40. They screen-mirror via home WiFi like Google Streaming, but don't require internet. Google Streaming requires the home WiFi network be internet-connected in order to screen mirror (creepy).
2. Wired Ethernet. We'll at least need a USB-C to Ethernet adapter $15. Configuring the Ethernet for the phone mirroring remains unknown as I write this today, but it is the preferred longer term solution.
3. A third option looks promising but is not workable. The hybrid Nyrius transmitter ($70), connects to the USB-C, however it requires that a phone have the DP alt-mode firmware. The XT1541 lacks Motorola "Ready For" firmware and thus lacks DP alt-mode.

Wired Ethernet is the safest long-term solution. Turn-on one's WiFi router, turn off its WiFi, and route the screen-mirroring through its physical ports.

Ethernet process/configuration

In progress. Configuration setups are currently being tested. WiFi screencasting allows the phone and TV to discover/detect each other as nearby devices, and then pass the video stream through the WiFi router.

But how can the phone and TV detect each other via wired Ethernet? This may require a dedicated app on the phone to detect the TV on the network, might depend on the TV's firmware, or some other. Not yet sure.