2.4.18 -> 2.6.8 yields ext3 errors?

[Michael ODonnell]

> I wonder whether there could have been an incompatible format change
> in, say, /etc/mtab.  If there's a stale copy from the earlier
> kernel, and the code in mount that reads it fails because of a
> format change, something higher up may not adequately distinguish
> that error from "already mounted".
>
> Did the appropriate package that includes mount get upgraded?


The systems in question are running Debian "testing"
and as far as I can tell there is no version dependence
on the admin apps (like mount) in question, and anyway
I have all the latest stuff, which runs just fine with
2.4.18 and, I assume, also with 2.6.8

BTW, I've seen different ways of handling /etc/mtab.
Sometimes /etc/mtab is a normal file that gets
{re,}written by mount and sometimes it's a symlink
to /proc/mounts.  And when 2.6.8 is running it
turns out that /proc/mounts is in turn a symlink to
self/mounts (and then self turns out to be a symlink
to /proc/[currentPID], but that's another story).

Meanwhile, I've learned a little more and it appears
that /etc/mtab is not the problem.  I grabbed source
codes and built my own "mount" and tracked it all the
way down to and back from the point where it's making
the "mount" syscall, verifying that it's passing the
right stuff down to the kernel, etc.  Everything looks
good, so it seems that it's the kernel that's unhappy
about my mount requests, because it's returning EBUSY,
for which I currently have no explanation.

The fact that my root is getting mounted OK means that
I have all the necessary EXT3 support present.  I can
rmdir and mkdir the mount point all I like and get no
EBUSY.  I can loopback mount other filesystems on that
mountpoint.  I can fdisk the device without error.
I can fsck.ext3 the partition 'til the cows come home.

(sigh) Life on the bleeding edge of FOSS.  Oh, well -
I guess I'll have to grab sources for this 2.6.8 kernel
and have a build/debug session, as if I had the time...