Hello there,
Yesterday (March 23, 2024), I attempted to update my EOS using pacman -Suy. Nothing unusual caught my attention. However, upon completion of the update, I encountered an issue where my keyboard ceased to function, leaving only the mouse operational, a problem given my keyboard centric environment. Initially, I attempted to shut down the system by pressing the power button, triggering a standard shutdown process #1. Unfortunately, the shutdown process hung #2, a somewhat uncommon occurrence, but sadly not unheard of. The error message displayed during this hang-up consisted of several green [ OK ] ... lines, with the final lines indicating the failure to power down properly. (See image).
The last three lines:
[ OK ] Finished System Power Off.
[ OK ] Reached target System Power Off.
[22705.816465] reboot: Power down.
In such cases, my usual recourse is to cut the power, but sensing potential complications, I opted to perform a forced restart by long-pressing the power button. Upon selecting my Zen kernel from the systemd-boot selector, I was greeted with a series of errors. (See image) The last four lines:
[FAILED] Failed to start Power Profiles daemon.
See 'systemctl status power-profiles-daemon.service' for details.
[ OK ] Finished Notify about reboot on special conditions..
[ 5.374454] Bluetooth: hci0: Malformed MSFT vendor event: 0x02
My primary concern is retrieving the full log of these events #3. While attempting to rectify the situation, I found myself confronted with a screen displaying only the last one or two lines of the log, an impractical scenario for troubleshooting purposes.
(For amusement)
‘Well, there goes my midnight!’ I hastily retrieved my spare EOS live Linux and embarked on a journey of chrooting my way to victory. Or so I thought… It turns out, keeping my only Linux pen-drive in my wallet wasn’t the wisest decision, especially when said USB was mechanically damaged. Friendly advice: Always keep multiple bootable Linux drives handy, so you don’t find yourself flashing a new one in a pinch, like with your Steam Deck.
(End of amusement section)
The following links proved invaluable in navigating this ordeal:
In summary, the steps I followed included:
- Determining the appropriate mount points using commands such as
lsblk,blkid,fdisk -l, andcat /etc/fstab. - Ensuring correct mounting of all necessary partitions (mounting the root
/to/mnt). - Initiating a chroot session using
arch-chroot /mnt. - Verifying the correctness of mount points.
- Modifying the mirrorlist to a date when the system was functional.
- Rebooting and hoping for the best.
Admittedly, I stumbled on this ‘easy’ task initially by forgetting to mount the efi partition on the first two attempts. On the third attempt, with all necessary partitions mounted, including efi, home, and data, I finally achieved success!
Today (March 24, 2024), I updated my mirrorlist and system successfully, with everything functioning as expected.
Now, onto my questions:
#0Are there any improvements I could make to my troubleshooting/problem solving approach?#1Does pressing the power button initiate a shutdown signal, and how can I confirm this?#2What measures can I take to prevent the shutdown process from hanging, and where should I focus my investigation? (Perhaps warranting a dedicated topic?)#3How can I retrieve the complete logs displayed on-screen in the event of a similar occurrence in the future?