Igor

I think I tried that.
 
 
Or copy config if not exists:
 
[[ ! -f "${homedir}"/.config/htop/htoprc ]] && cp /etc/skel/.config/htop/htoprc "${homedir}"/.config/htop/htoprc
File origin for PR:
https://github.com/armbian/build/blob/master/packages/bsp/common/etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx

We don't have enough resources to maintain more branches very long - make a build from master.

Its fixing bugs for you or fixing broken RC car for my kid. 

OK will do - thank you

Since when its Armbian problem if your computer is infected by malware?

Standard way, with additional parameter EXPERT=yes which is not documented by purpose. Things can fail and nobody will react.
https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
 
https://github.com/armbian/build/commit/cf45b970c1101625f6522208d62d6d3f8e6a343d
 
Just build the image. 
 
 

Hmm, that does not sound very promising at all :-(
 
 
 
I gave a  lot back to the Open Source community and their developers. Wrong target here:-) But I know what you mean.
 
Cheers,
 
Ford
 
 

I think it should.
 

Those hotfixes are triggered manually so there is no relation on github. Regular way:
https://docs.armbian.com/Process_Release-Model/

We are developing support for this board from scratch, based on modern kernel. There are just a little work here and there, by different people, some things are the same as on older, some not. It costs a lot of time at this stage. Perhaps we should provide images with stock closed loader and private kernel? That works at least the same as stock and now certainly works better then mainline based images ... but its a dead end support path. I tried to boot that kernel with modern u-boot ... which would be some good mid path, but I already lost two afternoons on that and got nowhere. Which could be used better. Perhaps spending with family
 
Our images are not done, which is why we label them WIP. They work or not. If they don't, we can't afford to left our jobs and/or spent afternoons to make them work. Which we usually do, when support is matured and we often (due too lots of investment into knowing how things works) knows why things bread down. And repair broken images.

Kernel config is one for all. In our world one per kernel family. With default config https://github.com/armbian/build/blob/master/config/kernel/linux-imx6-current.config it should work fine, right? But it's a bit too much for your use case ... I understand that. That diff you keep for yourself. We don't want to shrink down our default config.

We should also probably use layerfs ... but I just noticed AUFS is back in action https://github.com/sfjro/aufs5-linux/commits?author=sfjro

Thanks Nico - that worked! Much appreciated.
For the record, I installed as per your instruction, re-set consoleblank back to 0 (as this was making the console blank even when trying to actually use it!), rebooted, configured the timers via the GUI and all is well.
 
thanks again!
 
 

Armbian is all about "Kobol issue", kernel, low level support. I am not saying or judging how big role we are playing in this particular case, but we are supporting them, they are supporting us. In this "Kobol" issue. And Kobol do support us in - I believe - best possible way they can.

Armbian is not yet another Linux distribution like Debian, like Ubuntu, like Arch, like Manjaro and many small ones ... which are just using low level support and distribute their distribution. We provide Debian / Ubuntu userland, slightly modified, improved and fixed.
 
But core of the project is build engine. A lightweight "Yocto" / "buildroot" which gives you opportunity to build your own Linux distro. We are focused to ARM single board computers, so you can only build it for those. For hardware that is supported, but its relatively easy to add another supported hardware - if supported in u-boot / kernel. It's just a matter of few config files. But the problem is maintenance - if you don't have it, things surely starts to break down. We tag boards with "supported", where we pay attention and maintain them vs. others, mainly community, random person or vendor only supported builds. They are a part of Armbian Linux as unofficial builds. 
 

Things are mixed very much but I rather back down. I have enough of other troubles. I only answer on "how to help". We are asking for help - money is not the biggest issue since we are actually having our own jobs and are the core sponsor, but working on common goals. I would like to help with this interesting issue, if you help us with the boring ones and help us to hire help to relieve overloaded and overstressed volunteers or to tell you to just give us a break and stop asking for more ... That's my primary motive of speaking up.
 

It is a drop-in replacement for one server only. Same internet access, same power consumption. Network access upgrade is also planned, but not an urgent issue. We have several servers around, mainly donated, bare metal and virtualized, but so far nobody provided us better alternative to have dedicated machinery to build lets say 500 images really really fast. And once again and again when things fails ... Thredripper is still the cheapest way. You are welcome to become engaged in https://armbian.atlassian.net/browse/AR-444 We still need to design and maintain our infrastructure and talk with partners in this area. Developing and maintaining this is already a full time position, but currently covered by a few people on a side.
 

It's a sum of unavoidable costs and our work which needs to be done to keep this system running. This is estimated on 50-80 working hours every day. Responding on this is included even I usually would skip sticking my nose into. I can easily blow whole day every day if I react on emails, PMs and few forum posts. Sometimes I actually do ... 
 
 
No hard feelings, but I have life to catch up and many other problems are on the list so can't deal with this problem, even its appealing from the technical perspective. I am actually a bit frustrated that I am unable to help.

First you need to tell us filename of that image so we can verify.
 
Also there is an archive in the bottom of the download pages - checking previous build is also one of the options. This was added on last minute:
https://github.com/armbian/build/commit/ab9faf847affd34cd8c0a1e867e93c2edbb5f8e8

Just make a PR to the master and try not to create special things for this board such as dedicated kernel config or similar. Kernel is shared, u-boot can be per board.
 
If it's done the way that it can't break anything, we accept it. config/board/thisboard configuration must have .CSC suffix that its clear we don't maintain it.
 

Thank you!  Welcome to join. It's a lot to do and we are always short on people.

A build system that gives you superb option to boot your hardware with a specially prepared kernel and its not called Buildroot or Yocto. I would kill for having x86 Armbian when preparing our Threadripper server. Or my desktop machine - both are based on latest hardware which doesn't just work OOB on Ubuntu or Debian based distros, Arch is too reckless on the other hand. Just about every kernel out there sucks and preparing custom build with userland of choice is what we have achieved here. I would also use Armbian on other x86 builds, if this would be simple, since those possibilities and has important tweaks that are ignored in generic distros such as Debian / Ubuntu. 

If anyone is willing to bring x86 build support to the armbian build system and maintain it, it wouldn't be that stupid after all.

Typo: "roperly" power your board

Issue resolved. Rather than trying to subvert armbian-config I ran it after updating the system and and formatted the Samsung EVO 970 drive and flashed the SPI again, checked fstab pointed to the right UUID and rebooted. All is well now.   

Thank you - you save others  I didn't spot this problem ... fixed. I guess I'll need to expand my test rig with a few more boards.

https://github.com/armbian/build/commit/53bc9e481a6be1e76d13df1f3abca599dc305447

We had some troubles with the usual tool, but backup is this:
https://freenode.irclog.whitequark.org/armbian/2021-01-02

Add parameter
 
EXTRAWIFI="no"  

We have it, it works, but we don't provide it for end users yet: https://github.com/armbian/build/blob/desktop/config/distributions/hirsute/name This development branch will be merged to main branch in about 2 weeks, which means one could easily build images without much extra efforts, but don't know when we will switch groovy for hirsute on nightly builds. Its (will be) a matter of adjusting files as such https://github.com/armbian/build/blob/desktop/config/targets-cli-beta.conf Not much work for that, but someone has to pay attention and do it. Can also be done automagically, but then someone would need to script it ...  
 
 
Anything is possible if expenses for R&D are covered. Also if we would do everything users asks on this forum, we would need to work strait for several years and then this idea of yours will get in front for realisation. I agree it is nice to have, but there are many nice to have ideas, some are even critical problems and has to wait for our life to catch up. It's up to you how bad you need this - if you help project with your know-how, resources, cash .... it can be done much faster.
 
Also we never support or dug into distribution upgrades. Too many things, that are outside our domain & control, can go wrong. We have no intention to fix more of Debian or Ubuntu bugs. Our focus is to keep devices as such, usable, alive, supported https://docs.armbian.com/#what-is-armbian and build-able from sources.
 

Running Kodi on Linux is generally troublesome. With legacy kernels is just like with other RK3399 boards:
... but I would recommend you modern kernel. But here Kodi might not yet work OOB. IHMO NAS should do different job in 1st place ...

Google knows something about which would suggests its a generic issues, unrelated to Helios64 or Armbian.
https://www.google.com/search?q=starting+90-second+grace+period&oq=starting+90-second+grace+period

Thank you for swift reply. I figured out source of complication. It was data accidentally copied to sources/families/imx6.conf once I got rid of it everything went with flying colors.
I managed to boot system (!) with kernel v5 (!!) and Armbian loading screen (!!!) all of it is awesome
Right now I'm trying to build kernel for wandboard dl/q with no extra "fat" in it. For now I somehow trimmed USB keyboard support , I guess those TI OMAP platform files were not that useless after all. Strangely armbian-hardware-monitor.log shows all USB drivers load fine.
 
[ 1.692772] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.692797] ehci-pci: EHCI PCI platform driver [ 1.692863] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.692949] usbcore: registered new interface driver usb-storage [ 1.693037] usbcore: registered new interface driver usbserial_generic [ 1.693071] usbserial: USB Serial support registered for generic [ 1.693292] mousedev: PS/2 mouse device common for all mice [ 1.693534] i2c /dev entries driver [ 1.697027] device-mapper: uevent: version 1.0.3 [ 1.697419] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com [ 1.698358] ledtrig-cpu: registered to indicate activity on CPUs [ 1.698927] hid: raw HID events driver (C) Jiri Kosina [ 1.699086] usbcore: registered new interface driver usbhid [ 1.699092] usbhid: USB HID core driver
As soon I figure out that kernel is working I'll upload all files to github.
 
  

Thank you for your help, I'll try not to waste your time unless I'm absolutely sure I can't resolve issue myself.

Release planning: January 2nd. Meeting location is IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
 
Open topics / development directions:

- desktop branch merge into the master
- enabling 3D support on desktop(s)
- update u-boot (where possible) to 2020.10 and K5.10.y
- ZSH setting to default or optimise 1st run choosing
- moving blob section (except build packages) to newly created structure inside "desktop" branch (need to discuss best way / adjust framework if needed and set rules!)
- and Jira bugs / features we chose to deal with by then
 
There are reports about some broken images on Rockchip legacy, K5.9.y is EOL so there is an option to squeeze another bugfix update with focus on u-boot / kernel update + image refreshing. Anything that is outside of my test rig - I have no idea about the statue - except well known NIC troubles with Orangepi 3.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @Heisath @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava

Release planning: January 2nd. Meeting location is IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
 
Open topics / development directions:

- desktop branch merge into the master
- enabling 3D support on desktop(s)
- update u-boot (where possible) to 2020.10 and K5.10.y
- ZSH setting to default or optimise 1st run choosing
- moving blob section (except build packages) to newly created structure inside "desktop" branch (need to discuss best way / adjust framework if needed and set rules!)
- and Jira bugs / features we chose to deal with by then
 
There are reports about some broken images on Rockchip legacy, K5.9.y is EOL so there is an option to squeeze another bugfix update with focus on u-boot / kernel update + image refreshing. Anything that is outside of my test rig - I have no idea about the statue - except well known NIC troubles with Orangepi 3.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @Heisath @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava