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-xxxwere '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] bootand 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/sdaAfter 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