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?
