Nobiscuit
Above average nerdiness
Installing Debian to disk on an ix2-200
Posted by on August 6, 2011
Warning: This completely removes the existing filesystems from disk and kernel images from the flash that ship with the ix2-200 and leaves you with a basic Debian install. Only do this if you understand what this means and have nothing important stored on the device.
Most of the information in this post is based on Diogo Gomes’ work on the iConnect.
uBoot Parameters
The first step in installing Debian that I did was to reconfigure the uBoot environment to fix a number of issues. This is done from the uBoot prompt, which is only accessible via a serial interface.
Update the MAC address of the disconnected ethernet port on the SoC to an address from an unused range so that udev doesn’t get confused:
setenv ethaddr AA:00:00:00:00:01
Enable booting of a standard linux kernel
setenv mainlineLinux yes setenv arcNumber 1682
Save and reset
saveenv reset
Booting the Debian installer and completing the install
I used the published debian installer images from here copied to a ext2 formatted usb stick. I connected the usb stick to the front port of the ix2-200.
You should also have the ix2-200 connected to the internet somehow. A simple way of doing this for me was to connect to the Ethernet port of my laptop running Ubuntu and bridge it with the virtual bridge I use for running VirtualBox VMs and provides DHCP and NAT. Internet connectivity can than be used through another connection e.g. a home wireless connection. You can do this by running the following command on the laptop:
sudo brctl addif virbr0 eth0
From uBoot on the ix2-200, start the usb subsystem and load the netboot installer kernel and initial RAM disk into memory:
usb start ext2load usb 0:1 0x01100000 /uInitrd ext2load usb 0:1 0x00800000 /uImage
Set the boot arguments for the installer:
setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most
Boot the installer:
bootm 0x00800000 0x01100000
You can now go through the normal debian installation almost to the end. A few tips to get you through:
- Select eth1 for the network interface (eth0 doesn’t work).
- I used a single RAID1 instance across a single partition on each disk with LVM and volumes on top of that.
At the last step, the installer will tell you that it can’t make the system bootable. To get around this, we need to install the uboot utilities and save the uboot images to the usb stick.
First select the ‘Execute a shell’ from the Debian installer menu, and then chroot to your fresh Debian install:
chroot /target
Install the utilities:
apt-get install mtd-utils uboot-mkimage uboot-envtools
Change to the boot directory and convert kernel and initrd files to uboot format:
cd /boot mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d initrd.img-2.6.32-5-kirkwood uInitrd mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-5 -d vmlinuz-2.6.32-5-kirkwood uImage
Mount your usb memory stick and copy the new files to the memory stick:
mount /dev/sdXX /mnt cp uImage /mnt/uImage-new cp uInitrd /mnt/uInitrd-new
Exit the shell and reboot into uboot by selecting the “Finish the installation” option. At this point we should be able to now boot from disk using the uInitrd and uImage files on usb. Note that I also setup the mtd in the bootargs_console setting so we can write the kernel and initrd files to flash once we know it’s working. Replace the root value with what ever you setup during the install:
usb start setenv bootargs_console 'console=ttyS0,115200 mtdparts=orion_nand:0x300000@0x100000(uImage),0x1000000@0x540000(uInitrd) root=/dev/mapper/' setenv bootargs $(bootargs_console) ext2load usb 0:1 0x00800000 /uImage-new ext2load usb 0:1 0x01100000 /uInitrd-new bootm 0x00800000 0x01100000
Congratulations! You should now be in your debian install.
Configuration to boot from internal flash and disk
Login and become root, and execute the following command to confirm that the nand flash has been configured correctly:
# cat /proc/mtd dev: size erasesize name mtd0: 00300000 00004000 "uImage" mtd1: 01000000 00004000 "uInitrd"
We can now erase and flash the uImage and uInitrd files:
# flash_eraseall /dev/mtd0 Erasing 16 Kibyte @ 300000 -- 100 % complete. # flash_eraseall /dev/mtd1 Erasing 16 Kibyte @ 1000000 -- 100 % complete. # nandwrite -p /dev/mtd0 /boot/uImage ... # nandwrite -p /dev/mtd1 /boot/uInitrd ...
Reboot to get back the uBoot prompt to setup loading the kernel and initrd from flash. Replace the root value with what ever you setup during the install:
setenv mtdids 'nand0=orion_nand' setenv mtdparts 'mtdparts=orion_nand:0x100000@0x000000(uboot)ro,0x20000@0xA0000(uboot_env),0x300000@0x100000(uImage),0x1000000@0x540000(uInitrd)' setenv bootargs_console 'console=ttyS0,115200 mtdparts=orion_nand:0x300000@0x100000(uImage),0x1000000@0x540000(uInitrd) root=/dev/mapper/red_vg0-root' setenv bootcmd 'setenv bootargs $(bootargs_console); nand read 0x800000 uImage; nand read 0x1100000 uInitrd; bootm 0x00800000 0x01100000' saveenv reset
You should now be booting Debian from flash and disk.
Advertisements
Thank you for this 🙂 !
I follow your post and now I’ve got a tiny server who’s gonna be the pxe and nfs server for my dockstars !
a little typo ( I guess) :
..
# nandwrite -p /dev/mtd0 /boot/uInitrd
…
–> should’nt it be mtd1 (it’s what I’ve done) ?
You’re welcome! Thanks for spotting the error, I’ve updated it with the fix you’ve suggested.
Hi,
Great post! Thank you! Can you also post the performance achievements? For example: How many mb/s read/write can be archived with fresh debian+smbd. Or CPU usage at full load. Some real-world examples will be helpful. Thank you!
I haven’t done much testing, but using NFSv3 I can get >20MB/s read and write on large files e.g. 500MB. The CPU is ~80% at this rate. I haven’t tried samba.
I’ve also tried getting nfsv4 working using the instructions from here , but I’ve run into some strange behaviour where performance drops off significantly for larger files. I’ve posted to the linux-nfs mailing list about it and I’m hoping someone there can help.
thank you nigelr for your feedback! It much appreciated! can you please post some more info? mem used, top cpu utilization under load/idle etc? i’ve ix2-200 with stopped appweb and it shows nice read/write rates. with samba it shows sustained uncached 30 MB/s write and about 41 MB/s read with max cpu 30% (40-50 Gb bluray iso). also running trancemission eat about 10% cpu.
Much as I’d like to try, I don’t really want to setup samba just for testing the speed – perhaps someone else who has installed Debian might have a go?
Hi, great post.
I have a problem, when the system reboot after this commands:
>ext2load usb 0:1 0x00800000 /uImage-new
>ext2load usb 0:1 0x01100000 /uInitrd-new
>bootm 0x00800000 0x01100000
I have this log, Could do you help me?
Could you explain how did you configure raid1 and LVM?
odes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] NR_IRQS:114
[ 0.000000] Console: colour dummy device 80×30
[ 21.474998] Calibrating delay loop… 992.87 BogoMIPS (lpj=4964352)
[ 21.714910] Security Framework initialized
[ 21.714934] SELinux: Disabled at boot.
[ 21.714968] Mount-cache hash table entries: 512
[ 21.715342] Initializing cgroup subsys ns
[ 21.715361] Initializing cgroup subsys cpuacct
[ 21.715374] Initializing cgroup subsys devices
[ 21.715385] Initializing cgroup subsys freezer
[ 21.715394] Initializing cgroup subsys net_cls
[ 21.715463] CPU: Testing write buffer coherency: ok
[ 21.716428] devtmpfs: initialized
[ 21.718455] regulator: core version 0.5
[ 21.718720] NET: Registered protocol family 16
[ 21.719337] Kirkwood: MV88F6281-A0, TCLK=200000000.
[ 21.719353] Feroceon L2: Enabling L2
[ 21.719393] Feroceon L2: Cache support initialised.
[ 21.720520] Kirkwood PCIe port 0:
[ 21.720528] link down, ignoring
[ 21.721824] bio: create slab at 0
[ 21.722159] vgaarb: loaded
[ 21.722710] Switching to clocksource orion_clocksource
[ 21.727500] NET: Registered protocol family 2
[ 21.727795] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 21.728713] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 21.728933] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[ 21.729047] TCP: Hash tables configured (established 8192 bind 8192)
[ 21.729058] TCP reno registered
[ 21.729241] NET: Registered protocol family 1
[ 21.729456] Unpacking initramfs…
[ 22.179991] Freeing initrd memory: 5704K
[ 22.180124] NetWinder Floating Point Emulator V0.97 (double precision)
[ 22.180422] audit: initializing netlink socket (disabled)
[ 22.180463] type=2000 audit(0.690:1): initialized
[ 22.188302] VFS: Disk quotas dquot_6.5.2
[ 22.188620] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 22.188739] JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
[ 22.189514] msgmni has been set to 499
[ 22.191565] alg: No test for stdrng (krng)
[ 22.191710] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 22.191725] io scheduler noop registered
[ 22.191734] io scheduler anticipatory registered
[ 22.191743] io scheduler deadline registered
[ 22.191969] io scheduler cfq registered (default)
[ 22.199228] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 22.199803] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[ 22.532241] console [ttyS0] enabled
[ 22.536423] NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND 128MiB 3,3V 8-bit)
[ 22.544951] Scanning device for bad blocks
[ 22.587003] 2 cmdlinepart partitions found on MTD device orion_nand
[ 22.593311] Creating 2 MTD partitions on “orion_nand”:
[ 22.598484] 0x000000100000-0x000000400000 : “uImage”
[ 22.604178] 0x000000540000-0x000001540000 : “uInitrd”
[ 22.610476] mice: PS/2 mouse device common for all mice
[ 22.616057] rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0
[ 22.621995] i2c /dev entries driver
[ 22.625756] cpuidle: using governor ladder
[ 22.630016] cpuidle: using governor menu
[ 22.634057] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
[ 22.640468] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
[ 22.682785] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[ 22.722783] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
[ 22.762780] mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
[ 22.802780] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
[ 22.809708] TCP cubic registered
[ 22.812982] NET: Registered protocol family 17
[ 22.817861] registered taskstats version 1
[ 22.822820] rtc-mv rtc-mv: setting system clock to 2011-10-31 19:36:29 UTC (1320089789)
[ 22.830926] Initalizing network drop monitor service
[ 22.835996] Freeing init memory: 124K
Loading, please wait…
[ 22.933272] udev[44]: starting version 164
[ 23.343108] SCSI subsystem initialized
[ 23.352831] MV-643xx 10/100/1000 ethernet driver version 1.4
[ 23.367263] mv643xx_eth smi: probed
[ 23.469221] mmc0: mvsdio driver initialized, using GPIO 28 for card detection
[ 23.477948] net eth0: port 0 with MAC address aa:00:00:00:00:01
[ 23.570168] net eth1: port 0 with MAC address 00:d0:b8:0c:6f:ae
[ 23.600315] usbcore: registered new interface driver usbfs
[ 23.607400] usbcore: registered new interface driver hub
[ 23.613579] usbcore: registered new device driver usb
[ 23.638715] sata_mv sata_mv.0: version 1.28
[ 23.644052] sata_mv sata_mv.0: slots 32 ports 2
[ 23.649461] scsi0 : sata_mv
[ 23.654147] ehci_hcd: USB 2.0 ‘Enhanced’ Host Controller (EHCI) Driver
[ 23.660787] scsi1 : sata_mv
[ 23.664210] ata1: SATA max UDMA/133 irq 21
[ 23.668328] ata2: SATA max UDMA/133 irq 21
[ 23.673664] orion-ehci orion-ehci.0: Marvell Orion EHCI
[ 23.685171] orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
[ 23.722768] orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000
[ 23.742751] orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
[ 23.748762] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 23.755607] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 23.762881] usb usb1: Product: Marvell Orion EHCI
[ 23.767613] usb usb1: Manufacturer: Linux 2.6.32-5-kirkwood ehci_hcd
[ 23.774006] usb usb1: SerialNumber: orion-ehci.0
[ 23.779801] usb usb1: configuration #1 chosen from 1 choice
[ 23.785822] hub 1-0:1.0: USB hub found
[ 23.789639] hub 1-0:1.0: 1 port detected
[ 24.112768] usb 1-1: new high speed USB device using orion-ehci and address 2
[ 24.192773] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[ 24.232829] ata1.00: ATA-8: ST31000520AS, CC32, max UDMA/133
[ 24.238543] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[ 24.273184] usb 1-1: New USB device found, idVendor=058f, idProduct=6254
[ 24.279923] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 24.287220] ata1.00: configured for UDMA/133
[ 24.291870] scsi 0:0:0:0: Direct-Access ATA ST31000520AS CC32 PQ: 0 ANSI: 5
[ 24.301120] usb 1-1: configuration #1 chosen from 1 choice
[ 24.307570] hub 1-1:1.0: USB hub found
[ 24.312153] hub 1-1:1.0: 4 ports detected
[ 24.812773] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[ 24.852797] ata2.00: ATA-8: ST31000520AS, CC32, max UDMA/133
[ 24.858497] ata2.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[ 24.902856] ata2.00: configured for UDMA/133
[ 24.907496] scsi 1:0:0:0: Direct-Access ATA ST31000520AS CC32 PQ: 0 ANSI: 5
[ 24.987233] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[ 24.995501] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[ 25.004589] sd 0:0:0:0: [sda] Write Protect is off
[ 25.009583] sd 1:0:0:0: [sdb] Write Protect is off
[ 25.014517] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
[ 25.023748] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
[ 25.034724] sda:
[ 25.036601] sdb: sda1 sda2
[ 25.079911] sd 0:0:0:0: [sda] Attached SCSI disk
[ 25.131965] sdb1 sdb2
[ 25.155828] sd 1:0:0:0: [sdb] Attached SCSI disk
Begin: Loading essential drivers … done.
Begin: Running /scripts/init-premount … done.
Begin: Mounting root file system … Begin: Running /scripts/local-top … Begin: Loading[ 25.537931] md: raid1 personality registered for level 1
Success: loaded module raid1.
done.
Begin: Assembling all MD arrays … [ 25.574616] md: md0 stopped.
[ 25.655047] md: bind
[ 25.666829] md: bind
[ 25.675742] raid1: md0 is not clean — starting background reconstruction
[ 25.682569] raid1: raid set md0 active with 2 out of 2 mirrors
[ 25.688771] md0: detected capacity change from 0 to 997997797376
mdadm: /dev/md/0 has been started with 2 drives.[ 25.699921] md0:
unknown partition table
Success: assembled all arrays.
done.
done.
Begin: Waiting for root file system … done.
Gave up waiting for root device. Common problems:
– Boot args (cat /proc/cmdline)
– Check rootdelay= (did the system wait long enough?)
– Check root= (did the system wait for the right device?)
– Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/ does not exist. Dropping to a shell!
BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.
/bin/sh: can’t access tty; job control turned off
(initramfs)
Thanks!!
“ALERT! /dev/mapper/ does not exist. Dropping to a shell!” is the clue where it’s going wrong. What was the name of the LVM volume that should be mounted as root? Once you have that, you should change root parameter when booting linux. E.g. for me I use vg0-root as the volume and the command is the following:
setenv bootargs_console ‘console=ttyS0,115200 mtdparts=orion_nand:0x300000@0x100000(uImage),0x1000000@0x540000(uInitrd) root=/dev/mapper/vg0-root’
Pingback: Recovering IOmega ix2-200 NAS after failed upgrade « Surviving Digital Chaos
By the way, there is also available an u-boot recovery file. If someone is interested in having it, just let me know.
is it just an updated uboot?
nigelr im considering putting up one of these blogs aswel to keep track of my own installation procedure and kernel building would you mind if i borrowed some of the stuff that you have done like the pictures and perhaps parts of your instructions? (because im lazy and dont wanna have to type everything again lol)
yeah, no worries 🙂
I’d be keen – is this from iomega?
Hey buddy,
I would love to have a copy if you still have it.
Much appreciated.
Regards,
Kris M
I did the same myself by accident erased uboot after booting wrong kernel any idea how to fix it would be great.
hi all, is there option to make nas go to sleep and spin off hard drives? that hdds run all the time is irriting me, and last week one of them fail after year 😦
better with original iomega fw, or something with web management, i am not so big linux geek 🙂
i think that something like run linux from usb stick will solve this. like here http://spblinux.de/arm9/README.txt
you could also look at using the hdparm command. hdparm -S 12 should allow the drive to power down after 1 minute of no activity. You’ll need to cut right back on logging to make this work properly though.
if i was playing with hdparm, after i send this command via putty i heard loud click when drive stop. but immediately after this click drives spin on again 😦
I think this is because there are applications still writing to the disk. Perhaps using USB is the best way of doing this, and it should be easy enough to redo the Debian install with a USB flash drive connected.
i’ve disabled all necesary services and processes like media scanning, twonkymedia, all bittorrents, axis, etc.. but still no luck. funny is, that power saving options in iomega webmanagement has no effect, iomega working on this issues for ages: https://iomega-eu-en.custhelp.com/app/answers/detail/a_id/26614/related/1 🙂
btw all my notes about ix2-200 is on this my site http://mikrom.cz/nas/
Hi 🙂
I was just looking for a little bit of comfort… I have enabled ssh login on my ix2-200 and ordered a USB- serial TTL cable but am continuing to read and research in the meantime….
root@ix2-200:/# uname -a
Linux ix2-200 2.6.22.18 #1 Fri Aug 27 11:33:30 EDT 2010 armv5tejl GNU/Linux
root@ix2-200:/# cat /proc/mtd
dev: size erasesize name
mtd0: 000c0000 00004000 “uboot”
mtd1: 00020000 00004000 “env”
mtd2: 00300000 00004000 “zImage”
mtd3: 00300000 00004000 “initrd”
My ‘mtd0’ nand partition is marked ‘uboot’ so I am really worried that if I ‘flash_erase’ that, then BANG I end up with a black brick and no uBoot on the 4-pin serial connector – erk!
Have I made an incorrect assumption somewhere?
Yes, you don’t want to touch the flash where uboot is. In my instructions I use the following:
setenv bootargs_console ‘console=ttyS0,115200 mtdparts=orion_nand:0x300000@0x100000(uImage),0x1000000@0x540000(uInitrd) root=/dev/mapper/’
This tells the kernel the flash partitions I want to use, and you’ll note that I’ve only included partitions for uImage and uInitrd which are well outside what is used for uboot (0x4000@0xc0000). This makes it much harder to accidentally overwrite uboot.
Ah OK I think I get it… output from my existing NAS still running Iomega’s software:
root@ix2-200:/# cat /proc/cmdline
console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0x0(uboot),0x20000@0xa0000(env),0x300000@0x100000(zImage),0x300000@0x540000(initrd),128m@0x0(flash)
I’m guessing the driver was called nand_mtd in the 2.6.32 kernel and changed to orion_nand in 3.x.
# dmesg | grep NAND
NAND device: Manufacturer ID: 0xad, Chip ID: 0x75 (Hynix NAND 32MiB 3,3V 8-bit)
It throws one question at me, though… From the /proc/cmdline output, I can see the 32MB flash is arranged like this:
0x0000000 – 0x00c0000 uBoot itself
0x00a0000 – 0x00c0000 uBoot’s configuration
0x0100000 – 0x0400000 Kernel
0x0540000 – 0x0840000 initial ramdisk
But hang on, isn’t the space for the uBoot configuration overlapping with the uBoot partition? Does that sound right?
Thanks for the fast response!
Final question for the moment – 0x0300000 of space is allocated for the initrd, which is 3145728 bytes, but the initrd at http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-armel/current/images/kirkwood/netboot/marvell/openrd/ is 3172565 bytes – surely too big to fit?
In my install instructions, 0x300000 is for uImage, not uInitrd. I use 0x1000000 for uInitrd.
It does overlap. I think this intentional by the people who designed uBoot, perhaps to allow the config to be addressed seperately and included in a single image that is written to the uboot partition.
Thanks for setting my mind at rest about the overlap – it makes sense.
re: initrd NAND size 0x1000000 vs 0x0300000 – doh… yes it had been a long day 🙂
Pingback: Recovering IOmega ix2-200 after failed upgrade
Nice – everything else works, but writing ext4 partition through samba from an other client does hang network and serial console.
Anyone knowing why this? Kernel version is 3.4.2.
I think kernel 3.4 is broken i had it on my ix2-200 and im using nfs and the kernel kept panicing and crashing. so i went back to the 3.3.8 kernel and no problems since im also using wheezy not squeeze so it could possibly be a problem with the samba version in squeeze.
I’m using 3.4.3 at the moment and it seems to work ok so far while using nfs. I don’t use samba though.
hmmm well it might be sumthing else then i am using a btrfs raid 0 array for the drives in the nas so that cud be the cause of the instability either
Can someone post the 3.0.18 kernel config file? The link for this appears to be broken.
Hi Gary, I’ve updated the relevant post with updated patches and configs. Hopefully google drive is more reliable than fileden: https://blog.nobiscuit.com/2012/02/15/kernel-patch-to-support-leds-buttons-and-sensors/
just tried the 3.5rc5 with the ix2-200 and it stops at waiting for the root partition on boot so we may have some trouble with the 3.5 kernel unless they have changed something else in the config maybe?
Thanks for your post, it has been very helpful for me!
You’re welcome!
Hi,
Thanks for putting this together, I’m 90% of the way there. I’m running into the same problem as Giancarlo. I first made the mistake of blindly copying your root= argument and not replacing it with the proper path. I recorded the message at the end of the install that said it couldn’t make the system bootable and to manually specify root=/dev/sdb2. Even after doing that it still doesn’t work. Upon further investigation I found that the blkid command returned the following:
/dev/sda1: SEC_TYPE=”msdos” UUID=”481A-E4E4″ TYPE=”vfat”
/dev/sdb1: UUID=”fe327467-69d2-4e49-92a6-bbc7e8cc8290″ TYPE=”ext2″
/dev/sdb2: UUID=”8cbd9022-848a-4306-8c24-bcc3979992bc” SEC_TYPE=”ext2″ TYPE=”ext3″
/dev/sdb5: UUID=”768eddb9-11b4-41c1-8391-b02edcaa09b7″ TYPE=”swap”
I’ve tried specifying /dev/sdb1 for root= as well and that didn’t work. What else could be wrong?
Thanks,
Todd
Oh and I’m not using LVM in case that matters for some reason.
Are sda and sdb always detected in the same order? Perhaps sometimes you want to boot off /dev/sda2 instead depending on what disk gets detected first? If that’s the case, you’ll want to specify the UUID in the boot command rather than the dev name.
Other than that, I’m really not sure.
That did it! After I left that message I did some more research and it was looking like that was the problem, but when I’d run blkid it would show /dev/sdb2 as pointing to the right drive/partition, so I’m not sure why it wasn’t working. But regardless, it is now.
For those interested, the exact syntax for the root command was as follows:
root=UUID=
Thanks again for putting this all together, I never would have figured this all out on my own!
Todd
Another question… I noticed after about a week the NAS will become unresponsive and I have to unplug and restart, won’t even respond to pings. When I look at the logs all I see is the following:
rsyslogd: [origin software=”rsyslogd” swVersion=”4.6.4″ x-pid=”670″ x-info=”http://www.rsyslog.com”] rsyslogd was HUPed, type ‘lightw
eight’.
Which I think is benign. Can you think of anything I can look at to see why the NAS is locking up?
Thanks,
Todd
Are you able to leave a console enabled on it? Perhaps it’s some kind of kernel panic? Are you just using the default kernel that comes with Debian?
You mean leave a serial console open to it? I can try that. My guess is some kind of kernel panic too, but I’m not getting much to go by (or I don’t know where to look). Yes, I’m just using the default kernel, no patches or anything custom.
Actually, just noticed it’s dead this morning after a reboot maybe 15 hours ago, usually it takes longer than that.
Thanks
Yeah, leave a serial console running on it. I haven’t seen it lock up before, but I haven’t rung the stock debian kernel in a long time so I can’t compare.
OK it crashed again and I have the kernel panic log, I can’t make any sense out of it so I put the log up here, didn’t want to clutter your blog with the entire thing:
http://toddnelson.net/nas-crash.txt
Ironically, that website is hosted on an Apache instance on this troubled NAS, so download the file before it crashes again! 🙂
Thanks,
Todd
It looks like some info is actually missing from that kernel oops, but maybe you want to try again and look at following the steps here to find more info on why it’s crashing? http://www.armadeus.com/wiki/index.php?title=Oops%2C_Linux_crashes
I obtained the crash dump by leaving an SSH session open to the NAS during the crash, not a local serial, not sure if that matters.
Still crashing, here’s another report with maybe some more info? Thanks for trying to help, I probably should have just stuck with Iomega’s firmware, this is just well above my troubleshooting abilities!
http://toddnelson.net/nas-crash2.txt
For now my “fix” is to add the following to /etc/sysctl.conf
“kernel.panic = 10”
In other words, reboot upon a kernel panic 🙂
Do you know of any way to get Windows to run on one of these boxes? I seem to remember reading that Windows 8 will be compatible with the Arm processor.
Todd
windows would be a waste of time on 1 of these for a start there is no graphics chip so you would not be able to see anything. i have had both squeeze and wheezy running on mine without issue for over a year.
have you not tried compileing a custom newer kernel to see if that fix’s your issue? or try wheezy instead of the old squeeze?
I hear what you’re saying about Windows, my comment was more anecdotal than anything else 🙂
It appears my problem is worse now, yesterday I ran an apt-get update/upgrade and updated several packages, now the box is crashing everyday. And to make matters worse it doesn’t seem to be rebooting automatically like I told it to! I’ve used Linux off and on for 10 years and this has generally been my experience, it just doesn’t work. But I realize that isn’t the experience of many people out there.
As for compiling a new kernel, I’ve tried but I usually hit a point where I get above my head and I give up. Maybe I’ll give it another shot and report back here with questions, I just hate to be that guy that’s bothering people who know what they’re doing with silly questions Don’t get me wrong, I’m not completely useless in Linux, I have no problem writing shell and RC scripts, setting up Apache, Samba, etc. but I’ve never had luck messing with kernels. The only way I was able to get Debian going on this was thanks to the great instructions on this blog.
Thanks guys,
Todd
Does it always crash inside ext3 i.e. does it always have the following line at the top of the stack trace near the end of the crash message?
[] (free_rb_tree_fname+0x10/0x84 [ext3]) from [] (ext3_readdir+0x134/0x6c4 [ext3])
If so it might be a kernel bug. If it’s different every time then it’s probably hardware related.
Yeah there’s always been some reference to ext3, didn’t think much of it. Could you possibly upload your compiled kernel for me to test? I imagine it would work fine since the hardware is exactly the same. Also, I noticed the webmin package I had on there would kernel oops occasionally, so I just got rid of it entirely. So far the NAS has been up for 1 day and 16 hours without a crash, but then again it’s gone a week in the past, so maybe that’s meaningless. I’m almost positive I’ve been having this issue before I installed webmin, so I still don’t think that’s the main problem, but we’ll see.
Thanks,
Todd
What version of the kernel package are you using? The latest is 2.6.32-46. You could try regenerating the uImage/uInitrd files from the latest kernel image and write them to flash using the instructions in one of my posts. You could also try doing an fsck of the filesystem to see if it’s being triggered by corruption of some kind. I don’t have an easily installed kernel package of the kernels I used, so if this doesn’t work you could even try one of the kernels from the backports repository.
When I run “cat /proc/version” I get…
Linux version 2.6.32-5-kirkwood (Debian 2.6.32-45) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sun May 6 16:57:51 UTC 2012
Why is there a discrepancy between “2.6.32-5-kirkwood” and “Debian 2.6.32-45”. Also, when I run apt-get update / apt-get upgrade it says everything is up-to-date. So I’m not sure how I get a hold of 2.6.32-46. So far over 2.5 days without a crash…
Well I went ahead and made new uBoot files out of the uImage and uInitrd files I had in /boot and wrote them to onboard flash and rebooted. Now it’s reporting I’m on 2.6.32-46, so I think during an update process the new kernel got downloaded and I didn’t notice, so that’s why it was reporting being up-to-date. I’ll let it run like this and we’ll see how it goes.
Thanks
Well I hope I’m not jumping the gun but I think you were on to something with the fsck. Changing to the new kernel didn’t work, it still crashed within a day. I then decided to run a fsck as you suggested and so far I’ve been up for 10 days, definitely a record. I’ll keep and eye on it, but unless I report back, I think that solved it! Thanks for all the help, I really appreciate it!
Todd
Hi,
I have a new ix2-ng and I don’t find all the mtd partition.
I have only :
cat /proc/mtd
dev: size erasesize name
mtd0: 0007e000 00001000 “u-boot”
mtd1: 00001000 00001000 “env”
mtd2: 00001000 00001000 “env2”
any ideas?
Maybe the new ones don’t boot from flash at all and the flash is only used for u-boot itself? What do the u-boot and kernel boot messages tell you about the flash size and where the kernel images are being read from?
the spi_flash have only 1024 KB.
I have this kernel line:
Kernel command line: console=ttyS0,115200 root=/dev/ram0 mtdparts=spi_flash:0x7e 000@0(u-boot),0x1000@0x7f000(env),0x1000@0x7e000(env2) :::DB88FXX81:eth0:none
I have alsdo:
IDE read: device 0 block # 2048, count 6144 … 6144 blocks read: OK
IDE read: device 0 block # 8192, count 6144 … 6144 blocks read: OK
## Booting image at 00040000 …
Image Name: Linux-2.6.31.8
Created: 2012-10-04 20:59:31 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2804428 Bytes = 2.7 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum … OK
OK
## Loading Ramdisk Image at 00900000 …
Image Name:
Created: 2012-11-09 21:52:49 UTC
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 2904981 Bytes = 2.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum … OK
Starting kernel …
so, i think it is load on the hard disk
I have also :
bootcmd=ide reset; ide read 0x40000 0x800 0x1800; ide read 0x900000 0x2000 0x1800; setenv bootargs $(console) $(bootargs_root) $(bootargs_mtd) $(bootargs_end); bootm 0x40000 0x900000;run bootcmd2
I assume this means the kernel image and initrd are stored on the disks. With a bit of experimenting it should be easy enough to figure out how to write the files to the write parts of the disk, perhaps using ‘dd’. Alternatively you could just boot from a usb flash drive you leave plugged in.
Yes, i had made many experimentation with a USB, but the kernel won’t load. After some research, the new ix2 doesn’t the same ARM Core (a ARMADA 300 (88F6282) ).
So I have to make my own kernel image by cross compiling 🙂 (with the sources given by EMC)
Hey guys,
I do need a bit of help – if that’s possible of course.
I had ix2-200 up and running with Debian Wheezy on it for a nearly a year now.
So I have decided to upgrade drives to something a bit bigger that 2x1TB and thought that would be good to do fresh install – you know, new beautiful life for my oldy.
But that was a split of the second when I have realised that I have done something wrong.
My mistake was – “flash_eraseall /dev/mtd0”
Why? Because on “cat /proc/mtd” I did get
mtd0: “uBoot” itself
and
mtd1 was “uImage”
ans
mtd1: “uInitrd”
So I have erased uBoot itself by accident…
I had it running still on Debian for a few weeks while I was trying to build my own uBoot (as replacement for the erased one) and when I thought I had it decided to reboot and see…
Unfortunately I haven’t seen anything…
Basically something went wrong so no uBoot and therefore on signs of life…
Can someone please dump their uBoot NAND image and share it with me?
Much appreciated.
Regards,
Kris M
Hi!
I uploaded my uboot image.
http://www.mediafire.com/download/0nm67xjbxxgtm05/mtd0_uboot.dd
I hope you can flash it somehow via JTAG.
Regards,
pbakula
HI guys,
I followed this excellent tut – during install I just chose one drive (with lvm on top) – now im curious if it is possible to install RAID afterwards. Basically yes, it will work with Debian …
But my problem – as I am almost newbie on linux – I am not able to install Grub or anything similar …
Is there a chance for me to install second drive within RAID afterwards ?
By the way – I also have trouble with command “make menuconfig”; but that’s not so important to me at the moment 😉
Kernel version: 2.6.32-5-kirkwood
Thanks a lot in advance.
Timo
It’s possible to setup RAID after install by configuring the other disk as one half a RAID mirror the way you want it setup and copying the data before adding the other disk to the mirror. It’s probably quite complicated though and it maybe easier to backup and reinstall with the disk partitions you want. Maybe there’s a how to somewhere? Grub won’t work, but it’s not needed either (booting is handled by uBoot).
Hi,
thanks for the fest answer …
Yes I found some how to’s, e.g. http://www.huschi.net/2_334_de-software-raid-nachtraeglich-einrichten.html
I agree, it’s kind of copy and re-sync etc.
So, to my clarification – as I don’t need LILO or Grub, which I thought would be prerequisite – can you briefly advice how to update bootloader (which might be the crux) ?
Do I just need to setup things with mdadm and then mkimage of uImage and reflash ?
Really appreciate your effort.
I think you just need to set the uboot ‘boot_console’ parameter with the correct value for root and it should work. I don’t think any flashing is required.
Sure, thanks a lot for your time. I will try …
Does anybody ever tried to install wheezy from link ? : ftp://ftp.nl.debian.org/debian/dists/wheezy/main/installer-armel/current/images/kirkwood/netboot/marvell/openrd/
hello someone tried to install debian on a flash drive and boot from the IX2 this ? recognize the installed drives? as could be done ?
Yes, I’ve done this and it works well. One thing I haven’t tried is use a different part of flash for the custom kernel/uImage. In theory, this would let you restore the ix2-200 back to its default state.
I had an weekend headache with the U-Boot 1.1.4 (May 30 2012 – 06:42:24) Marvell version: 3.6.0.
It causes “Kernel” CRC FAILS, on last step (booting from flash) because of “erroneous” location of u-boot env in flash. I could boot the kernel + initrd from tftpboot (USB Disk cant be readed by this bootloader …. timeouts in many different disk).
So to those that had fighting for this error here is the cause: Inside the booted linux from tftp i readed the uImage from mtd0 and started to compare… at offset 0x004000 there is the u-boot env (ah!!! …because when it wrote uImage to flash caused uboot to reflash env defaults… uhmmm…)
So i went digging…
NOTE: env_start=0x84000 , env_size=0x4000 (it could be readed with printenv)
Marvell>> saveenv
Saving Environment to NAND…
Erasing Nand…Writing to Nand… done
Marvell>> nand write.e 0x00800000 uImage
NAND write: device 0 offset 0x100000, size 0x300000
Writing data at 0x100000 — 0% complete.Failed write verify, nand offset 0x00104000. Suggest to erase block and repeat write operation!
If problem persists suggest marking block as bad (nand markbad ) and repeating the operation!
writing NAND page at offset 0x104000 failed
Data did not fit into device, due to bad blocks
3145728 bytes written: ERROR
Marvell>> nand erase uImage
NAND erase: device 0 offset 0x100000, size 0x300000
Erasing at 0x3fc000 — 100% complete.
OK
Marvell>> saveenv
Saving Environment to NAND…
Erasing Nand…Writing to Nand… done
Marvell>> nand write.e 0x00800000 uImage
NAND write: device 0 offset 0x100000, size 0x300000
Writing data at 0x100000 — 0% complete.Failed write verify, nand offset 0x00104000. Suggest to erase block and repeat write operation!
If problem persists suggest marking block as bad (nand markbad ) and repeating the operation!
writing NAND page at offset 0x104000 failed
Data did not fit into device, due to bad blocks
3145728 bytes written: ERROR
OK – i thought – sooo… what if i put kernel at 0x110000… and – just because i will shift addresses let’s put uInitrd on some lower address (kernel tops up at 0x410000) so i put initrd starting at 0x510000 (random > 0x410000 )
setenv mtdids ‘nand0=orion_nand’
setenv mtdparts ‘mtdparts=orion_nand:0xc0000@0x000000(uboot)ro,0x4000@0x84000(uboot_env),0x300000@0x110000(uImage),0x1000000@0x510000(uInitrd)’
setenv bootargs_console ‘console=ttyS0,115200 mtdparts=orion_nand:0x300000@0x110000(uImage),0x1000000@0x510000(uInitrd) root=/dev/sda1’
setenv bootcmd ‘setenv bootargs $(bootargs_console); nand read 0x800000 uImage; nand read 0x1100000 uInitrd; bootm 0x00800000 0x01100000’
saveenv
(my system was installed on first HDD 2TB WD without LVM nor RAID, so my root = /dev/sda1 )
Reflashed the uInitrd and uImage…
Marvell>> dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.2.147
Marvell>> tftpboot 0x00800000 uImage-new
Using egiga1 device
TFTP from server 192.168.2.251; our IP address is 192.168.2.147
Filename ‘uImage-new’.
Load address: 0x800000
Loading: #################################################################
….
#####################
done
Bytes transferred = 1437344 (15eea0 hex)
Marvell>> tftpboot 0x01100000 uInitrd-new
Using egiga1 device
TFTP from server 192.168.2.251; our IP address is 192.168.2.147
Filename ‘uInitrd-new’.
Load address: 0x1100000
Loading: #################################################################
…..
#################################################################
###############################
done
Bytes transferred = 5482104 (53a678 hex)
Marvell>> nand erase uImage
NAND erase: device 0 offset 0x110000, size 0x300000
Erasing at 0x40c000 — 100% complete.
OK
Marvell>> saveenv
Saving Environment to NAND…
Erasing Nand…Writing to Nand… done
Marvell>> nand write.e 0x00800000 uImage
NAND write: device 0 offset 0x110000, size 0x300000
Writing data at 0x40fe00 — 100% complete.
3145728 bytes written: OK
Marvell>> nand erase uInitrd
NAND erase: device 0 offset 0x510000, size 0x1000000
Erasing at 0x150c000 — 100% complete.
OK
reset –>
…..
blah blah
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x110000, size 0x300000
3145728 bytes read: OK
NAND read: device 0 offset 0x510000, size 0x1000000
16777216 bytes read: OK
## Booting image at 00800000 …
Image Name: 2.6.32.5-kirkwood
Created: 2015-05-24 22:30:55 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1437280 Bytes = 1.4 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum … OK
OK
## Loading Ramdisk Image at 01100000 …
Image Name: 2.6.32.5-kirkwood
Created: 2015-05-24 22:31:43 UTC
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 5482040 Bytes = 5.2 MB
Load Address: 01100000
Entry Point: 01100000
Verifying Checksum … OK
Starting kernel …
Uncompressing Linux… done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
….. Aaaaahhhh!!! Finally!!!!
Do you know of a way to automatically start the Iomega at a regularly scheduled time? I use it for backup storage and only need it running an hour or so a day.