Solved Advice? External USB harddrive accidentally unplugged (no activity at time). Re-plugged, but `mountpoint`/`findmnt`/`lsblk` disagree if mounted?

Solved issue

dwawlyn

Member
Joined
Jul 17, 2023
Messages
38
Reaction score
19
Credits
651
So I just accidentally bumped and and unplugged the cable on an external USB harddrive.


- There was no activity at the time.

- It's btrfs (one big partition the whole drive, about 2TB... (I think it's spinning rust, not an SSD -- I dunno, it's just something I had in my box of random old things I inherited from I dunno where))


---
I just plugged it back in, and...

- mountpoint [[path]] #=> "[[path]] is a mountpoint"

- lsblk doesn't show it as having a mountpoint

- findmnt #=>
Code:
TARGET        SOURCE                                 FSTYPE    OPTIONS                                                                                      
/             /dev/sda3[/@/.snapshots/1/snapshot]    btrfs     rw,relatime,ssd,discard=async,space_cache=v2,subvolid=266,subvol=/@/.snapshots/1/snapshot    
[...]                                                                                                                                                       
[...]                                                                                                                                                       
[...]                                                                                                                                                       
└─[[path]]    /dev/sdb1                              btrfs     ro,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/

- but
sudo ls [[path]]
#=>
ls: reading directory '[[path]]': Input/output error


---
What should I do/check?

Like, I am aware of fsck,
but I don't know anything specific about how/why to use it, or what related/alternative tools I should use...?

Basically, what are my unknown-unknowns here?
How are you generally supposed to deal with this kind of situation?
 


This is going to sound a bit silly, but make sure everything is properly connected and reboot your system.

Do both of those things, even if you're 100% sure that it is properly connected right now.
 
i don't think that sounds silly. a reboot was part of my thought process as well. if there were no pending writes or reads at the time of the disconnection, all should be well and hopefully the reboot solves the mounted or not mounted question. if all is not well with the disk, a reboot really doesn't seem like it would affect that and checks could be run if necessary.

a couple of times i have forgetten to unmount a usb (not btrfs thought) before attaching it to a virtual machine. i believe that left an entry in mtab similar to the situation described here. one time i thought to try a umount on the leftover entry and that worked. otherwise a reboot always did the trick.
 
@KGIII @z7vl7abxc yeah, I didn't say it explicitly,
but "just reboot and see if it's fixed" was already the first thing that occurred to me as probably likely to fix it...
...but then I figured I should ask someone first,
in case there was some sort of answer like "no! don't reboot yet! first you should make sure to [do X]!"

I mean, I haven't even tried just like umount [[path]] yet,
just in case there was some sort of weird cache/journaling thing I'm completely ignorant of...?

But I guess it seems there isn't any such thing?
(I mean, at least not relevant to this -- I know there are plenty of "weird cache/journaling things" I'm completely ignorant of.)
 
in case there was some sort of answer like "no! don't reboot yet! first you should make sure to [do X]!"

In this case, you're not going to hurt anything.

i don't think that sounds silly. a reboot was part of my thought process as well.

Yup. For those reasons, that's why I figure it's a good starting point.

Even if it doesn't fix anything, we've established rebooting didn't help.
 
Even if it doesn't fix anything, we've established rebooting didn't help.

... I'm gonna guess contextually that "rebooting didn't help" was meant to be "didn't hurt"?
(ie one of those "brain-typos" where we somehow end up saying the opposite word of what we mean?)



i believe that left an entry in mtab similar to the situation described here
... I just noticed that I'm not actually sure what exactly /etc/mtab really is
(I have a bunch of ridiculous gaping holes in my general knowledge)

... Oh, I see, man findmnt says:
<span style="color:#00ffff;">DESCRIPTION</span>
<span style="color:#00ffff;">findmnt</span> will list all mounted filesystems or search for a filesystem. The <span style="color:#00ffff;">findmnt</span> command is able to search in <span style="color:#00ff00;">/etc/fstab</span>, <span style="color:#00ff00;">/etc/mtab</span> or <span style="color:#00ff00;">/proc/self/mountinfo</span>. If <span style="color:#00ff00;">device</span> or <span style="color:#00ff00;">mountpoint</span> is not given, all
filesystems are shown.
(
... uhhh, I tried to pass that through aha so the pretty color formatting from the man page would come through
(the color highlighting there does arguably have semantic content)
but yeah, not sure how to make it come through on this forum, if that's possible?
)

ANYway, yeah, it says:
The findmnt command is able to search in
/etc/fstab
/etc/mtab
or
/proc/self/mountinfo

If device or mountpoint is not given,
all filesystems are shown.
Which I think means that by default it just gets the info from those three files and combines-and-formats it together?



But yeah,
I think I'm actually just gonna try first umount [[mountpoint]],
cuz I have other reasons I'm afraid to reboot right exactly now.
(
I have a heavily custom keyboard (an old ergodox),
which I am extremely dependent on,
but when I woke my computer from sleep this morning,
it didn't come back immediately (like, didn't show up to lsusb) until I plugged it out and back in...
just, disturbingly wonky.

So I kinda want to... before I power off or sleep my computer again,
at least find some ergodox forum and find a bit more info for like,
a better emergency plan for if the microcontroller is failing or something.

I mean, it was working fine on my other laptop... before it exploded.
... But then, my external monitor worked fine with my other laptop too,
and I couldn't get that to work with this laptop either...
(
although I'm pretty sure that's due to some legacy-driver-regression-bug thing in the newer kernel in the opensuse tumbleweed I'm running
(problem with VGA and the radeon graphics or something in this old Thinkpad E525 or something?)
because the monitor worked fine when I tested it in an MX-Linux live usb...
)

(I am not having a good week. Or like... life.)
)



But yeah, just did sudo umount [[mountpoint]],
unplugged the external harddrive,
and plugged it back in,
and everything seems fine now! :D
 
If you get these types of errors.
ls: reading directory '[[path]]': Input/output error
And it is now working again.
unplugged the external harddrive,
and plugged it back in,
and everything seems fine now!
There is a chance your hard drive is starting to fail. I would run "dmesg" and check for any messages in the output, to see if you see other errors come across and also use smartctl to scan the health of the disk.
 
@f33dm3bits Thanks!

I checked dmesg,
and my heart made a micro-jump when I saw it was full of btrfs-related errors,
but of course there were lots of those from earlier.

Thankfully, the only output that gets added now after un-and-re- mounting the drive is:
Code:
[Mon Jul 17 11:48:21 2023] BTRFS: device label pc_slim devid 1 transid 4407 /dev/sdb1 scanned by mount (27616)
[Mon Jul 17 11:48:21 2023] BTRFS info (device sdb1): using crc32c (crc32c-generic) checksum algorithm
[Mon Jul 17 11:48:21 2023] BTRFS info (device sdb1): disk space caching is enabled

So it seems fine, eh?
(... right? O_O )



But still, I should ask:
how do I use smartctl by the way?
I mean, I assume just smartctl [[mountpoint]],
but any flags I should use, or...?
 
But yeah, just did sudo umount [[mountpoint]],
unplugged the external harddrive,
and plugged it back in,
and everything seems fine now! :D
if all's well with that drive, you could mark the thread solved just so folks can know.

I have a heavily custom keyboard (an old ergodox),
which I am extremely dependent on,
but when I woke my computer from sleep this morning,
it didn't come back immediately (like, didn't show up to lsusb) until I plugged it out and back in...
if that's a persistent issue, it might be worth its own post. maybe someone here has a similar keyboard?

i have a touchpad that is dead after resuming from suspend very infrequently. i remove its module and re-add it with modprobe to wake it back up. that may be different since yours is an external device, but also may be worth a look with dmesg.

So it seems fine, eh?
(... right? O_O )
if your distro uses systemd, you should be able to look at journal messages from previous boot sessions to see if the messages are similar to the new ones: https://www.thegeekdiary.com/beginn...urnalctl-to-view-and-manipulate-systemd-logs/
 
if your distro uses systemd, you should be able to look at journal messages from previous boot sessions to see if the messages are similar to the new ones: https://www.thegeekdiary.com/beginn...urnalctl-to-view-and-manipulate-systemd-logs/

Yup, systemd!
I had heard a little about those journalctl features,
such that it was on my big-messy list of "I should actually learn enough to start using that some time" things,
so thank you for the link!



i have a touchpad that is dead after resuming from suspend very infrequently. i remove its module and re-add it with modprobe to wake it back up. that may be different since yours is an external device, but also may be worth a look with dmesg.

(
Yeah, it's external, and connected through an old usb hub
(same as it was on the other computer)
so there are a few potential complicating factors I'd need to isolate...

But in my current state of ignorance,
doing anything that would unnecessarily risk physically shocking the electronics is exactly what I'm terrified of!
So yeah.
)

But modprobe eh? How does that work?
(I feel like maybe I vaguely recognize using that for something, but years and years ago when I was even more ignorant and incompetent than now...)

But yeah, from the manpage I see it seems to operate around modulename's as arguments,
but I couldn't spot how you find/list what the concrete modulename's you can operate on are,
or how they correlate with the output of lsusb or ... something else?
 

Hm, thanks, but after messing around a bit
(it does not take the mountpoint, but only the... "device path"?)
I found
sudo smartctl -i /dev/disk/by-label/pc_slim
#=>
Code:
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.4.2-1-default] (SUSE RPM)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               Seagate
Product:              Ultra Slim PL
Revision:             0304
Compliance:           SPC-4
User Capacity:        2,000,398,933,504 bytes [2.00 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
Logical Unit id:      0x5000000000000001
Serial number:        NA7VAJ70
Device type:          disk
Local Time is:        Mon Jul 17 12:29:00 2023 PDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Disabled
Temperature Warning:  Disabled or Not Supported

and it's not clear to me from the manpage whether there could be any sort of risk associated with trying to enable "SMART support"...?
Like, I wouldn't think so, but I barely know what I'm doing,
so I often worry that like, metaphorically, a field of potatoes might be landmines,
cuz with as little as I know they could be...

(
...
Also, whoever set the goddamn standards for manpages did a cursedly horrible job,
and simply extracting the syntax for the command to actually do the thing you want from the horribly formatted, over-abstract, concrete-example-bereft prose tends to be a major headache...
)

...
no wait, there are good examples at the end of this manpage,
just I missed them at first cuz I thought the screaming-case "ENABLE" stuff in the middle of the page was a part of the syntax itself,
so I was looking for full commands using that,
but the "ENABLE/DISABLE" stuff was just talking about the abstract operations,
not the syntax...

So I guess what I want is basically something like
smartctl --smart=on /dev/disk/by-label/pc_slim
and now I just need to figure out...

- what other flags I need?
(eg --offlineauto=on? --saveauto=on?)

- how to make sure I'm not doing anything stupid/risky by firing off the command...
 
Last edited:
... I'm gonna guess contextually that "rebooting didn't help" was meant to be "didn't hurt"?

No, I meant if you rebooted and nothing happened, we've established that rebooting didn't help.
 
No, I meant if you rebooted and nothing happened, we've established that rebooting didn't help

(ohhh, you meant given the assumption that "no, there are indeed no magic caches or anything you could disturb/lose by unmounting/rebooting".)
 
(ohhh, you meant given the assumption that "no, there are indeed no magic caches or anything you could disturb/lose by unmounting/rebooting".)

You got it. It's just that it'd be the first step I'd take in your situation.

Well, no... I'd probably grumble and wait until I needed to reboot. I do not reboot all that often. Modern computers use little energy when idle and with the monitor off, so I don't mind.

At the end of the day, it's great that you got it sorted. If you plan on sticking around (and you could, just 'cause we're nice people) then you can make an intro post in the introductions section and join or merry band of Linux enthusiasts.

I'm sure you have solutions to various problems all stored up and ready to share with your fellow enthusiasts. Plus we have cookies!
 
I had heard a little about those journalctl features,
such that it was on my big-messy list of "I should actually learn enough to start using that some time" things,
so thank you for the link!
in your situation, i would check something like
journacltl --list-boots | tail
to get a list the most recent boot sessions. if you can spot one before you unplugged the disk inadvertently, you could try
journactl -b-2 | grep -i btrfs
you could replace the -2 with the boot number that looks like the one you want to search.

but I couldn't spot how you find/list what the concrete modulename's you can operate on are,
or how they correlate with the output of lsusb or ... something else?
as you said, it might be abstracted behind the hub. however, if you have a line for the keyboard in lsusb, you might be able to see a driver with lsusb -t. this is from a generic usb keyboard:
Code:
lsusb
...
Bus 002 Device 005: ID 1a2c:0e24 China Resource Semico Co., Ltd USB Keyboard

lsusb -t
...
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
    |__ Port 1: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 1: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

i ran sudo dmesg -w before plugging the keyboard in and these were the messages that were output after doing so:

Code:
sudo dmesg -w
...
[121822.050860] usb 2-1: new low-speed USB device number 5 using xhci_hcd
[121822.203964] usb 2-1: New USB device found, idVendor=1a2c, idProduct=0e24, bcdDevice= 1.10
[121822.203967] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[121822.203969] usb 2-1: Product: USB Keyboard
[121822.203970] usb 2-1: Manufacturer: SEM
[121822.761013] hid: raw HID events driver (C) Jiri Kosina
[121822.769062] usbcore: registered new interface driver usbhid
[121822.769068] usbhid: USB HID core driver
[121822.776560] input: SEM USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/0003:1A2C:0E24.0001/input/input26
[121822.835025] hid-generic 0003:1A2C:0E24.0001: input,hidraw0: USB HID v1.10 Keyboard [SEM USB Keyboard] on usb-0000:00:14.0-1/input0
[121822.835197] input: SEM USB Keyboard Consumer Control as /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.1/0003:1A2C:0E24.0002/input/input27
[121822.894890] input: SEM USB Keyboard System Control as /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.1/0003:1A2C:0E24.0002/input/input28
[121822.894994] hid-generic 0003:1A2C:0E24.0002: input,hidraw1: USB HID v1.10 Device [SEM USB Keyboard] on usb-0000:00:14.0-1/input1

you can see that in addition to usbhid, hid-generic is also involved. you could probably get similar info with udevadm as well.
 
Oh, neat, thanks!

in your situation, i would check something like
journactl --list-boots | tail
to get a list the most recent boot sessions. if you can spot one before you unplugged the disk inadvertently, you could try
journactl -b -2 | grep -i btrfs
you could replace the -2 with the boot number that looks like the one you want to search.

Well, I unplugged the disk this morning, so that was this boot,
and without any sleep since...

So that's just sudo journalctl -b 0 eh?

And it contains everything dmesg does and more, eh?
I would guess it unifies all the output of a number of tools like dmesg,
and must have complex ways of doing all the sorting and filtering each tool already does,
plus some added complexity for combining them all together...

Is that a reasonable summary for an absolute newb of what the deal with journalctl is?

Anyway, the drive really does seem to be perfectly fine now, so yeah...




Aha, lsusb -t (and -tv), and dmesg -w!

I'm not actually going to do the unplugging yet,
cuz still paranoid terrified of losing my ability to type normally
(and having to fix that without being able to type normally...)

But it's helpful to see:
$ lsusb -t -v
#=>
Code:
 /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M
     ID 1d6b:0001 Linux Foundation 1.1 root hub
 /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
     ID 1d6b:0001 Linux Foundation 1.1 root hub
 /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
     ID 1d6b:0001 Linux Foundation 1.1 root hub
     |__ Port 3: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M
         ID 147e:1002 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor
     |__ Port 5: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
         ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
     |__ Port 5: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
         ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
     |__ Port 5: Dev 3, If 2, Class=Vendor Specific Class, Driver=, 12M
         ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
     |__ Port 5: Dev 3, If 3, Class=Application Specific Interface, Driver=, 12M
         ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
 /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
     ID 1d6b:0002 Linux Foundation 2.0 root hub
     |__ Port 3: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
         ID 04f2:b257 Chicony Electronics Co., Ltd Lenovo Integrated Camera
     |__ Port 3: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
         ID 04f2:b257 Chicony Electronics Co., Ltd Lenovo Integrated Camera
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
     ID 1d6b:0002 Linux Foundation 2.0 root hub
     |__ Port 3: Dev 9, If 0, Class=Hub, Driver=hub/4p, 480M
         ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
         |__ Port 2: Dev 10, If 0, Class=Mass Storage, Driver=uas, 480M
             ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
     |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/7p, 480M
         ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
         |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
             ID 046d:c52b Logitech, Inc. Unifying Receiver
         |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
             ID 046d:c52b Logitech, Inc. Unifying Receiver
         |__ Port 2: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
             ID 046d:c52b Logitech, Inc. Unifying Receiver
         |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 12M
             ID 0a12:4010 Cambridge Silicon Radio, Ltd 
             |__ Port 1: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
                 ID 0b0e:24c7 GN Netcom 
             |__ Port 1: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
                 ID 0b0e:24c7 GN Netcom 
             |__ Port 1: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M
                 ID 0b0e:24c7 GN Netcom 
             |__ Port 1: Dev 5, If 3, Class=Human Interface Device, Driver=usbhid, 12M
                 ID 0b0e:24c7 GN Netcom 
         |__ Port 6: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M
             ID 1d50:6028 OpenMoko, Inc. Teensy 2.0 Development Board [ErgoDox Keyboard]
         |__ Port 6: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 12M
             ID 1d50:6028 OpenMoko, Inc. Teensy 2.0 Development Board [ErgoDox Keyboard]
         |__ Port 6: Dev 6, If 2, Class=Human Interface Device, Driver=usbhid, 12M
             ID 1d50:6028 OpenMoko, Inc. Teensy 2.0 Development Board [ErgoDox Keyboard]
         |__ Port 6: Dev 6, If 3, Class=Human Interface Device, Driver=usbhid, 12M
             ID 1d50:6028 OpenMoko, Inc. Teensy 2.0 Development Board [ErgoDox Keyboard]
 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
     ID 1d6b:0002 Linux Foundation 2.0 root hub
     |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=uas, 480M
         ID 0bc2:ab2d Seagate RSS LLC SRD00F1 [Backup Plus Ultra Slim]

... and that reminds me,
what's in lshw...?
Aha!:
$ sudo lshw -sanitize |ag -B 2 -A 21 falba
#=>
Code:
 *-usb:2
      description: Keyboard
      product: FalbaTech ErgoDox ergonomic keyboard
      vendor: FalbaTech
      physical id: 6
      bus info: usb@2:4.6
      logical name: input28
      logical name: /dev/input/event16
      logical name: input28::capslock
      logical name: input28::compose
      logical name: input28::kana
      logical name: input28::numlock
      logical name: input28::scrolllock
      logical name: input29
      logical name: /dev/input/event17
      logical name: input30
      logical name: /dev/input/event18
      logical name: input30::capslock
      logical name: input30::compose
      logical name: input30::kana
      logical name: input30::numlock
      logical name: input30::scrolllock
      version: 1.00
      capabilities: usb-2.00 usb
      configuration: driver=usbhid maxpower=100mA speed=12Mbit/s
(had to awkwardly use before/after flags in ag, cuz lshw's -class flag can apparently take like input but not input28/input:28 or whatever?)




And I vaguely remember that there was some udev rule or something on the other computer (before it exploded),
which ran some setup/config script whenever the keyboard was plugged in
(and keeping its keymap somehow separate from the laptop's built-in keyboard's)
and I think that relied on the "FalbaTech" string somehow...

(
I'm... honestly reverse engineering all this stuff I inherited from my dead partner,
so this is... not just a splitting technical headache,
but also a crushing emotional heartache...
)

... was the udev thing... this?
$ cat udev.sh
#=>
Code:
 #!/bin/sh
 echo "/bin/su $USER -c /home/$USER/saneo/skb.sh > /dev/null" | at now
no, I guess that's a script that udev was repsonsible for running, right...
not sure where the actual udev bit itself is...

...
well, it's somewhere under:
/etc/init.d/
/etc/conf.d/
/etc/udev/
(
on the (perfectly fine (I hope)) SSD recovered from the dead computer
... which was an anciently out-of-date custom gentoo install that, I again, I didn't set up and just inherited,
but yeah, gentoo, so it was ... not systemd, some other init system
)

...

I also know
~/.xinitrc
ran like
Code:
 $HOME/saneo/skb.sh &
 xmodmap ~/.Xmodmap
(
Although now that I'm on KDE plasma on this opensuse tumbleweed laptop, with SDDM,
I no longer have an xinitrc here,
so I guess I should just use the "login script" feature through KDE systemsettings "autostart"...?
(systemsettings kcm_autostart)
)

aand
$cat ~/.Xmodmap
#=>
Code:
 pointer = 1 2 3 4 5 8 9 6 7
(it barely has to do anything cuz the ergodox itself does most of it -- just needs to set up the extra layers I think??)

and
$cat ~/saneo/skb.sh
#=>
Code:
 #!/bin/bash 

 # make sure this works no matter where we run from
 export DISPLAY=":0.0"
 export XAUTHORITY=$HOME/.Xauthority 

 # basic layout on laptop
 setxkbmap de      || exit 1 # use german default (laptop physical keyboard is german) 
 

 function ids_kbd() {
   xinput | grep "keyboard" | grep "$1" | grep -oP "id=[0-9]+" | cut -c 4- | sort -n
 } 

 sleep 0.1 # minor wait to let ergodox settle
 symbols="pc+inet(evdev)" # fix f13 keys
 for id in $(ids_kbd "FalbaTech ErgoDox"); do
   echo "setting ergodox layout on $id..."
   setxkbmap -device $id -symbols "${symbols}+saneo_ergodox" || exit  1
 done 

 echo "mouse sensitivity..."
 xset m 3 2 

 echo "default keyboard sensitivity..."
 xset r rate 300 200
 #xset r rate 300 75	#oc original 

 # generic xmodmap
 if [[ -e "$HOME/.Xmodmap" ]]; then
   echo "setting xmodmap..."
   xmodmap $HOME/.Xmodmap 2>/dev/null || exit 1
 fi 

 # notification
 echo "setting dbus"
 dbus=`find ~/.dbus/session-bus -type f -printf "%T@+\t%p\n" | sort -n -r | column.pl 2 | head -1`
 if [[ -e $dbus ]]; then
     source $dbus
 fi 

 echo "notifying..."
 if [[ -n $DBUS_SESSION_BUS_ADDRESS ]]; then
     notify-send "keyboard set up" || exit 1
 fi 

 echo
 echo "DONE {skb.sh}"

and
/usr/share/X11/xkb/symbols/saneo_ergodox
was involved somehow...
(For instance, for making the F13 to F28 keys work, and all the weird extra unicode characters)
$ /usr/share/X11/xkb/symbols/saneo_ergodox
#=>
Code:
 //
 default partial alphanumeric_keys modifier_keys keypad_keys
 xkb_symbols "saneo" { 

 // basically,
 	// we pretend to be a US qwerty keyboard
 	// that just happens to be arranged in a peculiar way.
 		include "us(basic)"
 		name[Group1] = "saneo";
 	// ...except for non-US keys, which we put on Mod3.
 	// we (unfortunately) re-define the normal keys too, but that's not a big deal.
 	// some keys are inherently redundant or shifted, and you shouldn't use those,
 	// which is why they're commented out
 	// ------------------ 

 	// definition of Mod3
 		key.type[Group1] = "FOUR_LEVEL";
 		key <RALT>	{ [ 	
 		          	    	ISO_Level3_Shift	,	//ISO_Level3_Latch	,	
 		          	    	ISO_Level3_Shift	,	//ISO_Level3_Latch	,	
 		          	    	NoSymbol        	,	
 		          	    	NoSymbol        	 	
 		          	] };	
 		modifier_map Mod5 { <RALT> }; 

 // main
 	//           	  	          	   	         	                   	UM          	SHIFT-UM    	    	
 	// top row   	  	          	   	normal   	, Level3_Latchshift	, mod3      	, mod3+shift	    	
 	             	  	key <AB02>	{ [	x        	, X                	, x         	, X         	] };	
 	             	  	key <AB04>	{ [	v        	, V                	, UFF62     	, V         	] };	
 	             	  	key <AC09>	{ [	l        	, L                	, l         	, L         	] };	
 	             	  	key <AB03>	{ [	c        	, C                	, U00AB     	, U2039     	] };	
 	             	  	key <AD02>	{ [	w        	, W                	, UFF3C     	, UFE68     	] };	
 	             	  	          	   	         	                   	            	            	    	
 	             	  	key <AC08>	{ [	k        	, K                	, k         	, K         	] };	
 	             	  	key <AC06>	{ [	h        	, H                	, U00BB     	, U203A     	] };	
 	             	  	key <AC05>	{ [	g        	, G                	, g         	, G         	] };	
 	             	  	key <AC04>	{ [	f        	, F                	, UFF63     	, F         	] };	
 	             	  	key <AD01>	{ [	q        	, Q                	, q         	, Q         	] };	
 	             	  	          	   	         	                   	            	            	    	
 	// home row  	  	          	   	normal   	, shift            	, mod3      	, mod3+shift	    	
 	             	  	key <AD07>	{ [	u        	, U                	, udiaeresis	, Udiaeresis	] };	
 	             	  	key <AD08>	{ [	i        	, I                	, U276E     	, U2983     	] };	
 	             	  	key <AC01>	{ [	a        	, A                	, adiaeresis	, Adiaeresis	] };	
 	             	  	key <AD03>	{ [	e        	, E                	, eacute    	, Eacute    	] };	
 	             	  	key <AD09>	{ [	o        	, O                	, odiaeresis	, Odiaeresis	] };	
 	             	  	          	   	         	                   	            	            	    	
 	             	  	key <AC02>	{ [	s        	, S                	, ssharp    	, U1E9E     	] };	
 	             	  	key <AB06>	{ [	n        	, N                	, n         	, N         	] };	
 	             	  	key <AD04>	{ [	r        	, R                	, UFF0F     	, U2044     	] };	
 	             	  	key <AD05>	{ [	t        	, T                	, U276F     	, U2984     	] };	
 	             	  	key <AC03>	{ [	d        	, D                	, d         	, D         	] };	
 	             	  	          	   	         	                   	            	            	    	
 	// bottom row	  	          	   	normal   	, shift            	, mod3      	, mod3+shift	    	
 	             	//	key <AE05>	{ [	5        	, percent          	, 5         	, percent   	] };	
 	             	//	key <AE08>	{ [	8        	, asterisk         	, 8         	, asterisk  	] };	
 	             	//	key <AC10>	{ [	semicolon	, colon            	, semicolon 	, colon     	] };	
 	             	  	key <AD10>	{ [	p        	, P                	, p         	, P         	] };	
 	             	  	key <AB01>	{ [	z        	, Z                	, z         	, Z         	] };	
 	             	  	          	   	         	                   	            	            	    	
 	             	  	key <AB05>	{ [	b        	, B                	, b         	, B         	] };	
 	             	  	key <AB07>	{ [	m        	, M                	, m         	, M         	] };	
 	             	  	key <AC07>	{ [	j        	, J                	, j         	, J         	] };	
 	             	  	key <AD06>	{ [	y        	, Y                	, y         	, Y         	] };	
 	             	//	key <AC10>	{ [	semicolon	, colon            	, semicolon 	, colon     	] };	 

 // fix function keys
 	key <FK13> { [	F13	] };	
 	key <FK14> { [	F14	] };	
 	key <FK15> { [	F15	] };	
 	key <FK16> { [	F16	] };	
 	key <FK17> { [	F17	] };	
 	key <FK18> { [	F18	] };	
 	key <FK19> { [	F19	] };	
 	key <FK20> { [	F20	] };	
 	key <FK21> { [	F21	] };	
 	key <FK22> { [	F22	] };	
 	key <FK23> { [	F23	] };	
 	key <FK24> { [	F24	] };	
 };




But I still only vaguely know what udev even is honestly,
and I've been dragging my feet on even just relearning how to set up cronjobs
(or learn the systemd equivalent?)
because.... I'm not even 100% sure why honestly...

... it's... not completely rational.
... or, "not completely" is an understatement...

... Sorry, I'm babbling so much raw rambling notes that only make any sense or have any value to me,
and now I'm... weeping...

... I haven't cried in ages,
I got too fucking broken and numb to even cry any more...

...

Welp, ANYWAY, time to get back to... trying to fix... everything. Somehow.

... Actually, I've been awake like 30 hours straight now,
time to get some sleep, and then back to trying to fix stuff...
 
Well, I unplugged the disk this morning, so that was this boot,
and without any sleep since...

So that's just sudo journalctl -b 0 eh?
that does seem like it should work since there were probably messages before the disk was unplugged containing the string "btrfs". in case it might help with future searches -b 0 can be shortened to just -b.
And it contains everything dmesg does and more, eh?
I would guess it unifies all the output of a number of tools like dmesg,
and must have complex ways of doing all the sorting and filtering each tool already does,
plus some added complexity for combining them all together...

Is that a reasonable summary for an absolute newb of what the deal with journalctl is?
that sounds like a good summary. here's a similar one from one of systemd's initial developers:
If you are wondering what the journal is, here's an explanation in a few words to get you up to speed: the journal is a component of systemd, that captures Syslog messages, Kernel log messages, initial RAM disk and early boot messages as well as messages written to STDOUT/STDERR of all services, indexes them and makes this available to the user. It can be used in parallel, or in place of a traditional syslog daemon, such as rsyslog or syslog-ng. For more information, see the initial announcement.
from: https://0pointer.de/blog/projects/journalctl.html
I'm not actually going to do the unplugging yet,
cuz still paranoid terrified of losing my ability to type normally
(and having to fix that without being able to type normally...)
that sounds completely understandable. the modprobe suggestion was more of a workaround than any kind fix. as you can see from your lsusb -tv output, there are other devices using the usbhid module/driver. it is likely that the unplug and replug method would be a quicker and cleaner way to restart your keyboard without affecting all of those other devices should the need arise again.
I'm... honestly reverse engineering all this stuff I inherited from my dead partner,
so this is... not just a splitting technical headache,
but also a crushing emotional heartache...
my condolences on your loss.

you have a lot of probably helpful info about the keyboard setup. i would suggest that it could benefit from its own post if it is an problem you are trying to solve.
well, it's somewhere under:
/etc/init.d/
/etc/conf.d/
/etc/udev/
(
on the (perfectly fine (I hope)) SSD recovered from the dead computer
... which was an anciently out-of-date custom gentoo install
from: https://wiki.gentoo.org/wiki/Udev#Rules

Rules​

udev provides a set of rules that match against exported values of uevents (events sent by the kernel) and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to setup and configure the device.

The rule definitions are stored in two locations:
  1. /lib/udev/rules.d/ - Rules in this directory are installed by certain packages, they generally should not be changed by users;
  2. /etc/udev/rules.d/ - This folder is for end-user specified rules. Any new rules should be added in this directory;
so /etc/udev/rules.d/ is where i would start my search for a user created udev rule to run those keyboard setup scripts.
But I still only vaguely know what udev even is honestly,
and I've been dragging my feet on even just relearning how to set up cronjobs
(or learn the systemd equivalent?)
because.... I'm not even 100% sure why honestly...
it sounds like in the context of all of the above, you are searching for a way (udev) to get those keyboard setup scripts to run when the keyboard is plugged in. if you can autorun the scripts at boot, that could be helpful but doesn't cover a situation in which you would need to unplug and replug the keyboard as you mentioned needing to do if it is dead after suspend.
 
@z7vl7abxc
Thank you so much for all your detailed helpful advice and tips!

I... kinda withdrew more and more after everything that happened and everything I lost,
to the point where I couldn't bring myself to even just try posting anywhere to ask about anything,
but I just recently started to... finally have some success pushing myself to reach out anyway,
and you've honestly been... a real bright point.
ie, you're been at least one shining example disproving my irrational fears that it's pointless and literally everyone will just ignore me or be mean and unhelpful.

you have a lot of probably helpful info about the keyboard setup. i would suggest that it could benefit from its own post if it is an problem you are trying to solve.

Yeah, that's what I'm thinking. I'm working up to it, and your responses here really helped me towards that.






@f33dm3bits
I mean, I assume just smartctl [[mountpoint]],
but any flags I should use, or...?

No on the disk.
Code:
smartctl /dev/sda

Thanks, but I already noted that in this post:
Hm, thanks, but after messing around a bit
(it does not take the mountpoint, but only the... "device path"?)
I found
sudo smartctl -i /dev/disk/by-label/pc_slim
(Again, not sure if "device path" is the correct term, but I think it's clear enough, at least in context?)

But yeah, like I said
(
since
$ sudo smartctl -i /dev/disk/by-label/pc_slim
#=>
Code:
[...]
SMART support is:     Available - device has SMART capability.
SMART support is:     Disabled
[...]
)
I got as far as this:
So I guess what I want is basically something like
smartctl --smart=on /dev/disk/by-label/pc_slim
and now I just need to figure out...

- what other flags I need?
(eg --offlineauto=on? --saveauto=on?)

- how to make sure I'm not doing anything stupid/risky by firing off the command...

but then I just kinda put the matter to the side and didn't go any further because:
it's not clear to me from the manpage whether there could be any sort of risk associated with trying to enable "SMART support"...?
Like, I wouldn't think so, but I barely know what I'm doing,
so I often worry that like, metaphorically, a field of potatoes might be landmines,
cuz with as little as I know they could be...
 

Members online


Top