I tried installing the Server image, checked it multiple times, is the correct image.
It boots then does this, then shuts off. I can’t get a wireless keyboard to work with it.
would anyone have any ideas about this?
This is most likely a power problem. Please read the OP.
I have the exact same problem as above. this is my 3rd board. first 2 are perfect from last year. this one is new just arrived today. tried raspbian and ubuntu images, different SD cards, same SD from another board, etc. using identical power supply from my other 2. tried swapping them as well. I really dont think it’s a power supply issue.
EFI stub: Booting Linux Kernel...
EFI stub: Using DIB from configuration table
EFI stub: Exiting boot services.
Thanks for playing, I tried swapping to a Pi 4 psu on your suggestion just now and it still does it.
If you have an USB UART cable, you can tell the exact reason by hooking it up and getting the logs. It’ll tell you what went wrong. You can also manually edit the boot command line and add noquiet.
Press e at the grub menu and then add noquiet to the linux command line.
1 Like
Could you provide references or links that provide the information on how to perform this operation with the USB UART cable specifically for our Le Potato (AML-S905X-CC)?
Or if it’s 100% the same as the procedure for a Raspberry Pi then can you please state that definitively?
I’m new to this forum. However, I can see from reading through this post that many of the users here are very non-tech savvy people;
The few guys above need to read up on zip files and what they are as user Luke_Burgess now thinks that random pieces of zip files come preloaded on brand new sd cards from the store and is most likely very paranoid (unnecessarily so by the way) of purchasing sd cards. If you’re reading this then please know that you yourself probably copied a zip file to the sd card. It did NOT come on there preloaded.
Any offerings of advice on this forum should contain complete instructions or links pointing to said instructions in order to better assist your customer/fan/tinkernaut-base.
Very generalized responses are only going to result in accidents, more confusion and then 10 times more posts on here to junk things up.
I myself somewhat appreciate generalized info and responses as it forces me to research DD for example and learn about it extensively before use. My command for the emmc flashing differed a bit such as status=progress to see the % completed and I’m not sure if you had the conv=fsync in there but I added that as well. There was a lot of conflicting info on which sync option to use. Some sources said conv=sync is all you need to do now and that it will sync the data and metadata but I chose conv=fsync just in case.
The problem isn’t getting people to do their own research anymore. The problem is people who have no idea what they’re talking about giving terrible advice all across the internet. Then you get people pulling bad or very often outdated info and advice and then regurgitating it back onto this forum (or other forums) and confusing the heck out of people or turning their devices into bricks.
If no ideal instructions / links are available let’s post a response requesting any users of whom can be of assistance to step forward and provide a working set of instructions. It can then be stickied, posted on here and linked to, etc.
Don’t be afraid to admit if you guys yourselves don’t have an answer. Most of us will understand and I’m pretty sure we all just want the truth in the end. We can all get there together…well…perhaps soberly I should add.
Thanks and no offense intended!
1 Like
Hi, as one of the people who answered questions about flashing here, and a fellow hobbyist, I’m glad to hear you opinion on how I spend my limited free time answering questions here.
Watch now as I trip over myself to google your question for you.
Sorry Angus, perhaps I should have specified that I wasn’t referring to the hobbyist community itself here but rather the mods. Is it too much to ask that the need for cross searching topics be kept at a minimum? Perhaps you’re younger and have time but my time isn’t plentiful unfortunately. How can you possibly know what level of environmental toxins I’ve been exposed to over the course of my life-time that might be making sifting through this technical data very hard to do so? I’m in NY state btw in the jet stream of OHIO - EAST PALESTINE. Just another thing added to whatever else I’ve been struggling with. Sorry, but be more considerate of all situations people might be dealing with. I have other health issues as well. I could’ve also been a 9yo but I’m not but just saying. I want answers in one place. That makes sense to me. Does it NOT make sense to you. There’s a lot of variables with these chips, SBCs, different OSes, etc. Please don’t play it off like you haven’t suffered sleepless nights over pouring over so much data that ended up being useless, irrelevant, etc. I’m just trying to help others make sense of this subject more easily.
I’m trying to flash Plasma Bigscreen os on Le Potato but it doesn’t seem work, the green light just doesn’t show up. I really wanted to flash it on to the board, what do I need to do for it to boot?
Do not double post the same issue on multiple theads. Use a new thread as this has no relevance to boot issues for official images.
So I can’t boot from a USB stick unless I have a boot loader in eMMC or SD card , right ?
Depends on the board. eMMC and SD are usually faster than USB 2.0 anyway and our images don’t have the issues Raspberry Pi does with destroying MicroSD cards.
USB 2.0 - 40MB/s optimal
MicroSD - 90MB/s optimal
eMMC - 180MB/s optimal
2 Likes
Hello,
I have a strange issue with the Le Potato board. I flashed Armbian with Cinnamon desktop on a uSD card and booted it. The board light up correctly, the kernel and services load correctly, and I am greeted with the Cinnamon login screen. I put my user and password and after I press ENTER the monitor enters sleep mode. I do not get to see the desktop.
I have not tried the CLI version of Armbian (tonight I will), or the Debian versions.
As for power, I am using a Raspberry Pi 4 approved brick capable of providing 2.4A and 5V.
Not sure what is the issue and I think no one here has had this issue. Can you please help me see what could be the issue?
The board was bought from Aliexpress, if that helps.
Thank you.
EDIT:
I have tested the Debian 12 image with Gnome and it works just fine! So Armbian image is the issue. Will not use it since I have Debian 12 built for Le Potato 
.
Armbian is a community project. The images can vary in quality depending on the time it was downloaded and since there’s no CI by the Armbian team yet, it may have issues.
1 Like
That really misses the point. That suggestion means some form of access to a somewhat working system already.
Booting uSD first means inserting a known-working uSD and starting from there. Simple access to a recovery process: insert uSD and boot.
Booting eMMC first means connecting UART to access uboot and interrupt - assuming that there isn’t some corruption within uboot on the eMMC. Complex access to a recovery process: assumes connectivity to UART and fully-functioning uboot.
It seems that the eMMC → uSD fallback it hard coded, then alternatively, is there a uboot that can be written onto eMMC which prioritizes USB/uSD booting such that it would attempt to load any uboot/EFI from uSD if present before using eMMC as a fallback? At least this would ensure easy recovery and dual-booting in the future.
That’s not quite the same. From what I understand of that thread, it is:
- boot eMMC Grub
- if select ‘uSD boot’ then boot uSD
Not the same as:
- attempt uSD boot first
- if fail, attempt eMMC boot
The ‘solution’ in the other thread is more of a workaround as it requires user interaction during the boot process.
Or am I misunderstanding the Attempting to dual boot - #5 by librecomputer recommendation to add boot_targets=usb mmc1 mmc0 in boot.ini file ? Does mmc1 refer to uSD and mmc0 refer to eMMC?
echo "boot_targets=usb mmc1 mmc0" > /boot/efi/boot.ini
This works! Well, it ALWAYS boots from eMMC, so adding this line to (/dev/mmcblk0p0)/boot.ini makes it try booting USB first, then uSD. So to answer my own questions:
- yes, this works on Raspbian11 by creating the boot.ini file in the first (FAT) partition
- yes,
mmcblk0refers to eMMC andmmcblk1refers to the uSD
This boot.ini above should be the default in every image, at the very least for lepotato.