TRS-80

Do you have something against regular vanilla Debian?  As a long time Debian user myself, I would feel much more out of my depth on Manjaro, personally.

Nice chart!  So nice, in fact, that I will spare you the rms sermon. 
 

Opened PR for this change: https://github.com/armbian/build/pull/3619
 
regards,
Chris

Do you have any hint on what to look at to try to fix that issue ?
I might invest some time on it (and hopefully also get some more knowledge about these things)

It seems to me like outreach efforts over the years (by people like @NicoD, etc.) have been putting us on the map.  I also tried to help get the word out on last release announcement, which ended up being picked up / re-posted more places than ever before (including LWN, Tom's Hardware, r/linux, etc.) which I think probably helped, too.

If the (one) disk is large enough, you could also dual boot.

Don't be discouraged if people don't see this right away.  Maybe bump it again later.  Well, here, take my bump. 
 
Those warnings are to scare off the tidal waves of people seeking free support through the back door, not for actual well thought out propositions like you are making here. 
 
Did you try playing with this locally yet?
 
 

Updating images 20220317 (edge 5.17 and current 5.16).
The operation of the standard procedure for installing the system on eMMC via armbian-config has been verified (i.e. you can install the system on eMMC directly on the Quartz64 itself, no additional adapter is needed to write the eMMC module via USB).
Added support for starting the system from USB media. This greatly simplifies and expands the possibilities of running different systems (for example, during testing). Now you can use not only SD cards, but also any USB media to start (and/or work). For example, I installed and configured the Armbian working system on eMMC (with support for launching from USB) and now I easily launch other Armbian test images from ordinary USB flash drives, which is much easier to handle (no card readers are needed to write SD cards, the cost of USB flash drives is much lower and the choice of which models to use \ buy is much wider).

I recently received a sample of Quartz64. I have added CSC level support for Quartz64a to the ArmbianTV build system, after checking and testing, I plan to send a PR with these changes to the official Armbian build system.
 
The first test images for Quartz64 can be found at the link.

https://disk.yandex.ru/d/xMVoaZXFFcWuog

Hi all,
 
While building a custom image that needs to do some things at the end of the first bootup and reboot, I ran into some issues with armbian-firstrun.service. It currently has Type=simple, which means dependencies will be started when armbian-firstrun is *started*, and there is no clean way to wait until after it has *finished*. Looking to fix this, I noticed some other things that could be improved in this area, such as using systemd's first-boot-complete.target and ConditionFirstBoot to more simply manage first-boot-only services.
 
I'm considering implementing some changes and submitting them in a PR, but before I do that, I'd like to get some feedback on the approach and whether it seems worth investing time into. I considered creating a github issue about this, but given it is sort-of a feature request and the github new issue wizard seems intended to redirect away from github issues, I thought to instead post here. If a github issue seems more appropriate, I'll gladly repost there.
 
In any case, to solve the particular problem I was having (a service that needs to run after the full first boot has completed, including resizing and firstrun script), here's three incremental changes that I would think would make sense (just 1. would be the minimal to solve this problem, 1. + 2. would solve it more generally, and 1. + 2. + .3 would simplify the code a bit maybe).

1. Make armbian-firstrun.service `Type=oneshot`, so you can declare `After=armbian-firstrun.service` and `After=armbian-resize-filesystem.service`. This also means that system boot is delayed until this service is completed, but it does not prevent other boot services to run in parallel, so I would not consider this an issue (if it is, then removing the `Before=getty...` stuff could be considered, which is currently pointless anyway (you will not get a login prompt until armbian-firstrun.service is started, but it will not wait for completion). Note that using `Type=simple` in armbian-firstrun.service originates from https://github.com/armbian/build/commit/ee8d396fa639cd89e08fdd6646c32308f3b25f4f, but there is no rational for this choice.
2. Give armbian-firstrun.service and armbian-resize-filesystem `Wants=first-boot-complete.target` and `Before=first-boot-complete.target` so `first-boot-complete.target` does not fire until `armbian-firstrun` is done, allowing others to just do `After=first-boot-complete.target` without having to explicitly reference specific services.
3. Give armbian-firstrun.service and armbian-resize-filesystem `ConditionFirstBoot=yes` to let systemd ensure they are only called on the first boot. This allows removing the `systemctl disable` calls in these respective scripts as well, but needs the `/etc/machine-id` file to be removed (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900366#20), but that's probably a good idea anyway (to be regenerated on first boot, currently all machines using the same image have the same machine id).
 
One thing (feature or seeming problem maybe) with using ConditionFirstBoot as suggested above, is that systemd ensures that if the first boot is interrupted, the first boot services are ran again on the subsequent boots, until they have all ran completely (to ensure they all had a chance to ran). This is implemented by (roughly) running ConditionFirstBoot services only if `/etc/machine-id` does not exist, and only writing it to disk *after* all `first-boot-complete.target` services have completed (also when they failed, I think). This means that if the boot is interrupted before *all* first-boot services are ran, all of them will be ran again on the next boot and needs these services to be ok with being ran twice (this is also currently the case when the boot is interrupted when either or both services are still running, except that if either service completes, then that particular service will not be retried, but others might be). See also https://man7.org/linux/man-pages/man5/machine-id.5.html
 
As a related optimization, if 1. above is applied I think we could also add a `Before=ssh.service` to armbian-firstrun.service and remove the sshd restart from `armbian-firstrun`, so systemd just delays sshd startup until the keys are generated (but only if armbian-firstrun is active, so on subsequent boots sshd is started as normal).
 
Also, regardless of all of the above, I see that the armbian-firstrun deletes the ssh host keys and then forces regenerating them by calling dpkg-reconfigure. However, it would seem safer to me to actually delete the ssh keys at the end of image generation somewhere (maybe in `post_debootstrap_tweaks()`?), to really rule out the possibility of machines all using the same (publicly known) keys from the image file.
 
So, how do these sound?

I needed rpi-clone support for Armbian as well, so I implemented at least basic support at https://github.com/billw2/rpi-clone/pull/140

Testing welcome (probably best to just download the script from the pullrequest, since there has not been significant activity in that repo, so I do not expect the PR to be merged anytime soon...)

Done.
 
Next time @MichaIng (or anyone, really) please 'flag' the post to bring it to (all) moderator attention.  I only happened to notice your request because I was skimming through the All Activity feed like I usually do.

Take care of yourself and those around you. Best of luck. These things can wait. Cheers.

Not AFAIK, and also ISP camera support was planned but I am not sure of the current status. I think those are the two main points why someone would like to stay using legacy.
 
I wanted to do some standard packages for all distros in mainline, but I have been overloaded since some time ago, and I am not sure when will I be able to have a look at it. I will announce if it becomes ready.

I've since become a maintainer for this board. 
I've added the new phy into the build, and it's working well for Linux-5.10y, Linux-5.15y and Linux-5.16y.

Hi all.
In my latest video I make an Armbian Build server out of my old x86 PC. And I set up an extra Odroid HC4 as NAS with the old hard drives from my PC.
I hope you'll like it, greetings.
NicoD
 
 

It seems to me like outreach efforts over the years (by people like @NicoD, etc.) have been putting us on the map.  I also tried to help get the word out on last release announcement, which ended up being picked up / re-posted more places than ever before (including LWN, Tom's Hardware, r/linux, etc.) which I think probably helped, too.

Previous estimate I totally pulled from my rear end, because I have no idea. 
 
But sounds like maybe a little more often than I was thinking.  Probably whatever system default is doing is likely fine, unless you really know what you are doing and/or have some reason for changing it?

Sounds way too frequent to me.  Unless you are maybe constantly writing to it or something.  In which case you should use something more robust like the sort of (industrial, expensive) hardware they recommend for ZFS cache.
 
In normal usage I would think like twice a year (or quarterly, monthly?) maybe, I dunno.  Why do you think you need to do it so often?
 
 
Yes and a lot of info out there on the Internet about trimming SSD are out of date.  In most cases all that is done automatically now.  As you point out though, I am not sure how this works on flash devices.

@IgorI support this 1000% This is common practice is large projects in open source and enterprise.     I definitely think we're ready to add this process.   It's a great sign that our project is growing more mature.
 
Lets strongly encourage that _anybody_ can click to suggest a reviewer so that the PR and discussion can get attention quickly.      Great chance for all the devs to learn more about each other.
 

Hi!
I am the owner of the SBC Zoo, my pets are:
 
Orange Pi PC 2 (H5)
Orange Pi Zero+ (H5)
Orange Pi Zero Plus2 (H5)
Orange Pi Zero 2 (H616)
NanoPi DUO2 (H3)
Radxa zero 4GB/32GB
Raspberry pi B+
Raspberry pi A (256MB)
Raspberry pi 2B
Raspberry pi 3B
Raspberry pi 3A
Raspberry pi zero W
Raspberry pi zero 2 W
Some A20 based boards and TV boxes
 
How can I integrate into the development of the project?
 
I've recently started moving to 64bit boards and I'm currently selling
 
Orange Pi PC (H3)
Orange Pi Zero 512MB (H2+)
Orange Pi Lite 512MB (H3)
 
boards, if you think these boards will be useful for the project, I'll keep them for Armbian.

I've made some advancement in debugging "armbian-ramlog & armbian-truncate-log" complex.
Your /usr/lib/armbian/armbian-ramlog has a syntax error in the array expression 
${XTRA_RSYNC_TO[@]+"${XTRA_RSYNC_TO[@]}"} The 1st array lacks a closing } curly braces. Secondly, I can't figure out, why the same array is duplicated.
Even if you parse a variable XTRA_RSYNC_TO=(--delete) from /etc/default/armbian-ramlog, it will result in :
--delete+--delete Another problem comes, when you call 
/usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1 from /usr/lib/armbian/armbian-truncate-logs. It actually produces the error:
# /usr/lib/armbian/armbian-truncate-logs /usr/lib/armbian/armbian-truncate-logs: 23: /etc/default/armbian-ramlog: Syntax error: "(" unexpected I believe there is a syntax error in the way the call is made, where the XTRA_RSYNC_TO=(--delete) variable is not accounted for.
Could you give it a glance?
Otherwise, if the XTRA_RSYNC_TO=(--delete) variable is remarked in /etc/default/armbian-ramlog
and "--delete" option is hard coded in /usr/lib/armbian/armbian-ramlog, the complex starts running without raising exceptions.

I found it:
 
You have to use device tree overlays for that:
https://github.com/OLIMEX/olinuxino-overlays/tree/master/sun7i-a20/A20-OLinuXino-Micro
 
Also there are some helper scripts here:
https://github.com/OLIMEX/olinuxino-overlays/tree/master/scripts
 
And this is how you turn backlight on and off:
https://www.olimex.com/forum/index.php?topic=8572.msg32849#msg32849

@NicoD was looking for a video thumbnail just the other day in fact.  Maybe you guys can eventually link up and do some collaboration?  Besides other things mentioned.
 
Thanks for reporting back.  Don't worry, we all come and go.  I disappear for weeks and months some times.  We all do what we can.  Cheers!

I was very happy to realize that the raspberry is now also supported. Many have waited a long time for this.
I immediately wrote an article about it on gnulinux.ch.
Hopefully this will not be a half-hearted project.
I also think it would be an advantage if Armbian would appear as a distribution on the Raspberry download page