The machine with the problem (I'll refer to it as
testbed from now on) was able to more-or-less boot up, at least well enough to connect to the local network. I have other Slackware machines nearby that I could (and did) use to compare environments. The only things complicating matters were:
- The root filesystem is jfs (don't judge me)
- The root filesystem is based off a logical volume.
- The logical volume the root filesystem uses has RAID1 physical volumes
- The initrd used didn't have any hid modules loaded, so you couldn't do anything interactive during early boot
The saving grace in this issue was that
testbed's /boot directory was on a different filesystem that was rw; that allowed me to update the initrd. If /boot was on the same filesystem as /, I would have absolutely needed to boot into a live system to fix the problem.
Since
testbed could allow local access via ssh, I could use one fully operational system to check things while modifying
testbed. That wasn't necessary, but it made things easier.
Within
/usr/share/mkinitrd/mkinitrd_command_generator.sh, there are a couple of functions that are quite useful:
Code:
# Search for USB keyboards:
function add_usb_keyboard() {
local USBMOD
if cat /proc/bus/input/devices | sed -e 's/^$/\$/g' | \
tr "\n$" " \n" | grep -q " Phys=.*usb.* .*Handlers=.*kbd.*B:"; then
USBMOD="xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch"
[ -n "$MLIST" ] && MLIST="$MLIST:$USBMOD" \
|| MLIST="$USBMOD"
fi
echo $MLIST
}
# Determine what USB Host Controller is in use
function add_usb_hcd() {
local USBMOD
for i in $(ls -Ld /sys/module/*_hcd/drivers/* 2> /dev/null); do
if ls -L $i | grep -q "[0-9a-f]*:" ; then
USBMOD=$( echo $i | cut -f4 -d/ | tr "_" "-")
[ -n "$MLIST" ] && MLIST="$MLIST:$USBMOD" \
|| MLIST="$USBMOD"
fi
done
echo $MLIST
}
I used the USBMOD value of the first function to get the list of usb keyboard modules and then simply ran
Code:
ls -Ld /sys/module/*_hcd/drivers/*
to see which host controller I needed. I ended up with
Code:
root@testbed:~# $( /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.15.117 -a "-F -o /boot/initrd-5.15.117.gz" -m "xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:uhci_hcd" -r )
So,
rescue mode on boot gives you a minimal environment when you get the shell prompt, which makes sense. A generic rescue mode should bring the system up enough so you can interact with it so you can find out exactly what failed and interactively fix it.
In this case, I know what's wrong and I'd like to not have to remember how to start my raid devices and then bring up my logical volumes to the state where I can mount them. @LuckyCyborg's suggestion of providing a BS root device worked quite well in this case.
When I rebooted
testbed with the new initrd, I interactively modified the grub entry to give it a root device of /dev/sdg55 (which doesn't exist on that machine, or anything else that I have). The initrd init script dropped me into a shell with an environment that easily allowed me to mount the root logical volume rw and fix the /etc/fstab entry that was causing the issue. On the subsequent reboot, the
testbed system came up with a rw / filesystem.
Many thanks to all of you who commented on this thread. I believe that it would be nice if the default initrd generated by the
/usr/share/mkinitrd/mkinitrd_command_generator.sh script loaded keyboard modules or provided a flag that would do that for you.
