root filesystem type is unknown

[WW]

My root partition is reiserfs, but mount says

/dev/hda2 on / type unknown (rw)

As far as I can tell, my system is running fine.
Zibby on the IRC said

Zibby: WW: my guess is the version of mount doesn't recognize riserfs for some
reason...but sounds like your ok.

More info:
 $ mount -V
mount: mount-2.12

The Ubuntu mount package that I have installed is version 2.12-7ubuntu6.

[Matt Zimmerman (mdz)]

This is a cosmetic issue; everything is working fine, and there is no cause for
concern. (adjusting severity appropriately) This is reproducible on all of my
Ubuntu systems.
My guess is that this has something to do with the way that the root device is
mounted from the initrd. checkroot.sh creates the mtab entry with:

mount -f -o $rootopts $fstabroot /

which seems to result in type "unknown".

[Matt Rickard (rickardm)]

Yep, seems to be a problem with debian's checkroot.sh. The following one-liner
patch fixes it:

--- checkroot.sh.orig 2004-09-28 19:56:29.000000000 -0400
+++ checkroot.sh 2004-09-28 19:57:03.000000000 -0400
@@ -295,7 +295,7 @@

 if [ "$init_mtab" = yes ]
 then
- [ "$roottype" != none ] && mount -f -o $rootopts $fstabroot /
+ [ "$roottype" != none ] && mount -f -o $rootopts -t $roottype $fstabroot /
        [ -n "$devfs" ] && mount -f $devfs
        . /etc/init.d/mountvirtfs
 fi

[Matt Zimmerman (mdz)]

(In reply to comment #2)
> - [ "$roottype" != none ] && mount -f -o $rootopts $fstabroot /
> + [ "$roottype" != none ] && mount -f -o $rootopts -t $roottype $fstabroot /

I thought about that, but it seems that $roottype actually comes from
/etc/fstab, and won't _necessarily_ match the real type which was mounted in the
initrd.
As confusing as "unknown" is, I think it would be more confusing for it to say
"ext3" when the root filesystem is actually reiserfs. :-)

[Matt Zimmerman (mdz)]

*** Bug 8379 has been marked as a duplicate of this bug. ***

[Matt Rickard (rickardm)]

If a user's root filesystem type in fstab doesn't match his real root filesystem
type, I'd say he is confused already. :-) In that case, I think it makes more
sense to show the correct filesystem type for the >99% of users without a broken
fstab.

That being said, I'm sure there's a way we can make this correctly identify the
filesystem regardless of a broken fstab. I'm just not quite sure what that way
is at the moment...

[Matt Zimmerman (mdz)]

I think the correct solution involves either passing more information over from
the initrd, or looking at the "/dev2/root2" mount:

mizar:[/tmp] grep -w / /proc/mounts
rootfs / rootfs rw 0 0
/dev2/root2 / ext3 rw 0 0
/dev2/root2 /.dev ext3 rw 0 0

/dev2/root2 seems to have the correct type. I do not know why there is more
than one such entry in /proc/mounts. /dev2/root2 is something done by the
initrd; I am not sure why it uses that naming scheme

[Matt Rickard (rickardm)]

Would something like this solve the problem (taken from the Slackware init scripts)?

--- /etc/init.d/checkroot.sh.orig 2004-09-28 19:56:29.000000000 -0400
+++ /etc/init.d/checkroot.sh 2004-09-29 02:54:05.688635088 -0400
@@ -296,6 +296,9 @@
 if [ "$init_mtab" = yes ]
 then
        [ "$roottype" != none ] && mount -f -o $rootopts $fstabroot /
+ # /etc/mtab is old here so we delete it and create a new one.
+ rm -f /etc/mtab*
+ mount -w -o remount /
        [ -n "$devfs" ] && mount -f $devfs
        . /etc/init.d/mountvirtfs
 fi

[Matt Zimmerman (mdz)]

(In reply to comment #7)
> Would something like this solve the problem (taken from the Slackware init
scripts)?
>
> --- /etc/init.d/checkroot.sh.orig 2004-09-28 19:56:29.000000000 -0400
> +++ /etc/init.d/checkroot.sh 2004-09-29 02:54:05.688635088 -0400
> @@ -296,6 +296,9 @@
> if [ "$init_mtab" = yes ]
> then
> [ "$roottype" != none ] && mount -f -o $rootopts $fstabroot /
> + # /etc/mtab is old here so we delete it and create a new one.
> + rm -f /etc/mtab*
> + mount -w -o remount /

I don't think it would; the 'mount -f' command is the right way to do it, and if
the earlier mount command couldn't determine the root filesystem type correctly,
I don't think the later one would either. Does it help for you?

[Matt Rickard (rickardm)]

On my system that change does make my filesystem type appear correctly.

[Scott James Remnant (Canonical) (canonical-scott)]

*** Bug 8733 has been marked as a duplicate of this bug. ***

[Scott James Remnant (Canonical) (canonical-scott)]

This is actually a major bug, because it stops laptop-mode from even working
(your hd simply won't sleep, at least on XFS).

[Matt Zimmerman (mdz)]

(In reply to comment #11)
> This is actually a major bug, because it stops laptop-mode from even working
> (your hd simply won't sleep, at least on XFS).

Huh? laptop-mode is a kernel thing, and the kernel knows exactly what type of
filesystem it's dealing with. Can you explain?

[Scott James Remnant (Canonical) (canonical-scott)]

But /usr/sbin/laptop-mode is a shell script, and it can only know the filesystem
type by poking around in /etc/mtab ... if this is non-revealing it can't set the
appopriate filesystem parameters and remount the filesytem noatime, etc.

The effect is that laptop-mode is ON, but the filesystem hasn't been tuned so it
prevents the hard drive from actually spinning down.

[Herbert Xu (herbert-gondor)]

IMHO the case where mtab disagrees fstab is so rare that we can ignore it. So
just get the fstype from fstab and be done with it. In fact the checkroot
initscript should already be doing that by filling in mtab with the info from
fstab. Why didn't that work?

[Scott James Remnant (Canonical) (canonical-scott)]

Because the checkroot script doesn't actually seem to fill it in, but hopes that
mount will for it.

[Herbert Xu (herbert-gondor)]

Mount should have filled it in using the value from fstab. It certainly does
for me.

[Scott James Remnant (Canonical) (canonical-scott)]

What filesystem type do you have?

It consistently, repeatedly doesn't ever for me.

[Herbert Xu (herbert-gondor)]

ext3. I just did it again by

> /etc/mtab
mount -f -o remount /

and it recreated mtab with the right type for /. Perhaps someone should fix mount?

[Scott James Remnant (Canonical) (canonical-scott)]

Really? I have the same problem with ext3 ...

descent scott% cat /etc/mtab
/dev/hda3 / unknown rw,errors=remount-ro 0 0

descent scott% sudo mount -f -o remount /
Password:
descent scott% cat /etc/mtab
/dev/hda3 / unknown rw,errors=remount-ro 0 0

[Herbert Xu (herbert-gondor)]

As I was saying mount is writing mtab based on /etc/fstab. So what is in your
/etc/fstab?

[Scott James Remnant (Canonical) (canonical-scott)]

I don't see where it's doing that *at all*, it doesn't take the type from fstab
and place it in mtab -- it needs the "-t $roottype" added to the line to be able
to do that.

/dev/hda3 / ext3 errors=remount-ro 0 1

is the fstab entry on my desktop,

/dev/hda2 / xfs defaults 0 1

on my laptop

[Herbert Xu (herbert-gondor)]

(In reply to comment #19)
> descent scott% cat /etc/mtab
> /dev/hda3 / unknown rw,errors=remount-ro 0 0
>
> descent scott% sudo mount -f -o remount /

Hang on a second. You gotta zap your mtab before it can rewrite it, e.g.,

sudo sh -c '> /etc/mtab; mount -f -o remount /'

[Scott James Remnant (Canonical) (canonical-scott)]

That's interesting, nuking mtab first makes the mount succeed on both the ext3
and xfs boxes. But they're still remaining as "unknown" on boot.

Reading checkroot.sh, the file certainly should be empty before the mount
option. So I had a little fiddle, and watch out, your mind is about to blow out
of your ears:

This is what just worked for both you and I ...

descent /etc# cat mtab
descent /etc# mount -f -o defaults /
descent /etc# cat mtab
/dev/hda3 / ext3 rw,errors=remount-ro 0 0

I added the -o defaults bit just to be a bit more inline with checkroot.sh, it
passes -o $rootopts rather than remount (the -f means it makes no difference
anyway). So that works. But that's not *quite* what checkroot.sh does, it also
passes $fstabroot

descent /etc# :> mtab
descent /etc# cat mtab
descent /etc# mount -f -o defaults /dev/hda3 /
descent /etc# cat mtab
/dev/hda3 / unknown rw 0 0

So that's what makes it fail, by giving the partition there it stops it from
actually guessing the partition type.

[Herbert Xu (herbert-gondor)]

I think we better find out the rationale for that change in checkroot. On my
fairly stale (~3 months) sid system, checkroot only does

if [ "$rootmode" = rw ]
then
        [ ! -L /etc/mtab ] && [ -f /etc/mtab~ ] && rm -f /etc/mtab~
        : > /etc/mtab
        mount -f -o remount /
        mount -f /proc
        [ -n "$devfs" ] && mount -f $devfs
fi

So it must've changed recently or perhaps only in Ubuntu.

[Herbert Xu (herbert-gondor)]

Right it looks like the culprit is recent work on sysvinit/initscripts perhaps
intended to add uuid/label support.

[Matt Zimmerman (mdz)]

So is this problem related to the information in /proc/mounts at all? Or is it
purely a mount(8) problem?
It seems we have two proposed solutions:

1. Add an explicit -t option using the type from fstab
2. Remove the explicit device specification, and let mount look it up itself

Debian previously did #2, but changed because of this bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254724

which sounds a bit unclear, but seems to have at least worked around a real
problem. Any objections to #1?

[Herbert Xu (herbert-gondor)]

(In reply to comment #26)
> 1. Add an explicit -t option using the type from fstab
>
> problem. Any objections to #1?

Nope. Debian seems to be doing exactly that.

[Matt Zimmerman (mdz)]

sysvinit (2.85-22ubuntu12) warty; urgency=low

  * Backport fix for Debian bug #255849: explicitly specify the filesystem
    type with mount -t when initializing mtab (Closes: Warty#1848)

 -- Matt Zimmerman <email address hidden> Mon, 4 Oct 2004 00:05:14 -0700

potpal:[~] mount
/dev/hda1 on / type ext3 (rw,errors=remount-ro)

[Scott James Remnant (Canonical) (canonical-scott)]

FWIW I had a browse through mount itself; for hysterical raisins it doesn't read
fstab when you pass both a device and mount-point. It only reads fstab when you
pass one of those two things (generally the mount point), and it's taking the
filesystem type from fstab there anyway -- not auto-detecting it from the
filesystem it's about to mount.

I think -t was the right solution here, thanks guys.

[Matt Zimmerman (mdz)]

*** Bug 8801 has been marked as a duplicate of this bug. ***