Igor

@Igor I created https://github.com/armbian/build/pull/2579
but please ignore the old part about the configuration.sh from 2019 - its only the 2021-part about the phy-mode patch

This is going to be fixed hopefully before next major release https://github.com/armbian/build/issues/2398
 

We have notice this problem but it seems to be related to some Debian library. There are so many problems and so little time ...

@ballerburg9005 I just wanted to add a few of my own thoughts to this thread.  Overall I can see both sides to the above discussion.  There are valid points made by everyone commenting.  While we all sometimes need to have 'grand visions' of the future we would like to work towards, we also have to deal with the reality of where we currently are.  I often think of a saying "crawl, walk, run".  While we all want to be running to the finish line of an Olympic race, we all start by crawling first.  As that relates to armbian and more specifically armbian on TV boxes, we are at the crawling stage.  There is a lot of work to be done to just get us walking.  That doesn't mean that crawling and walking in themselves aren't valid and productive stages (they are and you can use a lot of different TV boxes today to do a lot of productive stuff).
There is a lot of work to be done today to improve our crawling.  We need volunteers (like you) to pick up that work if we ever hope to get further along our path.  We need to build a community one volunteer at a time.  While visions are important, if we don't have people willing to do work today then we will never more forward.
If you hang around armbian for any extended period of time, you will learn that the single thing that most bothers the core maintainers of the project are people having grand visions or even small visions of what should be done but who don't contribute any time to help and expect others to do the work for them.
Whether intentional or not, that is how your post came across to Igor and Balbes and they reacted as they normally do to such posts.
If you want to run to the finish line with your vision, you need to start by crawling.  Spend time on these forums following the issues to build your knowledge.  Help support new users to allow others with the technical knowledge time to work on development and progress on our shared goals.  This all doesn't happen overnight.
I welcome your contributions to the efforts here, but starting off by getting into a disagreement with two of the core maintainers isn't likely the best way to have started.  Overtime you will realize we all share a lot of the same goals and can work together even through we have different personalities and sometimes have to overcome language/cultural differences.

Yeah, that's it. IMO something is wrong with / around LCD driver. I suspect this - Pine only sells Pinephone, which is the very similar hw, just in different form factor and by upstreaming LCD on Pinephone they break support for Pinebook somehow ... Since we already lost several afternoons trying to fix this it is unlikely to repeat that anytime soon. Not possible  

I'll take a closer look into that : )

https://twitter.com/nixcraft/status/1351224938980667393

FYI. Merge requests with labels: "beta" or "need testings" are automatically included in next nightly builds.

It looks like sufficient support for defaulting ZSH is not going to happen  But it will remain as a second choice ... lets repeat this question year later.

Speaking on armbian-config ... @tparys started to help on enhancements, I do what I can ... still more helping hand is needed. It's a long term job. Any idea how to get more movement there? Yes, its a wonderful tool, but require constant love. Like other parts of the project.

It looks like sufficient support for defaulting ZSH is not going to happen  But it will remain as a second choice ... lets repeat this question year later.

Speaking on armbian-config ... @tparys started to help on enhancements, I do what I can ... still more helping hand is needed. It's a long term job. Any idea how to get more movement there? Yes, its a wonderful tool, but require constant love. Like other parts of the project.

Great news! Thank you for trying. I will update images ASAP.

Banana PI. A20. Initially this topic was posted in the appropriate forum.
 
The question was: why do I need to freeze it from technical POV.
I do understand your team have limitations on support. The device I'm going to play with is mostly used for testing purposes, so if I completely fail with upgrade, I will do a clean install.
And thanks for the great job.
 
Do you mean do-release-upgrade or manual source list change?
I see there is some way to enable the 3rd party update along with the system upgrade (https://ubuntu.com/blog/how-to-upgrade-from-ubuntu-18-04-lts-to-20-04-lts-today , see Advanced options & third-party software).
Maybe I could try this and enable armbian repositories.

@Igorstrange - got near the same problem this evening with a nanoPi K1 Plus
(after updating to pihole FTL 5.5.1 and reboot  = https://pi-hole.net/2021/01/19/pi-hole-ftl-v5-5-released-update-today#page-content )
The NPI K1 Plus is searching a shorter UUID than shown as blkid
 
The Boot-Error does show
boot-err    971c3757-23ee-42

 
 
So I did put the card of the NPI K1 Plus in my Neo2 (IP24) and monuted it on /mnt/sdb1
 
But with blkid and in /etc/fstab and /boot/armbianEnv.txt I ons could find the long UUID:
boot-err 971c3757-23ee-42 blkid 971c3757-23ee-4281-b0cb-989e7255e3d9 fstab 971c3757-23ee-4281-b0cb-989e7255e3d9 armbianEnv 971c3757-23ee-4281-b0cb-989e7255e3d9  
 
Everthing seems OK - so because the Neo2 had the problem in /etc/fstab I deleted (the correct one) and replaced it with (in my sight) the same text and did put back the card in the NPI K1 Plus and it worked again ?? just fine  Dont know what happend - while booting- the 4 times before I removed the card...

This is the second time this month with a different device...
 
System diagnosis information has been uploaded to http://ix.io/2MCd

Suspecting media failure / image making trouble. I'll try to reproduce.

If we rule out deliberate cheating by Amlogic (to show bigger numbers and numbers are what people are buying), then yes, others are nothing better. But what you are not understanding at all is the difference between a complete trash (Amlogic/Rockchip/Allwinner TV box) and single board computer, a board that comes at least with a documentation and a team of engineers to provide some support. Also if there is not enough additional people / community, that will dig "read" the hardware, you can simply forget about. Cost of support is everything and bringing some garbage hardware from zero to the average Joe level is insane if there is not heavily community backing. There is a lot more hardware out there then people with interest and knowledge to do something about. A lot more.
 

According to your posts you have no intention nor knowledge to work on. Perhaps I am wrong? Armbian maintainers have common stand to not support any hardware on the extreme end since frustration of not being able to get anywhere is too high and it also cost 10 - 50x more. Remember that dealing with is 99% our private money that goes into your pleasure. And ain't small. I lost on average around 10h every day working on this project. I just lost 1h trying to explain something. And I am not alone. 

If average Joe wants bringing Linux on shit TV box, he can forget about seeking our free help, but otherwise, for normal hardware that comes with proper documentation and optional some vendor support we have "Board bring up section", so that posts as such are not scattered around forum. Its 2021. Market is saturated with all sorts of cheap hardware and all of them are seeking free community support without which they are just a paperweight. Currently its near to impossible to get eyes on something new. We barely can maintain / keep this hw usable. Each upstream upgrade kills some of the board or its primary function. That's the reality average Linux fan forgets and live his dream ... Vendor proprietary sw doesn't break since it never receives any updates. That is the key of "success", while maintaining mainline based sw is something different. More expensive and receive no support. Not from you, not from vendor. You want that, while vendor would like rather to push you their software where he might have some advantage from competition stored in closed library. Under their control. Its not about open / free so much, I agree on that point with you, but about the level of control.
 
 
You mean the most expensive part? Without any financial backing for developers / maintainers, free of charge. You already have a lot of that, you just don't notice and care and want more and better. That's the world of average Joe.

Documentation for average Joe: https://docs.armbian.com/ Images ready to run without any difficulties - burn and run, images are even tested for you https://www.armbian.com/download/?device_support=Supported so average "customer" doesn't waste their precious time. Then community supported tutorials for whatever you need: https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/ or 3rd party https://www.digitalocean.com/community/tutorials
 

Starting at average Joe level - contribution to Linux kernel directly require more rules which are hard sticking to for a beginner. You can start at more user friendly level: https://www.armbian.com/get-involved/
 

https://www.armbian.com/donate
Start covering what you have - you only cover around 0.5% of our running costs, 0.0% for TV boxes. From paperweight to running Linux. TV box is not a PC so it can't run as a PC. Its closer to embedded experiences or lets say it is something in between. Its cheapest possible form of single board computer, of barebone. Also we don't have resources of a desktop PC and we don't have (yet) proper foss drivers to support hardware function, we don't have acceleration within web browser, ... Each ARM family is like another architecture. Diverse, purpose oriented ARM world is far more complicated than heavily standardised PC world ...

and due to lack of any technical specs, development is not possible. Only more wasteful hacking and reverse engineering. If hardware is not under full control of community, open, it's pointless to invest sw support. Vendor can screw you up at any time. Can disable & enable features, can manipulate numbers ... 
 

BSP kernels from all vendors are already at 4.4 - 4.9 but they are full of non-standard solutions, shitty cheaply made solutions, closed drivers, etc. Usually only vendor engineers maintain that private kernel which they "support". This hasn't changed.
 

Marketing BS.
 
But I heard they are supporting some Foss development, porting drivers to mainline, but could also be just rummers. And kernel is just one thing. The easy part. You have to load this kernel somehow ... and here, things are certainly not (yet) foss. Not at Amlogic, not with Rpi ...
 
Also please do some forum search - we have been through those questions many times.

I have begun to make some changes to the TV Box 'Club' area.
 
The overall goal is to provide more useful information to users and reduce the support workload of answering the same questions over and over again.
 
To that end there is now a FAQ forum on the menu.  While it is currently empty and just a place holder it should provide a centralized location for TV Box information over time.
 
The second new addition is the forum titled 'TV Boxes running Armbian'.  The idea here is to provide a maintained list of current information with links to the details for boxes reported by the community to be successfully running armbian.
 
Both of the two above forums will likely be strictly moderated to keep the information concise and on topic.  I don't want these to become mega threads (like some of the TV box threads tend to be).  Content that gets posted here that belongs elsewhere will be moved.
 
I'm still trying to figure out how the rest of the area should be organized.  There needs to be a place for newbies to ask questions and it would be nice if there was a place for developers to share information.  The problem is that the current mega threads for the Rockchip CSC builds do that in a single thread, vs using one or more forums for that.  Also I wonder if there should be different forums by CPU family (AML,RK,AW?) by developer build (Balbes vs Jock's CSC builds?).  Any suggestions on how others think things should be organized?
 
  

The last looks good!
 

Media info:
https://arstechnica.com/gadgets/2020/12/openzfs-2-0-release-unifies-linux-bsd-and-adds-tons-of-new-features/
 
Remarks: 32bit support is broken in Debian Stretch, no upgrade there. Also this upgrade is needed to bump kernel to 5.10.y

ZFS was just upgraded to v2.0.1 https://armbian.atlassian.net/browse/AR-614 which is a preparation for pushing a kernel on and above 5.10.y. Upgrade was tested on Armbian Buster/Bullseye/Focal/Hirsute. My test ZPOOL was always loaded without any troubles.

We only support upgrade troubles - for ZFS functional problems, please check / file a bug report here https://github.com/openzfs/zfs/issues
 

Media info:
https://arstechnica.com/gadgets/2020/12/openzfs-2-0-release-unifies-linux-bsd-and-adds-tons-of-new-features/
 
Remarks: 32bit support is broken in Debian Stretch, no upgrade there. Also this upgrade is needed to bump kernel to 5.10.y

ZFS was just upgraded to v2.0.1 https://armbian.atlassian.net/browse/AR-614 which is a preparation for pushing a kernel on and above 5.10.y. Upgrade was tested on Armbian Buster/Bullseye/Focal/Hirsute. My test ZPOOL was always loaded without any troubles.

We only support upgrade troubles - for ZFS functional problems, please check / file a bug report here https://github.com/openzfs/zfs/issues
 

After checking, /var/log/armbian-hardware-monitor.log 
I detected btrfs did not exist in my build. I went back to lib/configuration.sh and saw btrfs-progs package was not installed if BUILD_MINIMAL = YES. 
 
if [[ "$BUILD_MINIMAL" != "yes"  ]]; then     # Essential packages     PACKAGE_LIST="$PACKAGE_LIST bridge-utils build-essential fbset \         iw wpasupplicant sudo linux-base crda \         wireless-regdb unattended-upgrades \         console-setup unicode-data initramfs-tools \         ca-certificates expect iptables automake html2text \         bison flex libwrap0-dev libssl-dev libnl-3-dev libnl-genl-3-dev keyboard-configuration"     # Non-essential packages     PACKAGE_LIST_ADDITIONAL="$PACKAGE_LIST_ADDITIONAL alsa-utils btrfs-progs dosfstools iotop stress screen \         ntfs-3g vim pciutils evtest pv libfuse2 libdigest-sha-perl \         libproc-processtable-perl aptitude dnsutils f3 haveged hdparm rfkill vlan bash-completion \         hostapd git ethtool unzip ifenslave libpam-systemd iperf3 \         software-properties-common libnss-myhostname f2fs-tools avahi-autoipd iputils-arping qrencode sunxi-tools" fi  
I changed then this from
 
PACKAGE_LIST="bc cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \         ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \         nocache debconf-utils python3-apt"  
to
 
PACKAGE_LIST="bc btrfs-progs cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \         ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \         nocache debconf-utils python3-apt"  
And now it works. I suppose btrfs-progs needs to be added to PACKAGE_LIST (or DEBOOTSTRAP_LIST?) only in the case ROOTFS_TYPE=btrfs and irrespectively of BUILD_MINIMAL.

Media info:
https://arstechnica.com/gadgets/2020/12/openzfs-2-0-release-unifies-linux-bsd-and-adds-tons-of-new-features/
 
Remarks: 32bit support is broken in Debian Stretch, no upgrade there. Also this upgrade is needed to bump kernel to 5.10.y

ZFS was just upgraded to v2.0.1 https://armbian.atlassian.net/browse/AR-614 which is a preparation for pushing a kernel on and above 5.10.y. Upgrade was tested on Armbian Buster/Bullseye/Focal/Hirsute. My test ZPOOL was always loaded without any troubles.

We only support upgrade troubles - for ZFS functional problems, please check / file a bug report here https://github.com/openzfs/zfs/issues