laibsch

It appears that Heiko is the maintainer for RPi boards (all varieties?) in Armbian, but I believe @Igor also has the device and maybe he can repond. I suggest you try to talk to Heiko and see if he has something to say. I just perused the git sources and you might want to talk to Pander as well.

Brace yourself, this is going to take a long time, most likely months to years and most likely you will never get this to run. That being said, to get yourself started, you probably ought to start compiling stuff and getting yourself familiar around the armbian build framework. Do you have another SBC that is supported by Armbian? If not, it's probably best to target one of the virtual system options. I wish the documentation for this stuff was better. As of now, it is scattered throughout.

Personally, I would suggest to not even run a Desktop Environment, certainly not on a true IoT device. What GUI software do you plan to run? Are you aware that X can forward a GUI over ssh for you? Let's say you wanted to run blender and display the output at home or in your office on your shiny 27-inch, curved 4K display. OK. First, install the software on the IoT device "sudo apt install blender". Secondly, make sure X Forwarding is enabled on the IoT device "sudo grep X11Forwarding /etc/ssh/sshd_config" and make sure it is set to yes. Then, you should be having no problem to get blender to run on your IoT device but the GUI window will show on your large display with "ssh -X $IP-of-your-IoT-device", run this of course from your beefy machine. This works just the same for any other software you want to run remotely.

Have you tried to ask this in our discord server?

I'm sorry, but I don't see where the problem is. Please be more specific.

it would be good to have those logs for a non-working setup.

awesome, well done! and thank you for sharing.

Hello @alg_42 You have only 1 GB of space in /tmp. This is tmpfs, so it uses your RAM. It is not enough to unpack your backup into. You can increase the size but the Pine64 either has only 512MB or 1GB of RAM, so that is not a good idea. I suggest you temporarily deactivate the /tmp mount instead, reboot, complete your backup and then reactivate the /tmp mount and reboot again. Armbian puts /tmp on tmpfs so that the frequent writes to it do not wear out your flash so it is important you reactivated it later on and don't leave it on your main partition indefinitely. Can you share the output of "grep tmp /etc/fstab" with us?

looks like a kernel oops does the unit run properly afterwards?

Thank you for that information. From a cursory look, it seems as if that is only binary images, no source (violating GPL).

I will try to make that easier and more automatic with APA, eventually.

Thank you for letting us know as it allows an interested party to more easily bisect the regression.

Thank you for letting us know, much appreciated. Have you tried to reach out to Michael Hawkins, the maintainer?

so, you are good now?

probably best to specify location for any sales offer

What is the status here?

The OrangePi Zero 2w is maintained by the community and chraac in particular. Maybe try to contact him by e-mail if you don't get a response here. Or talk to other owners of the device here in the forum to see if they can answer your question.

Great news and thank you for reporting back. Do you have any idea what they changed or where they host their sources so we can have a look? There is for example this. There is another user who reported running into problems that sounded a lot like yours.

Thank you for that information, @Mechano. Did you ever get this board to work, with armbian or another image?

looks like a really cool machine. unfortunately, no maintainer in armbian and I am not aware if any of the regular developpers has that SBC. It seems to be based on the H618 which it shares with the Orange Pi Zero3 which is reported working with the latest Armbian release. Did this board ever work with an older release? Is this a regression? I see somebody else mentioning they have issues with the board booting, , apparently due to issues with thermal management. And your crash apparently started in pstate.

Nice. To help other users of the forum, it would be good if you shared what fixed the issue.

To be honest, I'm confused. You reference three different systems and it is unclear to me which one it is that FTBFS for you. Let's take a step back. Do you have the latest git tree of armbian/build? Do you have any local changes? What is the exact command you for compile.sh? I will try to reproduce the problem here.

I do not understand what is "not working". Please elaborate. Also, providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

are you sure all storage devices are working without issues?