Subject: Re: bad144, take two
To: Ken Hornstein <firstname.lastname@example.org>
From: Rafal Boni <email@example.com>
Date: 07/16/2001 23:04:38
In message <200107161923.f6GJNxM03208@ginger.cmf.nrl.navy.mil>, you write:
-> b) bad144(8) hasn't really changed much since the initial 386BSD import
-> back in 1993.
Heh. I recall fighting with bad144 on my first NetBSD machine or maybe
even before that in the 386BSD days. I did have DOS and BSD partitions
on the disk, but recall having to jump through some flaming partitioning
hoops (probably related to (c) below).
I'm surprised bad144 hasn't been killed off yet, but I see it also hasn't
made much forward progress.
-> c) On the i386, bad144(8) uses the end of the C partition, _not_ the D
-> partition ... but only if the first partition is offset from the
-> beginning of the disk by a non-zero amount (I guess that's the 32
-> sectors you leave as room for the MBR and disklabel). This comment
-> still has "wfj" on it, so I'm guessing that it's been that way for
-> quite a while :-)
-> I'm forced to conclude that this couldn't really have worked ... ever, at
-> least on the i386 if you've got a DOS and Unix partition on the same drive.
I think it's actually gotten harder to make it work, as my first installs
of NetBSD had the c/d partitions somehow munged to suit bad144. Now, I
bet the partition code is slightly smarter about enforcing the boundaries,
making it hard to get working.
-> Now, if there's a giant outcry, and people think that bad144 should die
-> a horrible death, then that's fine ... but I'd prefer that in _that_ case,
-> we should just remove the damn thing so people don't think that it actually
-> works and waste time with it.
The other thing I found horribly annoying is that bad144 has a pretty tiny
limit of sectors it allows you to remap... I found on the drives that needed
it, you almost always overflowed the table 8-<
Rafal Boni firstname.lastname@example.org