Hello,
on 2.4.18 I get the following:
dreher@karpfen:~ > uname -a
Linux karpfen 2.4.18 #2 Sun Apr 21 23:27:03 CEST 2002 i586 unknown
dreher@karpfen:~ > df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 7060308 6276080 425580 94% /
/dev/hda4 3794936 3043812 558344 84% /home
dreher@karpfen:~ > cat /proc/mounts
/dev/root / ext3 rw,noatime,nodiratime 0 0
proc /proc proc rw 0 0
/dev/hda4 /home ext3 rw,noatime,nodiratime 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
devpts /dev/pts devpts rw 0 0
On the other hand, 2.4.19-pre7 gives:
dreher@karpfen:~ > uname -a
Linux karpfen 2.4.19-pre7 #6 Sun Apr 21 20:27:47 CEST 2002 i586 unknown
dreher@karpfen:~ > df
Filesystem 1k-blocks Used Available Use% Mounted on
rootfs 7060308 6276188 425472 94% /
/dev/root 7060308 6276188 425472 94% /
/dev/hda4 3794936 3042316 559840 84% /home
dreher@karpfen:~ > cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,nodiratime 0 0
proc /proc proc rw 0 0
/dev/hda4 /home ext3 rw,noatime,nodiratime 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
devpts /dev/pts devpts rw 0 0
I don't know if it is related, but in my bootscripts I link
/etc/mtab to /proc/mounts.
Regards,
Michael
On Fri, 26 Apr 2002, Michael Dreher wrote:
> dreher@karpfen:~ > df
> Filesystem 1k-blocks Used Available Use% Mounted on
> rootfs 7060308 6276188 425472 94% /
df(1) is wrong. There is (see /proc/mounts below) rootfs mounted as
root (ramfs, actually) and ext3 mounted over it. df sees two entries
in /etc/mtab (on your box - /proc/mounts) with mountpoint "/" and
does statfs("/", &buf); for both. Surprise, surprise, results of
two calls of statf2(2) are identical - what with arguments being
the same both times - and refer to the filesystem where your "/"
lives. I.e. to ext3.
> /dev/root 7060308 6276188 425472 94% /
> /dev/hda4 3794936 3042316 559840 84% /home
>
> dreher@karpfen:~ > cat /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/root / ext3 rw,noatime,nodiratime 0 0
> proc /proc proc rw 0 0
> /dev/hda4 /home ext3 rw,noatime,nodiratime 0 0
> usbdevfs /proc/bus/usb usbdevfs rw 0 0
> devpts /dev/pts devpts rw 0 0
On Fri, 26 Apr 2002 02:32:23 -0400 (EDT)
Alexander Viro <[email protected]> wrote:
>
>
> On Fri, 26 Apr 2002, Michael Dreher wrote:
>
> > dreher@karpfen:~ > df
> > Filesystem 1k-blocks Used Available Use% Mounted on
> > rootfs 7060308 6276188 425472 94% /
>
> df(1) is wrong. There is (see /proc/mounts below) rootfs mounted as
> root (ramfs, actually) and ext3 mounted over it. df sees two entries
> in /etc/mtab (on your box - /proc/mounts) with mountpoint "/" and
> does statfs("/", &buf); for both. Surprise, surprise, results of
> two calls of statf2(2) are identical - what with arguments being
> the same both times - and refer to the filesystem where your "/"
> lives. I.e. to ext3.
>
> > /dev/root 7060308 6276188 425472 94% /
> > /dev/hda4 3794936 3042316 559840 84% /home
> >
> > dreher@karpfen:~ > cat /proc/mounts
> > rootfs / rootfs rw 0 0
> > /dev/root / ext3 rw,noatime,nodiratime 0 0
> > proc /proc proc rw 0 0
> > /dev/hda4 /home ext3 rw,noatime,nodiratime 0 0
> > usbdevfs /proc/bus/usb usbdevfs rw 0 0
> > devpts /dev/pts devpts rw 0 0
On a related note (the listing of /dev/root reminded me), as of
2.4.19-pre7-ac2, I can no longer boot with a "root=/dev/discs/disc0/part1"
command line, I have to use "root=/dev/ide/host2/bus0/target0/lun0/part1". My
previous kernel (2.4.19-pre4-ac2-radix) and all ones before that worked fine
with the first version of the command line. Is this an intended change or is
it a bug? I can give more information if necessary, and it's happening on two
different AMD based systems with different chipsets.
Daniel
---
Recursion n.:
See Recursion.
-- Random Shack Data Processing Dictionary
Hi!
> > dreher@karpfen:~ > df
> > Filesystem 1k-blocks Used Available Use% Mounted on
> > rootfs 7060308 6276188 425472 94% /
>
> df(1) is wrong. There is (see /proc/mounts below) rootfs mounted as
> root (ramfs, actually) and ext3 mounted over it. df sees two entries
> in /etc/mtab (on your box - /proc/mounts) with mountpoint "/" and
> does statfs("/", &buf); for both. Surprise, surprise, results of
> two calls of statf2(2) are identical - what with arguments being
> the same both times - and refer to the filesystem where your "/"
> lives. I.e. to ext3.
df might be wrong, but lets say that this /proc/mounts become
interesting. This could not have happened in the past. That means you
changed kernel interface in stable series, and that's wrong.
> > /dev/root 7060308 6276188 425472 94% /
> > /dev/hda4 3794936 3042316 559840 84% /home
> >
> > dreher@karpfen:~ > cat /proc/mounts
> > rootfs / rootfs rw 0 0
> > /dev/root / ext3 rw,noatime,nodiratime 0 0
> > proc /proc proc rw 0 0
> > /dev/hda4 /home ext3 rw,noatime,nodiratime 0 0
> > usbdevfs /proc/bus/usb usbdevfs rw 0 0
> > devpts /dev/pts devpts rw 0 0
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Fri, 26 Apr 2002, Pavel Machek wrote:
> > does statfs("/", &buf); for both. Surprise, surprise, results of
> > two calls of statf2(2) are identical - what with arguments being
> > the same both times - and refer to the filesystem where your "/"
> > lives. I.e. to ext3.
>
> df might be wrong, but lets say that this /proc/mounts become
> interesting. This could not have happened in the past. That means you
This _could_ happen in past - as the matter of fact, I can reproduce it
on any 2.4 kernel. Mount something over the root of already mounted
filesystem and watch the show.
Now, we could disable showing rootfs in /proc/mounts and it might be a
good idea for 2.4, I'm not all that sure that it's a right thing, though.
On Fri, 26 Apr 2002, Alexander Viro wrote:
>
>
> On Fri, 26 Apr 2002, Pavel Machek wrote:
>
> > > does statfs("/", &buf); for both. Surprise, surprise, results of
> > > two calls of statf2(2) are identical - what with arguments being
> > > the same both times - and refer to the filesystem where your "/"
> > > lives. I.e. to ext3.
> >
> > df might be wrong, but lets say that this /proc/mounts become
> > interesting. This could not have happened in the past. That means you
>
> This _could_ happen in past - as the matter of fact, I can reproduce it
> on any 2.4 kernel. Mount something over the root of already mounted
> filesystem and watch the show.
>
> Now, we could disable showing rootfs in /proc/mounts and it might be a
> good idea for 2.4, I'm not all that sure that it's a right thing, though.
This happens all the time if you use initrd ramdisk and switch to hard
disk during boot up.
2.4.19-pre6 is ok, but 2.4.19-pre7 is not.
Jeff.
On Sat, 27 Apr 2002, Jeff Chua wrote:
> This happens all the time if you use initrd ramdisk and switch to hard
> disk during boot up.
This happens all the time with rootfs, period. For exactly the same
reasons.
Again, we could hide that fact (we _do_ have a filesystem mounted
underneath the final root), but I'm not sure that it's worth hiding.
The real problem is in the interaction between df(1) and /proc/mounts
and it occurs every time when mountpoint happens to be a root of
already mounted filesystem. Which could happen at any time since
the beginning of 2.4 (actually, way back in 2.3).
Notice that the same bug happens in _all_ version for chroot environment.
Namely, df(1) will try to call statfs() for mountpoints outside chroot
jail and that will give very interesting output, since results were for
corresponsing directories _inside_ the jail.
Arguably, correct way to handle that is to leave everything outside the
process' root out of /proc/mounts. Which would solve both the chroot
problems and rootfs one (all processes are chrooted into the "final"
root). It _still_ doesn't solve the old problem with overmounts, but
that one could be only handled in userland (by letting df(1) notice
that several getmntent(3) have the same mountpoint and ignore all
but the last one).
Unless somebody has a good reason why /proc/mounts in chroot jail should
show objects outside it, I'm going to do it that way.
On Sat, 27 Apr 2002, Jeff Chua wrote:
> On Fri, 26 Apr 2002, Alexander Viro wrote:
>
> >
> >
> > On Fri, 26 Apr 2002, Pavel Machek wrote:
> >
> > > > does statfs("/", &buf); for both. Surprise, surprise, results of
> > > > two calls of statf2(2) are identical - what with arguments being
> > > > the same both times - and refer to the filesystem where your "/"
> > > > lives. I.e. to ext3.
> > >
> > > df might be wrong, but lets say that this /proc/mounts become
> > > interesting. This could not have happened in the past. That means you
> >
> > This _could_ happen in past - as the matter of fact, I can reproduce it
> > on any 2.4 kernel. Mount something over the root of already mounted
> > filesystem and watch the show.
> >
> > Now, we could disable showing rootfs in /proc/mounts and it might be a
> > good idea for 2.4, I'm not all that sure that it's a right thing, though.
>
>
> This happens all the time if you use initrd ramdisk and switch to hard
> disk during boot up.
>
> 2.4.19-pre6 is ok, but 2.4.19-pre7 is not.
>
> Jeff.
>
In 2.4.18, it looks like this when booting initrd and switching
to a hard disk. This looks okay.
/dev/root.old /initrd ext2 rw 0 0
/dev/root / ext2 rw 0 0
/dev/sdc1 /alt ext2 rw 0 0
/dev/sdc3 /home/users ext2 rw 0 0
none /proc proc rw 0 0
/dev/sda1 /dos/drive_C msdos rw 0 0
/dev/sda5 /dos/drive_D msdos rw 0 0
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.