On Tue, Jan 18, 2011 at 6:16 AM, John Robinson
<john.robinson@xxxxxxxxxxxxxxxx> wrote:
> Did you mean to copy your message to the list? If so please go ahead and
> I'll also copy this reply to the list.
Yes, I meant to - thanks!
> Anyway: I only have experience of grub 0.9x, which has no knowledge of md
> arrays. To boot from a md array using grub 0.9x, you have to make /boot a
> RAID-1 with metadata at the end of the array (so mdadm 0.90 or 1.0
> superblock), so that grub can read the bare partition as a filesystem
> without understanding that it's part of a md array. grub-install does know
> about these arrays though, and will write its stage1 boot code into the MBR
> and the stage1_5 filesystem code into the next few sectors of all the drives
> participating in the array, so that whichever one the BIOS boots from, grub
> can read that mirror of the /boot filesystem and load the chosen kernel and
> initrd.
I'm not so sure that grub2 or the corresponding grub-install is any
further ahead on that account. I'm using Ubuntu which moved to grub2 a
couple releases ago. I'm using it for this attempt and it seemed not
to be able to install grub on a RAID0 drive. I tried both during the
initial install and subsequently booting from a live CD (on USB.)
IAC, I'm working with a non-RAID /boot partition at the moment. If I
get this up and running, it's not so hard to mirror that partition to
other drives.
>
> This is of course a fudge, because the system will fail to boot if there are
> bad sectors on the first drive where anything necessary to boot lives, even
> though there are good copies on another drive. (I've actually had this
> happen to me. I just told the BIOS to boot from the second drive until I
> could swap the faulty first drive.) This fudge is part of the reason for
> software RAID BIOSes and new grub.
I pretty much accept that. I think the only situation presently where
the raid would boot from a (second) RAID1 drive w/out intervention is
if the first drive failed in a way that it completely disappeared form
the system. I doubt that's a common situation.
>
> I understand that new grub does know how to read from md arrays, so
> potentially allowing booting from filesystems striped over several devices
> e.g. RAID-0 and RAID-5 as well as handling RAID-1 mirrors rather better, and
> it moves the fudge factor to just the few sectors grub itself needs and
> means it can cope with the kernel and initrd images having bad sectors in
> them (for RAID-1 and RAID-5). Software RAID BIOSes and hardware RAID cards
> avoid the fudge factor altogether.
Progress is good! :)
Wish I had made more. :(
>
> It looks like you're using new grub, which I don't have any experience of,
> so I'm afraid can't help with it, though I don't suppose it's all that
> different except that it must have another stage between the MBR boot code
> and the filesystem code.
Yes. And I may be battling a couple different problems. The testing I
described in the previous email was actually on another system (Eee PC
901) as it was simply more convenient. After I sent the email out I
tried the same USB sticks in the target system and found it fell far
short of the limited success I had with the Eee. I'm not sure it's
even loading the bootloader from the MBR. (Does that put anything on
the screen?) I can boot the Ubuntu install USB on that system so I
know it's capable of booting form a USB flash drive. But the install
USB sticks may be using some sort of emulation of the El Torrito
mechanism used to boot from CD.
Thanks again for your continuing help.
(Ordinarily I would trim quoted material from previous messages, but
I'll leave it intact since I forgot to CC the list with that.)
best,
hank
>
> On 17/01/2011 14:38, Hank Barta wrote:
>>
>> On Sat, Jan 15, 2011 at 2:54 PM, John Robinson
>> <john.robinson@xxxxxxxxxxxxxxxx> wrote:
>>>
>>> I'm sorry I wasn't clearer.
>>
>> No worries - you were clear enough. Lack of comprehension was my fault.
>>
>>>
>>> You will also need to make sure your initrd or initramfs includes the USB
>>> drivers if it doesn't do that automatically, as well as the usb-storage,
>>> scsi and md modules for your root filesystem, and just to be sure I'd
>>> include raid1.ko so it can potentially start /boot as well.
>>
>> I'm working through what I believe may be grub issues on this. At
>> present I'm working with three USB sticks. I've mounted them on my
>> main laptop, started the RAID and then tweaked the GRUB configurations
>> to put the menu up and add some boot options. I wanted to see the menu
>> to try to determine just how far GRUB was getting. The boot options
>> are from one of the pages I referenced earlier:
>> kopt=usb-storage.delay_use=1 rootfstype=ext4 rootflags=data=writeback
>>
>> (I have also tried it w/out "rootflags=data=writeback")
>>
>> The result is some progress during boot. Grub comes up and I get the
>> menu. When I select the preferred boot option, I can see it access the
>> boot stick for a couple seconds. Then there is no visible activity
>> followed by access of all three sticks. After that, there is an error
>> message:
>>
>> mount: mounting /dev/md1 on /root failed: invalid argument
>>
>> This is followed by three errors indicating that /dev, /sys and /proc
>> cannot be mounted due to "No such file or directory." After that an
>> error that init cannot be found (of course since root is not mounted.)
>>
>> At this point the console is dumped into BusyBox with the prompt
>> "(initramfs)" so it seems to me the problem is inability to mount the
>> raid.
>>
>> At this point I can 'cat /dev/mdstat' and the raid appears active. But
>> attempts to mount it fail with the same "Invalid argument" error.
>>
>> The 'blkid' command identifies the USB boot partition and the three
>> RAID partitions but does not find /dev/md1.
>>
>> there are no logs, but dmesg ends with the md messages:
>> [...] md1: detected capacity change from 0 to 12027691008
>> [...] md1: p1 p2
>> (There are a bunch of normal looking raid0 messages preceding this.)
>>
>> The menu entry I'm trying to boot from /boot/grub.cfg is:
>> menuentry 'Ubuntu, with Linux 2.6.32-24-generic-pae' --class ubuntu
>> --class gnu-linux --class gnu --class os {
>> recordfail
>> insmod ext2
>> set root='(hd1,1)'
>> search --no-floppy --fs-uuid --set
>> 8db30d89-6a2b-4d41-842d-3bb8d24e14b8
>> linux /vmlinuz-2.6.32-24-generic-pae root=/dev/md1 ro
>> kopt=usb-storage.delay_use=1 rootfstype=ext4 quiet
>> initrd /initrd.img-2.6.32-24-generic-pae
>> }
>>
>> So it seems that the initramfs loads and the raid gets started, but it
>> cannot mount the root fs on /dev/md1.
>>
>>>
>>> I may be being over-cautious with some of what I say above, but hopefully
>>> I've covered all the possibilities even if some are overkill, and your
>>> installer is likely getting more right than I'm giving it credit for.
>>
>> I did find some reports of nasty bugs regarding the installer getting
>> things very wrong, but I think those issues have been fixed.
>>
>>> Anyway, once again, good luck!
--
'03 BMW F650CS - hers
'98 Dakar K12RS - "BABY K" grew up.
'93 R100R w/ Velorex 700 (MBD starts...)
'95 Miata - "OUR LC"
polish visor: apply squashed bugs, rinse, repeat
Beautiful Sunny Winfield, Illinois
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
