belegdol

This design decision has been around from the early days of Armbian and SBC's.  If you think about Armbian as a firmware for your board instead of a general operating system like on your PC, that makes some sense as to why originally that would have made the most sense (you install new firmwares, you don't upgrade them in place).  Also, all those early boards were limited on the amount of internal emmc storage they may have had, if any, and SD cards were also much smaller in storage capacity at that time.  So wasting space with an entire extra kernel wasn't really an option.
 
Now move forward 10 years and most of those limitations are lessened.  So it could be supported today for most build targets.  But the current approach would likely still be needed for some boards.  So while it would be feasible to support having multiple kernels installed it would take a lot of effort to implement (across all the different booting scenarios, u-boot scripts, extlinux, uefi, etc).  Also in many of these scenarios it doesn't really help as you need an interactive boot (i.e. with hdmi and keyboard/mouse input) to present a menu to the user to select an alternate boot target, and that interactive boot environment isn't common on SBC's (unlike the PC world).  If you have to solder and hookup a USB-UART connector to monitor the debug output to be able to switch your boot kernel, is that better/easier then just popping in a different SD card?
 
So ultimately like a lot in the open source world, this change while possible, hasn't attracted the interest/need for any developer out there to want to undertake this effort.  Which leads me to the inevitable next comment, PRs are always welcome for contributions to the project 🙂
 
(Personally this is something I would also like to see, but in looking into the effort it would take, I know I personally don't have the time to implement, and the workarounds are good enough for me)

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)
 

I have downgraded kernel on my odroid xu4 and now is booting again.
This were my steps:
 
#mount sd (use lsblk to indentify your sd device) mount /dev/sda1 /mnt/armbi_root #install qemu to execute arm inside amd64 apt install qemu-user-static #and copy it to sd cp /usr/bin/qemu-arm-static /mnt/armbi_root/usr/bin/ #mount pseudo-filesystems needed mount -t proc /proc /mnt/armbi_root/proc mount --rbind /sys /mnt/armbi_root/sys mount --rbind /dev /mnt/armbi_root/dev mount --rbind /run /mnt/armbi_root/run #chrooting sd chroot /mnt/armbi_root /usr/bin/qemu-arm-static /bin/bash #show installed previous versions apt-cache madison linux-image-current-odroidxu4 apt-cache madison linux-dtb-current-odroidxu4 #install working previous version (mine was 24.11.1 - kernel-6.6.60) apt install linux-image-current-odroidxu4=24.11.1 apt install linux-dtb-current-odroidxu4=24.11.1 #rebuild initramfs (maybe this is not necessary, but do not harm) update-initramfs -u #exiting chroot exit #unmonting sd for finishing umount -R /mnt/armbi_root  

./compile.sh kernel SHARE_LOG=yes  ARTIFACT_IGNORE_CACHE='yes' BOARD=odroidxu4 BRANCH=current  
 
This   https://www.google.com/search?q=one+bite+at+the+time

If I understand correctly, have you installed packages from a local folder? Did you build these packages yourself and use the armbian build system?
 
If yes, then you need to look inside the kernel package. What scripts are there? And try to build a fresh kernel and then compare the scripts from the fresh kernel and the one you installed.
Unfortunately, I do not see many details and I find it difficult to give any advice.

@belegdol I don't use an odroid, but if you write down which image was originally recorded on the memory card and how the update took place, maybe I can fix it for a future release. And of course yes, 58 megabytes to accommodate the boot partition is not enough.
 

With https://github.com/armbian/build/pull/2569 and https://github.com/armbian/upload/pull/33 the problem seems to finally be gone.

My Ubuntu VM is no longer booting to X since the last apt upgrade which makes preparing updates slightly more annoying than it should be, but I can have a go at rebuilding the kernel this evening.

My Ubuntu VM is no longer booting to X since the last apt upgrade which makes preparing updates slightly more annoying than it should be, but I can have a go at rebuilding the kernel this evening.