Re: extended partitions

Theodore Ts'o (tytso@mit.edu)
Mon, 2 Oct 1995 00:43:49 -0400


: Speaking of extended partitions:, has anybody else noticed that (raw)
: extended partitions have become inaccessible in the recent kernels?
: This makes it impossible to install lilo into the boot sector of an
: extended partition. Is this a bug or a feature?

Out of curiosity, what's the scenario where you'd want to install LILO
on the boot sector of the (raw) extended partition? Usually it's
installed on the MBR, or in the boot sector of the linux partition. I
recognize that you _can_ install it in the (raw) extended partition, but
why is that better than storing it in the boot sector of the Linux
partition?

In case it turns out that many people need this possibility
to install lilo, we may have to replace this simple statement
by more complicated code (or teach lilo how to use /dev/hda,
or teach the kernel how to handle partitions that end with a
fractional block).

Lilo can use /dev/hda, though.... that's what you use if you want to
install the boot blocks on the MBR. The question is whether it's worth
the effort to allow LILO to install in the (raw) extended partition,
while trying to prevent people from accidentally running mke2fs on the
raw partition.

If we really want to do allow it, we could just set the size of the raw
extended partition to be 2 sectors (1 block), and mke2fs won't be able
to make a partition on a partition that small. I'd probably punt on the
fractional block, though, since with the size of the extended partition
set that small, users won't be able to do any damage to themselves
accidentally.

By the way, in the 0.5c version of mke2fs (due to be released real soon,
when I have time to actually put the release together), there's special
case code to warn users who accidentally type "mke2fs /dev/hd{a,b,c,d}"
(it'll only work if you specify the -f) --- basically, I got tired of
helping users recover from a completely trashed filesystem. :-(

- Ted