[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
From: "Post, Mark K" <[email protected]>
[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;
Well, we can read the source.
ext2_read_super() starts finding a blocksize:
blocksize = get_hardblocksize(dev);
and buffer.c:get_hardblocksize() returns hardsect_size[major][minor].
rd.c sets hardsect_size[] to rd_hardsec, and initializes rd_hardsec
to RDBLK_SIZE, which is 512.
OK, so blocksize = 512.
Next,
if (blocksize < BLOCK_SIZE)
blocksize = BLOCK_SIZE;
So, now it is 1024.
Then bread (dev, 1, blocksize) reads the wrong part,
if in reality blocksize was different.
I once submitted a patch for this, but apparently it is not in 2.2.20.
Might do so later this evening, if there is time.
Andries
From: "Post, Mark K" <[email protected]>
[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 answered:
I once submitted a patch for this, but apparently it is not in 2.2.20.
but was too hasty.
I recalled a buglet here, that was fixed in 2.4 and is still in 2.2,
and indeed, there is such a buglet, but your problem is elsewhere.
The kernel does set_blocksize() to change the blocksize of your
device. This set_blocksize() throws away all buffers with the
now incorrect size. But your device is a ramdisk, and throwing
out these buffers kills all your data.
So, after doing that, you have an empty ramdisk again.
Hence mount fails.
Andries
Andries,
Thanks for the update. So, what do I do now? Wait for a fix for 2.2? Send
my problem report to someone else? Let me know.
Mark Post
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, April 12, 2002 4:41 PM
To: [email protected]; [email protected];
[email protected]
Cc: [email protected]
Subject: Re: PROBLEM: kernel mount of initrd fails unless mke2fs uses
1024 byt e blocks
From: "Post, Mark K" <[email protected]>
[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 answered:
I once submitted a patch for this, but apparently it is not in 2.2.20.
but was too hasty.
I recalled a buglet here, that was fixed in 2.4 and is still in 2.2,
and indeed, there is such a buglet, but your problem is elsewhere.
The kernel does set_blocksize() to change the blocksize of your
device. This set_blocksize() throws away all buffers with the
now incorrect size. But your device is a ramdisk, and throwing
out these buffers kills all your data.
So, after doing that, you have an empty ramdisk again.
Hence mount fails.
Andries
The kernel does set_blocksize() to change the blocksize of your
device. This set_blocksize() throws away all buffers with the
now incorrect size. But your device is a ramdisk, and throwing
out these buffers kills all your data.
Andries,
Thanks for the update. So, what do I do now?
Wait for a fix for 2.2? Send my problem report to someone else?
First you check whether my analysis is correct:
check that after the failed mount attempt the ramdisk
does not hold any data anymore. (Say with od or so.)
Now we have a known problem. You can avoid meeting it
by only using blocksize 1024. On the kernel side this
of course will have to be fixed some time.
I think Adam Richter once submitted a patch to fix this,
but apparently it was not taken.
For 2.5 I think the aim must be to get rid of set_blocksize()
entirely. I don't know whether 2.2 and 2.4 will be fixed.
Andries