Message-ID: <564DE4477544D411AD2C00508BDF0B6A0C9DD0FE@usahm018.exmi01.exch.eds.com>
From: "Post, Mark K" <mark.post@eds.com>
To: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: PROBLEM: kernel mount of initrd fails unless mke2fs uses 1024 byt
	e blocks
Date: Tue, 9 Apr 2002 16:47:13 -0400 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org

[1.] One line summary of the problem:
	Trying to use an initrd for an installation fails unless the mke2fs
used a blocksize of 1024 bytes.

[2.] Full description of the problem/report:
	I'm trying to create a Linux for S/390 version 2.2.20 installation
kernel/ramdisk set.  When I create the ramdisk, if I issue the mke2fs
command with -b 2048 or -b 4096, it works fine.  But, I try to boot the
system, I get an "EXT2-fs: Magic mismatch, very weird !" error when the
kernel tries to mount the ramdisk as the root file system.  If I let the
blocksize default, or specify -b 1024, everything works fine.

The comparison that seems to be failing is at line 500 of
linux/fs/ext/super.c:
                if (es->s_magic != le16_to_cpu(EXT2_SUPER_MAGIC)) {
                        printk ("EXT2-fs: Magic mismatch, very weird !\n");
                        goto failed_mount;

I put in a couple of printk lines just before the "if" statement, and when
trying to use an initrd with a "bad" blocksize, the value at es->s_magic is
binary zeros.  The value generated by le16_to_cpu(EXT2_SUPER_MAGIC is a
decimal 21487 = 0x53EF.  When the initrd has a 1024 byte blocksize, the
value at es->s_magic matches correctly.

[3.] Keywords (i.e., modules, networking, kernel):
	initrd, mke2fs, blocksize

[4.] Kernel version (from /proc/version):

[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
	N/A

[6.] A small shell script or example program which triggers the problem (if
possible)
	N/A

[7.] Environment
	Linux 2.2.20, "vanilla" from kernel.org, compiled on a Linux/390
2.2.18 system, again, "vanilla" from kernel.org.

[7.1.] Software (add the output of the ver_linux script here)
	This information is from the *building* Linux system, not the
failing one:
# sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux slackware 2.2.18 #2 SMP Mon Mar 26 15:04:40 EST 2001 s390 unknown

Gnu C                  2.95.2
Gnu make               3.79.1
binutils               2.10.1
util-linux             2.11b
mount                  2.11f
modutils               2.4.6
e2fsprogs              1.22
reiserfsprogs          3.x.0j
Linux C Library        2.1.3
ldd: version 1.9.9
Procps                 2.0.7
Net-tools              1.60
Kbd                    command
Sh-utils               2.0
Modules Loaded         nfsd

[7.2.] Processor information (from /proc/cpuinfo):
	This information is from the *building* Linux system, not the
failing one:
# cat /proc/cpuinfo
vendor_id       : IBM/S390
# processors    : 4
bogomips per cpu: 98.50
processor 0: version = FF,  identification = 100003,  machine = 9672
processor 1: version = FF,  identification = 200003,  machine = 9672
processor 2: version = FF,  identification = 300003,  machine = 9672
processor 3: version = FF,  identification = 400003,  machine = 9672

[7.3.] Module information (from /proc/modules):
	This information is from the *building* Linux system, not the
failing one:
# cat /proc/modules
nfsd                  190816   1 (autoclean)

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
	N/A

[7.5.] PCI information ('lspci -vvv' as root)
	N/A

[7.6.] SCSI information (from /proc/scsi/scsi)
	N/A

[7.7.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):
	None.


Mark Post
-
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/