I had this same problem late last Fall on this same drive
and am not sure what is going on because there is another Linux
system here whose drive is arranged exactly the same way. An
update in March modified grub and I didn't even give it a thought
because that system just works but after an update a couple of
days ago, the dead system starts a boot but grub complains about
neither possible image being bootable.
When I rescued that system last Fall, I was advised on
this list to do the following which worked perfectly by the way:
>If you want a grub-install command that writes /boot/grub files
>somewhere onto /dev/sdd then you will first have to mount the desired
>target boot partiton of /dev/sdd on some mountpoint that you choose,
>and then run a command something like this:
> sudo grub-install
>--boot-directory=/some/mountpoint/where/is/the/sdd/boot /dev/sdd
I mounted the drive on /mnt so looking at /mnt gives you / and
the directory where the correct files are is then /mnt/boot or
possibly /mnt/boot/grub.
I created the following shell script which I named do_grub.
#!/bin/sh
sudo grub-install \
--boot-directory=/mnt/boot/
I get the following no matter where I point boot-directory:
./do_grub
[sudo] password for martin:
Installing for i386-pc platform.
grub-install: error: install device isn't specified.
I don't remember doing anything else.
I think this time I may also need to do update-grub on
the currently bootless drive.
As with the last time this happened, the dead drive
passes all fsck tests and the first time I ran fsck on it,
nothing needed fixing.
This is one of these problems that hardly ever comes up
which means that when it happens, one spends/wastes a lot of
time doing duckduckgo and puzzling. There should be a way to
automate or at least prompt the person running the recovery
attempt to find the right information to get things up and
running if at all possible. It's all there such as the grub file
in /etc/default which should have the uuid of the/ and swap
partitions. Right then, one could see if the uuid's are correct
and get a proper boot going in which one could then rerun
update-grub if necessary. Right now, it's just fumble and fiddle
and wonder what happened.
I must have something set wrong to cause the apt-get
upgrade to build a non-functional grub since the system in
question made a number of reboots successfully between about last
December 1 and now.
I also remember reading a message about problems with
swap which is on /dev/sda5 when the drive is booted. I found the
messages log which shows swap as correctly mounted and working
before the upgrade.
Is there another log which might still have that message
from apt-get upgrade. The message was not captured at the time.
I have been using Debian on several systems for a number
of years and this one system is the only one which seems to fall
down every time grub is touched. That indicates I need to check
one of the configuration files which probably has a wrong
partition ID or something similar.
I am just glad I have another Linux box to mount the
no-boot drive on and that the drive, itself, does not seem
corrupted just as the last time this happened.
Thanks for any constructive ideas.
Martin McCormick WB5AGZ
