[tlug] Weirdness with dual-boot NetBSD & linux partitioning

["Stephen J. Turnbull" <stephen@example.com>]

[tlug is eating random posts, including the original copy of this one,
with no warning again, nothing except a successful delivery shown in
my logs; anybody else seeing this?]

I've got a machine currently partitioned like

/dev/hda1    4GB  Windows
/dev/hda2    4GB  NetBSD
  a        256MB    /
  b        256MB    swap
  e        3.5GB    /usr
/dev/hda3  100MB  Debian /
/dev/hda4  <extended>
/dev/hda5  256MB  Debian swap
/dev/hda6    2GB  Debian /usr
/dev/hda7  200MB  Debian /var
/dev/hda8    1GB  Debian /home

Linux 2.2.19 (vanilla source, homebrew .config) and 2.4.17 (Debian
686-optimized .config) happily hook up the NetBSD partitions a, b, e
to /dev/hda9, /dev/hda10, and /dev/hda11, respectively, mounted as
ufs.

Now, under 2.4.17, I wanted to add a new partition (about 8GB free
space left) to use for Coda.  Fired up fdisk, and it only saw
partitions up to 8.  I tried creating /dev/hda9, no warnings.  But
being of a suspicious frame of mind, I didn't save.  Try cfdisk, same
result, so OK, we just don't look inside /dev/hda2.  So I thought, and
saved.  (No data except zsh history in NetBSD-land that wasn't going
to get overwritten when I next update NetBSD anyway.)

But ... now I can't boot NetBSD, and 2.4.17 will not mount the NetBSD
partitions, although 2.2.19 will.  And just to confuse matters, I
remembered sfdisk, which not only sees the NetBSD partitions, but
proceeds to label them 5, 6, and 7 under 2.2, but 10, 11, 12 under
2.4.  And both kernels recognize them in the partition check (as 10,
11, 12).

Of course, /dev/hda9 is recognized as a separate Linux partition.

Anybody can offer a clue about what's going on here?

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.