The stock Debian kernel also boots just fine with 2998 as well. I dunno. I think if you are constantly building and changing kernels, it is in your best interest to build a serial cable to have direct access to uBoot. At the very least, you had better keep a backup image of a known working stick.by kraqh3d - uBoot
You need Uboot access. Build a serial cable.by kraqh3d - uBoot
Using fw_setenv should save the changes. Do you have a correct /etc/fw_env.config file? That defines where the changes are supposed to be saved. arcNumber 2097 is a generic number for Sheevaplug. It will boot, but the LED's won't work. arcNumber 2998 is the correct one for Dockstar. The LED's will work with that number.by kraqh3d - uBoot
So far, so good... They appear to be the same exact model number of Fantom drive (HD204UI) and they are correctly being identified as different drives, as they both report unique serial numbers: 533248474A31435A38313836 533248374A394B4237313136 I don't believe that disk identifier is a problem. I suspect they came from the factory pre-formatted as NTFS and that value is stored inby kraqh3d - Debian
Sorry about that. Not sure what the heck I was thinking or how I typo'ed that. The option is definitely "-f" not "-n". It's like the same as "tail -f".by kraqh3d - Debian
Sorry I never got around to testing this. My Dockstar hosts all my media. I can't just take it off line to experiment as something is always playing via Xbmc. And I've not yet found an acceptable price on eBay for a second one. Yes I do have backup copies of those three mtd partitions. If you can boot an alternate OS, then you should be able to nandwrite the image back. Where couby kraqh3d - Rescue System
Comment out the entries in /etc/fstab. And forget Webmin. We'll need to work this out the old fashion way, via the command line. Do you have any logging enabled? If not, install busybox-syslogd. It's a pure memory logger so it won't write to your root filesystem. Unmount both devices and disconnect them. Open two consoles. In one, run "busybox logread -n" Cby kraqh3d - Debian
If that's an exact cut and paste then you made a silly typo... /dev/sbc1 ---------^ that's a "b" should be a "d" :)by kraqh3d - Debian
I'm fairly certain is mounted using the TYPE and not the SEC_TYPE from blkid. Sorry about that. I could've sworn the "/dev/root" line in the mount output displayed the actual file system type. I forgot about the virtual rootfs type. What does "df -T" report? I believe that will tell you the real type for /dev/root. And ls -l /dev/root should show you what dby kraqh3d - Debian
1. Yes this assumes you have the default uBoot installed. 2. Either quotes are acceptable. It won't matter in this case. 3/4. No. It doesn't have to be "ROOTFS" specifically, but it must exactly match the label of your root file system, that you set via e2label. That't just what I use ROOTFS on my Dockstar. The capital letters stand out. 5. Leave it as is whicby kraqh3d - Debian
Sorry about that. The easiest way to make this permanent is to fw_setenv from linux. I modified usb_init to make the change. I don't have access to my system at his very moment, but I'm fairly certain this is what I did: fw_setenv usb_init "run usb_scan ; setenv usb_root LABEL=ROOTFS" If you trace through the usb startup procedure, it goes like this: 1. bootcmd eventby kraqh3d - Debian
I think Jeff's install script at http://jeff.doozan.com/debian/ would work. It installs the uboot and has options for several plug devices. Then it debootstraps a minimal debian. The problem is that the script needs to be updated due to changes with debootstrap. http://forum.doozan.com/read.php?2,4244 This thread details some options that include fixes to the original script, an aby kraqh3d - Debian
I believe Jeff's original uboot install script will work. wget http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh Take a look at the script. There is a part near the end which asks what type of device you have so that it sets the arcNumber correctly, and Pogoplug v1 is in the list.by kraqh3d - uBoot
What does mount report? Mount will tell you if it was mounted as ext2 or ext3. I've experienced this funniness with (lib)blkid. Some partitions report a secondary type (SEC_TYPE="ext2") in addition to the primary type (TYPE="ext3"), but not all. I've never found a reasonable explanation of why only some report this. I just ignore it as it seems mount ignores it.by kraqh3d - Debian
I didn't get around to trying to boot the standard Pogoplug uImage file via USB. I see two issues. The default root location is /dev/mtd2 (which is jffs2.) I was going to manual change the bootargs to load the kernel from USB, but point root to the standard location. I expect that to work. The trick will be getting that root partition to exist on USB. I believe mtd3 is unused by Poby kraqh3d - Rescue System
@restamp Good catch. I never noticed that. I just checked blparam and arcNumber is definitely not in the old environment. I can't seem to mount the old uImage partition from nand though to get the file so I made a copy of /dev/mtd1 with dd. File reports it as a uImage. If I have time later tonight, I'll attempt to boot it with the standard debian uInitrd. If it boots, I'llby kraqh3d - Rescue System
You will have to correct this with a serial connection.by kraqh3d - Rescue System
Do you have the dhcp3 client installed?by kraqh3d - Debian
Ouch thats ugly. They are circular references. And you didn't do it. I just opened up modules.tar.gz and its like that in the package. Without the source, you're not going to be able to compile that module. You'll have to build your own custom kernel. A quick google search seems to indicate that this module is in the mainline kernel since 2.6.39. There was a post about coby kraqh3d - Debian
Cool. You didn't get any new dependency issues from forcing that version?by kraqh3d - Debian
You need libsqlit3-0 version 3.7.3-1 specifically. You can try installing that version specifically, but then you may get some other dependency errors for things already installed that now conflict. apt-get install libsqlite3-0=3.7.3-1by kraqh3d - Debian
I think you need to change /etc/fw_env.config to point to offset 0x60000 as that's where UBIT installed UBoot is saving its environment. (Everything else remains the same.) The other environment location isn't going to do you any good. It's not a backup. It's just where the non-UBIT UBoot saves it's environment. (And I wonder what it may have over written?)by kraqh3d - uBoot
Ah. Thanks for that clarification varkey. Your uboot env mod is simple enough but it requires booting exclusively from the first port, right? It looks for the kernel and initrd on ide 0:1 and makes use of the usb_set_bootargs since the default value of usb_root is /dev/sda1 which hopefully would be the same device name assigned by udev.by kraqh3d - Debian
It's standard Debian for Marvell Kirkwood, but Jeff's installer isn't designed for a standard Sheevaplug. Besides, Jeff's installer is currently broken. You need to muck around with the sh script to get squeeze to install. I think you'll be better off just following instructions specifically for the Sheeva, such as this. http://www.cyrius.com/debian/kirkwood/sheevaplby kraqh3d - Debian
You can have multiple Uboot environments at different locations in the nand. The linux rescue console is looking at 0xc0000 (based off /etc/fw_env.config). The original pogo environment is at 0xa0000 (at least on the dockstar it is.) The Marvell>> prompt may be referencing another location?by kraqh3d - uBoot
/etc/network/interfaces should contain: auto eth0 iface eth0 inet dhcpby kraqh3d - Debian
I've got nothing. I don't have a GoFlex Net to experiment on myself. Can you explain the entire boot process using UBIT? I've been reading the Arch forums and UBIT doesn't seem to anything more than a one time installer for a version of UBoot. I haven't pulled down and unpacked the ramdisk image though to look at the scripts referenced by the Arch instructions. Tby kraqh3d - Debian
That's not going to work because "run usb_set_bootargs" sets the bootargs variable which references "root=$usb_root". Altering usb_root after that does nothing at all to change your kernel boot parameters. It's already been defined according to usb_root=/dev/$dev at the end of usb_scan. This is the relevant bit from my environment: usb_scan=usb_scan_done=0;by kraqh3d - Debian
Strange. It looks like it should work. Mind trying a manual boot? usb start run usb_scan setenv usb_root LABEL=rootfs run usb_set_bootargs printenv usb_set_bootargs run usb_boot The hd_args and usb_args seem like attempts to do the same thing, but I dont see them being referenced anywhere. Booting from a label or uuid is the better way to go. You're doing that by force theby kraqh3d - Debian
It will work. This is one of the purposes of using an initrd. Post the full environment. It likely needs to be added someplace else so it doesn't get over written by the uboot script. And try it with the uboot scripts. Just break into the boot sequence and force everything to occur manually.by kraqh3d - Debian