On 06/11/2014 20:46, Don Armstrong wrote:
On Thu, 06 Nov 2014, Ron Leach wrote:
Tried the grub-install, but it failed complaining (loosely) that the
'image was too large for embedding, but the embedded image was needed
for raid or lvm systems'.
I'd mounted /boot2 to retain compatibility with the Lenny build. I
executed:
# mount /dev/sdb1 /boot2
# grub-install --root-directory=/boot2 /dev/sdb
which failed, complaining that the 'image' was too big. I tried grub-setup
as well but that complained, too.
Didn't get any further, because the grub-install failed.
Ugh. It's possible that this is because it was partitioned badly, and
the first partition starts too early to fit the full core image.
The problem was (I think) that the Squeeze installer rescue version of
Grub might not have been compatible with the Lenny installation, in
some way. Late on, I found another Lenny CD1 (Lenny 5.0.6) which read
fine and, with that rescue system, managed to install Grub onto
/dev/sdb though, on reboot, it only reached a Grub prompt. (But that
was what you'd suggested, so that was ok.) Incidentally, Grub on
Lenny is version 1.96. From the Grub prompt, I was able to see that
vmlinuz-xxx, and
initrd-xxx
were 'seen', so using manual completion at the prompt I was able to
enter (from the keyboard):
linux /vm[tab] root=/dev/md1
initrd /in[tab]
boot
and the system came up, running on sdb only, with the raid partitions
active but degraded.
Used parted to partition the new, blank, /dev/sda, including all the
raid flags, and restored all 6 raid1 arrays.
That left me with the booting problem of only reaching a Grub prompt.
Grub-install didn't solve it - the system continued to only reach
the Grub prompt on reboot. That happened whether the system booted
from sda or from sdb. Looking around with mc, I saw that there were
no grub.cfg files - which normally hold the Grub menu and commands -
and looking at some Grub documents they pointed to /etc/default/grub.
Looking at that, I could see that I also needed to run
# update-grub
before
# grub-install /dev/sda
After doing that (and making sure that /dev/sda was the first hard
disk boot choice in the BIOS) , the system rebooted perfectly.
I couldn't do the same for /dev/sdb because the grub.cfg looks for
some files on the (non-raid) sda1 filesystem, and if I left that there
then the system would not boot from sdb when sda fails. (I see now
why you suggested making sda1/sdb1 a raid1, as well; using raid1 here
would mean that Grub would find the files by searching for the
filesystem offered by raid, which would be on whichever disk was
available. Neat.) I will need to do that, and I need to reread the
approach you suggested. In the meantime, I copied the grub
installation from /dev/sda1 to /dev/sdb1, and changed grub.cfg to
refer to hd(1,1) instead of hd(0,1), and commented out the lines that
search for the filesystem by uuid. Even if it doesn't work, I can
reload from /dev/sdb by typing in the commands, as above.
Thanks for your help, we're back and running, the raid is synced and
we can boot. I'll get sda1/sdb1 onto a raid1 in the next few days.
regards, Ron
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545d1dc1.1030...@tesco.net