Messages in this thread | | | Date | Fri, 9 Mar 2001 19:28:02 +0100 (CET) | From | Mike Galbraith <> | Subject | Re: 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/
| |