Re: extended partitions
Robert Nichols (rnichols@interaccess.com)
Wed, 4 Oct 95 11:40 CDT
>From: Andries.Brouwer@cwi.nl
>Date: Wed, 4 Oct 1995 10:49:06 +0100
>: >It is this line in genhd.c:
>: >
>: > /* prevent someone doing mkfs or mkswap on
>: > an extended partition */
>: > hd->part[minor].nr_sects = 0;
>: >
>: >Since nothing else depends on it, you can take it out.
>: >But I think the advantages outweigh the disadvantages.
>
[SNIP]
>
>But LILO on the other hand already does study the partition tables -
>LILO is very much aware of these details - it has to convert
>"block 0 of /dev/hda4" into LBA and C/H/S addresses anyway.
>It would be a rather minor change.
>
>Anyway - there are many ways to solve this "problem" - but perhaps
>there is no problem.
>Reiterating: in my view it is very bad that writing to /dev/hda4
>can destroy /dev/hda5, and it is only slightly inconvenient that
>presently the number of ways to boot Linux has diminished a little.
>(There is the MBR, there is LOADLIN, there is fips to make a small
>Linux partition, etc. etc. And a small change in LILO will restore
>the original freedom.)
As long as Lilo can still be installed on the extended partition I'll be
satisfied. (If you were to force me to use LOADLIN, I'd have to draft
you to figure out why it doesn't work on my system. It claims to load
the kernel successfully, but the kernel just dies silently.)
BTW, if the Lilo installer is now responsible for reading the partition
table to figure out what "hda5" means, it will also have to cope with
possible alternate naming conventions that might have been used in
/dev. It is a bad idea to have the meaning "hda5" hard wired in the
code. (If you are going to cry, "But that's the standard name!" then
I must point out that standards change, and following that argument
leads to the conclusion that we don't need /dev at all -- just build
those names into the kernel and be done with it.)
Also, while you are considering changes to Lilo, how about preventing it
from being installed on the boot sector of an MSDOS file system? Quite
a few people get badly hurt by that mistake, too.
--
Bob Nichols rnichols@interaccess.com