Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I have two 2TB drives set up as a JBOD which need to be checked. When I boot normally under ffp using a USB stick (to ultimately run the fsck on the array) it gives me the correct size of 4TB:
root@server:~# mdadm -A /dev/md0 /dev/sd[ab]2
mdadm: /dev/md0 has been started with 2 drives.
root@server:/ffp# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.01
Creation Time : Thu Sep 6 21:25:45 2012
Raid Level : linear
Array Size : 3904939520 (3724.04 GiB 3998.66 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Sep 6 21:25:45 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Rounding : 64K
UUID : ed667f13:286e48b4:03b4208b:5d3ea322
Events : 0.1
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2But when I boot using Fonz' fsck package, I get an array of only 2TB:
root@server:~# mdadm -A /dev/md0 /dev/sd[ab]2
mdadm: /dev/md0 has been started with 2 drives.
root@server:~# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Fri Sep 7 01:25:45 2012
Raid Level : linear
Array Size : 1757455872 (1676.04 GiB 1799.63 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 7 01:25:45 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Rounding : 64K
UUID : ed667f13:286e48b4:03b4208b:5d3ea322
Events : 0.1
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2When I run fsck using Fonz' package it complains that the partition size doesn't match the size in the superblock (understandably) so fsck fails. Why would mdadm fail to create the array properly? Thankfully I was able to run fsck on the array after booting off of a USB but I would prefer to use the fsck package that Fonz provided.
Thanks!
Offline
It's an overflow bug. The array size is 3904939520 KiB, which equals 168C0A600 hex. If I strip the 33th bit, I get 68C0A600, which equals 1757455872 KiB, exactly the size of the 'faulty' array. So 'something' is limited to 32 bits. I'm not sure which part. I think it's the raid layer itself. It's the only part which works in KiB, I think. The disk unit is sector, 512 bytes, while the filesystem uses clusters of 4KiB.
The fonz fsck package reloads the kernel. Maybe the provided kernel has not large block device support. Have you tried one of the other kernels?
Offline
Mijzelf wrote:
It's an overflow bug. The array size is 3904939520 KiB, which equals 168C0A600 hex. If I strip the 33th bit, I get 68C0A600, which equals 1757455872 KiB, exactly the size of the 'faulty' array. So 'something' is limited to 32 bits. I'm not sure which part. I think it's the raid layer itself. It's the only part which works in KiB, I think. The disk unit is sector, 512 bytes, while the filesystem uses clusters of 4KiB.
The fonz fsck package reloads the kernel. Maybe the provided kernel has not large block device support. Have you tried one of the other kernels?
Thanks for the explanation. I suspected something similar but had no idea how to confirm it as you just did!
I did try the other two kernels provided:
zImage-2.6.25.1 did boot but never showed any of my hard drives. No /dev/sd* devices existed so I could not build the array.
zImage-2.6_orion just hangs when I try to reboot with that kernel
any idea how I can get either of these kernels to work?
Offline
No. But maybe you can extract your stock kernel from flash.
Offline
Mijzelf wrote:
No. But maybe you can extract your stock kernel from flash.
Not sure how to do this--any pointers?
Offline
The Wiki tells how to overwrite the kernel in flash. That is not a good idea, of course, but it can be reverted:
dd if=/dev/mtdblock2 of=kernel.bin
I *think* this will be an uImage, which means it has an 64 bytes header. 'file kernel.bin' can tell. reload.ko needs a raw image, so in that case the 1st 64 bytes need to be stripped.
Offline
Here's what I got:
root@server# dd if=/dev/mtdblock2 of=kernel.bin 3072+0 records in 3072+0 records out 1572864 bytes (1.6 MB) copied, 0.713983 s, 2.2 MB/s root@server# file kernel.bin kernel.bin: u-boot legacy uImage, Linux-2.6.12.6-arm1, Linux/ARM, OS Kernel Image (Not compressed), 1490204 bytes, Sun Nov 29 23:43:29 2009, Load Address: 0x00008000, Entry Point: 0x00008000, Header CRC: 0x0F9A904F, Data CRC: 0x76C77329
do you know how I can then create the corresponding zImage file for use with Fonz' reload.sh script?
Last edited by citivolus (2015-11-10 00:06:55)
Offline
dd if=kernel.bin of=zImage.2.6.16.6-arm1 bs=64 skip=1
Offline
Thanks, I tried this and booted the kernel but it just hung...any suggestion how I can diagnose it?
Offline
Besides serial log? No
Offline
Mijzelf wrote:
Besides serial log? No
Can I access the serial log without a custom serial hardware cable? I've read about those and the mini project of building one is over my head.
Offline
You need an TTL 3.3V serial cable. Ebay has them from about 1 euro/dollar/pound and up.
Offline