Pogoplug won't boot with USB HDD attached.

I'm having problems booting my pink Pogoplug with a Western Digital HDD attached to it.

I've followed the instructions on this website to install Debian on a 8gb Sandisk Cruzer usb stick, and it boots fine with this connected and without any other usb devices attached. However, I have a 2TB WD HDD which I want to attach for storage, and if it's connected during boot time the Pogoplug just doesn't respond. I've resorted to having to attach the HDD after the Pogoplug has booted and then mounting the partitions once it is up and running. Obviously this is far from ideal as if there is a power failure or I need to reboot, and I'm away from home, I can't physically disconnect and reconnect the hard-drive and the Pogoplug becomes unusable.

I have 2 partitions on the WD HDD which are both about 1TB. One partition is encrypted using cryptsetup/LUKS and the other is standard EXT format.

Any ideas what might be going on, and what I can do so this isn't a problem?

Thanks

Do you have serial connection? (or netconsole)

Typically, this sort of thing is due to the kernel making the wrong decision about the relative device letters to assign each of the two "sd" devices. With one "sd" device, it always winds up becoming "sda". (And, you are specifying /dev/sda1 as the root partition, right?) With more than one "sd" device, it becomes a toss-up as to which device becomes "sda" and which "sdb" -- the first one the kernel sees becomes sda, and the next sdb, etc. If you're lucky, reversing the plugs of the two devices might make things work. But, tread carefully: I've seen this become rather complicated and quite intractable: On a SheevaPlug I own, one disk typically becomes "sda" after a cold boot, but "sdb" after a warm boot.

I've been told that USB rules can be written to always assign a specific identifier to a specific hardware device, but I'm not well enough versed in this area to say how one would do this, and it would appear to me that it would have to be done in the initrd (right?) since it would have to be done before the root FS is first mounted, another complication.

In any event, this seems to indeed be a common and insidious problem with affects all these ARM-architecture units, and I for one would appreciate it if someone who has successfully surmounted it could address what they did to do so.

An addendum to my previous message:

One solution that has been proposed, and which I believe works, although not cleanly, is to specify the root partition by its UUID number instead of by a device itself. The problem with this approach is that, when this is done, the kernel goes off attempting to search every block device for a partition with that UUID in it, and this in turn causes a cascade of error messages to be emitted as it tries to read the various internal NAND partitions (and fails). When I tried this in an old Ubuntu load, it was eventually successful, but left some rather nasty looking log files of the boot sequence in its wake.

Or, you can do the obvious (which is what I did on my Pogo): In addition to the other partitions you wish to maintain on the hard drive, format it with a small root partition up front, plus whatever other *nix partitions you desire (swap is probably a good choice to include here), transfer the contents of the thumb drive to the hard drive, and then unplug the thumb drive and boot off the hard drive directly. That will generally work until you need to add a second drive.



Edited 1 time(s). Last edit at 02/23/2012 08:15PM by restamp.

@restamp,

I think a clean solution (kraqh3d's) is to modify UBoot envs to force UBoot to find the correct boot drive (i.e. the first USB drive that has a unique label, for example,rootfs).

See this post:
http://forum.doozan.com/read.php?2,5233,5957#msg-5957

bodhi

An interesting solution I had somehow overlooked before. Thanks for pointing it out bodhi.

In all honestly, these little ARM devices are changing the very way I think about servers. Until now, I've opted for fairly bullet-proof hardware (old Sun Sparcs) mated with mirrored drives. (That combination has served me amazingly well for the past 15 years. FWIW, in all that time, I've experienced exactly one hardware failure -- a mirrored SCSI disk drive, and I was able to replace the drive, resync it, and keep going without even needing to reboot the box!)

But, increasingly, I find myself thinking the way to go today is to have a pair of SheevaPlugs/Dockstars/Pogoplugs hanging off the LAN, each with one attached mass storage device with a complete set of server apps installed and ready to go, with half active on each box. Each box would rsync the pertinent parts of itself to the other at regular intervals. The hardware itself is do dirt cheap you could keep a couple spares on the shelf. The power draw would be a fraction of the Sparc's (an increasing concern given today's electric rates), and there would be almost implicit redundancy in the event of a hardware failure. At most, all that would have to be done in a failure scenario is to toggle a couple apps from the failed box over to the secondary.

It really is an amazing new world today compared to the conventional standards of even a decade ago.

Same here! I've been using an old Sparc-based NAS box for the same purpose for awhile. But these days, I've acquired a few pogoplug/dockstar boxes to do all the chores. Considering the cost and how little power usage go into the 24/7 operation and the capabilities, I think it is amazing we can do that. My goal is to run the same Debian USB stick on all these ARM devices, so when one fails I just put in another stick and boot it up! So far the only odd one out is the Pogoplug Pro, for which I need another spare 4GB stick because of the OXNAS customization for Debian.

I think the rootfs partition LABEL solution is very elegant! it allows us to boot with a backup Debian copy on any USB drive. The UUID solution is also very nice, however, it does require the UUID of the rootfs partition.

I don't have a serial cable, or netconsole installed at the moment.

Is the first partition of the WD HDD marked bootable by any chance? I thought uboot looks for that.

Thanks for all your help guys I've got this working now.

I used the label solution with command fw_setenv usb_init "run usb_scan ; setenv usb_root LABEL=ROOTFS" as suggested.

For some reason my system wants to mount the USB stick as SDB and my HDD as SDA.

I think it's probably because the HDD is coming up faster than the flash drive. The Pogoplug USB port right next to the Ethernet port usually assigned SDA, if no HDD drive attached. But it's really unpredictable. Unlike the Dockstar, where the top mini USB port always assigned SDA if there is a drive attached, regardless of the type.

Because of this thread, I took a look of my Dockstar and found something that I don't understand...
My Setup.
A Coby DP-152 picture frame is connected to the top/front USB port.
A 8GB USB flash drive is connect the the USB port next to the ethernet port
A 2 TB USB HDD is connected next to it.
A Canon iP2600 printer is connected to the side USB port.

As configured, the DockStar will not boot. I also tried swap the USB stick with the Coby DP-152 but it will still not boot.
It will only boot if I remove the picture frame and the printer. If only one is removed, no boot.


Below is the output of fw_printenv:

ethact=egiga0
bootdelay=3
baudrate=115200
mainlineLinux=yes
console=ttyS0,115200
led_init=green blinking
led_exit=green off
led_error=orange blinking
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
mtdids=nand0=orion_nand
partition=nand0,2
stdin=serial
stdout=serial
stderr=serial
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
force_rescue=0
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
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_list=1 2 3 4
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_device=0:1
usb_root=/dev/sda1
usb_rootfstype=ext2
usb_rootdelay=10
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
ethaddr=00:10:75:1A:5B:37
arcNumber=2097
usb_init=run usb_scan ; setenv usb_root LABEL=ROOTFS
serverip=192.168.1.175
if_netconsole=ping $serverip
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
preboot=run if_netconsole start_netconsole

Output of netconsole when all devices are plugged in:

U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan
Hit any key to stop autoboot: 10  9  8  7  6  5  4  3  2  1  0 
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... unable to get device descriptor (error=-1)
6 USB Device(s) found
       scanning bus for storage devices... Device NOT ready
   Request Sense returned 00 00 00
2 Storage Device(s) found
Loading file "/rescueme" from usb device 0:1 (usbda1)
** File not found /rescueme
reading /rescueme.txt

** Unable to read "/rescueme.txt" from usb 0:1 **
Creating 1 MTD partitions on "nand0":
0x000002500000-0x000010000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            219 MiB
UBI: number of good PEBs:        1751
UBI: number of bad PEBs:         1
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             1730
UBI: total number of reserved PEBs: 21
UBI: number of PEBs reserved for bad PEB handling: 17
UBI: max/mean erase counter: 1/1
UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:rootfs", error -19
Error reading superblock on volume 'ubi:rootfs'!
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1 bytes read
Found bootable drive on usb 0:1
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1438876 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4745145 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.32-5
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1438812 Bytes = 1.4 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4745081 Bytes = 4.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

How come DockStar detects 6 devices when I only have 4? Do I need to expand the search from 4 devices to 6?
Thanks.

I think the USB hub counts as devices? The Dockstar has 1 root hub and 1 4-port hub. So that would make the total 6. And you have 2 storage devices, which would be the only candidates in the booting sequence.

Does the netconsole output show the loader thinks the Coby DP-152 as the boot drive?



Edited 1 time(s). Last edit at 02/29/2012 10:18PM by funtoy1001.

Funtoy,

Looks like the net console output was when you put the boot USB drive on the top port (with the adapter)? and it did boot the kernel. How long did you wait after that? I would wait at least 5 minutes! to see if the kernel eventually finishes coming up. I ran into a weird problem that a warm boot took 5 minutes, and the extra 4 minutes was after rc.local has been completed.

Addendum: It turned out the "weird" problem with the warm boot I experienced intermittently was with my network bridge. Nothing to do with the kernel.

bodhi



Edited 1 time(s). Last edit at 03/01/2012 02:09PM by bodhi.

No, the log file is captured when I have the Coby DP-152 on the top port and the USB stick next to the ethernet port. The DockStar did boot (led is steady orange) but I can't SSH in and none of my samba shares are accessible from other machines. I did couple times this morning and was able to boot correctly with the Coby DP-152 removed. It seems the problem is with the mounting of the USB HDD after boot but I don't see how the mounting of the USB HDD is impacted by the present of the DP-152. I have the following in my /etc/fstab

/dev/root         /               ext2    noatime,errors=remount-ro 0 1
UUID=9xx      none         swap   sw   0       0
UUID=9xx      /mnt/data  ext3     rw,auto,user 0 0

The reason I think the issue is related to the USB HDD mounting is because the DP-152 showed free space of 3 GB on /tmp/mnt/data but my USB HDD has a lot of more than 3 GB left. The 3GB is what is free on the USB stick. If I removed the DP-152 and connected it back after booting, the free space shows up correctly.



Edited 2 time(s). Last edit at 03/01/2012 11:35AM by funtoy1001.

Suggestion: I would try to remove the HDD from fstab and mount it manually later to see what'll happen (keep the Colby attached). If that solve the problem then it will be easier to figure out what was causing the behavior.

The worst case, you can automate the HDD mounting in rc.local. I have a GoFlex Net that boots from USB flash, and no fstab entry for any HDD, so I mount whatever HDD that happen to be in the SATA slot when kernel coming up (in rc.local using the HDD label).

Thank you for the suggestions but is rc.local executes before the scripts in /etc/rc*.d? If not, I don't think mounting the HDD in rc.local will work for me.

rc.local should be the last thing executed, after all the scripts in /etc/rd?.d.

I've come across this thread in my search for help a pogoplug device, but I don't have the technical know how to understand much of the discussion. I simply want to connect my WD HDD to my router for network storage, but I can't seem to get it working at all. Is there some more basic instructions or help available? Should I need any software from pogoplug or elsewhere to get this working? Any help appreciated.
Thanks.