laibsch

Thank you for sharing. Would be good to have your findings corroborated by some of official documentation. Thanks again for sharing.

If they boot, I wouldn't worry about any difference.

sounds good. good luck and keep us posted!

Yes, your logs show hundreds of errors, so it will be hard to pinpoint which one it is exactly. Here's a few things I can suggest that might move you along. "sudo service restart lightdm" # see if X now comes up on your TV, assuming that lightm is what you are using "sudo nano /home/*/.xsession-errors" # check the errors listed in those log files, they are more specific Can you try to flash an (older) image to a microSD card, boot off it and see what the results are? @Efe Çetin is the maintainer of your board, maybe he has a comment? Your board is in community-maintained status for armbian. There are no guarantees.

Do you know how to compile your own images? Do you know how to use "git bisect"?

I am always happy to see people keeping old hardware running. But I think it would be best to make the necessary changes in Armbian itself. I am happy to help out where I can be useful.

The ones I linked. You mentioned that you have no experience to compile stuff. One option is to target another SBC or a virtual machine so that you can focus on learning the build framework (explicit instructions are already given in some of the links) instead of having to deal with a multitude of issues (setting up your compilation host, getting compilation to succeed, finding the artifact to flash, only to then run into the next issue that armbian currently does not support your board). With a virtual system, you can be sure that you should get a working image. You can then focus on the compilation and familiarize yourself with that before jumping into real hardware enablement.

I suggest you check the logs for clues what is going wrong. syslog, .Xsession-errors, etc.

Thank you for reporting about this issue. What is the latest image that still works? Is it still available for you to download? Maybe this is the change you want to revert and see if that brings things back in line? But supposedly, that commit was boot-tested by Niklas. Your board does not have an official maintainer in armbian, so I suggest you contact Niklas to find out what the situation is for him.

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