GoFlex Net: Boot from USB while SATA disks connected

Hi all,

I have following setup:

• USB stick with rootfs in USB-Port of GoFlexNet
• 2 SATA HDDs in both ports, right one also having a rootfs installed

Now the behaviour is the following:

• When booting with USB stick only installed, GoFlex does boot normally from stick
• When booting with SATA disks only installed, GoFlex does boot normally from disk
• When booting with USB stick and right SATA disk installed (with rootfs), it seems UBoot loads uImage/uInitrd from the stick but mounts the SATA disk rootfs to "/" (booting succeeds)
• When booting with USB stick and left SATA disk installed (without rootfs), uImage/uInitrd are loaded from the stick, Starting kernel message is displayed, but boot fails somewhere.

How can I achieve that the GoFlex boots from USB stick and mounts the rootfs of it when plugged in? If no stick is plugged in, then SATA should be used for booting.

Greets,
cyb

Here is my env:

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_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_init=run usb_scan
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
arcNumber=3089
ethaddr=XX:XX:XX:XX:XX:XX
ipaddr=10.0.10.6
ncip=10.10.10.5
ncipk=10.10.10.4
serverip=10.10.10.3
preboot=run nc_test nc_start
nc_start=setenv stdin nc; setenv stdout nc; setenv stderr nc; version
nc_test=ping $ncip
usb_rootfstype=ext3
set_bootargs_rescue=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts
bootcmd_rescue=run set_bootargs_rescue; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000
bootcmd_pogo=run bootcmd_rescue
rescue_installed=1
sata_boot=ide reset; mw 0x800000 0 1; ext2load ide 0:1 0x800000 /boot/uImage; if ext2load ide 0:1 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
sata_bootcmd=run usb_set_bootargs; run sata_boot
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run sata_bootcmd; run rescue_bootcmd; run pogo_bootcmd; reset

Just an idea... you'd probably want to start by having both USB and SATA drives label (using the ext2/3/4 utilities) as usb_root and sata_root, or something like that...

Then I'd try writing and testing the command script so that-
1 first try to boot from USB ... failover to...
2 try to boot from SATA ... and perhaps then failover to ...
3. try to boot from a NAND rescue image

=====================================================

• davy's Github Repo's rescue-dg

As I can figure out, it seems not to be a UBoot problem at all..
When connected the USB stick with the rootfs and only the SATA drive without the rootfs, UBoot uses the correct device:

Loading file "/boot/uImage" from usb device 0:1 (usbda1)
2279256 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
6996080 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-3.3.2-kirkwood-dg
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2279192 Bytes = 2.2 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:    6996016 Bytes = 6.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

But afterwards, debian does not start (can't ssh, no IP address assigned). Unfortunately I don't get any log messages from the kernel via nc. Also, the dmesg file seems to be untouched when I plug the stick into my notebook to check.

Could it be the bootargs or the fstab used?

fstab

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/root	/	ext2	noatime,errors=remount-ro	0	1
tmpfs	/tmp	tmpfs	defaults	0	0

usb_bootargs

console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)

@cyb,

Concurred with what Davy said, I'd suggest that you label the rootfs that you want to boot with, and set the UBoot env to find it.

# fw_setenv usb_init "run usb_scan; setenv usb_root LABEL=rootfs"

Think I got the problem. It is related to the different device mapping done in the os compared to the bootloader:

When the bootloader scans for bootable USB devices, it maps the first USB device for example to /dev/sda1. This is also passed as bootarg for the root parameter to the kernel. The OS instead maps the SATA devices first, so the connected SATA device gets /dev/sda1 and not the USB stick.

Therefore, the uImage and uInitrd can be loaded from the bootlader, but afterwards the kernel tries to use /dev/sda1 as rootfs, which is the SATA drive (which does not have the rootfs and so the boot fails). When setting manually the bootargs to root=/dev/sdb1, the booting succeeds!

The new problem now is, how can I avoid/workaround this? Any ideas?

I must admit, I didn't understand what exactly davy meant ;) But thats a good hint bodhi! Will give it a try...

It works now!

Just set the usb_bootcmd as following

setenv usb_bootcmd 'run usb_init; setenv usb_root LABEL=rootfs; run usb_set_bootargs; run usb_boot'

and labeled the usb stick root partition to 'rootfs'.

Everything works like a charm now! Thanks to you both!

However, question still stands:

- how to change the way ArchLinux or Udev assigns /dev/sd* letters and numbers?

I've the same issue, and it seems like instead of adding more env rules to Uboot, the more elegant solution is to correct some Udev rules, or make Uboot hand over some info about the /dev/sda1 that OS would pickup instead of ignoring it. So the question is, what's the root cause of this issue and is there a way for a user to fix?

sambul14 Wrote:
-------------------------------------------------------
> However, question still stands:
>
> - how to change the way ArchLinux or Udev assigns
> /dev/sd* letters and numbers?
>
> I've the same issue, and it seems like instead of
> adding more env rules to Uboot, the more elegant
> solution is to correct some Udev rules, or make
> Uboot hand over some info about the /dev/sda1 that
> OS would pickup instead of ignoring it. So the
> question is, what's the root cause of this issue
> and is there a way for a user to fix?

You can't change the order, because it depends on the hardware. For example, on the Dockstar, the port that most likely to be assigned sda1 is the one next to the Ethernet port and then one right next to it, and then the one on the side. However, if you plug in a GO drive or a thumb drive with USB mini-to-full USB adapter to the top port, then it's most likely to get sda1. On the GoFlex Home, the SATA drive always get sda1 and similarly on the GoFlex Net. It seems to be because a certain drive got recognized first, it get assigned sda1.

So the sure ways to tell UBoot to choose a drive to boot with is by some other means such as rootfs label, or manual insertion of drives, one at the time.

Is it a Uboot version of Persistent block device naming scheme? :)

In a way :-) since we can plug and unplug any new USB/SATA drives, not just the ones that we have already figured out the UUID or ones defined in fstab. So rootfs label is a very elegant scheme, IMO.

In what cases command saveenv is required?

Is there any difference in outcome btw your suggested command and cyb's ?

Once this command is entered, should previously used (printed) stand alone settings like run_usbinit be deleted by entering empty similar command?

Does the command order matter - found when printing resulting env? Should Uboot auto rearrange the sequence upon env correction, or how to rearrange it manually if needed?



Edited 5 time(s). Last edit at 10/26/2012 12:29PM by sambul14.

sambul14 Wrote:
-------------------------------------------------------
> In what cases command saveenv is required?
>

Only needed when you are in netconsole or serial console. For normal Linux shell, fw_setenv change the envs for good.

> Is there any difference in outcome btw
> [url=http://forum.doozan.com/read.php?3,9398,9423#
> msg-9423]your[/url] suggested command and
> [url=http://forum.doozan.com/read.php?3,9398,9426#
> msg-9426]cyb[/url]'s ?
>

Same outcome.

> Once this command is entered, should previously
> used (printed) stand alone settings like
> [i]run_usbinit[/i] be deleted by entering empty
> similar command?
>
> Does the command order matter - found when
> printing resulting env? Should Uboot auto
> rearrange the sequence upon env correction, or how
> to rearrange it manually if needed?

The printing order does not matter. UBoot takes whatever the value currently stored in an env variable.



Edited 1 time(s). Last edit at 10/26/2012 04:57PM by bodhi.

Thanks. It seems like I need serial cable now after playing with envs. :) Wanted to follow this guide. Where to download current and original Uboot .kwb files for GFN?

sambul14 Wrote:
-------------------------------------------------------
> Thanks. It seems like I need serial cable now
> after playing with envs. :) Wanted to follow this
> [url=http://archlinuxarm.org/forum/viewtopic.php?f
> =30&t=1323#p21403]guide[/url]. Where to download
> current and original Uboot .kwb files for GFN?

Do you mean you got problem and trying to restore original UBoot with serial console? or just want restore original UBoot? you can do that in Linux shell, too.

bodhi Wrote:
-------------------------------------------------------
>You can do that in Linux shell, too.

I guess env update went wrong, and GFN appears to no longer get network access at and after boot (despite its IP is defined by serverip settings), so inaccessible by any means I know of thus far including Netconsole. I didn't have a chance yet to install the rescue system either. Pls enlighten, how to fix Uboot in Linux shell without serial cable. :)

Actually< i'm not sure what's the best way to proceed at this point: restore latest Uboot, refresh only its environment if possible via Serial (natural question: how?), or restore the factory Uboot? Any arguments here? And corresponding .kwb files?



Edited 2 time(s). Last edit at 10/26/2012 07:22PM by sambul14.

In your situation, you need serial console since you don't have network access. I thought you meant restoring original Uboot while you have a functional system (some people wants to go back to stock).

The best thing to do is to connect serial console and then assess the damage :-) see if you can stop the boot process at the count down and then print out the envs. If they are wrong, then you can fix them at the console with setenv, savenv, and then reset. Because you already know that the problem occured after envs updates, it's probably an easy fix.

Thanks. Under reset did you mean reboot? If I need to reflash .kwb, will Dockstar's .kwb do the job (can't find any link to GFN's own)?

In console mode, to reboot you just do a reset after saveenv.

I should not answer the second question. I think if the NAND partitions were flashed using Jeff's UBoot or Davy's UBoot version then the answer is yes. However, it's best that you get confirmation from Jeff or Davy.

Found original .kwb for GFH.

Actually, Jeff's manual Update uBoot on your Dockstar, GoFlex, or Pogoplug NAS says:

"If, for some reason, you want to revert back to the original bootloader... write to NAND uboot.mtd0.dockstar.original.kwb ".



Edited 2 time(s). Last edit at 10/27/2012 09:40AM by sambul14.

sambul14 Wrote:
-------------------------------------------------------
> Found original
> .kwb for GFH.
>
> Actually, Jeff's manual
> Update
> uBoot on your Dockstar, GoFlex, or Pogoplug
> NAS says:
>
> "If, for some reason, you want to revert back
> to the original bootloader... write to NAND
> uboot.mtd0.dockstar.original.kwb ".

There you go! but did you print out the envs to see what was the problem? sometime it's as trivial as a mispelled name or value.

Commands usb_root LABEL=rootfs and usb_root=LABEL=rootfs don't work in ArchLinux,giving:

Cannot open root device "LABEL=rootfs" or unknown-block (0,0)              # kernel message,  OR

Error: illegal character "=" in variable name "usb_root=LABEL=rootfs"     # Uboot message at boot (not at entering var)

It looks like Uboot can't pass the Label to Arch, but may be its OK in Debian. Here's original hint from Vlad about Ubit not able to pass LABEL param. May be current Jeff's Uboot can pass it to Debian (unless you use a different Uboot), but not to ArchLinux. Dox...



Edited 3 time(s). Last edit at 10/27/2012 06:21PM by sambul14.

Is that from serial console?

Its from both Serial and Netconsole after fixing access to it.

Related issue is, netconsole launch by Uboot changes env from serial to nc, so I wonder if its auto restored to serial if nc server isn't reachable by ping, and by which Uboot env settings?

stderr=serial          # was with netconsole off
stdin=serial
stdout=serial

stderr=nc               # once netconsole started
stdin=nc
stdout=nc

Edited 1 time(s). Last edit at 10/27/2012 06:59PM by sambul14.

sambul14 Wrote:
-------------------------------------------------------
> Commands usb_root LABEL=rootfs and
> usb_root=LABEL=rootfs don't work in
> ArchLinux,giving:
>
>

> Cannot open root device "LABEL=rootfs" or
> unknown-block (0,0)              # kernel message,
>  OR
> 
> Error: illegal character "=" in variable name
> "usb_root=LABEL=rootfs"     # Uboot message at
> boot (not at entering var)
>

>
>
> It looks like Uboot can't pass the Label to Arch,
> but may be its OK in Debian. Here's
> [url=http://forum.doozan.com/read.php?2,5073,5073#
> msg-5073]original hint[/url] from Vlad about Ubit
> not able to pass LABEL param. May be current
> Jeff's Uboot can pass it to Debian (unless you use
> a different Uboot), but not to ArchLinux. Dox...

Sorry, I assume you're booting Debian! the label won't work without uInitrd, and Arch does not use it.

Plus, it appears that the label is hardcoded into ulnitrd as "rootfs", which is not in line with what Linux freedom is all about. :)

I did check the netconsole issue, and it transpired, when network is not available, Uboot auto resets the env to output to Serial port.



Edited 2 time(s). Last edit at 10/27/2012 08:16PM by sambul14.

You can name your rootfs anything! I'm not sure what you've meant?

Vlad wrote:
------------------------

> My solution was to use Debian's ramdisk and > hardcode the label of the rootfs partition which I chose to be "rootfs".

I think, this issue should be reported upstream as a bug, so that kernel could be fixed to directly accept LABEL param from Uboot.



Edited 2 time(s). Last edit at 10/28/2012 06:24AM by sambul14.

I think you're confused 2 different approaches using the rootfs label :-) Vlad's approach was tweaking the initrd so that it can boot with UBit. But if you're running UBoot, then no need to hardcode the label name. Just use the env to pass it, and it will work. You can name the rootfs any name you'd want.

bodhi Wrote:
-------------------------------------------------------
> I think you're confused

Thanks for clarifying the issue. Still, it works only in Debian, not in ArchLinux. The reason may be, Uboot devs need to find the way to inform OS, what disk to boot from. Will talk to them via mailing list, since it seems Jeff abandoned Uboot forking for ARM devices - don't see him on the forum active for awhile.