Igor

Thanks for your quick answer @Igor

So this is the standard way to update any package, So easy, I should have test that before posting here ....

I just successfully do :
apt update apt list --upgradable armbian-config/inconnu 25.5.0-trunk.53.0213.103604 all [pouvant être mis à jour depuis : 25.5.0-trunk.18.0207.210415] --> YES there is an update available apt install armbian-config --> juste to update only this package, to no impact other part of my system
And ....TADA ! I now have all the latest "software" available in armbian-config available 😉 
thx again

Yes of course. But documentation or FAQ should be somewhere and up2date. Its a lot of work / impossible for our small team to cover all aspects of a Linux system. But for at least Armbian specifics - which this is - we might have somehting.

Thanks!

I did it in one Odroid HC2 and it is up agin:
v25.2.1 for Odroid XU4 running Armbian Linux 6.6.60-current-odroidxu4
 
One more to fix...

leo@bananapim64:~$ sudo nano /etc/apt/sources.list.d/armbian.list http://apt.armbian.com =>> https://stpete-mirror.armbian.com/apt leo@bananapim64:~$ cat /etc/apt/sources.list.d/armbian.list deb [signed-by=/usr/share/keyrings/armbian.gpg] https://stpete-mirror.armbian.com/apt bookworm main bookworm-utils bookworm-desktop leo@bananapim64:~$ sudo apt update Сущ:1 http://deb.debian.org/debian bookworm InRelease Сущ:2 http://security.debian.org bookworm-security InRelease Сущ:3 http://deb.debian.org/debian bookworm-updates InRelease Сущ:4 http://deb.debian.org/debian bookworm-backports InRelease Сущ:5 https://github.armbian.com/configng stable InRelease Пол:6 https://stpete-mirror.armbian.com/apt bookworm InRelease [53,3 kB] Пол:7 https://stpete-mirror.armbian.com/apt bookworm/main all Packages [17,5 kB] Пол:8 https://stpete-mirror.armbian.com/apt bookworm/bookworm-utils arm64 Packages [37,4 kB] Пол:9 https://stpete-mirror.armbian.com/apt bookworm/bookworm-desktop all Packages [7 526 B] Пол:10 https://stpete-mirror.armbian.com/apt bookworm/main arm64 Packages [1 168 kB] Пол:11 https://stpete-mirror.armbian.com/apt bookworm/bookworm-desktop arm64 Packages [15,9 kB] Пол:12 https://stpete-mirror.armbian.com/apt bookworm/bookworm-utils all Packages [3 965 B] Получено 1 304 kB за 9с (149 kB/s) Чтение списков пакетов… Готово Построение дерева зависимостей… Готово Чтение информации о состоянии… Готово Может быть обновлено 4 пакета. Запустите «apt list --upgradable» для их показа.  

Hi guys,
it looks like my issue is solved now after entering a specific BSSID in my network connection.
Or to be more precise, the issue is solved for me now, but for sure the issue still exists when you have a meshed network.
The connection is rock solid now once it is pinned to an specific access point in my mesh network.
Without the entry for a specific BSSID  it disconnects after some time. To analyze this a bit further it would be necessary to have a LAN connection or at least a screen and a keyboard. But unfortunately i have neither and the location of the device is a bit odd (it hangs in several meters height 😉  ).
 
If somebody is interested in solving this issue i can provide log files on request. I have mounted a remote switchable power supply, so it would be no problem for me to reproduce the issue again without the need to climb up again and again to reset the device.....
 
Thanks to all for the help.
Best regards, Chris

XU4 / HC1 is fixed by 
https://github.com/armbian/build/commit/5115cdf47a91f9cf5eb15f1b4984deebbe329002
Images are in generation, update is going out when possible. (broken updates were also disabled, but takes time for repo to sync)
 

XU4 / HC1 is fixed by 
https://github.com/armbian/build/commit/5115cdf47a91f9cf5eb15f1b4984deebbe329002
Images are in generation, update is going out when possible. (broken updates were also disabled, but takes time for repo to sync)
 

Hi,
 
great, I will test asap.
 
See you

XU4 / HC1 is fixed by 
https://github.com/armbian/build/commit/5115cdf47a91f9cf5eb15f1b4984deebbe329002
Images are in generation, update is going out when possible. (broken updates were also disabled, but takes time for repo to sync)
 

XU4 / HC1 is fixed by 
https://github.com/armbian/build/commit/5115cdf47a91f9cf5eb15f1b4984deebbe329002
Images are in generation, update is going out when possible. (broken updates were also disabled, but takes time for repo to sync)
 

Hey! 
 

When those three jobs finishes:
https://github.com/armbian/os/actions/runs/13238582459
https://github.com/armbian/os/actions/runs/13240767648
https://github.com/armbian/armbian.github.io/actions/workflows/generate-redirector-config.yml
it should be O.K.

Fundamental problem is that at this moment, repo and index is not in sync. Why that happened ... is another story, it should not happen.
 
First job checks and updates if there is something to pull to stable repository. It pushes to 1st class repo
Second job is optional in this case.
Third job checks all mirrors and only serve the ones where index and files are in sync.

Problem is that those jobs takes hours ... and in the mean time, repo is broken.

No, I haven't yet. Thanks for letting me know. I'll try it out soon and report what I find.

I set most used combination as we have to set some limits. Currently we are at 500 weekly images, which is already a rape for (limited) CI infrastructure  After we manage to move desktops to runtime (https://github.com/armbian/configng), we will be able to remove many desktop images and provide more CLI combinations.
 

Exactly, I think its not worth going manual exceptions way. HAS_VIDEO_OUTPUT should suffice.

Server builds is heavier and comes with Network Manager, while minimal comes with systemd-networkd and less tooling. Debian based or Ubuntu, depends on what is your use case further. A very few native application suites won't work on one, while it will work on another. The rest are IHMO personal preferences and stereotypes. Ubuntu server is cleaned from Canonical things and its pretty much Debianized.
 

Exceptions can be covered that way. This build target is common for many different TV boxes, so I assume the user-base is also bigger, so is the need I guess.

I can confirm that Armbian_community_25.5.0-trunk.4_Helios4_noble_current_6.6.75.img.xz does not boot on Helios-4 with the same error described above:
 
Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing...  
I spent the weekend investigating a similar issue with upstream Debian and upstream u-boot that turned out to be after a certain size of mmc access data would be corrupted. Disabling the SDHCI_SDMA function in u-boot helped:
https://lore.kernel.org/r/20250208-a388-kerneladdr-v2-1-17c01313eba2@solid-run.com
 
Finally I pushed this and other changes to the SolidRun vendor fork for the Armada 388 System on Module (as used on Helios-4), and attempted booting the same armbian image again. This time boot succeeded:
 
BootROM - 1.73 Booting from SPI flash U-Boot SPL 2024.04 (Feb 08 2025 - 13:12:00 +0000) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from SPI U-Boot 2024.04 (Feb 08 2025 - 13:12:00 +0000) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) Core: 30 devices, 20 uclasses, devicetree: separate MMC: mv_sdh: 0 Loading Environment from SPIFlash... SF: Detected w25q32 with page size 256 Bytes, erase size 4 KiB, total 4 MiB *** Warning - bad CRC, using default environment Model: Helios4 Board: Helios4 Net: Warning: ethernet@70000 (eth1) using random MAC address - 86:69:49:e4:c6:90 eth1: ethernet@70000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 17 ms (171.9 KiB/s) ## Executing script at 00200000 Boot script loaded from mmc 158 bytes read in 13 ms (11.7 KiB/s) 28834 bytes read in 32 ms (879.9 KiB/s) 8146813 bytes read in 807 ms (9.6 MiB/s) 8550096 bytes read in 850 ms (9.6 MiB/s) Working FDT set to 100000 Kernel image @ 0x800000 [ 0x000000 - 0x8276d0 ] ## Loading init Ramdisk from Legacy Image at 01800000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 8146749 Bytes = 7.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00100000 Booting using the fdt blob at 0x100000 Working FDT set to 100000 Loading Ramdisk to 0f83b000, end 0fffff3d ... OK Loading Device Tree to 0f7cb000, end 0f83afff ... OK Working FDT set to f7cb000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 255.4-1ubuntu8.5
Binaries for reference:
https://images.solid-run.com/A38X/U-Boot/v2024.04/2025-02-08_695f767/u-boot-helios-4-sd.kwb
https://images.solid-run.com/A38X/U-Boot/v2024.04/2025-02-08_695f767/u-boot-helios-4-spi.kwb

Compatible field is reserved for almost identical boards or when image supports more devices, like Raspberry Pi 3 and 4. Base image is for Rpi4 but Rpi3 is also compatible.
 
Other two fields are deprecated as content is generated automatically. For customization of build targets, check this https://github.com/armbian/os/wiki

UPDATE: I managed to make it work eventually.
Here is an updated tutorial: https://gitlab.com/peltho/rock-5c-lite-u-boot-spi

A quick look at the shell code makes me think that it is a different purpose compared to how I use virtualization. I use only HW accelerated based virtualization, so -enable-kvm flag is missing, but might be added by virt-install. Also mostly Arm on Arm although I also use x86 on x86 as well. I do not use qcow2, but just flat images or a physical SD-card or NBD or LVM.
 
Before I got my Rock3A, I downloaded the Armbian Noble image for it (was 6.6.62) but put a 6.12 *rk3588 kernel on it as well. With the default Armbian U-Boot for QEMU I could then prepare everything and already 'run' my Rock3A as a VM on NanoPi-R6C like this:
taskset --cpu-list 0-3 qemu-system-aarch64 \ -M virt -cpu host -enable-kvm -m 2048 -smp 4 \ -bios u-boot.bin \ -drive if=none,file=rock3a.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1,mac=xx:xx:xx:xx:xx:xx \ -nographic The taskset is needed if host runs 6.1.x  vendor kernel and also makes it more realistic w.r.t. speed as then the VM gets 4x Cortex-A55, same as real Rock3A.
The 6.12/rk3588 kernel (inside the VM) was needed as that one has all included w.r.t. machine virt (same as vanilla Debian Bookworm kernel).
 
A note is that I later on added Btrfs support to a custom build u-boot for QEMU and converted Ext4 in rock3a.img into Btrfs, but principle is the same. Btrfs offers online shrink and differential snapshots that I use for remote backups. And with a MAC-address equal to the real Rock3A, it is easy flipping between real and VM.
 
Also note is that the following file needs to be created on the host, assuming it uses br0 as base for network I/O:
# cat /etc/qemu/bridge.conf allow br0  
To use full graphics in VM and for multi-year running VM on my RPi4B, I also use virsh and UEFI. But usually only CLI is needed.

hi @jock
 
I agree that changing the SMD 0201 parts is a real challenge - for this reason I used 0402's soldered them direct to the level shifter and run a tiny wire to the 5V source.
I'm thinking that an SoC side strong pull-up would do the trick eventually and remove R90611/12 entirely. But I haven't test this - but will do that with the next PCB I get on my table.
 
The Level-shifter is a Texas Instruments TX0102DCU with and with OE is high the internal 10K pull ups are enabled.  That might me not enough for the external monitor so the 6.8k has been applied.
Same for the SoC side, 10K only , so I support the internal SDA/SCL lines with the light diving strength of 2ma.
Datasheet:
8.3.5 Pullup or Pulldown Resistors on I/O Lines Each A-port I/O has an internal 10-kΩ pullup resistor to VCCA, and each B-port I/O has an internal 10-kΩ pullup resistor to VCCB. If a smaller value of pullup resistor is required, an external resistor must be added from the I/O to VCCA or VCCB (in parallel with the internal 10-kΩ resistors). Adding lower value pull-up resistors will effect VOL levels, however. The internal pull-ups of the TXS0102 are disabled when the OE pin is low.  
I would say it doesn't hurt to add the changes to the DTS for the i2c7_xfer pinctrl. But without fixing the Pull-up value on the 5V it will not improve anything.
 
Yes it is tiny tiny.

Do the same for max:
https://github.com/armbian/os/commit/45e7773d8fa023f3c5fb3c9c1402bf3616c59031
and wait for next automated rebuild cycle of community maintained images.
 
Then download pre-configured Gnome desktop image and forget about any other browser then preinstalled one. Also forget general understanding about desktop Linux on PC ... this is embedded Linux / custom hardware world, where things are "a bit" different. Developing and keeping functional desktop image was already on the level of miracle considering that we are operating with big negative budget and absolute absence of any support from HW dealer that makes big sales ... which are crushing ability of making things better. For you and for us.
 
Or dive into https://docs.armbian.com/Developer-Guide_Overview/

Make them build & boot able within the build framework
https://github.com/armbian/build
When you confirms, open a PR https://github.com/armbian/build/pulls and change config file from .eos to .csc and automation will become to produce images.

Successfully tested on the Orange Pi 5 with Ubuntu Noble minimal mainline image. Note that this image kernel panics every now and then on bootup (something to do with power management and interrupts). Disabling networking seems to solve the issue
 
The automated script now supports configuring the network interface on the target using ifupdown. This is primarily useful for statically configured setups

Thank you for quick reply. Haven't even thought it's not supported.
 
PS: I wanted to thank the developers for such build / config tool! It worked like a charm as I decided to upgrade from Ubuntu xenial.

Wow, unbelievable. But happy to see it is so actively maintained.
I don't mind being on beta for time being and I am fine with updating this often. I actually enjoy receiving updates, since I decided to switch to beta and keep the kernel unfrozen.
Worst case scenario - if some beta breaks my back, I will just restore whole SD card to a few month old backup and update to latest stable.
I do not have anything useful on my board that changes over time.
 
Lets consider this topic closed.

After applying patch from previous post, it updated to latest version without complaining about unhealthy status:

Link removed. That's all i can do for the time being.
 
@darkside40 Thanks!