Igor

Link fixed. We only have images here https://github.com/armbian/build/releases for now. When we get more feedback, we'll placed them to expected location and CDN.

Thanks for the fast reaction...as I said...I am an armbian-beginner and in the process to learn what you provide..and that is already great stuff.
 
In the meantime I learned that armbian-config has the option to install a kernel source...tried that...and BINGO ! Now we have the needed source-files. RTLA install procedure is than:
 
cd /usr/src/linux-source-5.19.14-rockchip64/tools/tracing/rtla
apt install python3-docutils -y
apt install pkg-config -y
apt install git -y
git clone git://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git
cd libtraceevent/
make
sudo make install
cd ..
git clone git://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git
cd libtracefs/
make
sudo make install
cd ..
make
sudo make install
 
great stuff.. now I can compare osnoise effects of different kernel configs and software setups on arm as I can already on x86...which is exptremely helpful to observe tickless mode and otimize for PCM-audio-playback in highest quality...

Armbian is probably the only Linux distribution that actually test upgrades on many devices we provide download for https://github.com/armbian/build/actions/workflows/smoke-tests.yml But we can't afford to have them all in the test rig, especially not laptops. This only cover upgrades.
 
Manually testing all images? Some yes, all - impossible.
 
Probably this will fix it https://github.com/armbian/build/pull/4397 I don't have a device. All I can do is to run another build with this fix and hope it works.
 
 
I understand your frustration. I really do. But see other side.

You were fooled by vendor for buying this crap. We are trying the best to keep it operational. I can also use this opportunity to inform you that Pine64 is one of those that never donated a cent to this project even their poor software support is the reasons why our update broke. 
 
In case you want better quality, volunteer directly:
https://docs.armbian.com/Board_Maintainers_Procedures_and_Guidelines/
https://forum.armbian.com/staffapplications/application/7-test-automation-engineer/
or fund few people so they will take care of this for all of us.
https://docs.armbian.com/User-Guide_FAQ/#development-time

Apologies for the short downtime about an hour ago.
 
Both forums and main website have been relocated to new hardware. You may notice a significant performance improvement, especially in forums.
 
Enjoy

Perhaps https://vscodium.com/ or https://www.geany.org/ ?

I can confirm that the latest Armbian kernel (6.0.6) boots just fine on rockpi 4a (and 6.0.5 did not).

4.19 legacy makes sense if you want to use functionalities for which there is no support in mainline for the rk3568 SoC yet. But this also requires special userspace software that can use these proprietary interfaces.

5.19 doesn't make much sense, because it requires backporting everything that has already landed in 6.1.0-rc. Especially if you use the tobetter tree to pull from because it is based on very early WIP patches that contain bugs that are already fixed in mainline.

As far as I know, 6.1.0-rc contains all mainline code available for the rk3568 SoC. So there is currently nothing relevant to add. For the ODROID M1 support only the source for the rk3568-odroid-m1.dts is missing. This can be easily added by cherrypicking the relevant commits from the maintainer tree. Or you build from linux-next and have the full preview on 6.2.0-rc1. But from the point of view of the ODROID M1, this only adds the rk3568-odroid-m1.dts out-of-the-box.
 
IMHO you should start with 6.1.0-rc for the ODROID M1 and mainline kernel support. Everything else is unnecessary work that does not provide any advantages over 6.1.0-rc. Of course, all distribution dependent additions can still be applied, but from the point of view of the ODROID M1 they are not absolutely necessary.

Fixed upgrade component is coming up ASAP. Just doing last tests.

Fixed upgrade component is coming up ASAP. Just doing last tests.

Hehe 😅
 
Ok, everythings works !
 
For people with same problem than mine, this is what i did
 
Install u-boot Debian package,  one that you knows works (download via: https://imola.armbian.com/apt/pool/main/l/linux-u-boot-nanopim4v2-current/) dpkg -i linux-u-boot-current-nanopim4v2_xxxxxx_arm64.deb Launch armbian-config tool  sudo armbian-config System -> Install -> Install/update the bootloader SD/eMMC The SD is now bootable Thx again to Igor for his help  🤜🤛
 

It should work in both cases. I am running it from NVME. But with eMMC boot. SPI boot loader is broken.

https://www.armbian.com/rock-5b/

I don't understand, what is there to explain? See the error, make corrections (makes a patch) and check in the work.

I see two ways.
1) You can turn the user's @hoov manual into a debian/rule file.
Mount the already patched kernel into the build environment and assemble the kernel module.
Take my branch. https://github.com/The-going/armbian-build/tree/chroot_build_pkg
Use the parameter mount_linux_src=yes
https://github.com/The-going/armbian-build/blob/1e9a7a1b24e5d5aead730f58ad910124782b5576/lib/chroot-buildpackages.sh#L313
 
Here I help the user to build a debian package in a chroot environment, bypassing many unnecessary steps.
 
2) I wanted to try to rework the debian rules directly from the original ubuntu repository:
/gituser/ubuntu-kernel> mkdir jammy /gituser/ubuntu-kernel> cd jammy/ /gituser/ubuntu-kernel/jammy> git init /gituser/ubuntu-kernel/jammy> git remote add origin git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy /gituser/ubuntu-kernel/jammy> git fetch /gituser/ubuntu-kernel/jammy> git checkout -b hwe-5.19-next origin/hwe-5.19-next I'll take that as a basis. Everything is available here. We only need to choose what we will take.

Workaround:
 
armbian-config -> system -> alternative kernel , pick previous, freeze, wait  

Hey. Yeah I noticed this problem already, see https://github.com/armbian/build/pull/4261
Unfortunately I did not get around to fix it last weekend, working on it right now
 
As for future proofing, unless someone has the energy to get the patches mainlined it will break from time to time...
 
 

I spent a day on this. Made some progress and some regression  I had a working nand-sata-install, could transfer to internal eMMC and boot from it but with latest images its not working anymore ... after going closer to @Cornelius patch.
 
u-boot button detection to switch booting from SD card is very unstable. It often hangs, so its some work to be done here ... Test image and a build PR: https://github.com/armbian/build/pull/4247 

AFAIK this feature is no enabled by default. It must work pretty much this way: https://www.lisenet.com/2013/set-up-wake-on-lan-wol-on-a-debian-wheezy-server/
 
 
This is known problem and we are developing things toward solution. We produce all different Docker images for that reason https://github.com/armbian/build/pkgs/container/build but what is missing is building header package under each one and store them into different repositories.
 
 
Fix for that was just merged https://github.com/armbian/build/pull/4263 and updates are pushing out ASAP.

Either that or the base installation should not have the haveged package installed anymore, unless there are special cases where the kernel version is less than 5.6.

I spent a day on this. Made some progress and some regression  I had a working nand-sata-install, could transfer to internal eMMC and boot from it but with latest images its not working anymore ... after going closer to @Cornelius patch.
 
u-boot button detection to switch booting from SD card is very unstable. It often hangs, so its some work to be done here ... Test image and a build PR: https://github.com/armbian/build/pull/4247 

Images were updated and installer should be ready to install it to windows system. Further testing and code review is needed before we can declare this install way as completely safe. 

Testing on and co-existence of AMD graphics drivers would be nice to check. I don't have any such hardware in the lab. X86 is good, both would be awesome!

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... 

We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build".
 

 
- improved support in GRUB (armbian wallpaper) & HiDPI GRUB support
- all preinstalled applications are normal apt packages
- current 5.15.y kernel, Jammy userland (5.19.y has some strange issues)
- snapd is not installed (user can install it)
- HiDPI support (automated adjustments on big screen resolutions)
- NVIDIA graphics acceleration with proprietary driver (x86 only)
- Intel graphics acceleration also works out of the box
- preinstalled Google Chrome (x86 only)
- preinstalled Microsoft Visual Studio Code (x86 only)
- ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms)
- face unlock works perfectly fine on this laptop
- installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it).
 
I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome.
 
Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy.
 
https://www.armbian.com/uefi-x86/
https://www.armbian.com/uefi-arm64/
 
Please report where it works and how (well)!

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... 

We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build".
 

 
- improved support in GRUB (armbian wallpaper) & HiDPI GRUB support
- all preinstalled applications are normal apt packages
- current 5.15.y kernel, Jammy userland (5.19.y has some strange issues)
- snapd is not installed (user can install it)
- HiDPI support (automated adjustments on big screen resolutions)
- NVIDIA graphics acceleration with proprietary driver (x86 only)
- Intel graphics acceleration also works out of the box
- preinstalled Google Chrome (x86 only)
- preinstalled Microsoft Visual Studio Code (x86 only)
- ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms)
- face unlock works perfectly fine on this laptop
- installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it).
 
I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome.
 
Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy.
 
https://www.armbian.com/uefi-x86/
https://www.armbian.com/uefi-arm64/
 
Please report where it works and how (well)!

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... 

We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build".
 

 
- improved support in GRUB (armbian wallpaper) & HiDPI GRUB support
- all preinstalled applications are normal apt packages
- current 5.15.y kernel, Jammy userland (5.19.y has some strange issues)
- snapd is not installed (user can install it)
- HiDPI support (automated adjustments on big screen resolutions)
- NVIDIA graphics acceleration with proprietary driver (x86 only)
- Intel graphics acceleration also works out of the box
- preinstalled Google Chrome (x86 only)
- preinstalled Microsoft Visual Studio Code (x86 only)
- ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms)
- face unlock works perfectly fine on this laptop
- installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it).
 
I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome.
 
Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy.
 
https://www.armbian.com/uefi-x86/
https://www.armbian.com/uefi-arm64/
 
Please report where it works and how (well)!

Thanks Igor - I will switch to nightlies.
(The PJR account is a temporary alter-ego!)