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=<[email protected]>, size=1830, class=-60, nrcpts=1, msgid=<[email protected]>, bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=vger.kernel.org [199.183
.24.194]
Mar 7 10:34:26 chaos sendmail[17994]: f27FYJh17986: to=<[email protected]>, 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.
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
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.
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
> 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
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.
On Wed, 7 Mar 2001 [email protected] 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/1done
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/1done
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.
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
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
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.
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.
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 ;-)
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
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.
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
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
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
> 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
On Fri, Mar 09, 2001 at 08:23:43PM +0100, [email protected] 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 <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
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.