Oops. I have no idea how that happened. How about: http://forum.doozan.com/read.php?3,323,2038#msg-2038by restamp - Debian
Swâmi, I think if you review the earlier posts in this thread, you'll find that the situation you describe is a common problem with the higher capacity Kingston thumb drives. Sandisk Cruzers seem to be better with cold boots. Yes, the conventional wisdom is that if a given stick doesn't cold boot, try another brand. Good luck.by restamp - Debian
peaslaker, it seems you understand arcNumber and how it integrates into the uBoot better than I do. I understand the basic concept that the kernel is informed about the subtleties of the hardware it is running on from the arcNumber, and thus can configure itself mores specifically to do things like control the LEDs on the device, but can you shed some light on: 1. How the arcNumber is actuallby restamp - uBoot
The order in which USB devices are recognized on the Dockstar or SheevaPlug when there are several on a hub has always been a mystery to me. I've got two disks, and if I boot my SheevaPlug with both attached, the "wrong" one always comes up as /dev/sda on a cold boot. But, the opposite happens on a warm boot. I suspect it may have something to do with how long it takes the electby restamp - uBoot
I don't think it is harmful to fsck a file system with the '-n' option; according to the manual, this causes the file system to be opened in read-only mode and no changes to be made. That's why the more pressing warning wasn't produced in this instance. I've used 'fsck -n' to peek at active file systems for years and never had a problem. It can be usefby restamp - Debian
Well, first, active file systems are often transiently inconsistent, plus they also contain things like unreferenced files that will cause fsck to complain, but if you shut down your system sanely and the file system is still screwed up, then you have a problem. What does your /etc/fstab say? I had a similar problem on my SheevaPlug running Ubuntu 9.04 and found a solution in the following thby restamp - Debian
Well, in all honestly, I didn't expect this would work after seeing your previous post. Unless you happen to have a boot directory with a uImage and uInitrd in it on your hard drive, SaintGermain, I'm out of good suggestions. You could try putting a root file system on your HD. If both devices were bootable, it might enable Debian to come up in some configuration and you could then fby restamp - uBoot
Hmm. I'm not sure why, but you have the usb_init variable defined to be "usb start", whereas I have it defined to be "run usb_scan". That means your Pogoplug will always try to boot from device 0:1 (/dev/sda1). You might try changing your usb_init and seeing if it makes a difference. However, it's not clear to me why the uBoot is finding the uImage/uInitrd on dby restamp - uBoot
FWIW, as an experiment, I just plugged a bootable thumb drive into my Dockstar, along with my bootable hard drive, and then allowed it to boot. It came up on the hard drive, which was assigned to /dev/sda. The thumb drive was assigned to /dev/sdb.by restamp - uBoot
SaintGermain, yes, the new uBoot should theoretically set the correct device, but I don't see the output of the code that does this being shown in the netconsole dump which you posted several posts back in this thread. Your boot sequence is: Error reading superblock on volume 'ubi:rootfs'! (Re)start USB... <---- you seem toby restamp - uBoot
Your /etc/fstab only has one entry -- for swap? Odd indeed. I've always seen an entry for '/' there, too, for every system I've encountered. You probably will want to add one eventually, if for no other reason than this: http://plugcomputer.org/plugforum/index.php?topic=4587.msg16676#msg16676 (I think this is the second time I've posted this link today.) Look,by restamp - uBoot
I have yet to have this problem on the Dockstar with Debian, but I was plagued with this on my SheevaPlug running Ubuntu. Have you investigated how badly the file system gets corrupted? (Have you taken the thumb drive over to another computer and fsck'ed it, and if so, was it still unbootable afterwards?) On the SheevaPlug, the following advice helped me: http://plugcomputer.org/plby restamp - Debian
ingmar_k, by all means let us know how it turns out when you get around to trying it.by restamp - Debian
Or just look here: http://forum.doozan.com/read.php?2,3465,3649,page=1#msg-3649by restamp - Debian
I agree, I settled for occasional rsyncs here, too. It's questionable in my view to do any sort of software RAID if you don't have two completely separate channels. Having two RAIDed devices hanging off of one USB hub causes more problems than it resolves. Another alternative would be to install a hardware raid device that supports a USB interface.by restamp - Debian
It depends on which Mail Transfer Agent (MTA) you are using. With sendmail, you should be able to do this by adding an entry such as root: external@address.com to the /etc/mail/aliases fileby restamp - Debian
Without a hardwired console, it is always a potentially dangerous thing to mess with the uBoot environment, which of course, you must do if you want to change the kernel's boot arguments. The boot arguments (you can see what they are by executing "cat /proc/cmdline" after Debian has booted) are set in usb_bootcmd by the usb_set_bootargs variable, and yes, usb_custom_params may beby restamp - uBoot
I meant the /etc/fstab on the Debian root file system. You might try using UUID. That works, and it might even solve your problem if it is related to drive letter confusion, but here's the problem with it, at least when I tried it on my SheevaPlug: When I specified a UUID in /etc/fstab, the OS tried to search every conceivable (every block?) device looking for it. When it encountered theby restamp - uBoot
Just to make sure I understand: You used Jeff's script to create a Debian system and then, without trying to see if it would boot and work with a dynamic IP, you modified it to use a static IP address? If so, I'd undo the changes and test the load to see if it works dynamically. If it does, then I'd ask how you made the static mod. Did you change /etc/network/interfaces? Whenby restamp - Debian
This is a situation where I believe a console would in all likelihood instantly make the situation clear. Barring that, here is what I suspect might be the problem: When you have only the USB stick plugged in, Linux assigns it as the /dev/sda device. However, when you have both devices plugged in, Linux assigns /dev/sda to the HD and /dev/sdb to the thumb drive. You don't say where you hby restamp - uBoot
I see you have your Linux swap partition defined as /dev/sda1 and your (presumed) Linux root partition defined as /dev/sda2. That's backwards from the normal arrangement. Is that the way it is on your thumb drive, too? What does your /etc/fstab say? If it points to /dev/sda1 as your root partition, as it normally would, this could be your problem.by restamp - Debian
The cite you give for mkfs-ing an ext file system that is "friendly" to flash memory is interesting, but I suspect modern devices - both SDcards and thumb drives - have a pretty bullet-proof wear-leveling layer that is designed to prevent premature wearout. I note that the SATA flash drives are warranted for 5 years now. 18 months ago, I formatted a generic MicroCenter SDcard using aby restamp - uBoot
A cold boot is a boot from which power has been applied to the Dockstar. A warm boot is one where either another OS is running and a "reboot" is given, without recycling power, or perhaps one where the uBoot has been interrupted and a "reset" command issued from there. geodog, you haven't given us a lot to go on. Reading between the lines, I take it that your Dockstaby restamp - Debian
Personally, I power down my Dockstar occasionally, take the hard drive (I boot off of a Seagate GO drive, but a thumb drive would work similarly) over to another box, and back up the file systems in the conventional manner. I also force fsck at this point to detect and correct any latent errors. If I want to snapshot the root fs while running, I use the method described here: http://forum.doozby restamp - Debian
Yes the '-r' option means reboot, but if you just do a 'shutdown' or a 'shutdown -h' (essentially the same thing on the Dockstar) you really have no visual feedback as to when it's safe to unplug the device. By using the '-r' option, you know when the kernel has ceded control and uBoot has again taken control, because the uBoot changes the LED to a fby restamp - Debian
I am currently running my Dockstar off of a GO drive and it works well. There are pros and cons, which I've commented on before. The pros are that it's simpler and the writes are faster. The cons are that there are pauses when the disk needs to spin up and the reads are slower (largely due to rotational delays). Is it safer? Well, it's largely a matter of what works for you.by restamp - Debian
geodog, it looks to me as if, even though you created the file system as an ext3, you are mounting and using it as an ext2. I say this because you have "usb_rootfstype=ext2" in your uBoot environment, and this will cause an ext2 mount. You can verify this by "cat /proc/mounts". The good news: This should not be a problem: The salient difference between ext2 and ext3 isby restamp - Debian
This thread provoked me to pose my question about data corruption in the plugcomputer.org forum, and one of the more knowledgeable users made a suggestion that seems to have immediately helped. In a nutshell, if the root file system type is not specified correctly in the /etc/fstab file, the root file system may not be unmounted on shutdown correctly, leading to file system corruption. This mayby restamp - Debian
There is no reason why an ext3 file system should not work fine on a thumb drive or SDcard (or any storage device which presents a block interface). The reason people tend to avoid it with NAND technology is that it is more write-intensive than an ext2 file system and thus there is some fear that it may shorten the life of the underlying flash memory. Also, NAND writes are inherently slow, andby restamp - Debian
geodog, what type file system are you running? I run an ext2 filesystem on my SheevaPlug (Ubuntu 9.04). It seems quite stable when running, but I notice that after a power failure it usually requires manual intervention during the fsck phase. I've never had a problem with other Unixes, so I'm at a loss to explain what is going on, but there is often significant corruption, although nby restamp - Debian