Armbian UEFI (arm64 and x86)

[Igor]

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)!

[Igor]

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!

[balbes150]

jetson Nano does not require installation, I tested it in EFI\Grub mode - everything works (with EFI fixes to build the image), in the near future I plan to send a PR with the transfer of jetson Nano to EFI mode. 

 

also, almost all my supported devices work well in EFI mode, they only lacked the installation mode with EFI, if you finalize the installation, all images can be transferred to one universal image (by drastically reducing the count. image variants collected and posted on the site). 

[balbes150]

I propose to divide the installer into several independent scripts that are optimized by architecture. An attempt to combine very different principles (x86 and ARM) in one nand-sata-install script will require the addition and maintenance of complex analysis algorithms. It's better to simplify it. In the main script, a primary analysis will be performed on which architecture the installation procedure is running, according to the result, one of the necessary scripts is selected (x86-install arm-install, etc.). And these scripts will describe only the necessary procedures for these architectures, taking into account their features. For example, on ARM, in principle, there can be no partitions with Windows, and other differences.

 

https://github.com/armbian/build/pull/4227

[Igor]

On 9/28/2022 at 10:02 AM, balbes150 said:

in the near future I plan to send a PR with the transfer of jetson Nano to EFI mode. 

This means we only need to tackle kernel config ? Are there any patches for Jetson inside media kernel? When Jetson is moved to UEFI image, this means we can completely remove it from the build system, remove board config from Jetson nano? Or we need to have board config with minimal assembly changes but common UEFI kernel? (or I don't understand this right?)

 

On 9/28/2022 at 10:02 AM, balbes150 said:

all images can be transferred to one universal image

As many as possible and not if there will be big compromises. Lets do one (a few) by one, not all at once. Its important we set this direction and not just you and me knows about and agree upon.

 

6 hours ago, balbes150 said:

I propose to divide the installer into several independent scripts that are optimized by architecture.

Architecture should, in theory, not play a role here. Its more like a question of supporting different methods. For example - eMMC install works on x86 and arm64 the same, UEFI as well ... (re)generation or copying of boot scripts, that's another topic and is more family specific. One idea is to move all boot handling into platform install https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L15 but perhaps naming doesn't follow if we push UEFI under that. That would additionally help lowering complexity of the script.

 

6 hours ago, balbes150 said:

It's better to simplify it.

That's the idea / wish. First stage was adding UEFI that we have something that works on this platform, a start, then holistic approach on - what to do to make it simple. I already went further with cleaning out not needed code (Allwinner A10/A20 nand install we really don't need anymore), but that is coming in a separate commit too.

[balbes150]

17 часов назад, Igor сказал:

This means we only need to tackle kernel config ?

What kind of core are we talking about ?

 

17 часов назад, Igor сказал:

When Jetson is moved to UEFI image

is it about the general arm-efi image?

 

17 часов назад, Igor сказал:

Lets do one (a few) by one, not all at once

I do not propose to transfer everything at once, the process can go slowly, with detailed testing. I have outlined the prospects only for my models

 

17 часов назад, Igor сказал:

Architecture should, in theory, not play a role here.

it also plays a very significant role there is no DTB on x86, there is no u-boot, but there are specifics of installing several systems together (Windows + several Linux, etc.), this significantly changes the logic of the installation process and mixing their analysis into one script creates unnecessary problems that are easily solved when splitting. Even the logic of GRUB is different on x86 and ARM. By the way, for proper operation (image assembly) with EFI support for ARM, the grub extension is available.sh is not suitable, I am using a modified version.

 

17 часов назад, Igor сказал:

That's the idea / wish.

I suggest going smoothly, slowly, debugging and testing individual steps. Therefore, the best option is to leave the existing nand-sata-install installation script and create a separate version of armbian-install (with separate installation scripts for different architectures), this will make it much easier to conduct the development process when you do not need to track and test the changes being made on two platforms at once (there may be mutually exclusive fixes). And only after everything is working, it will be possible to smoothly start the process of unification.

[Igor]

47 minutes ago, balbes150 said:

What kind of core are we talking about ?

media. And all those that are going to be merged into generic kernel. I have also spoke about this with @ManoftheSeaas his Espressobin can also be moved there without any issues. To be on the safe side, kernel configs should be merged (media-*, mvebu64-*) to the arm64 generic kernel. If not already. mvebu family is good for another reasons - it covers one board only, which results in little testings needed.

 

47 minutes ago, balbes150 said:

is it about the general arm-efi image?

Yes. I assume it should just boot it? I haven't tried it yet.

 

47 minutes ago, balbes150 said:

it also plays a very significant role there is no DTB on x86, there is no u-boot, but there are specifics of installing several systems together (Windows + several Linux, etc.), this significantly changes the logic of the installation process and mixing their analysis into one script creates unnecessary problems that are easily solved when splitting. Even the logic of GRUB is different on x86 and ARM. By the way, for proper operation (image assembly) with EFI support for ARM, the grub extension is available.sh is not suitable, I am using a modified version.

No DTB is IMO not that critical problem ... main question is how to make this change to be best from maintainership perspective. It has to be straight understandable if you look at the code structure. Currently we have chaos shattered around many locations. Then there is Rpi, which drags its own flash-image way, which is complicated and poorly maintained Debian version of our platform-install. We need to replace this too.

[balbes150]

25 минут назад, Igor сказал:

To be on the safe side, kernel configs should be merged (media-*, mvebu64-*) to the arm64 generic kernel

OK, I'll take a look at it myself and try to combine them and check how it will work.

 

26 минут назад, Igor сказал:

Yes. I assume it should just boot it? I haven't tried it yet.

it lacks u-boot, so by default it will not be able to work on devices with "factory" firmware (where there is no SPI with an already built-in EFI-enabled bootloader) 

Jetson nano has SPI with EFI support, so it's easy to experiment with it, for the vast majority of RK - you need an additional u-boot when writing to the media (earlier I wrote to you how to implement it as a separate bootloader file to overlay on the image)

 

33 минуты назад, Igor сказал:

No DTB is IMO not that critical problem ... main question is how to make this change to be best from maintainership perspective. It has to be straight understandable if you look at the code structure. Currently we have chaos shattered around many locations. Then there is Rpi, which drags its own flash-image way, which is complicated and poorly maintained Debian version of our platform-install. We need to replace this too.

There are several problems related to this. There are several solutions, I checked different ones and came to the conclusion that the optimal solution is to bind the name of the DTB used to u-boot, the current implementations of the EFI startup bundle are able to use this for ARM.

[Igor]

We are getting close to:

cut & merge to it?

[balbes150]

10 минут назад, Igor сказал:

cut & merge to it?

ok

[Marco Schirrmeister]

Hello,

 

I have a question for the Armbian UEFI for x86. On the main page https://www.armbian.com/uefi-x86/ it mentions ZFS 2.1.5 ready. When I compare Bullseye and Jammy repos, I only see 2.1+ packages in the Jammy Armbian repo. The Bullseye repo has 2.0.x packages. I saw differences for other packages as well between the distros/repos. 

 

Based on the "classic" differences between Bullseye and Jammy, I picked for a server typically Debian. If Jammy is more often updated for Armbian, I guess I have to choose Jammy. 

Is there anything you can say about which one is "better" or preferred over the other from the available options?  

[Igor]

On 1/18/2023 at 2:21 PM, Marco Schirrmeister said:

If Jammy is more often updated for Armbian

Armbian components are kernel, boot loader, tweaks - those are all updated the same way, but Jammy has more recent user land packages as its assembled from Ubuntu packages (Canonical stuff should be cleaned out). I am using such assembly on all of my machines and its IMHO best combination. Regarding ZFS - we serve latest (2.1.6) from our repository (from), while with Debian, this applies to get latest.

[Marco Schirrmeister]

Thanks for the information where the packages come from.

 

For now I am testing with Debian and I have the zfs package preferred in the apt preferences to pull in a newer version. Which is right now 2.1.7.

Will see how all goes and I maybe also give the Armbian Jammy repo a try.

 

 

[Igor]

2 hours ago, Marco Schirrmeister said:

Which is right now 2.1.7.

Status on Jammy ZFS packages updates (and many others) is currently unknown as its maintainer is no longer with us, rip Jonathon.

[SoSie]

@Igor have a noob question for the new year of rabbit (we have had a parade previous year😞 does this distro can arm64 cross compile (I am tired to compile on bananapi m5 and now the debian multimedia maintainer tries to help the rabbit - who made vapoursynth working (unfortunately with no sound) for arm to be able to play any video) - but has no arm device under the hand?

Edited January 21, 2023 by SoSie

[Igor]

8 minutes ago, SoSie said:

does this distro can arm64 cross compile

Yes, we even want to provide x86 Armbian ISO image + preinstalled all what is needed even our build script takes care about environment and install what is needed. 

TL;DR; Most of people, our CI, are cross compiling as its a lot faster due to lack of serious arm64 hardware. 

[SoSie]

WOAW THIS IS A AWESONE CAROT @igor !, I inform the owner of the deb-multimedia of this! If we can have an iso of it to feed ventoy that would very nice for x86/arm64  developers

I confirm before having serious arm64 hardware, let's start with sdcard failures setting after a while system ro! Now I understand why flash..

 

EDIT:

Humm I did not realized it was I think here; https://www.armbian.com/uefi-x86/ . I don't know if ventoy can boot on .img.xz, if not i will unpack to try on .img
GREAT WORK THANXX A LOT!
 

REPORT:

@igor, the Armbian_22.11.1_Uefi-x86_jammy_current_5.15.80_cinnamon_desktop.img boots with ventoy but drops the user at initramfs stage (busybox) . 
We can thus don't use armbian-x86 as live distrib maybe the .iso I don't have works.

Edited January 21, 2023 by SoSie

[SoSie]

Works  fine when booting on 16go USB key 😃

[zetabar]

it works fine with myb asus eeepcs but i have some trouble to set properly the cpu Fan. i would open a new post but it seems i need to wait to be aèpproved by an admin.

how i can get this approval?

thanks

 

[Werner]

3 hours ago, zetabar said:

eeepcs

IIRC there is some sort of Asus related package within Debian/Ubuntu repository. Maybe that will deal with your issue.

 

Regarding forums I do not see any further content from you. New users are limited in posting for a short period of time. This measure is unfortunately necessary in order to fight spam.

[m][sko]

Some UEFI is able to start only signed GRUB/KERNEL

Are there any support this this?

I found that for that purpose suse has some signed shim 

[targa]

I second @SoSie. Being able to keep Armbian on my Ventoy stick which I have always on my keyring... would be perfect. I'll try to figure it out. Can't be too difficult.

 

[Igor]

On 1/30/2023 at 11:09 AM, m][sko said:

Are there any support this this?

Not familiar with.
 

12 minutes ago, targa said:

Being able to keep Armbian on my Ventoy

 

You mean you have tried, but it didn't work? So far, booting from USB key always worked, but am not familiar much how Ventoy is combining distributions. If it doesn't work, we must be missing some small details in this UEFI structure or Ventoy is too rigid.

I have recently found a bug which could affect UEFI booting, but this is related to the install part.
https://github.com/armbian/build/pull/4758/files

 

[targa]

Thanks for answering, need to do some more investigations, I have the feeling I did something wrong on my side.

[targa]

Sorry, I had apparently a download problem and that on both the text and the GUI variant simultaneously. I only noticed when I tried to flash it with etcher, which didn't like the xz file. Now it boot natively and from Ventoy! Perfect.

[targa]

I have some things to report though:

After fresh installation of the text variant using btrfs /swapfile was marked "Copy-On-Write", setting the attribute alone didn't help, so I needed to clean and re-init the swapfile:

swapoff -a
truncate -s 0 /swapfile
chattr +C /swapfile
fallocate -l 512M /swapfile
mkswap -U clear /swapfile
mkswap /swapfile
swapon /swapfile

Then the kernel log is flooded with messages of evbug, a module that apparently isn't usually used for general purpose.

in /etc/fstab the entry of the EFI partition lacked the actual UUID value, it only said UUID=   vfat ....


Then I saw this error, described in here, probably nothing you can do about it, seems Wifi-driver related:
https://lore.kernel.org/netdev/87bkxn4kpf.fsf@toke.dk/T/


Will install Cinnamon now ;)
 

[trapexit]

What's the likelihood of getting an image that will boot on a Intel Atom Z3735D? One of those 64bit CPUs with a 32bit UEFI setup.

[DeterminedOpier]

Hi Team.

 

i saw this seems to be a project that you guys care about, so am posting my results. My questions from the past two months have gone unanswered, so I don't know if you guys have finally been maxed out or what. I have been an Armbian enthusiast since before it was fashionable, so I understand how thankless this thing can be.

 

I am attempting to install this on an intel Pentium N3540.  The pastebin is here: http://paste.armbian.com/opuhipapep

 

I did the performance test with armbian monitor and it never got over 38c.

 

With both the rolling download from the amd64 page and Igor's link above, everything worked fine until I attempted to install it only the computer's drive.  When I did so, it all worked great, but on reboot I got a single letter, J. That's it.

 

I can still boot into the SD card, but repeated attempts at transferring to the drive didn't work.

 

[DeterminedOpier]

In hopes of avoiding the obvious, I have tried this on two known good SD cards, and an EMMC with a USB reader.  All installed perfectly, booted into the desktop after setup, and ended with J. 

[DeterminedOpier]

Linux Mint installed first time no problem.