Search the Community

Below image file is bad https://dl.armbian.com/uefi-x86/archive/Armbian_24.2.1_Uefi-x86_jammy_current_6.6.16.img.xz I have downloaded twice from diff locations and after grab menu it goes to BusyBox error (initramfs) `Free initramfs and switch to another root fs:` PS Never reaches the setup cli wizard

Hello @Igor I have installed Armbian 24.2.4 Jammy Kde-neon Kernel: 6.6.21, Size: 1.9GB, Release date: Mar 12, 2024 on a mini pc J4125 Celeron based. What I noticed that is during initial boot, when finds the timezone and asks to accept or select a diff one, i tried 2 times. I selected accept and then took minuted to complete and enter the desktop First time I killed it and second clean i waited.:-) I checked in armbian-config the locales and noticed that ALL options were checked. Which makes sense why I waited so long If this a know bug or needs to be fixed? Just wanted to bring to your attention. Rest work smooth and fast! Tx for your work

I have tried all known possible combos to hide the grub menu on boot but no luck I tested on the /etc/default/grub and /etc/default/grub.d/98-armbian.cfg Is there another config file Im missing that ignores above, especially later? Tried also with custom override config at boot. Any advise is welcome

I have a 32-bit Celeron notebook with 1Gb RAM. It boots only from DVD. Will it work with Armbian? Thanks.

Hi community, Context I build my own custom Arabian image on arm 32bit (prod), and experimenting running the following armbian image configuration on Qemu with console/serial only support for uefi-x86 and uefi-arm64 boards to speed up development/test. Problem I stumble upon something odd: both "uefi-*" boards are configured to only run GRUB in gfxterm mode ONLY. BOARD: uefi-86 -> BOARDFAMILY="uefi-x86". -> UEFI_GRUB_TERMINAL="gfxterm" [0] BOARD: uefi-arm64 -> BOARDFAMILY="uefi-arm64". -> UEFI_GRUB_TERMINAL="gfxterm" [1] [0] https://github.com/armbian/build/blob/2afd8fe9bb8aca33a2a3913e931fc43c43c8e309/config/sources/families/uefi-x86.conf#L11 [1] https://github.com/armbian/build/blob/2afd8fe9bb8aca33a2a3913e931fc43c43c8e309/config/sources/families/uefi-arm64.conf#L10 Image built from these boards should be runnable as CLI image (no gui) or Desktop image (gui). However, when running with qemu -nographic ... these image can't boot up to a working shell and produce an error: "GRUB: gfxterm is not supported" Proposed change I would like to submit a patch to change UEFI_GRUB_TERMINAL to "gfxterm vga_text console serial" to cover a large set of virtualised hardware configurations. 1. Is this something you guys are interested in ? 2. Does this fix need more than the proposed change to achieve the desired objective ? Thanks

Hello, Is anybody able to install and install Armbian bookworm on Proxmox (OVMF uefi, Q35)? I tried multiple times but proxmox doesn't recognize the UEFI partition and I can only boot from the USB... Debian boots fine tho.

Hello, I wanna test Armbian x86 on virtual machine. Is possible to convert its img file to some format (vdi or vmdk) and boot on Virtualbox? I made a attempt but it wont boot.. VBoxManage.exe convertfromraw --format VDI armbian.img ambian.vdi Thx a lot

I was curious if anyone has experience with using Armbian on older x86 server hardware systems. This would be for a home-lab sort of setup. In the past, I fought with Ubuntu Server and found that I missed the Armbian-Config utility that made setup a breeze. (Specifically looking at WIWYNN LYRA-M SV315, INTEL XEON E5-2670 V2 SR1A7 2.5GHZ 10-C0RE) I am planning to run a MariaDB instance for a scientific database. My past test use was using Armbian on an 8 GB Raspberry pi 4B, with MariaDB, and it worked very well, until the SD card failed. Any thoughts or points of caution before attempting this would be appreciated. I have generally had a very positive experience with Armbian so far.

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

hello i am new user of armbian and i really like it. so i am experimenting with it a little. yesterday i successfully installed armbian on one of my old laptops in the lab (Armbian Bullseye with XFCE desktop with kernel 5.15.y released on feb 27, 2023), so currently it boots from internal hard drive. today i wanted to try another image, so i wanted to do the same thing: 1. boot from USB key 2. download the new image on USB key 3. run xzcat armbian.img.xz | dd of=/dev/sda status=progress 4. reboot laptop (to new system) but the step 1 failed - instead of booting the system from USB key (yes - i selected the USB key on laptop start), system started from the laptop's hard drive. i think, this is not expected behavior. or am i missing something and it is really a feature? 🙂 anyway - thanks for the project. it gives my old laptops new life mirek

Is it possible to install the x86 version in the RockPIX emmc? The nand-sata-install command doesn't solve it. Thank you

Hi all, I have a bit of an odd application, but given the recent effort being put into UEFI boot, I thought I'd ask for some help. I have a Gigabyte R152-P30, which is an Ampere 80 core, single socket server. Flash drive boot works just fine, but nand-sata-install onto the server's NVMe SSD has been troublesome. I've tried several permutations of having partitions and not having partitions on the NVMe drive, but none seem to actually create a bootable result. I see on the generic armbian image page that it suggests creating an EFI partition which I do (nvme0n1p1). It then proceeds to leave that partition empty. I also have another btrfs partition on the same nvme drive (nvme0n1p2). The second partition is the one that shows up in the nand-sata-install config menu. The script sucessfully moves all files onto this new btrfs drive, and I can see it all when I mount it. If I remove the EFI partition, nothing shows up in the servers boot optoins menu. If I leave the EFI partition in, I get an option in the boot options menu, but it does nothing (black screen). I assume this is because the EFI partition is empty. I'm still pretty new to understanding the Linux boot sequence, so please forgive me if I've forgotten anything trivial. My best guess was simply CP-ing over the flash drives efi folder to the nvme drive's but naturally that didn't work (unknown filesystem) and just dropped me into grub rescue. Attaching logs from the servers BMC (apologies that they're screenshots). If needed I can figure out a way to get armbianmonitor -U out to you guys. Thanks! pics: https://imgur.com/a/yunzvJy

Hello, when I try to update the kernel via armbian-config (System -> Other ), I always get the message "Test installed failed. Can't change firmware". I use the Image "Armbian_22.08.5_Uefi-x86_bullseye_current_5.15.73" The /tmp/switch_kernel.log says the following linux-image-current-x86=22.08.6 linux-dtb-current-x86=22.08.6

Hi All , I try to install Armbian_22.08.7_Uefi-x86_bullseye_current_5.15.69_gnome_desktop.img.xz and using rufus to create bootable flashdisk to install on mini pc z83 but found the result as error: attempt to read or write outside of disk 'hd0' , is anyone here know what is the problem and what should I do? Thx in advance

I'm writing from a limited perspective, so constructive criticism appreciated. In this thread, I'm recording some thoughts about how the OS gets from files into the memory of various boards, and what might make this more unified and easier and/or more flexible. Current U-boot My knowledge comes from the mvebu64 and rockchip64 families. At this time, the board boot process starts from code in the processor that attempts to find u-boot, and u-boot runs a script from its environment that searches for a UEFI application or a boot.scr file. They call this "Distro-boot" Armbian uses the boot.scr to load an uncompressed kernel image and a compressed initramdisk, along with a device tree. These use u-boot legacy image format. U-boot then passes control to the kernel. On mvebu64 (espressobin), u-boot is contained within the SPI on the board, along with its environment. U-boot 2022.04 on this board can do network booting as well as searching emmc, sd, or sata devices for a boot device based on a GPT type or simply the existence of files within the first partition on each device. On rk3399, some earlier stage attempts to launch idbloader from sector 64, which loads u-boot.itb from sector 16384, from whatever device can be detected: SPI, USB, eMMC, SD. The boot.scr loads the legacy uboot images from the first partition on the device, then applies overlays - I believe this enables HATs on boards that can use them. U-boot capabilities Boot process: UEFI. U-boot can load the linux kernel through the UEFI stub, or the GRUB bootloader. As far as I can tell, it's not a drop-in replacement for a legacy kernel boot. Boot file format: Flattened uImage Tree. This is a monolithic file that has one or more of kernels, initramdisks, and device trees, along with "configurations" that can be selected to tell u-boot which files to actually load. Additionally, the components of this file can be compressed, as u-boot can uncompress the kernel before passing control. Boot media: dhcp(v6) to tftp. U-boot can attempt to boot an EFI application from tftp, before it attempts to run a script from dhcp, before it attempts to PXE boot. Extlinux script: u-boot can read /extlinux/extlinux.conf where a menu of kernels can be provided, with paths to kernel, initrd, and dtb, and an entry for the cmdline. Each kernel on the system would need to contribute a fragment of this config, which isn't currently done. Image Layout Currently, many armbian images use an MBR partition table. It's the default, and a device needs to request GPT during the build to get it. But with GPT come a few advantages. The systemd/freedesktop people seem to have a vision of a single layout that would allow a linux system to boot on several architectures, and then auto-configure based on "discoverable partitions". There are partition type uuids for such things as ARM64 root partition, or dm-verity superblock and signature partitions. These features would give a read-only, integrity checked, signed image. There are partition flags for things like "read-only" (60), "no auto" (63), or "grow-file-system" (59). Beyond this, the ESP (EFI System Partition) has a structure to allow multiple kernels/OSes to deconflict the storage of their files. Boot Sequence Type #1 Boot Loader Specification: $BOOT is the (typically) vfat partition with type "bc13c2ff-59e6-4262-a352-b275fd6f7172", or the ESP (VFAT, "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"). Under $BOOT/loader/entries/, there would be files (e.g. ${machine-id}-${uname -r}-${os-release}.conf) that give configuration to find kernel and initrd at $BOOT/${machine-id}/${uname}/{linux,initrd,dtb,dtbo} Type #2: Unified kernel image - EFI PE w/ stub loader, initrd, and commandline, and can be signed cryptographically. These are at $BOOT/EFI/Linux/*.efi I assume these are handled by GRUB, as they do not seem to match u-boot's distro-boot. Armbian currently uses the boot.scr from u-boot's distroboot sequence to boot off the filesystem where boot.scr was found. First-boot and nand-sata-install When armbian builds the image, it does so through chroot and debootstrap. This results in artifacts like /etc/machine-id or /etc/ssh/ssh_host_*_key, which shouldn't be on multiple systems. They're removed as part of the image creation. Partition UUIDs ought to be changed too, but these are less likely to be a problem. The nand-sata-install attempts to create partitions to make a filesystem on some other block device, and then rsync's the running armbian system over to the new block device. It also tries to manage the u-boot bootloader and all the possible ways that can exist. (Goal) SD card partitioning sgdisk -n 14:${biosstart}:${biosend} -c 14:bios -t 14:ef02 -n 15:${uefistart}:${uefiend} -c 15:efi -t 15:ef00 -n 1:${rootstart}:0 -c 1:root -t 1:8305 -A 1:set:59 ${SDCARD}.raw This produces a GPT-formatted disk with the first partition (numbered 14) with a BIOS type (recommended 1 mb, or covering u-boot and files), an ESP (recommended 550 MB, to mount on /efi/), and an auto-detected ARM64 root partition that is labeled to grow to fill the disk when booted. Linux should be stored in a UEFI or FIT image, preferably as a UEFI boot method. U-boot environment variables for a given board should be able to select the appropriate armbian kernel, allowing the root filesystem to have multiple kernels for different boards installed and an SD card that boots on multiple boards.

Hello, first of all thank you for the development of the Armbian software. I am currently using version Armbian_22.08.2_Uefi-x86_bullseye_current_5.15.69 on my Terramaster F5-221. Unfortunately I have two small problems. Firstly, there is no linux header for the kernel used for compiling. Secondly, unfortunately I can't add a network interface in openmediavault. That always gives me an error. It works on Debian with Openmediavault. unfortunately this surprises me. Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; omv-salt deploy run --no-color systemd-networkd 2>&1' with exit code '1': NAS-Steinke:

Hi I installed the official release on my Z83 mini PC and it boots up great, but when I go to install to the emmc it fails at the U-Boot generation step with the error below. Has anyone seen this before or know a workaround? I did check to see if this was just a red herring error but as the error says the bootloader does not get written. "Error while creating U-Boot loader image with mkimage" "Error: no u-boot package found, exiting." Thank you in advance for any help.

Hello, Just wondering how this build compares to XanMod for performance related features under an AMD CPU? Thank you.