PROBLEM: kernel mount of initrd fails unless mke2fs uses 1024 byt e blocks

From: Post, Mark K (mark.post@eds.com)
Date: Fri Apr 12 2002 - 09:52:22 EST


[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/



This archive was generated by hypermail 2b29 : Mon Apr 15 2002 - 22:00:21 EST