SteeMan

Interesting. I didn't know that existed. It must be a wrapper for the functionality available through armbian-config (or vise-versa). Either way the standard Armbian functionality doesn't work with the amlogic TV box builds and will not leave you with a working EMMC install. That is why the amlogic TV box install instructions give the correct alternative. Regardless of that, your logs show that you are booting from sd card. And the state of your EMMC shouldn't cause the type of error you are seeing.

Start here: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus

Moved post to correct forum. Your board isn't supported by Armbian, but you were posting in the supported boards section, that is why you couldn't apply the correct board tag. Moved to community maintained/ unsupported

Also, you mentioned armbian-install, but I'm assuming you meant armbian-config. As there is no armbian-install. Unless you are using the ophub images which have a script called armbian-install, but they aren't armbian but a fork of armbian.

Based on the logs you posted, it is booting from SD when you have the SD card inserted. I don't know why it is erroring in that way. I would try a more recent image and see if that might work.

I think your real question is why hasn't Rockchip put in the effort to get these drivers into mainline linux? It isn't the goal of Armbian to be the repository of large amounts of unmaintained code. The goal is really to bring mainline linux to devices. But that assumes that everyone else is working to bring various bits and pieces from custom linux forks to mainline linux. While sometimes it is necessary to temporarily host code that has been ported to mainline, but not yet incorporated upstream, most of the efforts should be to get the code into upstream mainline linux.

The instructions you are using are 4 years old. No longer relevant. Wrong. That does not work for the TV box builds. You need to be following the current instructions in the TV Box FAQ: https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus

It reports it is full, probably because it is full. The last set of commands @going suggested you run are to try to figure out what has filled up the storage. du -s will be your tool in looking as where the storage is being used. Google for how others use this command for this purpose.

It looks like that box is using an amlogic s805 cpu (which is a very old 32 bit cpu). The amlogic s905 was their move to 64 bit cpu. There isn't any currently active work that I am aware of to support this cpu anytime recently. There is a very old thread dedicated to this cpu:

Lets start with some basic information: What build are you using? What installation instructions are you using?

Did you no read what I wrote? If you want help that thread is where you need to post your question/issue.

You should be following the instructions in this thread: https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards And if you have any questions or issues you should post them there.

post moved to correct location

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

The reason this would work is that you really have a s905L2 cpu. This wouldn't be the first time that a TV Box vendor and/or parts supplier changed the markings on a chip to give the impression it is something else.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

GPT is something the Armbian build framwork supports, not currently the default, but here is a list of boards that use it: grep -i gpt * armsom-sige7.csc:IMAGE_PARTITION_TABLE="gpt" armsom-w3.csc:IMAGE_PARTITION_TABLE="gpt" bananapir2pro.csc:IMAGE_PARTITION_TABLE="gpt" fxblox-rk1.wip:IMAGE_PARTITION_TABLE="gpt" hinlink-h28k.csc:IMAGE_PARTITION_TABLE="gpt" hinlink-h88k.csc:IMAGE_PARTITION_TABLE="gpt" hinlink-ht2.csc:IMAGE_PARTITION_TABLE="gpt" indiedroid-nova.csc:declare -g IMAGE_PARTITION_TABLE="gpt" jp-tvbox-3566.tvb:IMAGE_PARTITION_TABLE="gpt" khadas-edge2.conf:declare -g IMAGE_PARTITION_TABLE="gpt" mangopi-m28k.csc:IMAGE_PARTITION_TABLE="gpt" mixtile-blade3.wip:declare -g IMAGE_PARTITION_TABLE="gpt" nanopct6.wip:IMAGE_PARTITION_TABLE="gpt" nanopi-r5c.csc:IMAGE_PARTITION_TABLE="gpt" nanopi-r5s.wip:IMAGE_PARTITION_TABLE="gpt" nanopi-r6s.conf:IMAGE_PARTITION_TABLE="gpt" odroidm1.conf:IMAGE_PARTITION_TABLE="gpt" orangepi3b.csc:IMAGE_PARTITION_TABLE="gpt" orangepi5.conf:IMAGE_PARTITION_TABLE="gpt" orangepi5-plus.conf:IMAGE_PARTITION_TABLE="gpt" panther-x2.csc:IMAGE_PARTITION_TABLE="gpt" quartz64a.csc:IMAGE_PARTITION_TABLE="gpt" quartz64b.csc:IMAGE_PARTITION_TABLE="gpt" radxa-e25.wip:IMAGE_PARTITION_TABLE="gpt" rock-3a.conf:IMAGE_PARTITION_TABLE="gpt" rock-5a.wip:IMAGE_PARTITION_TABLE="gpt" rock-5b.conf:IMAGE_PARTITION_TABLE="gpt" rock-5-cmio.csc:IMAGE_PARTITION_TABLE="gpt" station-m2.csc:IMAGE_PARTITION_TABLE="gpt" station-m3.csc:IMAGE_PARTITION_TABLE="gpt" station-p2.csc:IMAGE_PARTITION_TABLE="gpt" xiaomi-elish.conf:IMAGE_PARTITION_TABLE="gpt"

@MrK My question would be, are you planning on submitting your changes upstream to mainline? So any patches you end up with don't become a long term Armbian maintenance burden.

There are images on the download page, but the OrangePi One is in the Community Maintained status there. I think @Stephen Graf question them becomes why is is listed as Community Maintained when it is a .conf, not a .csc?

That was my thought as well, odd. @Jedge Can you reproduce the problem? As Werner stated, on first boot the filesystem on the SD card is supposed to be expanded to take up the entire card. Do you have smaller SD cards you could try, curious if the card size is triggering an issue.

Moved to Community Maintained Allwinner. @krrmbn Note that this is not an Armbian supported board. It is community maintained.

Moved out of TV Boxes to Standard Support forum. The vim2 I believe is standard support as it is .conf but there is no subsection for vim2 so I moved it to the vim3 section.

I just want to add a few comments to this whole dtb overlay discussion. First I want to thank all of you involved in this discussion. You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution. What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well. From what I have seen, good minds are thinking this through and I expect a good result to follow. The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum. And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that. The status of the dtb overlay's across Armbian supported and community maintained boards is poor. There is no standardization from family to family or board to board. And no testing of what does exist to ensure that it works. Now I'm not saying that all of this needs to be solved in what comes out of this design discussion. I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things. I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide. But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

Moved to a new post, instead of reopening a thread that is over a year old.