I'm trying to persuade an RHEL3.9 PAE kernel running on a machine
with 4GB RAM to let me create a ~1Gb ramdisk and the results
are, um, vexatious.
I start the kernel with the requisite ramdisk_size=nKb where I've
tried various values of n like 1000000 and 1048576. After the
kernel boots I say:
dd if=/dev/zero of=/dev/ram1 bs=1k count=n
...and dd reports success writing to the device. I then say:
mkfs.ext2 /dev/ram1
...followed by:
fsck.ext2 -f /dev/ram1
...and I see this:
e2fsck 1.32 (09-Nov-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/ram1: 11/131072 files (0.0% non-contiguous), 4127/262144 blocks
...and everybody appears to be happy. If I generate a hexdump
of the device I see the expected sort of glop:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000010 - etc...
00000400 00 00 02 00 00 00 04 00 33 33 00 00 E1 EF 03 00
........33......
00000410 F5 FF 01 00 00 00 00 00 02 00 00 00 02 00 00 00
................
00000420 00 80 00 00 00 80 00 00 00 40 00 00 00 00 00 00 [EMAIL
PROTECTED]
00000430 AC 49 8A 48 00 00 20 00 53 EF 01 00 01 00 00 00 .I.H..
.S.......
00000440 AC 49 8A 48 00 4E ED 00 00 00 00 00 01 00 00 00
.I.H.N..........
00000450 00 00 00 00 0B 00 00 00 80 00 00 00 00 00 00 00
................
00000460 02 00 00 00 01 00 00 00 BC 85 6E EC 56 B1 46 65
..........n.V.Fe
00000470 95 AA CA CB 96 52 24 C7 00 00 00 00 00 00 00 00
.....R$.........
00000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000490 - etc...
000004e0 00 00 00 00 00 00 00 00 00 00 00 00 AE 55 AB 2B
.............U.+
000004f0 F2 6D 49 80 90 BE 4A BC 8B 3D 5F C4 02 00 00 00
.mI...J..=_.....
00000500 00 00 00 00 00 00 00 00 AC 49 8A 48 00 00 00 00
.........I.H....
00000510 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000520 - etc...
00001000 02 00 00 00 03 00 00 00 04 00 00 00 F7 7D F5 3F
.............}.?
00001010 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00001020 02 80 00 00 03 80 00 00 04 80 00 00 FC 7D 00 40
.............}.@
00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00001040 00 00 01 00 01 00 01 00 02 00 01 00 FE 7D 00 40
.............}.@
00001050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00001060 02 80 01 00 03 80 01 00 04 80 01 00 FC 7D 00 40
.............}.@
00001070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00001080 00 00 02 00 01 00 02 00 02 00 02 00 FE 7D 00 40
.............}.@
00001090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
000010a0 02 80 02 00 03 80 02 00 04 80 02 00 FC 7D 00 40
.............}.@
000010b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
.
.
.
...but when I then say:
mount /dev/ram1 /mnt/test
...I immediately see this:
mount: wrong fs type, bad option, bad superblock on /dev/ram1,
or too many mounted file systems
...whereupon the same fsck command now says this:
e2fsck 1.32 (09-Nov-2002)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/ram1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
...and the hexdump now shows this:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
WTF?!?!
Since there's nothing subtle about this b0rken behavior I assumed
that I'd have no trouble finding stuff on the WWW that explains
how this is all my own stooopid fault but, so far, nothing...
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
