Shell-only Emergency Work
I recently reinstalled Debian on my laptop (something I do every year to remove the built-up cruft), and about half-way through the process had the thought: What if the reinstall went bad?
That led to several minutes of pondering, and the worst I could think of (short of a failure to boot) was to have access only to the login shell--which for Debian is the dash shell.
The reinstall went fine, but the thought of "What could I do if I only had access to the shell?" remained in my mind. So I started playing around with dash and as part of the experiment, I decided to see how much I could accomplish using only the shell built-ins that come with that particular shell. Suddenly, I had a very limited tool set. No mkdir or ps or cat or any one of a dozen command-line programs I use daily without a second thought. Not even the more "expansive" version of echo--only the one built into the dash shell. My computing world shrank to the size of a postage stamp.
The first task I thought needed to be tackled was file manipulation: could I read/write to a file? I assumed in fixing a broken system, I'd need a way to create config files. Writing turned out to be the easier of the two:
echo [text] > [file] creates a file and writes the line of [text] into that file. Echoing text into the same file using ">>" appends the text to the end of the file.
As for just creating (or clearing) a file, the command
>[file] will create or empty a file, in a way similar to the "touch" command.
Reading a file and printing it to the standard output turned out to be harder than I first thought. I tried using redirection to directly read a text file. No luck. In the end, I had to create a short one-liner shell script with read/echo, which I then aliased to a simpler command. The one-liner is as follows:
alias look=while read line; do echo "$line"; done<[file]
As for looking at what processes were currently running on the system, the best solution I could find was to use my aliased "look" command to prowl through the various files in the /proc directory. Slow and sloppy, but a lot of useful information can be found with this method. Some useful files I found were:
/proc/uptime = how many seconds the computer has been on
/proc/filesystems = file systems supported by the kernel
/proc/meminfo = memory usage and memory free
/proc/stat = status info for the system as of the last time it booted up
/proc/version = kernel version and linux kernel in use
/proc/cpuinfo = info on the CPU
/proc/devices = currently running device drivers
/proc/mounts = what's currently mounted on the file system
/proc/loadavg = system load average
/proc/modules = currently loaded kernel modules
/proc/partitions = partitions currently on the system
/proc/cmdline = the command line passed to the kernel at boot time
/proc/net/ = directory that contains wifi and other connection statistics for the computer
/proc/sys/ = directory that allows you to examine (and *modify*) kernel and other parameters of the running system
There are also numbered directories in /proc. These are the PIDs (process IDs) of the processes currently running on the system. Within each numbered directory are a number of useful files that relate to that particular process, such as:
cmdline = gives the command line that started the process/program
cwd = the current working directory of the process
environ = shows the environment variables of the process
fd = shows which files and/or file descriptors the process is using
maps, statm = shows memory usage by the process/program
status = provides overall status of the process/program
A bit of time prowling online taught me that there was no quick and easy way to fix problems with the file system using only the dash shell. However, you can force the kernel to check the file system on the next reboot by issuing the following command:
>/forcefsck
This creates the empty file "forcefsck" in the root directory, which will tells the system to run fsck as the system comes back up.
If I was able to fix whatever ailed my system through creating configuration files and/or looking at active processes, the next step would be to poweroff and reboot the system. The steps for this were a bit more complex than I thought:
1. become root using sudo su (if necessary)
2. echo 1 >/proc/sys/kernel/sysrq (lets kernel know to accept commands that follow)
3. echo s >/proc/sysrq-trigger (syncs the file system)
4. echo i >/proc/sysrq-trigger (sends a SIGKILL to all the processes execept init)
5. echo [b or o] >/proc/sysrq-trigger (b reboots the system, o shuts the system off)
These commands can also be given by holding down the 'alt' and 'printscreen' keys (and possibly the function key to get to 'printscreen,' depending on your keyboard) at the same time. Then slowly type "reisub" while holding the alt and printscreen keys down. This will switch to raw mode (r); then issue a sigterm (e) and a sigkill (i) to all processes except init; sync (s) then unmount (u) all file systems; finally, reboot (r) the system. (Typing "reisuo" shuts off the system rather than rebooting it.)
Even with a postage-stamp-sized arena in which to work, I was surprised just how much computer and file manipulation I was able to achieve. If the next annual hard-drive-scraping goes bad, I feel more confident that I could, conceivably, solve my problems within just the dash shell.
~~~~~~~~~~~~~~~~~~~~~~~~~
~Thumos
[email protected]
September 2023