Re: Re Molle and Carl-Daniel, some last words

[Molle Bestefich]

Gerte Hoogewerf wrote:
>> need to know: You can install GRUB just fine IFF you boot
>> from a GRUB boot floppy. NEVER (except for trivial configurations)
>> use the GRUB shell running under any operating system.
>
> Saying that (meaning: "IFF") would mean we would never be able to
> install Linux using an installer. That's not true, so don't say it.

Hm, you're right.
The patch is good if you want a Linux installer to be able to install
on device-mapped devices.

Gerte, do you have the time to check that the patch is "clean" (I
think it is), and perhaps vote +1 over on bug-grub for getting it
included in GRUB?


> (hd0,x) must be on (hd0) (duh!)

Well, as mentioned before, even though it's real simple, the GRUB
stage2 simulator seems to screw it up.  I'll see if I can fix that bug
another day.


> I agree that installing grub is don't most safely when running the GRUB
> shell in real-mode.

I think that dmraid should protect the HPT metadata blocks :-).


>> and it destroyed my RAID0.
>> GRUB is such a piece of crap :-).
> GRUB is not a piece of crap. It's very very sensible when running it on
> "unknown" things like the device-mapper stuff.

Right, sorry, just got a little worked up because it borked my RAID array again.


> My experience is, you should always specify a (correct or in this case
> empty) device-map when running grub:
> /sbin/grub --device-map=/dev/null

Yes.  It seems, well, a bit dumb that the default in GRUB is to take a
wild guess, assuming that's what it does if you don't tell it to relax
and smoke a null file?

> Remember always to specify partitions (like: (hd0,x)) with with the grub
> "device" command first and to specify the disk (like: (hd0)) in the last
> place!!

Order shouldn't matter, that's a bug in GRUB as I see it.
At least if we want GRUB to be user friendly.

> And don't ever blame me of installing bootloaders into (hd0,5),
> I never recommend people to do this.

I'll just quote your web site,
http://tienstra4.flatnet.tudelft.nl/~gerte/gen2dmraid/.
=== Installing grub on a /boot partition:
# That's it, the rest should be easy:
[...]
grub> setup (hd0,0)
===
Humn :-).
(It isn't *exactly* (hd0,5), but isn't (hd0,0) equivalent?  or?)


I'll just take the opportunity to thank you very much for the effort
you put into helping others by making the gen2dmraid ISO images and
the nice guides on your web site available.  They are a great help,
thanks!

That said, could you perhaps share with us the LILO patch you use to
make LILO work with device-mapped devices?  Your site only mentions
that it "needs to be patched", no link to the patch.  Also, feel free
to include my patch, it could be helpful for others wanting GRUB to
work with dmraid from eg. inside the livecd or any booted Linux :-).


> My last words on bootloaders and device-mapper stuff:
> * I'm too busy to fix Saout's patch for Lilo to include straight
> mappings.

I took a quick look, but can't figure out what's needed.
Care to explain real quick?


> * To make grub more dmraid-friendly, device-map code (asigning realmode
> names to /dev names) {c,sh}ould be improved a tiny little bit.

Or just dropping the feature, seeing as there's no reasonably sane way
to implement it for the foreseeable future.  Rather let the user know
that he has to tell us, than to make some wild guess that's correct "a
lot of the time" and turns your data into bitsoup the other half.


> It could be an idea to make it less important in which order device commands 
> are
> given on the Grub shell.

Paramount to user friendliness, if you ask me.

Further, I think that the device (hdx,y) command should just be
disallowed - as you said, (hdx,y) always resides on (hdx)!  Entering
just device (hdx) instead of both (as seen in your example), works for
me, so perhaps it's time to modify the example and remove the "device
(hd0,0) /dev/blah" line?


> * To make dmraid more accepted in the Linux world, we have to find a
> generic way of (re-)reading partitiontables and giving names to devices
> that might be 'something bootable'.

I seem to remember fdisk spewing out "Calling ioctl() to re-read
partition tables" when you do part modifications under Linux.  What's
wrong with doing the same with device-mapped devices?  Just tell the
kernel to re-read partition tables?