FWIW, I had exactly the same problem on a dockstar, the only difference being a Linux-3.1.10-16-ARCH kernel.
I'd get to the "Starting kernel ..." line, and that'd be the end of it.
No further chitchat on the wire, wouldn't respond to ping or ssh. When I pulled the USB stick the dockstar would boot into the default seagate linux.
My error turned out to be really simple.
I was missing the usbrootfstype in the environment, even though I knew I had set it to ext2.
And that was the key: I had set usbrootfstype with the command:
which looks plausible but is wrong.
The correct invocation is:
After which
returns: usb_rootfstype=ext2
... and now my dockstar boots from the usb stick.
Wouldn't have noticed that the usbrootfstype was missing had Timmypro not mentioned the fact. :-)
So there are two ways you can be SOL on a USB storage device while being only microscopically away from success:
1) format the usb stick as ext2 but set the usbrootfstype to ext3 (as instructed by one of the alarm pogoplug install pages; it seemed strange at the time, but I assumed that ext3 probably covered ext2 as well ... until I came across this link: ).
That's why I knew I'd set usbrootfstype ... because I'd looked, and it was set to ext3.
2) use bad syntax for the fw_setenv command.
ie when I re-set usbrootfstype from ext3 to ext2, I used bad syntax, and fw_setenv deleted the env variable.
_____________________________________________________________
Y'know, it wouldn't be a bad idea for fw_setenv to complain about garbage chars at the end of the line; instead, it seems to take the '=' as the line or option terminator, interpret the command as:
and understand that to mean "delete the environment variable."
All sorts of havoc can flow from what seems to me to be a fairly natural error. After all, the syntax for unix environment variable assignment is VAR=value, so even if one knows better, it's easy to slip.
Alternatively, fw_setenv could by default echo back the env variable it changed, and the value assigned to the variable.
I'd get to the "Starting kernel ..." line, and that'd be the end of it.
No further chitchat on the wire, wouldn't respond to ping or ssh. When I pulled the USB stick the dockstar would boot into the default seagate linux.
My error turned out to be really simple.
I was missing the usbrootfstype in the environment, even though I knew I had set it to ext2.
And that was the key: I had set usbrootfstype with the command:
fw_setenv usbrootfstype=ext2
which looks plausible but is wrong.
The correct invocation is:
fw_setenv usbrootfstype ext2
After which
fw_printenv usbrootfstype
returns: usb_rootfstype=ext2
... and now my dockstar boots from the usb stick.
Wouldn't have noticed that the usbrootfstype was missing had Timmypro not mentioned the fact. :-)
So there are two ways you can be SOL on a USB storage device while being only microscopically away from success:
1) format the usb stick as ext2 but set the usbrootfstype to ext3 (as instructed by one of the alarm pogoplug install pages; it seemed strange at the time, but I assumed that ext3 probably covered ext2 as well ... until I came across this link: ).
That's why I knew I'd set usbrootfstype ... because I'd looked, and it was set to ext3.
2) use bad syntax for the fw_setenv command.
ie when I re-set usbrootfstype from ext3 to ext2, I used bad syntax, and fw_setenv deleted the env variable.
_____________________________________________________________
Y'know, it wouldn't be a bad idea for fw_setenv to complain about garbage chars at the end of the line; instead, it seems to take the '=' as the line or option terminator, interpret the command as:
fw_setenv usbrootfstype
and understand that to mean "delete the environment variable."
All sorts of havoc can flow from what seems to me to be a fairly natural error. After all, the syntax for unix environment variable assignment is VAR=value, so even if one knows better, it's easy to slip.
Alternatively, fw_setenv could by default echo back the env variable it changed, and the value assigned to the variable.