Scan all USB devices and boot from the first bootable drive.

i mounted it with atime i still got like 1 mb/s through samba those are my mount options:

/dev/sdc1 on /media/share1 type fuseblk (rw,sync,noatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

removing the sync option didn't help aswell same write/read speeds :(

Quote
BillyBoy
@Nero:
By the way, thank you very much for sharing your experience. It was a great help for me when creating NTFS partitions within Linux. I didn't know exactly how to do that before. I guess you're not using the Dockstar kernel, are you?

Quote
Nero
It seems that giving back cynicism to people how want to be helpfull, is the "Vienna way".
Please stay there and have a nice day!

>I guess you're not using the Dockstar kernel, are you?
I'm using the Dockstar kernel of Jeffs site. Why should i come here and post about problems with other kernels?

@Nero:
I read your reply today. Howcome you think my statement was meant to be cynical? Maybe my English is not perfect, but I'm grown up enough to know that such a forum only works if users are willing to help each other. In order to find out if your previous problems were based on the same reason as mine, I just wanted to know which kernel you are using. As this forum section is just covering Jeff's uBoot (which is the ultimate standard for all Dockstar modders meanwhile), my question was really serious. Noone could ever know at the beginning that my boot related problem should turn out to be a kernel issue.

Also my thanks to you weren't meant to be ironical. As mentioned before, I'm currently running Plugbox and I'm a former Windows user just starting to get in touch with Linux. Debian might be the next step when understanding things better. Therefore I really didn't know the tools you described for preparing NTFS partitions within Linux. I'm sorry if you misinterpreted my statement. Anyway, it was never my intention to offend you, regardless who you are or where you come from.

@To Plugbox Dockstar-Kernel users:
Due to a bug report also at the Plugbox forum site the boot issue with the Plugbox-Dockstar-Kernel has been fixed by the Plugbox admin few days ago.

Regards,
BillyBoy

Anyone else notice, that when booting with this method (my 1st usb device is my samba share hdd, second usb device is Debian usb stick), the booting from the non-1st usb device works as described, but it does not mount the swap partition.

I guess this happens because it is nor /dev/sda2 anymore but /dev/sdb2. Any workaround?

Use the UUID in fstab to identify the swap partition instead of using the device node.

Any short instructions how to do that? I am not that familiar with Linux...

Thanks =)

How to specify your swap partition using a UUID:

1. Determine the UUID of your swap partition. Assuming it's on /dev/sda2 (check /proc/swaps to make sure):

# blkid /dev/sda2
/dev/sda2: UUID="long-string-of-hex-digits"

2. Change the swap line in your /etc/fstab file to be:

UUID=long-string-of-hex-digits none swap sw

3. Check that it works by doing:

# swapoff -a
# swapon -a
# free

Surprisingly my swap partition does not have a UUID

root@debian:/# blkid
/dev/sda1: UUID="ffa9d7e3-a047-46e8-a014-098ceb7848dd" TYPE="ext2"
/dev/sda2: TYPE="swap"
root@debian:/#

Solution:

swapoff -a
mkswap /dev/sda2

This will get you an UUID for swap. Thanks for the help, now everything is fine :)



Edited 1 time(s). Last edit at 10/03/2010 03:59AM by metacircle.

Hello,

I have the same problem: everything works fine with the USB stick plugged. But as soon as I also connect my hard drive (formated in ext3), the Dockstar seems to boot on the USB stick and is stuck somewhere. I've tried every plugging combination, but no matter what, it always fail.

The netconsole output are exactly identical (except for the number of detected USB).
Here it is with only the USB stick:

U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan
Hit any key to stop autoboot:  0 
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices... 1 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:        1750
UBI: number of bad PEBs:         2
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:             1729
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'!
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1434220 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4736680 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.32-5-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1434156 Bytes = 1.4 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-2.6.32-5-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4736616 Bytes = 4.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

And with both the USB stick and the hard drive:

U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan
Hit any key to stop autoboot:  0 
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 5 USB Device(s) found
       scanning bus for storage devices... 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:        1750
UBI: number of bad PEBs:         2
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:             1729
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'!
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 5 USB Device(s) found
       scanning bus for storage devices... 2 Storage Device(s) found
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1434220 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4736680 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.32-5-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1434156 Bytes = 1.4 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-2.6.32-5-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4736616 Bytes = 4.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Can someone point me toward a solution or help me debug this ?

Thanks

Also, I installed rsyslog and haven't found any log at all. So it seems that the kernel is started but immediatly freeze without writing any logs

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 have plugged each device in physically on the Dockstar. Is the HD a GO drive on the top slot? If so, I think it will always get /dev/sda, so you might try changing any reference of /dev/sda* to /dev/sdb* in /etc/fstab. Otherwise, you might try swapping the ports used for each.

Hello,

Thanks for your answer.
I've already tried swapping the ports:

Quote

I've tried every plugging combination, but no matter what, it always fail

Note: I have a regular USB hard-drive, so I cannot use the top slot.

Are you talking about the /etc/fstab of Pogoplug of the /etc/fstab of the debian installation on the USB stick ?
If it's the /etc/fstab of the Debian, wouldn't it work better if I use the UUID of the partition ?
Otherwise I'm afraid that I won't be able to boot with only the USB stick. But I seem to have read that it is not recommended to use the UUID with the Dockstar.

Regards,

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 the NAND devices, they returned errors causing the OS to spew out lots of error messages during the boot sequence. I don't think it hurts anything, but I don't like to see pages of errors flash by on boot. This was a year ago on Ubuntu 9.04. Maybe they've fixed this in the meantime. In any event, it might be worth a try. Good luck and let us know what happens.

The /etc/fstab from the Debian only contains one entry with /dev/sda2 pointing to the swap partition (others entiers are just /dev/root and tmpfs).
I've tried using the UUID or just commenting the line, but the result is always the same: without the hard drive, it is booting correctly, with the hard drive it is stuck somewhere.

Do you have another idea for me to debug this ?

Thanks a lot,

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, without a console, we're stabbing in the dark, but if you make the presumption that plugging in the hard drive causes the HD to be assigned /dev/sda and the thumb drive to in turn be assigned /dev/sdb, then I suspect the kernel is trying to attach the wrong device as the root file system.

Try interrupting uBoot from netconsole, and temporarily changing the uBoot environment variable usb_root from /dev/sda1 to /dev/sdb1. You should be able to do this for one boot without having to save the environment. If this is the problem, this change may help. If not, then no harm should be done. You could also try adding an entry for your root file system to your /etc/fstab using its UUID, but try changing usb_root first.

Sorry for the misunderstanding, but I have 3 entries in /etc/fstab but only one use the /dev/sda* file system identifier:

/dev/root / ext4 noatime,errors=remount-ro 0 1
/dev/sda2 none swap sw 0 0
tmpfs /tmp tmpfs defaults 0 0

So I only changed the /dev/sda2 to the UUID.
I may also try to change the /dev/root to the UUID of /dev/sda1, but I don't think that's necessary ?

I also previously tried to change the usb_root to /dev/sdb1 but it doesn't work and I thought that the new uBoot was taking care of that ? I thought that it was initializing the UBS root after running a script which was looking for the right files.

Thanks for your help, I'll keep you informed

I've tried replacing /dev/root in the /etc/fstab by th UUID and still the same result: it boots fines without the hard drive and is stuck otherwise.
Changing the usb_root doesn't help either.

Do you have other idea ?

Thanks

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 to have a second "usb start" here
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
                                                                   <---- but no "run usb_scan" here
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1434220 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4736680 bytes read

But on my system, I see:

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)
1431460 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4735472 bytes read

Note the addition of the three lines. ending in "Found bootable drive on usb 0:1". That's where the determination of the name of the root file system is made, and I don't see that in your boot sequence, which is what makes me suspicious that your kernel may be acquiring the wrong name.

Or maybe I'm just not seeing something. Anyway, it appears your uBoot environment is different from mine, so it might be interesting if you'd post it.

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.

Here is my environment:

Pogoplug:~$ /usr/sbin/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_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:D5:06
arcNumber=2097
usb_rootfstype=ext4
usb_init=usb start;
serverip=192.168.0.10
ipaddr=192.168.0.20
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

I have messed a little with usb_init, usb_root and usb_boot but I think that I have put everything back to normal.
If you think that something is not right, I may create a new one from scratch ?

Anyway thanks a lot for taking the time to help me. I really appreciate it !

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 device 0:1 if this is the hard drive (as is our working assumption) and not the thumb drive. Hence, we may be barking up the wrong tree, but try setting usb_init to "run usb_scan" and let us know what happens.

I've tried replacing usb_init, but still the same result (boot only without the hard drive).

Here is the netconsole output:

U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan
Hit any key to stop autoboot:  0 
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 5 USB Device(s) found
       scanning bus for storage devices... 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:        1750
UBI: number of bad PEBs:         2
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:             1729
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)
1434220 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4736680 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.32-5-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1434156 Bytes = 1.4 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-2.6.32-5-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4736616 Bytes = 4.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

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 figure out what is going on. But at this point, I think your best bet would be to install a serial console port so that you could see what's going on during the boot sequence. If you do get to the bottom of this, I think it would be of interest to more than just yourself, so please keep us updated.

And, good luck!

I've tried installing Debian on the hard drive and on a second USB stick.
The results are:

• With the hard drive and the USB stick 1, it always boots on the hard drive (wherever I plug them)
• With the USB stick 1 near the ethernet port and USB stick 2 the farthest away, it boots on the USB stick 2
• With the USB stick 2 near the ethernet port and the hard drive the farthest away, it boots on the USB stick 2

This evening I will try re-installing the USB stick 1 and try other things.
I'll keep you updated.

Same results after a fresh re-installation of USB stick 1: if someone else is available, the dockstar always avoid booting on USB stick 1 !

I guess that I just have to change my USB stick !
Do you have any explanation for this strange behavior ?
It seems that because it's a slow key, the others ones are always the first to respond and so get the boot.

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 electronics on the two drives to become available once power is applied, but I really don't know.

The bottom line: Often, it appears that you just have to change devices if the one you are using doesn't do something correctly, until you find one that works in a given situation. Maybe changing your USB stick is the easiest solution.