Grub vs Lilo

Grub vs Lilo

[Lewis Shobbrook]

Hi All,

Wondering if anyone can comment on an easy way to get grub to update all 
components in a raid1 array.  I have a raid1 /boot with a raid10 /root and 
have previously used lilo with the raid-extra-boot option to install to boot 
sectors of all component devices.  With grub it appears that you can only 
update non default devices via the command line.  I like the ability to be 
able to type lilo and have all updated in one hit.  Is there a way to do this 
with grub?  

Cheers,

Lewis

Re: Grub vs Lilo

[Michael Tokarev]

Lewis Shobbrook wrote:
> Hi All,
> 
> Wondering if anyone can comment on an easy way to get grub to update all 
> components in a raid1 array.  I have a raid1 /boot with a raid10 /root and 
> have previously used lilo with the raid-extra-boot option to install to boot 
> sectors of all component devices.  With grub it appears that you can only 
> update non default devices via the command line.  I like the ability to be 
> able to type lilo and have all updated in one hit.  Is there a way to do this 
> with grub?  

You only need to update stuff for grub once - when installing it.
And during installation, it's ok to run it multiple times, once for
each component device - not a big deal really.  Just like you will
partition your disks and install an MBR - once for each disk.

After installation, grub does not need to modify boot records - only
/boot/grub/menu.lst (whatever) file is updated to reflect your kernels,
and this is a normal file (grub will find it by its own, by properly
reading the filesystem).

/mjt

Re: Grub vs Lilo

[Jason Lunz]

mylists@blue-matrix.org said:
> Wondering if anyone can comment on an easy way to get grub to update
> all components in a raid1 array.  I have a raid1 /boot with a raid10
> /root and have previously used lilo with the raid-extra-boot option to
> install to boot sectors of all component devices.  With grub it
> appears that you can only update non default devices via the command
> line.  I like the ability to be able to type lilo and have all updated
> in one hit.  Is there a way to do this with grub?  

assuming your /boot is made of hda1 and hdc1:

grub-install /dev/hda1
grub-install /dev/hdc1

Jason

Re: Grub vs Lilo

[Michael Tokarev]

Jason Lunz wrote:
> mylists@blue-matrix.org said:
>> Wondering if anyone can comment on an easy way to get grub to update
>> all components in a raid1 array.  I have a raid1 /boot with a raid10
>> /root and have previously used lilo with the raid-extra-boot option to
>> install to boot sectors of all component devices.  With grub it
>> appears that you can only update non default devices via the command
>> line.  I like the ability to be able to type lilo and have all updated
>> in one hit.  Is there a way to do this with grub?  
> 
> assuming your /boot is made of hda1 and hdc1:
> 
> grub-install /dev/hda1
> grub-install /dev/hdc1

Don't do that.
Because if your hda dies, and you will try to boot off hdc instead (which
will be hda in this case), grub will try to read hdc which is gone, and
will fail.

Most of the time (unless the bootloader is really smart and understands
mirroring in full - lilo and grub does not) you want to have THE SAME
boot code on both (or more, in case of 3 or 4 disks mirrors) your disks,
including bios disk codes.  after the above two commands, grub will write
code to boot from disk 0x80 to hda, and from disk 0x81 (or 0x82) to hdc.
So when your hdc becomes hda, it will not boot.

In order to solve this all, you have to write diskmap file and run grub-install
twice.  Both times, diskmap should list 0x80 for the device to which you're
installing grub.

I don't remember the syntax of the diskmap file (or even if it's really
called 'diskmap'), but assuming hda and hdc notation, I mean the following:

  echo /dev/hda 0x80 > /boot/grub/diskmap
  grub-install /dev/hda1

  echo /dev/hdc 0x80 > /boot/grub/diskmap # overwrite it!
  grub-install /dev/hdc1

The thing with all this "my RAID devices works, it is really simple!" thing is:
for too many people it indeed works, so they think it's good and correct way.
But it works up to the actual failure, which, in most setups, isn't tested.
But once something failed, umm...  Jason, try to remove your hda (pretend it
is failed) and boot off hdc to see what I mean ;)  (Well yes, rescue disk will
help in that case... hopefully.  But not RAID, which, when installed properly,
will really make disk failure transparent).

/mjt

Re: Grub vs Lilo

[Bernd Rieke]

Michael Tokarev wrote on 26.07.2006 20:00:
....
....
 >The thing with all this "my RAID devices works, it is really simple!" 
thing is:
 >for too many people it indeed works, so they think it's good and 
correct way.
 >But it works up to the actual failure, which, in most setups, isn't 
tested.
 >But once something failed, umm... Jason, try to remove your hda 
(pretend it
 >is failed) and boot off hdc to see what I mean ;) (Well yes, rescue 
disk will
 >help in that case... hopefully. But not RAID, which, when installed 
properly,
 >will really make disk failure transparent).
 >/mjt

Yes Michael, your right. We use a simple RAID1 config with swap and  / on
three SCSI-disks (2 working, one hot-spare) on SuSE 9.3 systems. We had to
use lilo to handle the boot off of any of the two (three) disks. But we had
problems over problems until lilo 22.7 came up. With this version of lilo
we can pull off any disk in any scenario. The box boots in any case.

We were wondering when we asked the groups while in trouble with lilo
before 22.7 not having any response. Ok, the RAID-Driver and the kernel
worked fine while resyncing the spare in case of a disk failure (thanks to
Neil Brown for that). But if a box had to be rebooted with a failed disk
the situation became worse. And you have to reboot because hotplug still
doesn't work. But nobody seems to care abou or nobody apart of us has
these problems  ...

We tested the setup again and again until we find a stable setup which works
in _any_ case. Ok, we're still missing hotpluging (seems to be solved 
for aic79
in 2.6.17, we're testing). But when we tried to discuss these problems 
(one half
of the raid-devices go offline on that controle where hotplugging 
occurs) there
was no response, too.

So we came to the conclusion that everybody is working on RAID but nobody
cares about the things around, just as you mentioned, thanks for that.

Bernd Rieke

Re: Grub vs Lilo

[Michael Tokarev]

Bernd Rieke wrote:
> Michael Tokarev wrote on 26.07.2006 20:00:
> .....
> .....
>>The thing with all this "my RAID devices works, it is really simple!" thing is:
>>for too many people it indeed works, so they think it's good and correct way.
>>But it works up to the actual failure, which, in most setups, isn't tested.
>>But once something failed, umm... Jason, try to remove your hda (pretend it
>>is failed) and boot off hdc to see what I mean ;) (Well yes, rescue disk will
>>help in that case... hopefully. But not RAID, which, when installed properly,
>>will really make disk failure transparent).
>>/mjt
> 
> Yes Michael, your right. We use a simple RAID1 config with swap and  / on
> three SCSI-disks (2 working, one hot-spare) on SuSE 9.3 systems. We had to
> use lilo to handle the boot off of any of the two (three) disks. But we had
> problems over problems until lilo 22.7 came up. With this version of lilo
> we can pull off any disk in any scenario. The box boots in any case.

Well, alot of systems here works on root-on-raid1 with lilo-2.2.4 (Debian
package), and grub.  By "works" I mean they really works, ie, any disk
failure don't prevent the system from working and (re)booting flawlessly
(provided the disk is really dead, as opposed to when it is present but
fails to read (some) data - in which case the only way is either to remove
it physically or to choose another boot device in BIOS.  But that's
entirely different story, about (non-existed) "really smart" boot loader
I mentioned in my previous email).

The trick is to set the system up "properly".  Simple/obvious way
(installing grub to hda1 and hdc1) don't work when you remove hda, but
"complex" way works.

More, I'd not let LILO to do more guesswork for me (like raid-extra-boot
stuff, or whatever comes with 22.7 - to be honest, I didn't look at it
at all, as debian package of 2.2.4 (or 22.4?) works for me just fine).
Just write the damn thing into the start of mdN (and let raid code to
replicate it to all drives, regardless of how many of them there is),
after realizing it's really a partition number X (with offset Y) on a
real disk, and use bios code 0x80 for all disk access.  That's all.
The rest - like ensuring all the (boot) partitions are at the same
place on every disk, that disk geometry is the same etc - is my duty,
and this duty is done by me accurately - because I want the disks to
be interchangeable.

> We were wondering when we asked the groups while in trouble with lilo
> before 22.7 not having any response. Ok, the RAID-Driver and the kernel
> worked fine while resyncing the spare in case of a disk failure (thanks to
> Neil Brown for that). But if a box had to be rebooted with a failed disk
> the situation became worse. And you have to reboot because hotplug still
> doesn't work. But nobody seems to care abou or nobody apart of us has
> these problems  ...

Just curious - when/where you asked?
[]
> So we came to the conclusion that everybody is working on RAID but nobody
> cares about the things around, just as you mentioned, thanks for that.

I tend to disagree.  My statement above refers to "simple advise" sometimes
given here and elsewhere, "do this and that, it worked for me".  By users
who didn't do their homework, who never tested the stuff, who, sometimes,
just has no idea as of HOW to test (it's not an insulting statement
hopefully - I don't blame them for their lack of knowlege, it's something
which isn't really cheap, after all).  Majority of users are of this sort,
and they follow each other's advises, again, without testing.  HOWTOs
written by such users, as well (as someone mentioned to me in private
email as a response to my reply).

I mean, the existing software works.  It really works.  The only thing left
is to set it up correctly.

And please PLEASE don't treat it all as blames to "bad" users.  It's not.
I learned this stuff the hard way too.  After having unbootable remote
machines after a disk failure, when everything seemed to be ok.  After
screwing up systems using famous "linux raid autodetect" stuff everyone
loves, when, after replacing a failed disk to another, which -- bad me --
was a part of another raid array on another system, and the box choosen
to assemble THAT raid array instead of this box's one, and overwritten
good disk with data from new disk which was in a testing machine.  And
so on.  That all to say: it's easy to make a mistake, and treating the
resulting setup as a good one, until shit start happening.  But shit
happens very rarely, compared to "average system usage", so you may never
know at all that your setup is wrong, and ofcourse you will tell how
to do things to others... :)

/mjt

Grub vs Lilo

[Lewis Shobbrook]

Hi All,

Wondering if anyone can comment on an easy way to get grub to update all 
components in a raid1 array.  I have a raid1 /boot with a raid10 /root and 
have previously used lilo with the raid-extra-boot option to install to boot 
sectors of all component devices.  With grub it appears that you can only 
update non default devices via the command line.  I like the ability to be 
able to type lilo and have all updated in one hit.  Is there a way to do this 
with grub?  

Cheers,

Lewis

Re: Grub vs Lilo

[Simen Thoresen]

Lewis Shobbrook wrote:
> Hi All,
> 
> Wondering if anyone can comment on an easy way to get grub to update all 
> components in a raid1 array.  I have a raid1 /boot with a raid10 /root and 
> have previously used lilo with the raid-extra-boot option to install to boot 
> sectors of all component devices.  With grub it appears that you can only 
> update non default devices via the command line.  I like the ability to be 
> able to type lilo and have all updated in one hit.  Is there a way to do this 
> with grub?  

Hi All,

I'll second this RFI - I /think/ I know how to set this up by hand (I'm 
following the doc on 
http://www.ex-parrot.com/~pete/software-raid-howto.html
, and have tested booting from each drive from this), but this is 
neither very simple, nor automatically applied to a new disk when it is 
hot-added. Thus the procedure will need to be executed each time a drive 
is replaced.

Perhaps a GRUB-forum is a better venue for this discussion?

-S


> Cheers,
> 
> Lewis
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Simen Thoresen, Dolphin ICS
Systems Administration and Wulfkit Support

GRUB vs LILO

[Trevor Woolven]

Does anyone know if GRUB has an in-built limit to the size of DOC you
can use it with?

I've got a 4MB DOC2000 and a 24MB DOC2000, both with very similar
filesystems & kernels on. I can boot my system (from hard-disk or DOC)
using LILO (with Dvir Oren's patch applied) with either device installed
but GRUB will only allow me to use the smaller one.

My command line is:
grub> kernel (hd0,0)/mtd/bzImage root=/dev/hda5

and I get:

  [Linux-bzImage, setup=0x800, size=0x88440]

Selected item cannot fit into memory

Any help much appreciated.

Thanks

Trevor.
-- 
Trevor Woolven - Director of Customer Applications Engineering
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647	 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: GRUB vs LILO

[David Woodhouse]

trevw@zentropix.com said:
> 
>   [Linux-bzImage, setup=0x800, size=0x88440]
> Selected item cannot fit into memory 

This is because the M-Systems firmware takes up a large chunk of your system 
RAM for caching block attributes - this is proportional to the size of the 
DiskOnChip, naturally.

The code I'm currently hacking into Grub will drive the DiskOnChip directly, so
you can remove the M-Systems firmware. My Grub code doesn't do any caching - so
it'll be a tad slower, but it'll work on bigger devices. 



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: GRUB vs LILO

[Dvir Oren]

David Woodhouse writes ("Re: GRUB vs LILO "):
> This is because the M-Systems firmware takes up a large chunk of your system 
> RAM for caching block attributes - this is proportional to the size of the 
> DiskOnChip, naturally.

Does Grub already work?

-- 
Dvir Oren               <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: GRUB vs LILO

[David Woodhouse]

dvir@hotpop.net said:
>  Does Grub already work? 

Not yet. It detects the DiskOnChip hardware, and scans it until it finds an 
NFTL Media Header. I haven't coded any more than that yet.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org