On 19 June 2015 at 00:17, steve-ALUG@hst.me.uk wrote:
On 17/06/15 20:40, Jenny Hopkins wrote:
Hi all,
I'd be grateful for some help getting my server booting again. It's running debian jessie, with software RAID and LVM, running xen (or was). Yesterday one of the disks failed, so I ordered another, and, when it arrived today, removed the dead one from the array, put the new disk in, and.....landed at the grub rescue prompt.
So I booted up into a rescue disk, assembled the RAID, mounted the root on /mnt, and did a chroot.
Running install-grub on the disk (/dev/sdb) gave me this error: warning: your core.img is unusually large. It won't fit in the embedding area. error: embedding is not possible, but this is required for RAID and LVM install.
This seems to explain the message https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1059827
So I looked at the partition table. I have two partitions, /dev/sdb1 and /dev/sdb2. The latter is nearly 1TB, and is the root. Both are of type 'linux raid autodetect'. /dev/sdb1 started at 63, so I deleted this partition, created a new one as type linux raid autodetect, and it was automatically assigned the start of 2048.
Then I ran grub install again, calling the raid and ext2 and lvm modules, but now I keep getting the error grub-install: error: unknown filesystem
I'm not entirely sure what I'm actually doing here....been searching for help for hours. I found one page that suggested grub2 gets confused by a single disk in an array.
Here's the current partition table: Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 996029 993982 485.4M fd Linux raid autodetect /dev/sdb2 * 996030 1915060454 1914064425 912.7G fd Linux raid autodetect
/boot is part of the root on /dev/sdb2 rather than a separate lvm one.
I'm not entirely sure how it even managed to boot before, but I only had the /dev/sda2 and /dev/sdb2 in a raid array, so there must have been a subtle difference in /dev/sda that had allowed grub to install to it. Maybe grub was installed before I created the RAID array - I originally only had one disk in there?
Anyway, any suggestions very welcome. The trouble with a xen server being that all my eggs are in one proverbial basket.
Bit out of my depth with the rest, but my first thought was how broken is the broken disk? Is it worth looking at the partitions on it and working out what their sizes and contents were, then re-creating that on the new disk?
Good luck!
Steve
It's unreadable, unfortunately - input/ouput errors.
Thanks for the bug report link. I'm "grubbing" about trying to do this at the moment:
Another workaround is to setup a simple ext4 /boot partition rather than try to boot directly from raid or lvm or btrfs.
So I've made an ext 4 partition, and my drive now looks like this: Device Boot Start End Blocks Id System /dev/sdb1 2048 996029 496991 fd Linux raid autodetect /dev/sdb2 996030 1915060454 957032212+ fd Linux raid autodetect Partition 2 does not start on physical sector boundary. /dev/sdb3 * 1915060455 1919060639 2000092+ 83 Linux Partition 3 does not start on physical sector boundary.
So do I need to mount the new partition /dev/sdb3 somewhere in order to try and install grub to it? The end of 'mount' output from the ubuntu rescue instance is this: /dev/mapper/nutmeg-nutmeg_root on /mnt type ext3 (rw) /dev on /mnt/dev type none (rw,bind) /dev/pts on /mnt/dev/pts type none (rw,bind) /proc on /mnt/proc type none (rw,bind) /sys on /mnt/sys type none (rw,bind) /run on /mnt/run type none (rw,bind)
If I chroot back to my system in /mnt, /dev doesn't seem to know about a partition sdb3, but fdisk lists it. Even if it had shown up, I wouldn't quite know what to do - move /boot and mount it there before running grub?
So confused. It's almost time to reformat the entire disk and restore from the backups on the external hard drive.
Thanks,
Jenny