On Sunday 19 Aug 2007, Duncan wrote:
Peter Humphrey [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Sun, 19 Aug
2007 11:34:56 +0100:
This box now has a slightly odd arrangement of disks. It has two new
SATA disks on the first two SATA interfaces, another SATA disk on the
third SATA interface, and it also has the original IDE disk for the odd
occasion when I want to run Windows.
The two new disks have been set up with LVM2 and contain my usual Gentoo
system. I followed the Gentoo LVM quick-install guide and created
/dev/md1 for my boot partition, putting the logical volumes into
/dev/md3. I can't boot via /dev/md1.
Four things:
Number one, if you are using md/RAID, you failed to mention it,
I did not fail. I gave sufficient information, as what follows confirms:
which makes it confusing since you mention md device names. If you aren't
using md/RAID, why are you using md/RAID device names? I mean, you can if
you wish, since it's really the device numbers that make the difference, but
it's going to forever be confusing everyone, likely including yourself at
times.
From which anyone can see the only plausible conclusion: that I am indeed
using RAID.
Number two, if you ARE using md/RAID, ensure /boot is on RAID-1 or a plain
disk partition,
It is on RAID-1.
since GRUB doesn't really understand RAID at all and can only handle RAID-1
because it's mirrored, and GRUB happens to be able to get to one single
disk's copy of the boot system on one disk of the mirror.
Except that on my box it can't (but see below). That's what I'm asking about.
# fdisk -l /dev/sda
[...]
/dev/sda1 1 8 64228+ fd Linux raid autodetect
/dev/sda2 9 252 1959930 82 Linux swap / Solaris
/dev/sda3 253268519543072+ fd Linux raid autodetect
/dev/sda42686 18241 124953570 fd Linux raid autodetect
/dev/sdb is exactly the same. /dev/md1 is RAID-1, made up of /dev/sd[ab]
1; /dev/md3 is RAID-1, made up of /dev/sd[ab]3; and /dev/md4 is RAID-1, made
up of /dev/sd[ab]4. Grub is installed in the MBR of the disk.
/dev/sdc is an older Gentoo installation:
# fdisk -l /dev/sdc
[...]
/dev/sdc1 1 9 72261 83 Linux
/dev/sdc2 10 259 2008125 82 Linux swap / Solaris
/dev/sdc3 260269219543072+ 83 Linux
/dev/sdc42693 24792 1775182505 Extended
/dev/sdc52693439513679316 83 Linux
/dev/sdc64396828631254426 83 Linux
/dev/sdc782879016 5863693+ 83 Linux
/dev/sdc89017 1388039070048+ 83 Linux
/dev/sdc9 13881 1752829302528+ 83 Linux
/dev/sdc10 17529 1996119543041 83 Linux
/dev/sdc11 19962 20205 1959898+ 83 Linux
/dev/sdc1 is the /boot partition of that older system, /dev/sdc3 is its root
and so on. Grub is installed in the MBR of the disk.
Perhaps I could have made it clearer that /boot is on /dev/md1, / is
on /dev/md3, and everything else is managed by LVM in five logical volumes in
one volume group on /dev/md4. I didn't create a /dev/md2 but left /dev/sd[ab]
2 for swap. I can't see however how supplying all these extra details helps
to diagnose a problem that occurs before they become relevant.
The problem seems to be either that the BIOS can't find grub's executable code
in the MBR of the first SATA disk, or that grub does start but can't find its
configuration data on /dev/md1, which of course is the first primary
partition* on each of the disks and the same size on both. From the time
spent in searching, I infer that the same failure occurs on the second disk.
Eventually the third one is found and grub runs as it should.
Perhaps the failure is the first of those: not finding grub in the MBR.
Otherwise, if grub did start and not find its data, I suppose it would just
stop, not return control to the BIOS. I'd have to dig in the code to find
this out, and I'm no C coder (I used to find assembly languages easier, and
that was a long time ago too).
* The disks are identical, physically and logically. I created all the
partitions in fdisk as primary partitions, then set their type to 0xfd (not
the swap, of course), but I assume they still count as primary partitions.
Perhaps that's too large an assumption.
--
Rgds
Peter.
Linux Counter 5290, Aug 93
--
[EMAIL PROTECTED] mailing list