lanefu

I wasn't sure where to put this...but this thread seemed closest. Armbian wallpaper / artwork rendered in Blender 3.1 with procedural text and materials.
 

This is quite interesting board and it would be really nice to have the Armbian powering it.
What makes the board good are the features, like:
8GB RAM - awesome! M.2 SSD connector - so the drive can be added with very low profile and no wires. I wished there were 2x M.2 connectors to easily create RAID.1 mirrors. Additional SATA so more drives can be connected or even the hub for NAS applications. Solid heatsink. Price is on the level of other 4GB RAM models of Odroid. Theses boards can be easily stacked to create compact but powerful clusters that make no noise and fit nicely into the closet data-center.

Its impossible to get all people together and this meeting was anyway on a short notice due to upcoming holidays and the fact we are late. 
 

Anytime, at once - found something?, file a bug. Focus is CURRENT kernel, others are optional. Check once again in Jira if closed and on device, after code freeze. That would be ideal process for now. I hope we are going to bump automated testings on a better level soon, so not much manual intervention will be needed.
 
Other general things like bug in 1st run script or similar, should also be booked to Jira. Unless they are not already present. In case something else, not something from your field needs to be closed or moved ahead (to this version), help is welcome. Somebody has to do it ...

Release Candidate Code Freeze Date: 2022-05-14 Release Planning Meeting Date:  2022-04-23 14:00 UTC+1  Release Planning Meeting Location: Armbian IRC Release Date: 2022-05-28 Release Coordinator: Igor  
Board maintainers:
@Contributor/Maintainer
 
Open / close bugs related to your board  in Jira for your board and close them if they are resolved before release date. Record also bugs that were closed but they were not recorded to Jira (to have this info in release documentation) Bugs that are resolved change field "Fix versions" to "22.05". Optional select board and SOC.
Everyone with Jira access:
@private/contributor
 
claim ownership of closed tasks (Assignee) close issues if they are done (change field "Fix versions" to "22.05") move issues to next release cycle (this needs to be done) or backlog (one day)
Anyone that wants to join:
 
we are fairly good in maintain hardware, a little less in tweaking OS and desktops, ... We are good with infrastructure, except forums. Here we need help in moderating and reorganising. We also need help in leading projects. Like this release cycle and many small projects. If you wanna join coordinating release, read this ...  
Meeting preface:
 

 

 

Presumably this is a crosstalk problem, USB 3.0 uses a high frequency that interferes with WiFi (the chips are too close to each other). Details are available on the khadas official forum.

Hello to everyone and greetings for the great work they do, just to tell them about the experience of having armbian, installed in my tv box, to the purpose the operating system I have installed it in a tv box, with rk322x processor, of 1gb branch and 8 storage, so far it is working with normal detail to the following:
wifi: works with your own wifi, if I put external antenna (door dongle) also works the same.
bluetooth: it works perfectly with outside dongle.
searched by voice with external microphone (in fact the tv box, has not incorporated), works perfectly with ob-type sound card.
print documents? of course, with any printer connected to the ob port.
scan documents? effectively without problems.
Also works with normal an external disk connected directly to an ob port.
I hope this information will serve someone, I only intend to share my experience of using armbian on a tv box, rk322x, any very grateful comment, and again congratulations to the developers of this excellent distribution...and to the people who make possible the installation on the tv box, long life to you...ya linux.

You're probably going to need to be a little more hands on with the tool you choose.    
 
I like borg and borgmatic.

You're probably going to need to be a little more hands on with the tool you choose.    
 
I like borg and borgmatic.

Gentlemen, thank you very much for the topic raised.
I discovered libgpiod. Today I checked on orangepipc2. All the functionality described in the help for teams works. And I saw more advantages.
If the pin is configured as an input, then I get a timestamp about the event automatically.
Two different processes will not be able to access the pin at the same time.
There are more advantages.

Hi great question.  Def can be confusing.  We're working to be more clear.
 
GitHub issues (NOT PRs) are meant to be specific to the Armbian build engine and not specific to devices.
 
Raise device issues on forum for conversation and hopefully find the attention of a maintainer.  (Part of reason we do it on forum is it creates too much noise on GitHub for such a small team of devs)
 
If it's an issue a maintainer or armbian developer thinks it needs to be prioritized, they will add to our Jira
 
For those that don't like posting on forum anybody can open a draft PR with a proposed solution and explanation of what's being solved in GitHub 

Dears,
I have recently posted several issues wrt. OPi0+. GPIO (sysfs), armbian-config (bug confirmed by Igor), WiFi AP, GPIO event handling. Except for GPIO, where high activity is going on, I cannot find anything in "GitHub-issues" about the other problems, I have raised. I therefore would like to know, what would be the right place to rise issues? Here in the forum, or in GitHub?
I mean "issues", not "how tos"

now I merged it to releases 🙂

congratulations!

This functionality existed in our pervious stable kernel 5.10.y and should absolutely continue to be supported. It was a breaking change that should not have happened.
 
lane

Hi Folks
 
I am selling my KOBOL64. It is completely brand new. It has never been switched on, when I received it we had just bought a new house and we were busy with the move. I took it out of the box once to take a look and then got stuck into a renovation project at home and ended up forgetting about the NAS until recently.  My house renovations are not finished and I will not have time to tinker with this for many more months so am selling it. I have the extra SSD bay holder purchased?
 
I am located in Australia and can send anywhere.  
 
MORAL of the story, think hard before renovating your house and then consciously decide not to renovate. 
 
 

@gounthar - if you are looking for arm laptops for use with linux, then you should also consider arm chromebooks. best supported are the mediatek mt8183 based kukui and the snapdragon 7c based trogdor devices - nearly everything is working for them with mainline with only very few to no patches required and they are available used or new really cheap (by a factor lower than any other arm laptop option). both have 8 cores, 4gb (some 8gb) ram and 64+/-gb fast emmc. performance wise they are above odroid n2 level. if you can get (not easy due to supply issues) or build (there are a few docs with instructions online) a suzyqable you even get features like a serial console on a laptop which you usually never get. the build quality and reliability of such chromebooks is usually way higher as for average sbc's and with mainline on the above mentioned series you get: panfrost gpu support, working suspend/resume and power saving modes, working wifi, bt, sound and for most of them even camera(s). maybe have a look at cadmium: https://github.com/Maccraft123/Cadmium or my linux on arm chromebooks page: https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks to get started.
 
the best supported other arm laptop is the a few years old lenovo c630 (not the chromebook version) and it is still missing some basic functionality here and there (sleep/suspend etc.). another option - the pinebook pro - is in a different performance and quality league (sadly downwards).
 
best wishes - hexdump

Nope, I do like Debian, but the laptop I got is very specific (Asus) and it looks like the only supported distros are Arch based.
 
Thanks a lot @hexdumpfor this detailed workaround.
I could go the arm laptop/chromebook route, of course. Most of my use will be web surfing and using my x86 Linux laptop through vnc, so I don't need a powerful laptop.
I tried to buy the PineBook Pro a long time ago, at the very worst moment (just when it disappeared from the store in fact). It never came back.

Sounds like a great use of available features.

Merged three posts. You may want to use spoiler ( ) for longer posts to reduce overall topic length.

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?

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?
 
 

@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.
 

After this is merged, we are going to produce images by default when making a pull request labelled with "desktop". A combination of those desktop images are created:
 
matrix: board: [uefi-x86,rpi4b] release: [focal,bullseye,jammy] desktop: [xfce,gnome,mate,cinnamon]  
... it takes around one hour after PR is approved.
 
Artefact download page looks like this:

Hi all,
I got my helios4 sometimes in 2019 and it was one of the best purchases I ever made. It has served and was solid as a rock. Unfortunately all that ended couple of days ago when I noticed the Helios was not powering up properly, think it was the power supply not connected well (because I just recently changed the location) I removed and fitted the PSU a couple of times, I could see the led light come on but still it would not boot properly.
 
By the time I found out what the real problem is things had gone worse, the reason for the incomplete boot was the SD card has been removed. Unfortunately, it seems my constant removing and refitting the PSU to the board most have done some damage because right now the board has refused to come on.
 
I used a multi-meter to check the reading from the PSU and it is constantly at 12.5v but the molex for the sata is are all completely 0v. Same for the fan ground and 12v pin for the Fan male header. Curious enough, the control and sense pin out for the FAN reads about 4v. This is pretty much the only thing I was able to get reading from. Rest of the board just seem dead, no LED, no indication whatsoever that PSU is connected to the board.
 
I am aware that the PSU was one of the weak side of the Helios4, But like I said, the pin out of the PSU reads 12.5v so I am thinking maybe this is an issue with a blown mosfet? I am a total newb when it comes to computer hardware. There are no device out there (arm based and DIY) That comes close to the Helios so I am pretty much stuck. Any advise on how to troubleshoot this would be very much welcome.

Congratulations. Armbian is adedd to the distrowatch list. 
https://distrowatch.com/table.php?distribution=armbian
Already 2 years ago I submitted you to the list but then they refused to listen to me, despite the fact that RaspbianOS was placed a long time ago.
I think that this will further influence the popularity of the venture.