Igor

Add: rm /root/.not_logged_in_yet Ref: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-firstlogin#L302 but this will disable whole 1st login procedure - check if script is doing something you might need.

What about recent ones from here https://github.com/armbian/community (those builds are unchecked - mainstream support only)

So you think adding this would be enough?

We are getting close to: cut & merge to it?

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. Yes. I assume it should just boot it? I haven't tried it yet. 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.

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?) 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. 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. 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.

DDR_BLOB="${DDR_BLOB:=rk35/rk3568_ddr_1560MHz_v1.10.bin}" BL31_BLOB='rk35/rk3568_bl31_v1.28.elf' https://github.com/armbian/build/blob/master/config/sources/families/include/rockchip64_common.inc#L85-L89

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

... one option is to install armbian-firmware-full ... which has it all. For slim variant, follow @Werneradvice.

https://armbian.com/bugs

And also this looks odd. Do you perhaps have both (edge and current) kernels + headers installed? Perhaps you didn't reboot on upgrade?

ZFS package on Debian is too old for 5.19.y ... You need 2.1.5. I only manage to bring it up to Ubuntu, while on Debian another afternoon. Which I can't afford. Try getting updated packages, perhaps with those from Ubuntu will work. Dunno.

header install fails or ZFS compilation?

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!

Nothing extraordinary in the logs ... huh.

You run unchanged Armbian or something else?

Just run apt update & apt upgrade.

In the name of all developers, maintainers and support staff, thank you! We can't have universal approach as x86 is yet another hardware family. Via armbian-config -> software or apt install linux-headers-current-x86 I don't know what they use - systemd networking, network manager, netplan on top of something, ifupdown ... ? Our default is Network Manager, so not so skilled user can easily set it up.

Should be fixed by now.

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

apt service was disabled temporally until some solution is implemented in re-director service. This way people, which might be blocked, doesn't have troubles, while main download remain unchanged - manual selection of another mirror. IMO this is good solution for now.

@dev001 Images were recreated.

OMG We have one mirror in Ukraine. Is that blocked in Russia? Here is the code. I have asked author to check what would best to deal with such exceptions that we resolve this problem at server side and users don't need to tackle this. Adding some sort of "international-relations.db " ?

Which image exactly did you boot and what is the revision of the board. Picture might help.