Ramdisk (and other) problems with 2.4.2

Ramdisk (and other) problems with 2.4.2

[Richard B. Johnson]

After attempting to run 2.4.2, and killing all my hard disks, I
have finally gotten 2.4.1 back up. There is a continual problem
that even exists on 2.4.1, that will show if you execute this.
However, unmount your hard disks before you execute this simple
harmless script. 


dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
/sbin/mke2fs -Fq /dev/ram0 1440 
mount -t ext2 /dev/ram0 /mnt
dd if=/dev/zero of=/mnt/foo bs=1k count=1000
ls -la /mnt
umount /mnt

The first time you execute it, fine. It runs. The second time, you
get:

Mar  7 10:29:00 chaos last message repeated 11 times
Mar  7 10:29:00 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 631 
Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41 
Mar  7 10:30:32 chaos last message repeated 11 times
Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 53 
Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 310 
Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 614 
Mar  7 10:30:32 chaos last message repeated 4 times
Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 619 
Mar  7 10:30:32 chaos last message repeated 11 times
Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 631 
Mar  7 10:34:25 chaos sendmail[17986]: f27FYJh17986: from=<linux-kernel-owner@vger.kernel.org>, size=1830, class=-60, nrcpts=1, msgid=<200103071529.f27FTjO26978@aslan.scsiguy.com>, bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=vger.kernel.org [199.183
.24.194]
Mar  7 10:34:26 chaos sendmail[17994]: f27FYJh17986: to=<root@chaos.analogic.com>, delay=00:00:07, xdelay=00:00:01, mailer=local, pri=138660, dsn=2.0.0, stat=Sent
Mar  7 10:34:46 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41 
Mar  7 10:34:46 chaos last message repeated 11 times
Mar  7 10:34:46 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 53 
Mar  7 10:34:46 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 310 
Mar  7 10:34:58 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41 
Mar  7 10:34:58 chaos last message repeated 11 times
Mar  7 10:34:58 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 53 
Mar  7 10:34:58 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 310 
Mar  7 10:35:06 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41 
Mar  7 10:35:06 chaos last message repeated 11 times
Mar  7 10:35:06 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 53 
Mar  7 10:35:06 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 310 
Mar  7 10:38:58 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41 
Mar  7 10:38:58 chaos last message repeated 11 times
Mar  7 10:38:58 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 53 
Mar  7 10:38:58 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 310 


...and no files are generated in the ramdisk ... and, If you don't
reboot soon, you will have file-system corruption all throughout your
hard disks(s) including those which are not mounted (really). Some
offset gets screwed so umounted disks are written. Reboot with the
reset switch.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Wed, 7 Mar 2001, Richard B. Johnson wrote:

> After attempting to run 2.4.2, and killing all my hard disks, I
> have finally gotten 2.4.1 back up. There is a continual problem
> that even exists on 2.4.1, that will show if you execute this.
> However, unmount your hard disks before you execute this simple
> harmless script.
>
>
> dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
> /sbin/mke2fs -Fq /dev/ram0 1440
> mount -t ext2 /dev/ram0 /mnt
> dd if=/dev/zero of=/mnt/foo bs=1k count=1000
> ls -la /mnt
> umount /mnt
>
> The first time you execute it, fine. It runs. The second time, you
> get:
>
> Mar  7 10:29:00 chaos last message repeated 11 times
> Mar  7 10:29:00 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 631
> Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41

Hmmm.. no problem here.

Script started on Wed Mar  7 17:31:28 2001
[root]:# uname -a
Linux el-kaboom 2.4.2 #5 Wed Mar 7 17:16:17 CET 2001 i686 unknown
[root]:# cat ./testo
dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
/sbin/mke2fs -Fq /dev/ram0 1440
mount -t ext2 /dev/ram0 /mnt
dd if=/dev/zero of=/mnt/foo bs=1k count=1000
ls -la /mnt
umount /mnt
[root]:# ./testo
1440+0 records in
1440+0 records out
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
1000+0 records in
1000+0 records out
total 1019
drwxr-xr-x   3 root     root         1024 Mar  7 17:31 .
drwxr-xr-x  23 root     root         1024 Feb 28 07:13 ..
-rw-r--r--   1 root     root      1024000 Mar  7 17:31 foo
drwxr-xr-x   2 root     root        12288 Mar  7 17:31 lost+found
[root]:# ./testo
1440+0 records in
1440+0 records out
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
1000+0 records in
1000+0 records out
total 1019
drwxr-xr-x   3 root     root         1024 Mar  7 17:31 .
drwxr-xr-x  23 root     root         1024 Feb 28 07:13 ..
-rw-r--r--   1 root     root      1024000 Mar  7 17:31 foo
drwxr-xr-x   2 root     root        12288 Mar  7 17:31 lost+found
[root]:# ./testo
1440+0 records in
1440+0 records out
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
1000+0 records in
1000+0 records out
total 1019
drwxr-xr-x   3 root     root         1024 Mar  7 17:31 .
drwxr-xr-x  23 root     root         1024 Feb 28 07:13 ..
-rw-r--r--   1 root     root      1024000 Mar  7 17:31 foo
drwxr-xr-x   2 root     root        12288 Mar  7 17:31 lost+found
[root]:# exit
exit

Script done on Wed Mar  7 17:31:50 2001

I'd sweat bullets over system integrity if _I_ got this reply ;-)
Something is seriously amiss.

	-Mike

Re: Ramdisk (and other) problems with 2.4.2

[Richard B. Johnson]

On Wed, 7 Mar 2001, Mike Galbraith wrote:

> On Wed, 7 Mar 2001, Richard B. Johnson wrote:
> 
> > After attempting to run 2.4.2, and killing all my hard disks, I
> > have finally gotten 2.4.1 back up. There is a continual problem
> > that even exists on 2.4.1, that will show if you execute this.
> > However, unmount your hard disks before you execute this simple
> > harmless script.
> >
> >
> > dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
> > /sbin/mke2fs -Fq /dev/ram0 1440
> > mount -t ext2 /dev/ram0 /mnt
> > dd if=/dev/zero of=/mnt/foo bs=1k count=1000
> > ls -la /mnt
> > umount /mnt
> >
> > The first time you execute it, fine. It runs. The second time, you
> > get:
> >
> > Mar  7 10:29:00 chaos last message repeated 11 times
> > Mar  7 10:29:00 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 631
> > Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41
> 
> Hmmm.. no problem here.
> 
> Script started on Wed Mar  7 17:31:28 2001
> [root]:# uname -a
> Linux el-kaboom 2.4.2 #5 Wed Mar 7 17:16:17 CET 2001 i686 unknown
> [root]:# cat ./testo
> dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
> /sbin/mke2fs -Fq /dev/ram0 1440
> mount -t ext2 /dev/ram0 /mnt
> dd if=/dev/zero of=/mnt/foo bs=1k count=1000
> ls -la /mnt
> umount /mnt
> [root]:# ./testo
> 1440+0 records in
> 1440+0 records out
> mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> 1000+0 records in
> 1000+0 records out
> total 1019
> drwxr-xr-x   3 root     root         1024 Mar  7 17:31 .
> drwxr-xr-x  23 root     root         1024 Feb 28 07:13 ..
> -rw-r--r--   1 root     root      1024000 Mar  7 17:31 foo
> drwxr-xr-x   2 root     root        12288 Mar  7 17:31 lost+found
> [root]:# ./testo
> 1440+0 records in
> 1440+0 records out
> mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> 1000+0 records in
> 1000+0 records out
> total 1019
> drwxr-xr-x   3 root     root         1024 Mar  7 17:31 .
> drwxr-xr-x  23 root     root         1024 Feb 28 07:13 ..
> -rw-r--r--   1 root     root      1024000 Mar  7 17:31 foo
> drwxr-xr-x   2 root     root        12288 Mar  7 17:31 lost+found
> [root]:# ./testo
> 1440+0 records in
> 1440+0 records out
> mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> 1000+0 records in
> 1000+0 records out
> total 1019
> drwxr-xr-x   3 root     root         1024 Mar  7 17:31 .
> drwxr-xr-x  23 root     root         1024 Feb 28 07:13 ..
> -rw-r--r--   1 root     root      1024000 Mar  7 17:31 foo
> drwxr-xr-x   2 root     root        12288 Mar  7 17:31 lost+found
> [root]:# exit
> exit
> 
> Script done on Wed Mar  7 17:31:50 2001
> 
> I'd sweat bullets over system integrity if _I_ got this reply ;-)
> Something is seriously amiss.

Well now the denial phase sets in. This system has run fine for
two years. It ran until I tried to use new kernels.

Question. How come you show a lost+found directory in the ramdisk??
mke2fs version 1.19 doesn't create one on a ram disk.

Script started on Wed Mar  7 12:22:20 2001
# mke2fs -Fq /dev/ram0 1440
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
# mount /dev/ram0 /mnt
# ls -la /mnt
total 0
# umount /mnt
# exit
exit

Script done on Wed Mar  7 12:23:21 2001


Also, check your logs. The errors reported don't go out to stderr.
They go to whatever you have set up for kernel errors.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Wed, 7 Mar 2001, Richard B. Johnson wrote:

> On Wed, 7 Mar 2001, Mike Galbraith wrote:
>
> > I'd sweat bullets over system integrity if _I_ got this reply ;-)
> > Something is seriously amiss.
>
> Well now the denial phase sets in. This system has run fine for
> two years. It ran until I tried to use new kernels.

?? It's not denial Richard.  I showed you your script running here and
working just fine.  As to your system running fine for two years, all
I can say is that _every_ system runs fine until it doesn't any more.

There may be a problem elsewhere, but the ramdisk does not display
the symptom you claimed it would.

> Question. How come you show a lost+found directory in the ramdisk??
> mke2fs version 1.19 doesn't create one on a ram disk.

Well it certainly does create a lost+found here as you can see.  It
sounds as though you're implying that I dummied up the script output.

> Script started on Wed Mar  7 12:22:20 2001
> # mke2fs -Fq /dev/ram0 1440
> mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> # mount /dev/ram0 /mnt
> # ls -la /mnt
> total 0
> # umount /mnt
> # exit
> exit
>
> Script done on Wed Mar  7 12:23:21 2001
>
>
> Also, check your logs. The errors reported don't go out to stderr.
> They go to whatever you have set up for kernel errors.

I know what kernel messages are.  There are none.

	-Mike

Re: Ramdisk (and other) problems with 2.4.2

[Richard B. Johnson]

On Wed, 7 Mar 2001, Mike Galbraith wrote:

> On Wed, 7 Mar 2001, Richard B. Johnson wrote:
> 
> > On Wed, 7 Mar 2001, Mike Galbraith wrote:
> >
> > > I'd sweat bullets over system integrity if _I_ got this reply ;-)
> > > Something is seriously amiss.
> >
> > Well now the denial phase sets in. This system has run fine for
> > two years. It ran until I tried to use new kernels.
> 
> ?? It's not denial Richard.  I showed you your script running here and
> working just fine.  As to your system running fine for two years, all
> I can say is that _every_ system runs fine until it doesn't any more.

No. It's __my__ denial phase.

> 
> There may be a problem elsewhere, but the ramdisk does not display
> the symptom you claimed it would.
> 
> > Question. How come you show a lost+found directory in the ramdisk??
> > mke2fs version 1.19 doesn't create one on a ram disk.
> 
> Well it certainly does create a lost+found here as you can see.  It
> sounds as though you're implying that I dummied up the script output.
> 

No. I did not imply that. I only stated a "so-called" fact.
Would you please check your /dev/ram0 and verify that it is:

	block special (1/0)


> > Script started on Wed Mar  7 12:22:20 2001
> > # mke2fs -Fq /dev/ram0 1440
> > mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> > # mount /dev/ram0 /mnt
> > # ls -la /mnt
> > total 0
> > # umount /mnt
> > # exit
> > exit
> >
> > Script done on Wed Mar  7 12:23:21 2001
> >
> >
> > Also, check your logs. The errors reported don't go out to stderr.
> > They go to whatever you have set up for kernel errors.
> 
> I know what kernel messages are.  There are none.
> 
> 	-Mike
> 

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Wed, 7 Mar 2001, Richard B. Johnson wrote:

> Would you please check your /dev/ram0 and verify that it is:
>
> 	block special (1/0)

Why zzzt zzt are we now zzt troubleshooting _my_ zzzzt system :-)

	tilt

	-Mike

Re: Ramdisk (and other) problems with 2.4.2

[matthew.copeland]

> Question. How come you show a lost+found directory in the ramdisk??
> mke2fs version 1.19 doesn't create one on a ram disk.
> 
> Script started on Wed Mar  7 12:22:20 2001
> # mke2fs -Fq /dev/ram0 1440
> mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> # mount /dev/ram0 /mnt
> # ls -la /mnt
> total 0
> # umount /mnt
> # exit
> exit
> 
> Script done on Wed Mar  7 12:23:21 2001


That's interesting.  Mine does.  I wonder if the version difference
between mke2fs 1.18 aand 1.19 is what is causing that?  I even tried it
with the exact same arguments as in your script and I still got a
lost+found.  (I am assuming that in Red Hat 6.2 they didn't change the
mke2fs code at all.)

Matthew M. Copeland


Script started on Wed Mar  7 11:49:24 2001
[root@testgrndstn /root]# dd if=/dev/zero of=/dev/ram1 bs=1k count=4096
4096+0 records in
4096+0 records out
[root@testgrndstn /root]# mke2fs -qm0 /dev/ram1 4096
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
[root@testgrndstn /root]# mount /dev/ram1 /test
[root@testgrndstn /root]# ls -als /test
total 17
   1 drwxr-xr-x    3 root     root         1024 Mar  7 11:49 .
   4 drwxr-xr-x   30 root     root         4096 Mar  7 11:47 ..
  12 drwxr-xr-x    2 root     root        12288 Mar  7 11:49 lost+found
[root@testgrndstn /root]# exit
exit

Re: Ramdisk (and other) problems with 2.4.2

[Richard B. Johnson]

On Wed, 7 Mar 2001 matthew.copeland@honeywell.com wrote:

> 
> > Question. How come you show a lost+found directory in the ramdisk??
> > mke2fs version 1.19 doesn't create one on a ram disk.
> > 
> > Script started on Wed Mar  7 12:22:20 2001
> > # mke2fs -Fq /dev/ram0 1440
> > mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> > # mount /dev/ram0 /mnt
> > # ls -la /mnt
> > total 0
> > # umount /mnt
> > # exit
> > exit
> > 
> > Script done on Wed Mar  7 12:23:21 2001
> 
> 
> That's interesting.  Mine does.  I wonder if the version difference
> between mke2fs 1.18 aand 1.19 is what is causing that?  I even tried it
> with the exact same arguments as in your script and I still got a
> lost+found.  (I am assuming that in Red Hat 6.2 they didn't change the
> mke2fs code at all.)
> 
> Matthew M. Copeland
> 
> 
> Script started on Wed Mar  7 11:49:24 2001
> [root@testgrndstn /root]# dd if=/dev/zero of=/dev/ram1 bs=1k count=4096
> 4096+0 records in
> 4096+0 records out
> [root@testgrndstn /root]# mke2fs -qm0 /dev/ram1 4096
> mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> [root@testgrndstn /root]# mount /dev/ram1 /test
> [root@testgrndstn /root]# ls -als /test
> total 17
>    1 drwxr-xr-x    3 root     root         1024 Mar  7 11:49 .
>    4 drwxr-xr-x   30 root     root         4096 Mar  7 11:47 ..
>   12 drwxr-xr-x    2 root     root        12288 Mar  7 11:49 lost+found
> [root@testgrndstn /root]# exit
> exit
> 
> 

Okay, on my system mke2fs doesn't make a lost+found on /dev/ram0, but
it does on /dev/ram1.


Script started on Wed Mar  7 13:03:52 2001
^[[9;0]# sh -v xxx.xxx

cp /dev/zero /dev/ram0
cp: /dev/ram0: No space left on device
mke2fs /dev/ram0 1440
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group

Writing inode tables: 0/1\b\b\bdone                            
Writing superblocks and filesystem accounting information: done
mount /dev/ram0 /mnt
ls -la /mnt
total 0
umount /mnt
mke2fs /dev/ram1 1440
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group

Writing inode tables: 0/1\b\b\bdone                            
Writing superblocks and filesystem accounting information: done
mount /dev/ram1 /mnt
ls -la /mnt
total 17
drwxr-xr-x   3 root     root         1024 Mar  7 13:03 .
drwxr-xr-x  26 root     root         4096 Mar  7 11:44 ..
drwxr-xr-x   2 root     root        12288 Mar  7 13:03 lost+found

# exit
exit

Script done on Wed Mar  7 13:04:22 2001



Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Ramdisk (and other) problems with 2.4.2

[Pavel Machek]

Hi!
> Script started on Wed Mar  7 12:22:20 2001
> # mke2fs -Fq /dev/ram0 1440
> mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> # mount /dev/ram0 /mnt
> # ls -la /mnt
> total 0
> # umount /mnt
> # exit
> exit

No "." and ".."? something is definitely wrong here!

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Wed, 7 Mar 2001, Richard B. Johnson wrote:

> On Wed, 7 Mar 2001, Mike Galbraith wrote:
>
> > On Wed, 7 Mar 2001, Richard B. Johnson wrote:
> >
> > > After attempting to run 2.4.2, and killing all my hard disks, I
> > > have finally gotten 2.4.1 back up. There is a continual problem
> > > that even exists on 2.4.1, that will show if you execute this.
> > > However, unmount your hard disks before you execute this simple
> > > harmless script.
> > >
> > >
> > > dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
> > > /sbin/mke2fs -Fq /dev/ram0 1440
> > > mount -t ext2 /dev/ram0 /mnt
> > > dd if=/dev/zero of=/mnt/foo bs=1k count=1000
> > > ls -la /mnt
> > > umount /mnt
> > >
> > > The first time you execute it, fine. It runs. The second time, you
> > > get:
> > >
> > > Mar  7 10:29:00 chaos last message repeated 11 times
> > > Mar  7 10:29:00 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 631
> > > Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41
> >
> > Hmmm.. no problem here.

I think I've figured it out.. at least I've found a way to reproduce
the exact errors to the last detail and some pretty nasty corruption
to go with it.  The operator must help though.. a lot ;-)

If you do mount -o remount /dev/somedisk / thinking that that will get
rid of your /dev/ram0 root, that isn't the case, and you will corrupt
the device you remounted (I did it to a scratch monkey) very badly when
you write to the still mounted ramdisk.

You must exec a shell (or something) chrooted to your mounted harddisk
to un-busy the old root and then pivot_root/unmount that old root.  I
tested this, and all is well.

I think this is a consequence of the multiple mount changes.. not sure.
(ergo cc to Al Viro.. he knows eeeeverything about mount points)

	-Mike

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Fri, 9 Mar 2001, Mike Galbraith wrote:

> You must exec a shell (or something) chrooted to your mounted harddisk
> to un-busy the old root and then pivot_root/unmount that old root.  I
> tested this, and all is well.

This came out a little backassward.. pivot_root then chroot/unmount.

Re: Ramdisk (and other) problems with 2.4.2

[Richard B. Johnson]

On Fri, 9 Mar 2001, Mike Galbraith wrote:

> On Wed, 7 Mar 2001, Richard B. Johnson wrote:
> 
> > On Wed, 7 Mar 2001, Mike Galbraith wrote:
> >
> > > On Wed, 7 Mar 2001, Richard B. Johnson wrote:
> > >
> > > > After attempting to run 2.4.2, and killing all my hard disks, I
> > > > have finally gotten 2.4.1 back up. There is a continual problem
> > > > that even exists on 2.4.1, that will show if you execute this.
> > > > However, unmount your hard disks before you execute this simple
> > > > harmless script.
> > > >
> > > >
> > > > dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
> > > > /sbin/mke2fs -Fq /dev/ram0 1440
> > > > mount -t ext2 /dev/ram0 /mnt
> > > > dd if=/dev/zero of=/mnt/foo bs=1k count=1000
> > > > ls -la /mnt
> > > > umount /mnt
> > > >
> > > > The first time you execute it, fine. It runs. The second time, you
> > > > get:
> > > >
> > > > Mar  7 10:29:00 chaos last message repeated 11 times
> > > > Mar  7 10:29:00 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 631
> > > > Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41
> > >
> > > Hmmm.. no problem here.
> 
> I think I've figured it out.. at least I've found a way to reproduce
> the exact errors to the last detail and some pretty nasty corruption
> to go with it.  The operator must help though.. a lot ;-)
> 
> If you do mount -o remount /dev/somedisk / thinking that that will get
> rid of your /dev/ram0 root, that isn't the case, and you will corrupt
> the device you remounted (I did it to a scratch monkey) very badly when
> you write to the still mounted ramdisk.
> 
> You must exec a shell (or something) chrooted to your mounted harddisk
> to un-busy the old root and then pivot_root/unmount that old root.  I
> tested this, and all is well.
> 
> I think this is a consequence of the multiple mount changes.. not sure.
> (ergo cc to Al Viro.. he knows eeeeverything about mount points)
> 
> 	-Mike
> 

Well. You did discover something. When the new root gets mounted
upon startup, all references to the original ramdisk root should
have been gone. It is well known that the original ramdisk-root
remains,  mounted under /initrd if this directory exists. Writes
to (or even destruction of) this file-system, hanging off a mount
point should not have affected the parent mount point or the
parent file-system. However, as you and I have found, it does.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Fri, 9 Mar 2001, Richard B. Johnson wrote:

> On Fri, 9 Mar 2001, Mike Galbraith wrote:
>
> > On Wed, 7 Mar 2001, Richard B. Johnson wrote:
> >
> > > On Wed, 7 Mar 2001, Mike Galbraith wrote:
> > >
> > > > On Wed, 7 Mar 2001, Richard B. Johnson wrote:
> > > >
> > > > > After attempting to run 2.4.2, and killing all my hard disks, I
> > > > > have finally gotten 2.4.1 back up. There is a continual problem
> > > > > that even exists on 2.4.1, that will show if you execute this.
> > > > > However, unmount your hard disks before you execute this simple
> > > > > harmless script.
> > > > >
> > > > >
> > > > > dd if=/dev/zero of=/dev/ram0 bs=1k count=1440
> > > > > /sbin/mke2fs -Fq /dev/ram0 1440
> > > > > mount -t ext2 /dev/ram0 /mnt
> > > > > dd if=/dev/zero of=/mnt/foo bs=1k count=1000
> > > > > ls -la /mnt
> > > > > umount /mnt
> > > > >
> > > > > The first time you execute it, fine. It runs. The second time, you
> > > > > get:
> > > > >
> > > > > Mar  7 10:29:00 chaos last message repeated 11 times
> > > > > Mar  7 10:29:00 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 631
> > > > > Mar  7 10:30:32 chaos kernel: EXT2-fs error (device ramdisk(1,0)): ext2_free_blocks: bit already cleared for block 41
> > > >
> > > > Hmmm.. no problem here.
> >
> > I think I've figured it out.. at least I've found a way to reproduce
> > the exact errors to the last detail and some pretty nasty corruption
> > to go with it.  The operator must help though.. a lot ;-)
> >
> > If you do mount -o remount /dev/somedisk / thinking that that will get
> > rid of your /dev/ram0 root, that isn't the case, and you will corrupt
> > the device you remounted (I did it to a scratch monkey) very badly when
> > you write to the still mounted ramdisk.
> >
> > You must exec a shell (or something) chrooted to your mounted harddisk
> > to un-busy the old root and then pivot_root/unmount that old root.  I
> > tested this, and all is well.
> >
> > I think this is a consequence of the multiple mount changes.. not sure.
> > (ergo cc to Al Viro.. he knows eeeeverything about mount points)
> >
> > 	-Mike
> >
>
> Well. You did discover something. When the new root gets mounted
> upon startup, all references to the original ramdisk root should
> have been gone. It is well known that the original ramdisk-root
> remains,  mounted under /initrd if this directory exists. Writes
> to (or even destruction of) this file-system, hanging off a mount
> point should not have affected the parent mount point or the
> parent file-system. However, as you and I have found, it does.

I was generally exercising with 'what can I do wrong' scenarios when I
noticed some strangness.  If you boot a ramdisk root with init=/bin/sh,
mount a drive, cd to it and exec chroot . /bin/sh and then mount proc,
proc/mounts shows /dev/root and the freshly mounted drive as both being
root.  /dev/root must still be the ramdisk, as no pivot (or playing
with remount) had been done at that time.

I don't know if it would show the same using two partitions or not,
nor if it's a problem.. certainly looks odd though.

	-Mike

Re: Ramdisk (and other) problems with 2.4.2

[Alexander Viro]

On Fri, 9 Mar 2001, Mike Galbraith wrote:

> I was generally exercising with 'what can I do wrong' scenarios when I
> noticed some strangness.  If you boot a ramdisk root with init=/bin/sh,
> mount a drive, cd to it and exec chroot . /bin/sh and then mount proc,
> proc/mounts shows /dev/root and the freshly mounted drive as both being
> root.  /dev/root must still be the ramdisk, as no pivot (or playing
> with remount) had been done at that time.
> 
> I don't know if it would show the same using two partitions or not,
> nor if it's a problem.. certainly looks odd though.

Why would it be a problem? /proc/mounts shows names in the context of
process reading it. We could filter out stuff that happens to be
outside of visible subtree, but that won't change anything.

Could somebody post the exact way to reproduce the problem? -o remount
scenario is obvious, but that's a case of you get what you ask for.
Anything else?
							Cheers,
								Al

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Fri, 9 Mar 2001, Alexander Viro wrote:

> On Fri, 9 Mar 2001, Mike Galbraith wrote:
>
> > I was generally exercising with 'what can I do wrong' scenarios when I
> > noticed some strangness.  If you boot a ramdisk root with init=/bin/sh,
> > mount a drive, cd to it and exec chroot . /bin/sh and then mount proc,
> > proc/mounts shows /dev/root and the freshly mounted drive as both being
> > root.  /dev/root must still be the ramdisk, as no pivot (or playing
> > with remount) had been done at that time.
> >
> > I don't know if it would show the same using two partitions or not,
> > nor if it's a problem.. certainly looks odd though.
>
> Why would it be a problem? /proc/mounts shows names in the context of
> process reading it. We could filter out stuff that happens to be
> outside of visible subtree, but that won't change anything.

Ok.

> Could somebody post the exact way to reproduce the problem? -o remount
> scenario is obvious, but that's a case of you get what you ask for.
> Anything else?

I only managed to kill two devices with one write once.. and I had to
work at it, so nope.

	-Mike

Re: Ramdisk (and other) problems with 2.4.2

[Alexander Viro]

On Fri, 9 Mar 2001, Mike Galbraith wrote:

> I think I've figured it out.. at least I've found a way to reproduce
> the exact errors to the last detail and some pretty nasty corruption
> to go with it.  The operator must help though.. a lot ;-)
> 
> If you do mount -o remount /dev/somedisk / thinking that that will get
> rid of your /dev/ram0 root, that isn't the case, and you will corrupt
> the device you remounted (I did it to a scratch monkey) very badly when
> you write to the still mounted ramdisk.

Ugh. mount -o remount ignores dev_name argument. It will change the
flags of fs mounted from /dev/ram0 and will not even touch a /dev/somedisk.
If you write to device you have mounted... Well, don't expect it to be pretty.

> You must exec a shell (or something) chrooted to your mounted harddisk
> to un-busy the old root and then pivot_root/unmount that old root.  I
> tested this, and all is well.
> 
> I think this is a consequence of the multiple mount changes.. not sure.
> (ergo cc to Al Viro.. he knows eeeeverything about mount points)

I _really_ doubt that it has anything to multiple mounts. mount -o remount
never unmounts anything. Never did. The rest is an obvious result - you
leave fs mounted, you do direct write to its device, you see it fucked.
The fact that it is a root doesn't matter. Relevant part of manpage:
              remount
                     Attempt  to  remount an already-mounted file
                     system.  This is commonly used to change the
                     mount flags for a file system, especially to
                     make a readonly file system writeable.
Hmm... Might be cleaner. IMO
                     Attempt  to  change the mount flags of
                     already-mounted file system.  This is commonly
                     used to make a readonly file system writeable.
would be less confusing. Andries, your comments?
							Cheers,
								Al
(fully expecting a long rant from Richard declaring that -o remount had
_always_ been used to mount a different fs and both ANSI C standard and
X-files fan guide mention it somewhere ;-)

Re: Ramdisk (and other) problems with 2.4.2

[Richard B. Johnson]

On Fri, 9 Mar 2001, Alexander Viro wrote:

> 
> 
> On Fri, 9 Mar 2001, Mike Galbraith wrote:
> 
> > I think I've figured it out.. at least I've found a way to reproduce
> > the exact errors to the last detail and some pretty nasty corruption
> > to go with it.  The operator must help though.. a lot ;-)
> > 
> > If you do mount -o remount /dev/somedisk / thinking that that will get
> > rid of your /dev/ram0 root, that isn't the case, and you will corrupt
> > the device you remounted (I did it to a scratch monkey) very badly when
> > you write to the still mounted ramdisk.
> 

Mount was not executed.


> Ugh. mount -o remount ignores dev_name argument. It will change the
> flags of fs mounted from /dev/ram0 and will not even touch a /dev/somedisk.
> If you write to device you have mounted... Well, don't expect it to be pretty.
[Snipped wonderful explaination of how to change flags using `mount`]

> 							Cheers,
> 								Al
> (fully expecting a long rant from Richard declaring that -o remount had
> _always_ been used to mount a different fs and both ANSI C standard and
> X-files fan guide mention it somewhere ;-)
> 

Nope. I didn't have anything to do with the way an
initial ramdisk is implemented either. However, here
is the point at which the root file system gets changed
from the initrd file-system to the real root.

This is `dmesg` stripped down:

 sda: sda1 sda2 < sda5 >
SCSI device sdb: 4406960 512-byte hdwr sectors (2256 MB)
 sdb: sdb1 sdb2
SCSI device sdc: 17783240 512-byte hdwr sectors (9105 MB)
 sdc: sdc1 sdc2 sdc3
VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=3  < ============= Note the count!
Freeing unused kernel memory: 80k freed

At one time d_count meant something. Then there were changes.
Then more changes. This might have something to do with the
dangling references that can kill.

The `mount` command, nor its internal mount(2) doesn't enter into
this at all. There were no command-scripts that executed the
change_root. This is all part of the built-in initial RAM Disk
capabilites.

The problem is, simply, once you have booted a system using the
RAM Disk, don't expect to ever use the RAM disk again. Writes
to this, even though not currently mounted, can (will) make a mess
of your file-systems, even those which are not mounted.
This is simply a bug that should be fixed. It's not somebody
trying to do something for which the system was not designed.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Ramdisk (and other) problems with 2.4.2

[Mike Galbraith]

On Fri, 9 Mar 2001, Alexander Viro wrote:

> On Fri, 9 Mar 2001, Mike Galbraith wrote:
>
> > I think I've figured it out.. at least I've found a way to reproduce
> > the exact errors to the last detail and some pretty nasty corruption
> > to go with it.  The operator must help though.. a lot ;-)
> >
> > If you do mount -o remount /dev/somedisk / thinking that that will get
> > rid of your /dev/ram0 root, that isn't the case, and you will corrupt
> > the device you remounted (I did it to a scratch monkey) very badly when
> > you write to the still mounted ramdisk.
>
> Ugh. mount -o remount ignores dev_name argument. It will change the

Ah.. didn't know that.

> flags of fs mounted from /dev/ram0 and will not even touch a /dev/somedisk.
> If you write to device you have mounted... Well, don't expect it to be pretty.

I knew the ramdisk would be history :)  It munged the disk though too.

> > You must exec a shell (or something) chrooted to your mounted harddisk
> > to un-busy the old root and then pivot_root/unmount that old root.  I
> > tested this, and all is well.
> >
> > I think this is a consequence of the multiple mount changes.. not sure.
> > (ergo cc to Al Viro.. he knows eeeeverything about mount points)
>
> I _really_ doubt that it has anything to multiple mounts. mount -o remount
> never unmounts anything. Never did. The rest is an obvious result - you
> leave fs mounted, you do direct write to its device, you see it fucked.
> The fact that it is a root doesn't matter. Relevant part of manpage:

I started imagining a possible connection when I saw two root entries
in proc/mounts.

	-Mike

Re: Ramdisk (and other) problems with 2.4.2

[Andries.Brouwer]

> Andries, comments?

> remount
>    Attempt  to  change the mount flags of
>    already-mounted file system.  This is commonly
>    used to make a readonly file system writeable.

Yes. But maybe "mount flags" is too narrow?
It is up to the filesystem what precisely it does.
What about

remount
        Attempt to remount an  already-mounted  file
        system.  This is commonly used to change the
        mount flags for a file system, especially to
        make  a  readonly  file system writeable. It
        does not change device or mount point.
?

Andries

Re: Ramdisk (and other) problems with 2.4.2

[David Weinehall]

On Fri, Mar 09, 2001 at 08:23:43PM +0100, Andries.Brouwer@cwi.nl wrote:
> > Andries, comments?
> 
> > remount
> >    Attempt  to  change the mount flags of
> >    already-mounted file system.  This is commonly
> >    used to make a readonly file system writeable.
> 
> Yes. But maybe "mount flags" is too narrow?
> It is up to the filesystem what precisely it does.
> What about
> 
> remount
>         Attempt to remount an  already-mounted  file
>         system.  This is commonly used to change the
>         mount flags for a file system, especially to
>         make  a  readonly  file system writeable. It
>         does not change device or mount point.

Why not emphasize the last sentence, and write

"It cannot change device or mount point." instead.


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </