bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH (updated): 'lilo -R' functionality


From: Paul Hedderly
Subject: Re: PATCH (updated): 'lilo -R' functionality
Date: Tue, 17 Dec 2002 09:21:09 +0000
User-agent: Mutt/1.3.28i

On Wed, Dec 11, 2002 at 03:05:44AM +0900, Yoshinori K. Okuji wrote:
> 
> Sorry, I don't like this, either. Perhaps I should have made it clear
> why I don't like it.

I actually think it's the cleanest solution around...

> The reason is that it always modifies the boot image directly. This is
> dangerous, especially on a running OS, because the OS may relocate the

I depends how much of the boot image has to be modified. If there is a
small section that it the only bit that is written, and only holds
non-critical booting 'hints' then it should be very safe.

> data of the image in a disk physically. Also, this is not desirable,
> if using a flash memory, because the same sector is rewritten
> frequently, so it is deteriorated very soon.

For flash memory agreed this is not desirable (except maybe on CF which
does its own wear levelling.) So you make it clear that these optional
extras (savedefault and nextbootonly) should not be used on primitave
flash.

> Another way is to use a file on a disk as a substitute for
> NVRAM. Although GRUB doesn't support writing files, GRUB can write
> data into disks. If my understanding is correct, it is safe for GRUB
> to modify the contents of a file, as long as the size of the file
> doesn't change.

This will totally screw up a raid1 image!

And how is this safer than writing to the boot partition? Unless the
nvram.dat file moves every now and again you get the same flash
problem. And you have to deal with all the filesystem checks... for
every type of filesystem.

When GRUB is in use, the whole of the boot sector belongs to it. So
making use of that space by grub is easy. And tweaking options in
designated areas of that space is similarly easy for grub tools.

Messing with filesystems gets much much harder to do safely.

> I don't know if this idea is really nice, because this can be
> error-prone (consider how many error checks would be required...).

Exactly.

In my mind the _only_ clean and portable way to do these things is in
the bootsector.

--
Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]