uBoot errors booting new Debian install

I just installed Debian on a Centon 16 GB usb flash drive for use on an older generation Dockstar. When I went to reboot into the new install, it became clear that Debian hadn't booted, it was the original Pogoplug system. I activated the netconsole to observe the boot process and it looks like uBoot doesn't like the partition although the partition looks fine from the Pogoplug system and also when I look at it on my Ubuntu desktop. I'm attaching the uBoot log. The usual problem I see in the forums with booting is that uBoot complains that the device is not ready. I don't see that in this log. The only think I did differently was I created the ext2 filesystem on my desktop to follow the guidelines to prevent damege to flash devices that I found here: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device and modified the install script so that it would preserve the filesystem. Could uBoot be having problems with this ext2 filesystem? Another thing that worries me from the log is the reported errors reading the NAND blocks. Does this mean that my Dockstar is dying?

Thanks

Why does your bootcommand obviously try to load a fat filesystem from the USB stick? Is your stick really FAT16/FAT32 formatted?

The usb stick has partition 1 ext2 and partition 2 swap. If I can unwind the environment variables, what is happening is that the first attempt is a force_rescue_boot which attempts to load a rescue system from an EXT2 partition, then FAT16/32 partition. After that it tries a UBIFS partition. When that fails, goes to load the regular kernel from ext2.

This is from fw_printenv:

bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset

force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi

I have it successfully completing a boot from a 2.5" disk in a USB enclosure, but I would like to have it work from the flash drive and I didn't want to buy a solid state disk. The booted system doesn't seem to be actually talking to the network, but I'm still working on that.

I think that my idea thatf the non-standard ext2 partition causing trouble is probably correct, so I'll probably make a small boot partition with the standard ext2 format, and the larger root partition with the special ext2 format.

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 a conventional ext2 system. This system has been running fine 24/7 with a not insignificant amount of writes to the flash.

One thing that I think may be biting several people here is that, unless the modern uBoots have been fixed, they can only fetch blocks that are on the first 2GB of the device. Not the partition, but the device. I know that is a problem with the uBoot on my SheevaPlug. I have a 7GB root partition there, but one lightly populated, so most of the time a new uImage works fine. But, occasionally, one wont boot, and when this happens, I figure it is because the file system has placed some of the uImage's blocks out of the first 2GBs of the partition. In these cases, I boot on the old uImage and then make another copy of the new one, and then that will almost always boot.

In any event, that's the reason for having a small /boot partition in the first place -- to ensure the bootable files are up front on the device and are thus always accessible to the boot firmware. I suppose it is possible this might be affecting you, too.