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

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

[Andries.Brouwer]

    From: "Post, Mark K" <mark.post@eds.com>

    [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

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

[Andries.Brouwer]

        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

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

[Post, Mark K]

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: Andries.Brouwer@cwi.nl [mailto:Andries.Brouwer@cwi.nl]
Sent: Friday, April 12, 2002 4:41 PM
To: Andries.Brouwer@cwi.nl; linux-kernel@vger.kernel.org;
mark.post@eds.com
Cc: alan@lxorguk.ukuu.org.uk
Subject: Re: PROBLEM: kernel mount of initrd fails unless mke2fs uses
1024 byt e blocks



        From: "Post, Mark K" <mark.post@eds.com>

        [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

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

[Andries.Brouwer]

        From: "Post, Mark K" <mark.post@eds.com>

        [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

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

[Post, Mark K]

[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

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

[Post, Mark K]

[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