b3 keeps resetting ** File not found uImage **

[sebi]

Dear forum community,

I am encountering an issue with my B3: it doesn't boot on the HDD anymore.

I have a serial console bounded onto the main board so I can observe the boot sequence and basically it keeps rebooting after saying ** File not found uImage **.

I tried reinstalling Debian stretch (9) image 1.1 from MouettE as well as the official depreciated b3-install-2.4.1.1, getting the same issues after the installations complete.

I tried reflashing U-Boot based on the information in this post http://forum.excito.com/viewtopic.php?f=9&t=5829 with the two methods described by MouettE: the one involving the USB key and the one involving direct serial transfer.
Flashing seemed to work fine but it didn't solve the issue.

Can anyone help me fix my bricked b3?

Here is a detailed log of the boot sequence keeping repeating forever recorded from the serial console:

Code: Select all

U-Boot 2013.01.01-b3-rodeus-g53a85c9 (Jan 16 2016 - 01:59:03)BUBBA|3

SoC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
WARNING: Caches not enabled
SF: Detected M25P16 with page size 64 KiB, total 2 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1116 Initializing on egiga0 @08 done
88E1116 Initializing on egiga1 @09PHY reset timed out
done
Hit any key to stop autoboot:  0
** File not found uImage **
resetting ...

[Gordon]

Your u-boot seems okay. According to the message it just fails to find the file "uImage" on the first partition of your HDD (/dev/sda1). Is this the original drive or did you swap it for something new?

[sebi]

Dear Gordon,
It is not the original drive indeed (I don't remember which drive is the original one).
I tried reinstalling Debian Stretch on several drives (300GB, 3TB, and 10TB) always getting the same behavior (B3 keeps resetting).
What is weird is that the installation seems to go flawless (according to the indications read using the serial console) but in the end, once it reboots to reinitialize, I get this strange behavior

[Gordon]

Right.

The 300GB is probably a SSD? It is a known issue that u-boot does not recognize certain types of SSD firmware which makes it impossible to boot from such a drive. I actually have such a drive in one of my B3s and to be able to use it I had to edit the u-boot environment to read the kernel from a USB stick.

In theory the same could apply to rotating disks, but that also most likely means that you have the wrong type of disk. Beware that due to the B3's enclosure you need a cool running disk which in practice means that its rotation speed should not exceed 5400 RPM. WD Red (NAS) drives are recommended.

Of course there is always a chance that the disk was in fact not properly initialized. You could use one of the Live USB editions to verify partitioning (/dev/sda1 must exist), formatting (/dev/sda1 must be either ext2 or ext3) and content.

[MouettE]

Hi sebi,

Could you try to type manually the boot commands in uboot (stop autoboot by pressing any key on the prompt, printenv bootcmd to show the active boot command list) and show us the result until the first error ?

[sebi]

Dear Gordon and MouettE,
All my drives are mechanical. They used to work in the past with the B3 (I don't remember about the 10TB).
I used the bootable live-USB of Arch Linux for the Excito B3 miniserver by Sakaki to verify partitioning:

Code: Select all

[root@archb3 ~]# fdisk -l

***SNIP***

Disk /dev/sda: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf4a36c07

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048    133119    131072    64M 83 Linux
/dev/sda2        133120   2230271   2097152     1G 82 Linux swap / Solaris
/dev/sda3       2230272 390721967 388491696 185.3G 83 Linux

***SNIP***

[root@archb3 ~]# blkid /dev/sda1
/dev/sda1: LABEL="boot" UUID="8e3ffd17-9f84-49e6-8980-f6504a5c2f76" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="f4a36c07-01"
[root@archb3 ~]# mkdir /mnt/sda1 && mount /dev/sda1 /mnt/sda1
[ 2560.853103] EXT4-fs (sda1): mounting ext3 file system using the ext4 subsystem
[ 2560.911357] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[root@archb3 ~]# ls -l /mnt/sda1
total 10392
drwxr-xr-x 2 root root    1024 Jun 25 16:32 boot
-rwxr-xr-x 1 root root      20 Mar 19  2015 cache_head_patch
drwxr-xr-x 2 root root    5120 Sep 13  2018 dtbs
-rwxr-xr-x 1 root root 5292543 Sep 13  2018 initramfs-linux.img
-rwxr-xr-x 1 root root    1589 Sep 13  2018 kexec.sh
-rwxr-xr-x 1 root root   10516 Mar 20  2015 kirkwood-b3.dtb
drwx------ 2 root root   12288 Jun 25 16:32 lost+found
-rwxr-xr-x 1 root root 5270360 Sep 10  2018 zImage
[root@archb3 ~]# ls -l /mnt/sda1/boot
total 5249
-rw-r--r-- 1 root root  108243 Apr  9  2016 config
-rw-r--r-- 1 root root 5243850 Apr  9  2016 uImage

...so everything seems to be fine, right?

I rebooted and typed manually the boot command in uBoot:

Code: Select all

B3> printenv bootcmd
bootcmd=run sataboot || reset
B3> run sataboot
** File not found uImage **

Just a little bit of context: this issue happened to me after I tried to install my B3 on RAID-1 volumes following the official tutorial for Bubba 2 and a post on the forum saying I have to modify uBoot sataroot environment variable (http://forum.excito.com/viewtopic.php?f ... 5&start=16) to make it work on the B3. Once I swapped the drives I got this weird behavior. Since, I tried to reflash uBoot and to reinstall Debian Stretch on a single drive but it didn't help

[Gordon]

ehm... So what are the present values for "sataboot", "sataroot" and "satadev"?

Note: if dumping the full environment do anonymize the eth*, serial and key values - these values give access to your easyfind account.

[sebi]

Values are:

Code: Select all

sataboot=setenv diskdev $sataroot; run setdiskargs; ext2load $satadev
satadev=sata 0:1
sataroot=/dev/sda1

The full environment is:

Code: Select all

baudrate=115200
bootalt1=run sataboot || reset
bootalt2=run usbinstall || run usbflash || run sataboot || reset
bootargs=root=/dev/md1 console=ttyS0,115200 serial=*** wiped out *** key=*** wiped out *** button=0
bootcmd=run sataboot || reset
bootdelay=1
bootfile=uImage
button=0
console=ttyS0
diskdev=/dev/md1
*** eth* removed ***
filesize=0x39fd9a
flashfile=u-boot.kwb
installfile=install.itb
*** key removed ***
loadaddr=0x800000
sataboot=setenv diskdev $sataroot; run setdiskargs; ext2load $satadev
satadev=sata 0:1
sataroot=/dev/sda1
*** serial removed ***
setbootargs=setenv bootargs root=$rootdev rw console=$console,$baudrate $othbootargs
setdiskargs=setenv bootargs root=$diskdev console=$console,$baudrate serial=${serial#} key=$key button=$button
stderr=serial
stdin=serial
stdout=serial
usbboot=usb start; setenv diskdev $usbbootroot; run setdiskargs; ext2load $usbbootdev $loadaddr /boot/$bootfile; bootm
usbbootdev=usb 0:1
usbbootroot=/dev/sda1
usbflash=fatload $usbflashdev $loadaddr /install/$flashfile && sf probe 0:0 && sf erase 0 80000; sf write $loadaddr 0 $filesize
usbflashdev=usb 0:1
usbinstall=usb start; setenv diskdev $usbinstallroot; run setdiskargs; fatload $usbinstalldev $loadaddr /install/$installfile; bootm
usbinstalldev=usb 0:1
usbinstallroot=/dev/ram0

Environment size: 1406/65532 bytes

[Gordon]

sataroot and satadev are okay. sataboot seems incomplete to me, but that may be because you are running a custom u-boot version. Whether or not the defaults that are apparently implied (like the "uImage" file name) work out the same is impossible to judge by me. In any case, sataboot in my environment lists as:

Code: Select all

sataboot=setenv diskdev $sataroot; run setdiskargs; ext2load $satadev $loadaddr /boot/$bootfile; bootm

[sebi]

Dear Gordon,

Thanks a lot! You gave me the solution: my sataboot environment variable was wrong indeed.
I corrected it with the content you gave me and now it works like a charm!

(I remember indeed I messed up with that variable when I was trying to configure RAID-1: I mixed up sataroot with sataboot at that time so once I noticed my mistake before saving environment variables, I tried to give sataboot its original value. I must have misread this value and gave it the wrong one.)

Anyhow, thank you both a lot!

Can you still explain me:

- why when reflashing uBoot, the environment variables are not reflashed with their original values as well?
- what exact environment variables do I need to modify to install RAID-1 on B3: diskdev, sataroot or both?

[Gordon]

1)
No, the flash should not touch the u-boot environment since this contains values unique to your device. I do believe that the flash image does contain defaults for at least some of the environment variables though and thus you'll likely get a better result from deleting a key then guess at its original content.

2)
Can't tell. I also think implementing RAID on a device for home use is somewhat pointless so I can't really be bothered about it as well. Should I however want to set up RAID I would most definitely not choose ancient MD Soft-RAID but go for more modern btrfs. I have no doubt that u-boot will not support that but honestly it doesn't really need to as long as it is able to hand control to a kernel that can. To still allow boot in case of a failed disk you could change "bootalt1" to read something like "run disk1boot || run disk2boot || reset" (obviously you need to define what disk1boot and disk2boot actually execute here).

[sebi]

1)
Wiping done. Thanks. Regarding deleting a key rather than guessing its original content, do you mean that when I erase a key, it will be reset with its originel value?
2)
Maybe MouettE can help me with this topic? (He is the one who wrote the tutorial regarding RAID-1.)
Indeed I might not set my device with RAID-1. But I remember experiencing many years ago the breakdown of my HDD on my B3, and having RAID-1 at that time would have been of great use.
I need to investigate what you mean by MD Soft-RAID versus modern btrfs because it is currently out of my knowledge.

[Gordon]

Sorry, no, not reset. What I meant is that the u-boot image itself contains default values for several/most/all of the variables you see being listed in the environment. Since the u-boot image is specifically created for this device it is very likely that the defaults are in fact the same as the values in the actual environment that is stored in /dev/mtd1 and overwrites these defaults.

MD as said is ancient and it is an absolute nuisance and not anywhere near transparent to mount the remaining member if it breaks. It is in fact how Excito originally set up the storage partition and even with the single disk configuration it wasn't exactly easy to mount the disk on another system when I needed to. I instantly dropped it when I moved to a new disk and that was even still on the old Squeeze based system.

[MouettE]

Maybe MouettE can help me with this topic? (He is the one who wrote the tutorial regarding RAID-1.)

Well, running the system partition on RAID-1 on the B3 should be possible. I think that Gordon has a good point it may not be worth it and the technology behind is somewhat old (the b3 is old too) but is still is a good hack.

The B2 tutorial for RAID-1 has been designed for the B2 but it can be adapted for the B3. Some stuff like having a separate boot partition might not be needed. It also depends on the OS image you use. For U-Boot, the variable that needs changing is sataroot. Also like Gordon mentioned, to be able to boot on either disk you need to make deeper changes in uboot configuration.

You should also know that flashing and/or changing uboot environment can sometimes lead to unexpected changes in the u-boot environment such as the one you encountered. It didn't surprise me.

[sebi]

Thank you both!