lkml.org 
[lkml]   [2001]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ramdisk (and other) problems with 2.4.2
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.063 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site