[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fixing a Grub Foul-up, Not There Yet.



I did some duckduckgo-ing about grub rescue and found useful
things but am still dead in the water.

	I appear to be using grub, not grub2.  One of the
articles I found had an example of how to use grub rescue that all
works except, of course, for the actual booting of the kernel.

	There's an extra little wrinkle in that, as a computer
warier who happens to be blind, grub isn't really accessible in
that you can not get direct access to it via a serial port and
terminal, say, from another computer that is actually working.  A
really clumsy work-around does work off of the dead computer in
that it is old enough that the Print-screen key dumps an ASCII
character dump of the screen to the parallel printer output every
time you press Print-screen.  I found out after connecting a
second computer to a parallel-to-serial converter that I was in 
grub rescue>  mode.

	Each time one types on a keyboard attached to the dead
computer, one then must hit Print-screen to find out whether it
goes or blows.

	This is slow and awkward because there is no
character-by-character feedback so if you hit the n instead of
the m, you don't find out that it's a no go until you read the
whole screen.

	Also the Tabs you hit don't show up in the output so
it'salloneunbrokenline.

	Is there a way I can write the commands in to a text file
that I can call to at least know what commands I am executing in
grub rescue and do in a tenth of a second what it takes minutes
to do otherwise?

	What I have right now is a text file called stuffcommands
and it is sitting in the boot level of the dead boot disk.
When I had the drive mounted on a working system, I did chmod +x
stuffcommands but since there are no shells running, I just put
the following lines in the file.  Everyone of these commands
works when typed in except for the final one which boots the
kernel.

	What I need to type in with, of course, no mistakes looks
like:

set root=(hd0,1)
linux	(hd0,1)/boot/vmlinuz-4.19.0-5-686-pae	root=/dev/sda1

#I have yet to see this one work.

initrd (hd0,1)/boot/initrd.img-4.19.0-5-686-pae	boot

	Here is a screen capture of what pressing Print-screen
produces  The first line is that error message and is probably
the clue as to what went wrong.  The successful commands were
laboriously typed in by hand once again to prove they work
although by now, I know the kernel version number about as well
as my last name.

error: symbol `grub_calloc' not found.                                          

That's the smoke that the booster is going to blow up on the
launch pad.

Entering rescue mode...                                                         
grub rescue> ls                                                                 
(hd0) (hd0,msdos5) (hd0,msdos1) (fd0) (fd1)                                     

	The root partition is Partition #1.

grub rescue> (hd0,1)/boot/stuffcommands                                         
Unknown command `(hd0,1)/boot/stuffcommands'.                                   

Ah, if only.  Those few lines would make each retry so much more
efficient.

grub rescue> set root=/de/sda1                                                  

It worked.

grub rescue> linux(hd0,1)/boot/mlinuz-4.19.0-5-686-paeroot=/de/sda1             

And that one worked!

grub rescue>                                                                    

That much works and it would be so nice not to have to repeat
those steps every time.  Is there a way to call that
stuffcommands text file so that grub thinks it's coming from the
keyboard?


	I think I'd like a keyboard that one can store commands
like this in so as to keep the donkey work down to the problem
lines.

	Actually, if only grub could be made to operate remotely,
I'd just script all the stuff that works and also know if I
fat-fingered anything when it happens so one could backspace and
fix it the way we fix any typing error.

	Before I retired in 2015, I occasionally had to setup new
servers and these had lights-out minicomputers that helped one 
remotely access even a powered-down box in another state,
province or country.  The linux kernel, itself can easily be
configured to be accessible via a serial port or on the local
console so grub sorely needs headless capabilities for those rare
times where stuff just doesn't come back from a reboot.

	I appreciate the good suggestions I have gotten from
several of you so far.

Martin McCormick


Reply to: