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

The new uBoot installer (since 10/3/2010) will configure USB scanning automatically.

The following script is a more configurable method of scanning for USB drives:

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_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;

By default, this will scan the first partition on up to 4 USB devices. If it finds a /boot/uImage, it will stop configure usb_device and usb_root with the values defined in usb_scan_X. By changing the values of usb_scan_X, you can scan different partitions.

The values in usb_scan_list configure which usb_scan_X definitions will be used for scanning.

The original post below is kept for posterity.

----------------------------------------

If you're going to be changing or moving your usb devices, and you only have one device with boot files, you can use this script to scan each drive and then boot from the first one with boot files:

usb start;
if ext2load usb 0:1 0x800000 /boot/uImage; then
  setenv usb_device 0:1;
  setenv usb_root /dev/sda1;
elif ext2load usb 1:1 0x800000 /boot/uImage; then
  setenv usb_device 1:1;
  setenv usb_root /dev/sdb1;
elif ext2load usb 2:1 0x800000 /boot/uImage; then
  setenv usb_device 2:1;
  setenv usb_root /dev/sdc1;
elif ext2load usb 3:1 0x800000 /boot/uImage; then
  setenv usb_device 3:1;
  setenv usb_root /dev/sdd1;
fi;

If that's what you're looking to do, you can modify 'usb_init' to include your script by running the following command in uBoot:

setenv usb_init 'usb start; if ext2load usb 0:1 0x800000 /boot/uImage; then setenv usb_device 0:1; setenv usb_root /dev/sda1; elif ext2load usb 1:1 0x800000 /boot/uImage; then setenv usb_device 1:1; setenv usb_root /dev/sdb1; elif ext2load usb 2:1 0x800000 /boot/uImage; then setenv usb_device 2:1; setenv usb_root /dev/sdc1; elif ext2load usb 3:1 0x800000 /boot/uImage; then setenv usb_device 3:1;setenv usb_root /dev/sdd1;fi;'

If you'd prefer to run that command from linux, use the 'fw_setenv' command:

fw_setenv usb_init 'usb start; if ext2load usb 0:1 0x800000 /boot/uImage; then setenv usb_device 0:1; setenv usb_root /dev/sda1; elif ext2load usb 1:1 0x800000 /boot/uImage; then setenv usb_device 1:1; setenv usb_root /dev/sdb1; elif ext2load usb 2:1 0x800000 /boot/uImage; then setenv usb_device 2:1; setenv usb_root /dev/sdc1; elif ext2load usb 3:1 0x800000 /boot/uImage; then setenv usb_device 3:1;setenv usb_root /dev/sdd1;fi;'

-- Jeff



Edited 2 time(s). Last edit at 10/03/2010 08:35AM by Jeff.

Jeff,

Would it be possible to set it up:

If USB drive present and bootable - Boot USB;

If not, boot Pogoplug.


Without having to chain boot?

Edit: Yes, use the new mtd0 uBoot.
--------

Not that I know of.

We can't load the old pogoplug files in the new uBoot because the ecc is different so it won't load anything larger than 0x7ff from mtd1:

Marvell>> nand read.e 0x900000 0x100000 0x07ff

NAND read: device 0 offset 0x100000, size 0x7ff
2047 bytes read: OK

Marvell>> nand read.e 0x900000 0x100000 0x0800

NAND read: device 0 offset 0x100000, size 0x800
NAND read from offset 100000 failed -74
0 bytes read: ERROR


And we can't load the old uBoot from inside the new uBoot (in case it would still have non-persistent values in ram):

Marvell>> nand read.e 0x600000 0x000000 0x080000

NAND read: device 0 offset 0x0, size 0x80000
524288 bytes read: OK
Marvell>> go 0x600200
## Starting application at 0x00600200 ...
nt Time out .

controllerricenication controllers


So that takes us back to the original problem: we can't modify the old uBoot settings from inside the new uBoot, and the old uBoot doesn't support USB so we're limited in how intelligently we can select a boot device.

Currently, the pogoplug uBoot is configured to alternate between booting USB and booting the internal install. It does this by setting a persistent variable each time it's booted so that on the next run it will attempt to boot from the other device.

If anyone creative comes up with a better solution, I would love to try it!

-- Jeff



Edited 1 time(s). Last edit at 08/22/2010 04:30PM by Jeff.

I tried this method, but it doesn't seem to work! :(

I connected two flash drives, one with the debian install and another one which is NTFS for storing the data. But when both flash drives were connected the system failed to boot. But once I removed the 2nd Flash Drive, it booted to debian without any issue.

I used to fw_setenv command and verified it using the fw_printenv command.

Anything I am doing wrong? :(

Solved my problem! :)

If the drive which you have connected is not having a linux partition, then the primary OS drive should be connected to the first USB port. I was using an NTFS drive and hence the ext2fs_ls threw an error and the device goes into an indefinite reset loop.

Quote

USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
scanning bus for storage devices... 2 Storage Device(s) found
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
** Can not find directory. **
** Error ext2fs_ls() **

** Block device usb 2 not supported

** Block device usb 3 not supported
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
resetting ...

I'm glad it's working for you.

I've updated the command to use ext2load instead of ext2ls, which should solve the problem you had.

-- Jeff

Didn't notice that you had updated the instructions.

So with the new commands, will it work even if I connect the devices in a different order?

Yes, with the new script, it should boot from the first bootable device even if the devices are in a different order.

-- Jeff

Which one is the first USB-Port?

varkey Wrote:
-------------------------------------------------------
, then the primary OS
> drive should be connected to the first USB port.

The top port is the first one, number two is the one next to the ethernet port, three the one next to two, four the one on the side.

I'm a little bit confused now. Has this script already been implemented into the new mtd0 uBoot or not? I'm asking because I still have problems to boot from my USB stick when an original Seagate FreeAgent Go drive is connected to the dock:

One week ago I modified my new Dockstar by applying the new uBoot on mtd0 and installing Plugbox Linux with the Dockstar kernel on a 2GB USB stick. What can I say, it worked like a charm. Some modules are already running, and there were no problems booting into any of the two worlds, the "pseudo" Pogoplug (LED orange) or the new Plugbox environment (LED green). Regardless on which port the OS USB stick was plugged in, it worked perfectly. If the stick was present, also the new uBoot loader managed to boot correctly into Plugbox.

All that started to change when I first decided to attach an original Seagate FreeAgent Go 640GB hard drive directly to the integrated Mini USB dock on the device top. When doing so, uBoot always fails to boot into PlugBox Linux and you can observe the LED's showing it reboots twice until ending up in Pogoplug. I tried to change the USB slots for my stick, but no success. The only way to make it boot into PlugBox again is by sticking to the following configuration:

Port 1 (Mini USB plug on top): none
Port 2 (backside next to LAN port): USB stick with OS
Port 3 (backside outmost): none
Port 4 (right side of device): Seagate FreeAgent Go Drive

Unfortunately that's exactly a configuration I wanted to avoid. The Seagate drive shouldn't be connected by using an external USB cable, of course it should reside in its dedicated dock. And the little USB stick (which is featuring a LED) should be visible from the front view, so it should be attached on the right side of the device, leaving two unused slots at the backside for future disk extensions.

I'm a n00b, but for me it seems that I stumbled over a problematic configuration. Maybe if there's a device attached to the first port (mini USB), the time scanning the USB ports is too short for uBoot in order to recognize the bootable OS USB stick connected to one of the other standard USB slots. Maybe also the Seagate Go drive itself delays the whole scan process so that uBoot gives up searching and decides to reboot into Pogoplug.

However, following Jeff's edits in the thread above let me believe that the new uBoot should now handle all different port combinations by always choosing the bootable USB port automatically. I'm not owning any CA-42 and/or JTAG cables. Before messing around with uBoot parameters or scripts, I'd like to ask twice if the described script is still valid and should be applied anyway. Or do you have any other hints for me in order to make the DockStar boot up PlugBox with a connected FreeAgent Go drive on top?

Thank you in advance.

[EDIT on]

There are two more working combinations. Finally I figured it out:

As long as the OS USB stick is fitted into a slot with a lower internal USB port number than the FreeAgent Go drive, the PlugBox OS will be recognized by uBoot and load correctly. If the USB stick is the last device in the row (that means with a higher USB slot number than the harddisk), the DockStar will fail to boot and fall back into PogoPlug.

So what do I have to do exactly if I want to keep my USB stick in the side slot (#4) and connect the FreeAgent Go drive to its dedicated mini USB dock slot (#1)?

[Edit off]

Regards,
BillyBoy



Edited 3 time(s). Last edit at 09/18/2010 03:24PM by BillyBoy.

Nobody able to help?

Still I don't know if this thread is also applicable for the new uBoot. I don't like to make changes if there's already another search routine for USB ports implemented which I could break.

On the other hand I still have this issue with my Seagate FreeAgent Go drive. For compatibility reasons it's NTFS-formatted because I also use it directly on my FreeAgent Theater+ streaming device. However, when attached to the top USB port (#1) of the DockStar, uBoot can't find the bootable Linux OS anymore even if the stick is properly attached to any of the three higher numbered USB ports (#2 to #4). It seems that the same issue still exists that Varkey described few posts before.

Maybe I could solve the scan problem by applying the described script but just using a different search order:

usb start;
if ext2load usb 3:1 0x800000 /boot/uImage; then
  setenv usb_device 3:1;
  setenv usb_root /dev/sdd1;
elif ext2load usb 2:1 0x800000 /boot/uImage; then
  setenv usb_device 2:1;
  setenv usb_root /dev/sdc1;
elif ext2load usb 1:1 0x800000 /boot/uImage; then
  setenv usb_device 1:1;
  setenv usb_root /dev/sdb1;
elif ext2load usb 0:1 0x800000 /boot/uImage; then
  setenv usb_device 0:1;
  setenv usb_root /dev/sda1;
fi;

Would that approach work? Would I destroy anything if there's already a similar routine implemented in the new uBoot?

Regards,
BillyBoy

The search and boot routine is not implemented in the default configuration. You have to add it yourself as Jeff describes at the start of this thread. It should not be necessary to reverse the search order, unless a device in front of your USB stick has a bootable ext2 filesystem with a uBoot kernel image in /boot.

The default configuration only tries the first USB mass storage device and if that doesn't have an ext2 file system with a valid uBoot kernel image called /boot/uImage in the first partition, the boot loader falls through to the rescue system.

Thank you Johannes, I'll give it a try!

After some trial and error cycles I guess the solution described here is not working for me, not even if I change the search order of the USB drives in the script.

Yes, there has been a small improvement when changing the usb_init parameter from just 'usb start' to the command sequence shown above, as uBoot doesn't automatically reboot anymore into Pogoplug. At least it keeps flashing green until it gets solid green (I'm using the Dockstar kernel with LED support), indicating that the OS has taken over. But instead of keeping on loading up (I can watch my USB stick LED) the device freezes completely and cannot be accessed anymore, neither by SSH, nor by Webmin or anything else. There's not much left than to pull the power plug. However, if no other drive than the USB stick is involved in the boot process and the HDD drive will be attached later on (after the OS has come up), everything will just work fine.

Since I'd like to boot the OS from the side slot (usb_device 3:1 / usb_root /dev/sdd1), and my HDD drive is in the top dock slot (usb_device 0:1 / usb_root /dev/sda1), are there eventually any drive parameters which have to be passed over to the OS? If yes, how can this be achieved?

Or it's already a problem that my HDD with its NTFS partition is getting accessed during boot time and is confusing the whole boot process. If I could prevent uBoot from scanning the HDD drive at all, it would be recognized the first time after the OS has come up. I guess then everything would work like it should. Can this be done somehow? Any other hints for me?

Thank you in advance for your help.

Regards,
BillyBoy

The current search and boot routine is doing a bit of guessing regarding the "root" kernel parameter. It assumes that if there are say 2 devices in front of the one with the kernel image, then the device with the kernel image is going to be /dev/sdc in Linux. That isn't necessarily true. Unfortunately the boot loader does not support a sufficiently flexible scripting environment to figure this out reliably. It is therefore best to boot from the device which is first among the USB devices. If you have console access to the boot loader (either serial or netconsole), then you can try to find the right root parameter like this:

usb start
setenv usb_device 0:1;
setenv usb_root /dev/sdc1;
run usb_load_uimage;
run set_bootargs_usb;
run usb_boot;

That's the original boot sequence, with manual setting of usb_device and usb_root. Set usb_device to one of 0:1, 1:1, 2:1 or 3:1. Set usb_root to one of /dev/sda1, /dev/sdb1, /dev/sdc1, /dev/sdd1. One of those combinations should work. You can then modify the search script to set the right root parameter for the usb_device that matches your configuration.

Thanks, Johannes. Unfortunately I don't have any serial cable and I don't own a Linux PC where I could run netconsole. But would it be possible to set the 'usb_init' parameter back to 'usb start' and just change the two parameters 'usb_device' and 'usb_root' directly using the 'fw_setenv' command within Pogoplug environment until I find the matching combination for my config out of the 16 possible combinations?

Regards,
BillyBoy

Yes, you could change the parameters from Linux, but be aware that you're then relying completely on the internal system until you find a combination that works for you. I'd recommend using the netconsole. You don't need a Linux PC. There's a Windows port of netcat here:
http://joncraton.org/files/nc111nt.zip

The netconsole is just this:
nc -u -l -p 6666
(it means: netcat udp listen port 6666)

I have previously commented on the netconsole here:
http://forum.doozan.com/read.php?2,935,982#msg-982

Hmmm...

First I tried all 16 combinations of 'usb_device' and 'usb_root' by changing their values directly using the 'fw_setenv' command. I couldn't achieve a better result than already experienced by using the 'usb_init' script shown in this thread. When my HDD was involved and I was choosing certain combinations, the system at least booted from stick, but always only up to the kernel start, then it freezed. When detaching my HDD from the USB dock, all those attempts were okay and passed the kernel until the full OS was up.

Here's a good trial booting up without HDD:

U-Boot 2010.06-00695-gbd23130-dirty (Aug 30 2010 - 23:04:56)
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... 3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1986336 bytes read
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1986336 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
** File not found /boot/uInitrd
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.35.1-dockstar-00165-g6
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1986272 Bytes = 1.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

And here's a bad trial booting up with HDD:

U-Boot 2010.06-00695-gbd23130-dirty (Aug 30 2010 - 23:04:56)
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... 2 Storage Device(s) found
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
Loading file "/boot/uImage" from usb device 1:1 (usbdb1)
1986336 bytes read
Loading file "/boot/uImage" from usb device 1:1 (usbdb1)
1986336 bytes read
Loading file "/boot/uInitrd" from usb device 1:1 (usbdb1)
** File not found /boot/uInitrd
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.35.1-dockstar-00165-g6
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1986272 Bytes = 1.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

I'm just wondering if the following error message is also okay (as it appears in both cases):

** File not found /boot/uInitrd

Next I tried to follow your instructions above using netcat by entering the commands one by one. When entering the line 'run usb_load_uImage' there was always an error message:

##Error: "usb_load_uImage" not defined

However, I also didn't succeed making the Dockstar boot up that way. So I guess there's nothing more I can do about that fact. Any ideas left?

Regards,
BillyBoy



Edited 1 time(s). Last edit at 09/21/2010 03:04PM by BillyBoy.

Should be
run usb_load_uimage

Note: no capital I in uimage

The boot logs indicate that you still use the search script. The script overwrites the usb_device and usb_root variables in RAM, so any flash values you set from Linux won't take effect. To make the variables stick, you'd have to revert the usb_init variable to just "usb start". Anyway, don't do that. Using the netconsole to test these things is safer, because any changes to the variables are only temporary. You can always get back to the working environment in flash memory simply by rebooting. (You can save the modified environment to flash with "saveenv", but you shouldn't. Take notes of changes and upon a successful boot, make the changes from Linux with fw_setenv.).

Sorry, mea culpa. I forgot to mention that I had already changed the value of the usb_init parameter back to script read when I created the 2 logs shown above.

Of course I had the parameter set to 'usb start' when first testing all combinations by directly editing the usb_device and usb_root parameters via fw_setenv. Because I wasn't successful that way, I decided to re-apply the script for further testing. Before installing netcat the first time and capturing my logs, I simply forgot to change the usb_init parameter back to default. Sorry if I caused any confusion.

However, today I repeated the boot interruption method using netcat with the default usb_init setting, this time of course without any typos (as a Windows user I will never get used to this forced case sensitivity) :-). As expected I still had the same results as already experienced yesterday when using the other method described before. Whatever I set up, the best thing I can achieve is a system booting up from stick, but just until the Dockstar LED is turning to solid green. After that the device doesn't show any reaction anymore.

I found out, that in my preferred configuration (stick on Dockstar's side, HDD in the top dock) only usb_device 1:1 with all its 4 usb_root variants /dev/sda1,sdb1,sdc1,sdd1 will at least boot into the kernel and then suddenly stop as already described. Representing such a case here's a corresponding log:

Device 1:1

Marvell>> usb start
usb start
(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... 2 Storage Device(s) found
Marvell>> setenv usb_device 1:1;
setenv usb_device 1:1;
Marvell>> setenv usb_root /dev/sdd1;
setenv usb_root /dev/sdd1;
Marvell>> run usb_load_uimage;
run usb_load_uimage;
Loading file "/boot/uImage" from usb device 1:1 (usbdb1)
1986336 bytes read
Marvell>> run set_bootargs_usb;
run set_bootargs_usb;
Marvell>> run usb_boot;
run usb_boot;
Loading file "/boot/uInitrd" from usb device 1:1 (usbdb1)
** File not found /boot/uInitrd
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.35.1-dockstar-00165-g6
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1986272 Bytes = 1.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

All other 3 usb_device settings being left don't work out for me, even when trying all their 4 usb_root variants /dev/sda1,sdb1,sdc1,sdd1. Depending on the usb_device setting, the error messages differ a little bit from each other. Here 3 examples:

Device 0:1

Marvell>> usb start
usb start
(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... 2 Storage Device(s) found
Marvell>> setenv usb_device 0:1;
setenv usb_device 0:1;
Marvell>> setenv usb_root /dev/sdd1;
setenv usb_root /dev/sdd1;
Marvell>> run usb_load_uimage;
run usb_load_uimage;
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
Marvell>> run set_bootargs_usb;
run set_bootargs_usb;
Marvell>> run usb_boot;
run usb_boot;
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Marvell>>

Device 2:1

Marvell>> usb start
usb start
(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... 2 Storage Device(s) found
Marvell>> setenv usb_device 2:1;
setenv usb_device 2:1;
Marvell>> setenv usb_root /dev/sdd1;
setenv usb_root /dev/sdd1;
Marvell>> run usb_load_uimage;
run usb_load_uimage;
** Block device usb 2 not supported
Marvell>> run set_bootargs_usb;
run set_bootargs_usb;
Marvell>> run usb_boot;
run usb_boot;
** Block device usb 2 not supported
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Marvell>>

Device 3:1

Marvell>> usb start
usb start
(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... 2 Storage Device(s) found
Marvell>> setenv usb_device 3:1;
setenv usb_device 3:1;
Marvell>> setenv usb_root /dev/sdd1;
setenv usb_root /dev/sdd1;
Marvell>> run usb_load_uimage;
run usb_load_uimage;
** Block device usb 3 not supported
Marvell>> run set_bootargs_usb;
run set_bootargs_usb;
Marvell>> run usb_boot;
run usb_boot;
** Block device usb 3 not supported
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Marvell>>

So I guess the problem doesn't have to be related to the uBoot scan process only. It might be a timing problem when handing over drive control to the OS, any incompatibility with my NTFS formatted HDD, its sector size or something totally different. It's just giving me headache to know that everything will work right if I just boot up with stick only and I attach the HDD later on when the OS is already running. Really crazy!

Es ist zum Kinderkriegen...
as we say in german...

Greets from Vienna,
BillyBoy



Edited 1 time(s). Last edit at 09/22/2010 02:20PM by BillyBoy.

Billiboy,
before you get too much kids (Es ist zum Kinderkriegen... ) maybe the solution i found can help you too!
I also tried to connect a NTFS formated usb drive to the Dockstar and run into the same problems as you.
The drive was formated under windows7 and when i checked the filesystem under linux i saw some error messages.
So i went the other way and formated the drive under linux.
Cfdisk - Type 7 and mkntfs /dev/sdx1 -f and now it works with the HDD drive on the top,
and the HDD is also recognized under windows7.
The only problem left is that the write speed to the ntfs HDD is really slow ~2MB/s,
reading is ok ~10MB/s.
Liebe Grüße aus Graz,
Nero

BillyBoy(this time i got it right),

my report on slow write speed to the NTFS HD was not correct because the HD was mounted with wrong params.

So measured it again with dd and hdparm and got:
NTFS partition
disk read 26 MB/sec
disk write 9 MB/sec

best regards,
Nero

It took almost the whole weekend to figure out what was going wrong here. Finally I found out why it's not possible at all to boot up my Plugbox OS when an original Seagate FreeAgent Go Drive is attached to the upper USB socket of my DockStar.

I repeated the whole installation process several times, using three different USB sticks carrying the OS and two different Seagate FreeAgent Go drives. I ran tests with different USB environment parameters, I modified the boot scan script, I even changed the partition tables many times from Linux to NTFS (and vice versa) to get sure what's the reason. What turned out was very surprising for me.

The problem was...

...not related to the USB scan routines explained here in this thread
...not related to the type of USB stick used to boot up the OS
...not related to the FreeAgend Go drives attached to the top USB port
...not related to the different partition and file systems used (Linux / NTFS).

IT LOOKS LIKE THE PROBLEM IS ONLY CAUSED BY THE PLUGBOX DOCKSTAR KERNEL!

When installing the latest default "Kernel with Linux 2.6.35.4-1" everything is still working like it should. The system continues booting from stick even though an HDD is attached to USB top port #1 from the beginning (in this case it really doesn't matter to which port the USB stick is attached if the scan script described in this thread is applied).

But after using pacman to update to the new "Dockstar Kernel26 2.6.35.4-1" which offers LED support for Dockstar users, the problem suddenly occurs. From that moment on the system won't boot anymore into the OS, it gets stuck somewhere in the middle while passing the kernel module (in this case there's nothing that can be done to avoid that issue anymore, no config change will help to get rid of that situation except reverting back to the other kernel).

Even though the two kernels have the same version number, it seems that they show different behaviour, especially when it comes to the boot process. I hope the developers will take a closer look to fix that issue. As by now, I think not all features and/or functions have been migrated to the Plugbox Dockster Kernel version. I hope someone will take care of all that differences so both versions will work out the same way.

@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?

Regards,
BillyBoy

Edited by moderator to emphasize the problem is with the Plugbox kernel, and not with any of the kernels provided on this site.



Edited 2 time(s). Last edit at 09/26/2010 04:23PM by BillyBoy.

BillyBoy wrote:
....any incompatibility with my NTFS formatted HDD, its sector size or something totally different. It's just giving me headache to know that everything will work right if I just boot up with stick only and I attach the HDD later on when the OS is already running. Really crazy!

As i already wrote, i had the same problem with the Dockstar and an NTFS formatted drive connected to the top USB port.
The last debug message i got was also
Starting kernel ...
Connecting the NTFS drive to one of the other USB ports worked without any problems.
My problem was solved by reformatting the driver under linux, that was all i wanted to tell you.

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 Wrote:
-------------------------------------------------------
> BillyBoy(this time i got it right),
>
> my report on slow write speed to the NTFS HD was
> not correct because the HD was mounted with wrong
> params.
>
> So measured it again with dd and hdparm and got:
> NTFS partition
> disk read 26 MB/sec
> disk write 9 MB/sec
>
> best regards,
> Nero

hi,

what params did u use to reach those speeds?

Finally ended up using the default(auto,...) params and only setting the sync option.
(mount reports type fuseblk "rw,sync,relatime,user_id=0,group_id=0,allow_other,blksize=4096")
Only my boot/system usbstick is fixed at USB slot 2 and mounted via fstab during boot.
For USB slot1/3/4 i have configured a pluggable automount system with an Udev rule file.
(so i needed the auto option)

somehow i only get like 1 mb r/w :o

Do not use relatime. To much overhead.
Use noatime.