RE: [BUG] 2.4.16pre1: minix initrd does not work, ext2 does

RE: [BUG] 2.4.16pre1: minix initrd does not work, ext2 does

[Andreas Steinmetz]

Well, no pointer but the same effect with 2.4.15pre7 and romfs (as posted
earlier to the list). It seems initrd handling is fs type picky :-(

Just to repeat myself:

1. the romfs initrd is fine, loop mounting it works.
2. the romfs initrd is detected at boot time.
3. the romfs initrd is not root mounted at boot time, thus without a root fs
   the kernel panics.
4. Doing the same with an ext2 initrd works fine.

Not really nice for systems where the only reason ext2 is compiled in the kernel
is this initrd behaviour.

On 27-Nov-2001 vda wrote:
> Hi,
> 
> I have 2 slackware initrds, one with minix fs on it, other with ext2.
> 
> I compiled 2.4.13 and it panics (can't mount root fs) (don't remember with 
> both initrds or only with minix one...).
> 
> I copied .config to 2.4.10, did make oldconfig and all that other reqd makes,
> and it boots both initrds.
> 
> Finally I tried it with 2.4.16pre1 (came .config again) 
> and it cannot mount minix initrd.
> ("FAT: bogus sector size 0","VFS: unable to mount root fs")
> I further tested and that initrd CAN be mounted by 2.4.16pre1 
> over loopback device with
> 
># mount -o loop /tmp/initrd.minix /mnt/mnt
> 
> and
> 
># mount -t fat,minix -o loop /tmp/initrd.minix /mnt/mnt
> 
> (so we can't blame FAT for first saying "Yes it's fat, don't probe for 
> others" and then "it is corrupted, can't use")
> 
> Seems there is some problem with fs detection order during root fs mount.
> (minix isn't tried at all?) However, I failed to grok what affect order of fs
> type guessing at boot... can somebody point me where to look?
> --
> vda
> -
> 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/
> 

Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH

[BUG] 2.4.16pre1: minix initrd does not work, ext2 does

[vda]

Hi,

I have 2 slackware initrds, one with minix fs on it, other with ext2.

I compiled 2.4.13 and it panics (can't mount root fs) (don't remember with 
both initrds or only with minix one...).

I copied .config to 2.4.10, did make oldconfig and all that other reqd makes, 
and it boots both initrds.

Finally I tried it with 2.4.16pre1 (came .config again) 
and it cannot mount minix initrd.
("FAT: bogus sector size 0","VFS: unable to mount root fs")
I further tested and that initrd CAN be mounted by 2.4.16pre1 
over loopback device with

# mount -o loop /tmp/initrd.minix /mnt/mnt

and

# mount -t fat,minix -o loop /tmp/initrd.minix /mnt/mnt

(so we can't blame FAT for first saying "Yes it's fat, don't probe for 
others" and then "it is corrupted, can't use")

Seems there is some problem with fs detection order during root fs mount.
(minix isn't tried at all?) However, I failed to grok what affect order of fs
type guessing at boot... can somebody point me where to look?
--
vda

Re: [BUG] 2.4.16pre1: minix initrd does not work, ext2 does

[vda]

On Tuesday 27 November 2001 12:13, Andreas Steinmetz wrote:
> Well, no pointer but the same effect with 2.4.15pre7 and romfs (as posted
> earlier to the list). It seems initrd handling is fs type picky :-(
>
> Just to repeat myself:
>
> 1. the romfs initrd is fine, loop mounting it works.
> 2. the romfs initrd is detected at boot time.
> 3. the romfs initrd is not root mounted at boot time, thus without a root
> fs the kernel panics.
> 4. Doing the same with an ext2 initrd works fine.

Ok, here what I did to further investigate initrd problem:

ext2.gz contains gzipped ext2 ramdisk image.
minix.gz contains gzipped minix ramdisk image.
minix is gunzipped minix.gz.

Initrd          2.4.10  2.4.13,2.4.16pre1
--------------- ------- -----------------
ext2.gz         ok      ok
minix.gz        ok      minix fs not detected (bad fs magic)
minix           ok      minix magic ok, can't open console, can't find init

(2.4.16pre1 was instrumented to show minix magic etc)

As you can see, we have decompression bug: results for
compressed and uncompressed minix ramdisks are different.
Or maybe kernel corrupts ramdisk image after gunzip.
I'm puzzled...

Guys, who fiddled with zlib/ramdisk/??? in 2.4.11 - 2.4.13 range?

Intrumenting diff attached.
Test tarball with both initrd images and both kernels is at
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/initrd.tar.bz2
(4.5 meg file). It is designed to be started from DOS
via loadlin or linld. Problem is not in loaders since both preform
identically.
--
vda

diff -u --recursive linux-2.4.16pre1-orig/fs/minix/inode.c 
linux-2.4.16pre1-new/fs/minix/inode.c
--- linux-2.4.16pre1-orig/fs/minix/inode.c	Sun Sep 30 17:26:08 2001
+++ linux-2.4.16pre1-new/fs/minix/inode.c	Wed Nov 28 01:52:30 2001
@@ -119,6 +119,10 @@
 	return 0;
 }
 
+/* Defined nowhere. Used to trigger link errors.
+*/
+extern void compile_time_bug_here(void);
+
 static struct super_block *minix_read_super(struct super_block *s, void 
*data,
 				     int silent)
 {
@@ -131,12 +135,16 @@
 	unsigned int hblock;
 	struct minix_sb_info *sbi = &s->u.minix_sb;
 
+	printk("VDA: entered minix_read_super\n");
+	
 	/* N.B. These should be compile-time tests.
 	   Unfortunately that is impossible. */
-	if (32 != sizeof (struct minix_inode))
-		panic("bad V1 i-node size");
+	if (32 != sizeof(struct minix_inode))
+		compile_time_bug_here();
+		//panic("bad V1 i-node size");
 	if (64 != sizeof(struct minix2_inode))
-		panic("bad V2 i-node size");
+		compile_time_bug_here();
+		//panic("bad V2 i-node size");
 
 	hblock = get_hardsect_size(dev);
 	if (hblock > BLOCK_SIZE)
@@ -160,6 +168,11 @@
 	sbi->s_log_zone_size = ms->s_log_zone_size;
 	sbi->s_max_size = ms->s_max_size;
 	s->s_magic = ms->s_magic;
+	printk("VDA: ms->s_magic = %lu\n",ms->s_magic);
+	printk("VDA: MINIX_SUPER_MAGIC   %lu\n",MINIX_SUPER_MAGIC  );
+	printk("VDA: MINIX_SUPER_MAGIC2  %lu\n",MINIX_SUPER_MAGIC2 );
+	printk("VDA: MINIX2_SUPER_MAGIC  %lu\n",MINIX2_SUPER_MAGIC );
+	printk("VDA: MINIX2_SUPER_MAGIC2 %lu\n",MINIX2_SUPER_MAGIC2);
 	if (s->s_magic == MINIX_SUPER_MAGIC) {
 		sbi->s_version = MINIX_V1;
 		sbi->s_dirsize = 16;
@@ -242,7 +255,7 @@
 	goto out_freemap;
 
 out_no_root:
-	if (!silent)
+	//if (!silent)
 		printk("MINIX-fs: get root inode failed\n");
 	goto out_freemap;
 
@@ -257,12 +270,12 @@
 	goto out_release;
 
 out_no_map:
-	if (!silent)
+	//if (!silent)
 		printk ("MINIX-fs: can't allocate map\n");
 	goto out_release;
 
 out_no_fs:
-	if (!silent)
+	//if (!silent)
 		printk("VFS: Can't find a Minix or Minix V2 filesystem on device "
 		       "%s.\n", kdevname(dev));
     out_release:
@@ -275,7 +288,7 @@
 
 out_bad_sb:
 	printk("MINIX-fs: unable to read superblock\n");
- out:
+out:
 	return NULL;
 }
 
diff -u --recursive linux-2.4.16pre1-orig/fs/super.c 
linux-2.4.16pre1-new/fs/super.c
--- linux-2.4.16pre1-orig/fs/super.c	Mon Nov 26 20:17:18 2001
+++ linux-2.4.16pre1-new/fs/super.c	Wed Nov 28 01:18:59 2001
@@ -1021,7 +1021,9 @@
 			kdevname(ROOT_DEV));
 	}
 
+	printk ("VDA: check_disk_change\n");
 	check_disk_change(ROOT_DEV);
+	printk ("VDA: get_super\n");
 	sb = get_super(ROOT_DEV);
 	if (sb) {
 		/* FIXME */
@@ -1036,6 +1038,7 @@
 		struct file_system_type * fs_type = get_fs_type(p);
 		if (!fs_type)
   			continue;
+		printk ("VDA: read_super %s\n", p);
   		sb = read_super(ROOT_DEV, bdev, fs_type,
 				root_mountflags, root_mount_data);
 		if (sb) 

Re: [BUG] 2.4.16pre1: minix initrd does not work, ext2 does

[vda]

On Wednesday 28 November 2001 12:18, vda wrote:
> ext2.gz contains gzipped ext2 ramdisk image.
> minix.gz contains gzipped minix ramdisk image.
> minix is gunzipped minix.gz.
>
> Initrd          2.4.10  2.4.13,2.4.16pre1
> --------------- ------- -----------------
> ext2.gz         ok      ok
> minix.gz        ok      minix fs not detected (bad fs magic)
> minix           ok      minix magic ok, can't open console, can't find init
>
> (2.4.16pre1 was instrumented to show minix magic etc)
>
> As you can see, we have decompression bug: results for
> compressed and uncompressed minix ramdisks are different.
> Or maybe kernel corrupts ramdisk image after gunzip.
> I'm puzzled...
>
> Guys, who fiddled with zlib/ramdisk/??? in 2.4.11 - 2.4.13 range?

I narrowed it down to 2.4.10 -> 2.4.12 (2.4.11-dontuse wasn't tested)
2.4.10 can boot my minix initrd, 2.4.12 can't.
--
vda

Re: [BUG] 2.4.16pre1: minix initrd does not work, ext2 does

[vda]

On Wednesday 28 November 2001 15:41, vda wrote:
> On Wednesday 28 November 2001 12:18, vda wrote:
> > ext2.gz contains gzipped ext2 ramdisk image.
> > minix.gz contains gzipped minix ramdisk image.
> > minix is gunzipped minix.gz.
> >
> > Initrd          2.4.10  2.4.13,2.4.16pre1
> > --------------- ------- -----------------
> > ext2.gz         ok      ok
> > minix.gz        ok      minix fs not detected (bad fs magic)
> > minix           ok      minix magic ok, can't open console and find init
> >
> > (2.4.16pre1 was instrumented to show minix magic etc)
> >
> > As you can see, we have decompression bug: results for
> > compressed and uncompressed minix ramdisks are different.
> > Or maybe kernel corrupts ramdisk image after gunzip.
> > I'm puzzled...
> >
> > Guys, who fiddled with zlib/ramdisk/??? in 2.4.11 - 2.4.13 range?
>
> I narrowed it down to 2.4.10 -> 2.4.12 (2.4.11-dontuse wasn't tested)
> 2.4.10 can boot my minix initrd, 2.4.12 can't.

Well, I'm still can't find out what was broken there...
A couple of negative info: bootloader isn't guilty, 
initrd is NOT corrupted: when 2.4.13 is booted with 'noinitrd', I can dump
initrd 'cat /dev/initrd > file' and it's perfectly mountable via loop device
(good, usable minix fs there). Same with gzipped minix - good fs
after ungzipping. These two even compare ok (no difference).
I presume this means that initrd is not tampered with in RAM.
Something bad must be happening when initrd is copied to ramdisk
or when ramdisk is mounted. Both seem unlikely because
rd.c diff between 2.4.10 and .12 is tiny (see below)
and ramdisk mount is tested from userspace (ok),
but something *must be* broken there or I'm doing something stupid.

My test minix.gz is here (btw: it's unmodified slackware one,
~1.4 meg):
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/minix.gz

I'll be glad if anyone will try to reproduce initrd problem
with 2.4.x, x>=12 with this image.

Andreas, can you give me your image for testing?
--
vda

diff -u --recursive linux-2.4.10/drivers/block/rd.c 
linux-2.4.12/drivers/block/rd.c
--- linux-2.4.10/drivers/block/rd.c	Sun Sep 23 14:44:37 2001
+++ linux-2.4.12/drivers/block/rd.c	Mon Oct  8 16:25:14 2001
@@ -276,7 +276,6 @@
 			if (!Page_Uptodate(page)) {
 				memset(kmap(page), 0, PAGE_CACHE_SIZE);
 				kunmap(page);
-				flush_dcache_page(page);
 				SetPageUptodate(page);
 			}

@@ -301,8 +300,11 @@
 		kunmap(page);
 		bh_kunmap(sbh);

-		if (rw != READ)
+		if (rw == READ) {
+			flush_dcache_page(page);
+		} else {
 			SetPageDirty(page);
+		}
 		if (unlock)
 			UnlockPage(page);
 		__free_page(page);