Hi guys,

 

I'm getting this error while trying to boot my Banana Pi with an SD card.

 

Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2447 bytes read in 211 ms (10.7KiB/s)
##Executing script at 43100000
Wrong image format for "source" command
SCRIPT FAILED: Continuing...
scanning bus for devices...
Found 0 device(s).
 
SCSI device 0:
         Device 0: not available
[...]

 

I'm coming from using Lubuntu with no problems for nearly a year. The SD card works no problem (or at least it worked perfectly fine with Lubuntu). I also tested with a way faster microSD 64GB I usually have in the GoPro, with the same result.

 

What should I do to continue? I reckon this must be a n00b mistake, I must be missing something...

Please provide a link to the image you are installing.

I'm very sorry, I just noticed I missed what I was using and was heading already to post it..

http://mirror.igorpecovnik.com/Armbian_5.14_Bananapi_Ubuntu_xenial_4.6.2.7z

 

Xenial server (vanilla) 4.6.2 for Banana Pi.

It boots fine. How did you write an image?

 

http://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

I used dd if=./file of=/dev/sdc

Since you mention it, I'll use the buffer size option and try again...

I'm getting this error while trying to boot my Banana Pi with an SD card

 

And does it then continue to boot after showing countless info, warnings or even errors or does booting stop?

...aaaand it seems to get much further. But...still not. Stuck at "*Starting SSH Keys regeneration" for over 10 mins. Should I ssh into it?

 

 

 

And does it then continue to boot after showing countless info, warnings or even errors or does booting stop?

 

Yeah, it eventually crashed and stopped booting. It gave me an uboot prompt. But now it seems to load the kernel, although it still seems to be doing something...

Getting stuck on u-boot prompt might be related to peripherals connected (I personally had weird USB peripherals causing this as well as a noisy power source leading to noise on RX of uart0 which prevented u-boot from continuing) so it's the best idea to disconnect everything expect serial console.

 

Then we might have introduced a 'bad user experience' problem a few months ago since the board might be ready for login while the user waits for an automated reboot that will never happen with Xenial images.

 

But since you mention 'Starting SSH Keys regeneration' (part of our firstrun script that does a lot in the background) it might also be related to insufficient power supply. Unless you power Banana Pi M1 through the SATA power port it's a known problem that many USB cables drop voltage too much under load due to high resistance. If you can try to exchange PSU and cable if problem persists. In case peripherals or a board powered SATA disk is connected please try without at least for first login.

 

Once you got Armbian up and running you can monitor voltage available through sysfs and check whether that's the culprit or not

Hum...I was just waiting thinking maybe it was doing something extremely long. I just hit enter, just in case, and gave the login prompt back. So it seems after finishing whatever it was doing with the SSH keys, it didn't throw any further messages. I SSHed into it, and was prompted to change the password. Did a reboot and wasn't shown again any first boot script. Seems to work now!

Hum...I was just waiting thinking maybe it was doing something extremely long. I just hit enter, just in case, and gave the login prompt back.

 

Yeah, 'bad user experience' as already suspected. Since we had a few complaints regarding this we already had a look into it and Zador came up with some ideas that hopefully prevent this sort 'failure experience'...

Oh ok...not that horrible user experience, huh!

So far it's looking good...I'll get into more complicated stuff now, thanks a lot!

Yeah, 'bad user experience' as already suspected. Since we had a few complaints regarding this we already had a look into it and Zador came up with some ideas that hopefully prevent this sort 'failure experience'...

The main idea is - remove all extra messages from firstrun script. Since now we use fallocate instead of dd for emergency swap file creation and we don't update packages list on first boot, the script should execure fast enough that we don't need to output its progress.