From: vda <vda@port.imtp.ilyichevsk.odessa.ua>
To: Andreas Steinmetz <ast@domdv.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUG] 2.4.16pre1: minix initrd does not work, ext2 does
Date: Wed, 28 Nov 2001 12:18:45 -0200 [thread overview]
Message-ID: <01112812184503.00924@manta> (raw)
In-Reply-To: <XFMail.20011127151356.ast@domdv.de>
In-Reply-To: <XFMail.20011127151356.ast@domdv.de>
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)
next prev parent reply other threads:[~2001-11-28 10:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-27 17:49 [BUG] 2.4.16pre1: minix initrd does not work, ext2 does vda
2001-11-27 14:13 ` Andreas Steinmetz
2001-11-28 14:18 ` vda [this message]
2001-11-28 17:41 ` vda
2001-11-30 12:21 ` vda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01112812184503.00924@manta \
--to=vda@port.imtp.ilyichevsk.odessa.ua \
--cc=ast@domdv.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox