Re: Boot Repair
Weaver <weaver@riseup.net> writes:
> Well, let us know how it goes, because I've noted a few visually
> disadvantaged users on the list, and they would find the reference
> useful.
I have found out that grub is very accessible if one has
defined a serial console and there is a working serial port on
the target system. In this case, both conditions are true.
The next thing one needs is a talking terminal which is
no problem if one has another computer equipped with a serial
terminal program like microcom or what I consider the gold
standard, kermit which apparently has too many dependencies to be
part of the Debian distributions any more. Kermit has a decent
scripting language so one can save the commands that work, even
the commands that involve entering a huge string in which one
typo means completely starting over again.
This means you can completely repeat all the things that
work each time and feed it all in again in a fraction of a
second. Talk about working smarter as opposed to harder.
While I call kermit the gold standard, the gold standard
for scripting is expect so one can call unix applications from
the login shell to any valid command, read the output and
generate commands as if one was there. You can even simulate
human typing rhythms to defeat attempts to detect robots. I'd
love to see a good CAPTCHA solver with OCR that was so good that
CAPTCHA designers would go out and find honest work but I digress.
This is actually a systemic problem these days when
dealing with sick machines. Nobody is selling new desktops
with RS-232 native serial ports and that is fine as long as
there is an alternative way such as a bluetooth interface or ssh
network connection. The dream solution would be a local network
login covering all the lights-out conditions such as BIOS
configuration and failure to boot as in this situation where grub
is confused.
Before I retired, some of our newest servers used
management interfaces and ipmitool where one could turn power on
and off, do BIOS setups and other configuration remotely. It was
so cool to be able to do those things on a system in another town
without leaving the chair or grabbing a go bag and blowing a
whole day just to flip a couple of switches. Of course,
if it was that simple, we usually could call someone we trusted
at one of our remote campuses and ask them to flip the switches
but I'm sure you see the advantage of remote management.
For folks who are blind, you treat all those things as if
they were halfway round the Earth instead of sitting less than 1
meter apart. They are all headless even if I can extend my arms
and touch both machines.
I think the grubdisk2 GUI app is basically a lost cause
but that's the rule when dealing with accessibility. When
it's done wrong, you chase down endless rabbit holes all day and
muse as to how there must be some way to turn the sausage machine
backwards and have live farm animals running away from the
other end.
There was an American country and Western song back in
the early seventies which had a line at the end of each verse
that went,
"Work your fingers to the bone
What do ya' get?
Bony fingers."
I think the best course right now is to take my bony
fingers and workup a kermit script to interact with grub and get
it to produce one boot and then use the running system and grub
to fix itself. So far, nothing else is less work.
I do appreciate your telling me about grubdisk2 because
sometimes, these things turn out to be life savers and you have
to try the rabbit holes to know for sure.
Martin
Reply to: