Re: Bug#56821: [POSSIBLE GRAVE SECURITY HOLD]
I do not wish to disturb the work for boot-floppies, so I cut the cc
to firstname.lastname@example.org. I left cc: to -devel list only to let people
know about the need for boot-managers in MBR.
In article <20000202170101.A5223@cosanostra.net>,
at Wed, 2 Feb 2000 17:01:01 -0500,
on Bug#56821: [POSSIBLE GRAVE SECURITY HOLD],
Elie Rosenblum <email@example.com> writes:
> On Wed, Feb 02, 2000 at 06:11:24PM +0100, Pierre Beyssac wrote:
> > I can't understand why everyone insists on keeping this MBR since
> > its "features" serve strictly _NO_ useful purpose other than
> > bypassing Lilo and BIOS security, so the argument that removing it
> > would impair the system's ease of use is totally flawed.
I am the maintainer of another "boot-manager" for i386.
So I personally do know the usefulness of the boot-manager in MBR.
As others repeatedly wrote, the LILO can not work without it's 2nd
loader and others (mapfiles, chain loaders, etc)
Now my system has three Debian in one disk. One for rescue system,
because this machine is the notebook and floppy drive is not included
in it. An external floppy drive is not handy to take with. Using this
rescue system, I can boot up this system without floppy in an emergency.
2nd system is the development system. I use this for development of
my packages and the work for boot-floppies, as well as for
the development of other free software projects.
3rd system is the main system. I use this for my daily work.
Usually, active partition is the 3rd system, and lilo's boot sector
is saved on it's PBR. I can setup lilo.conf to boot up other systems
via this partition and put the lilo's 1st boot loader in MBR, but
in such a setting, when this partition is corrupted or just overwrite
the lilo's 2nd loader or other required components by accident, then
I can not boot up from other (rescue/test) system. And more, to make
lilo use the kernels for other systems, I must mount their partitions.
Since that partitions is not required at all in order to use the main
system, it is very inconvenient. And if I update the kernel on my test
system, then I have to re-run the lilo on my main system to boot up
from that partition, while I don't change the kernel on my main system.
This is also irritating and inconvenient (I have experience to forget
to re-ren the lilo, and found that I can not boot up the test system
unless using the mbr's feature and the separate lilo installed in
the PBR on the test system).
Putting the main lilo into test or rescue system is not the solution.
So, using the boot-managers in MBR is useful and required thing for me.
I was an user of slacware, and it's default is to store the lilo's 1st
boot loader into the MBR. But I dislike it, and alternate the setting
to use the small and smart (just work in 446bytes) boot-manager locally.
So I like the Debian's choice of using "mbr", while I use other tool
(which is one of my package) in the MBR on my system.
I notice the existence of some boot-manager different than lilo as soon as
I used the installer, because it asked to "creating master boot record ?"
separately from the message to run the lilo.
You can claim your expectation, and I can claim my expectation too.
I think the best thing is just to update the documents, but I don't
claim the objection to the modification which is done recently by
boot-floppies team (disable the powerfull feature of "mbr"), because
I know what I have to do in order to fill the requirement for my system.
Maybe other users who know the merit of this mbr will notice the change
and will understand what they should do to make the system to match
their requirement, because they knows what the others do not know while
they use it everyday.
> I agree that there should be a warning, however, the mbr _does_ provide
> useful features, as outlined in the same documentation several people
> have obviously _NOT_ read:
> * Support for accessing large disks (>8G) has been added. This means
> that the active partition doesn't have to be within the first 8G for
> the MBR to load it's boot sector. The new code will be used on
> systems which support it.
> Also, the ability to boot other partitions and floppies _is_ useful,
> but not for everyone - you, for instance, don't want it. That should
> mean that before it is installed, you are warned and given a choice,
> but it does NOT mean that it should not be there, as the majority of
> users probably benefit more from the flexibility.
Documentation update and add the warning messages is the good compromise,
I think. I will work on this, if I can help this work. (Karl wrote on
-boot list that he already started the work for this. So I will start
to read his work).
Taketoshi Sano: <firstname.lastname@example.org>,<email@example.com>,<firstname.lastname@example.org>