SteeMan

Moved post to correct forum.

@vitor Have you paid for support? Armbian is composed of volunteers who donate their time. If no volunteer desires to work on any particular board/feature/bug, no one is getting paid to be told to add such board/feature/bug. This is open source so anyone can go in and make changes/fixes/improvements and then hopefully submit them back for others to benefit from. First and foremost Armbian provides a place (forums, frameworks, source code) for anyone to join the volunteer community and help support the wide variety of boards that are out there.

This is good to know. I'm only starting to upgrade to Win11, so I haven't run into this yet. But I can pass this advice on to others.

It would be helpful to include which options in armbian-install you are running to create the problem

@samaritan You do understand that the Odroid C1 board is listed as EOS (End of support). No one is working to maintain that board anymore and thus over time more and more will cease to work on that board.

@samaritan This is an Armbian forum, not a dietpi forum. Please direct your posts elsewhere for dietpi issues.

@wyim Have you read: It may or may not work. For example the installs for coreelec and armbian are incompatible.

That file is located in the armbian build system at: packages/bsp/common/etc/X11/xorg.conf.d/01-armbian-defaults.conf running a ./compile.sh will rebuild the deb's

Either use armbian-config to switch to nightly (unstable) builds, or build images yourself via the build framework. But either way in doing so you would be switching from a stable build to unstable/under development builds. Also at this moment do to significant changes in build framework introduced after the release of 23.02, no nightly builds are being produced as issues are being sorted out.

https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-patches

@SuperMaximus What exactly are you trying to accomplish and why? In your post in this other thread (https://forum.armbian.com/topic/21590-rotate-armbian-logo-in-startup-splash-screen/#comment-161028) you are asking about changing the boot logo, here you are asking to disable the video output. Those are very different things. I think if you are looking to disable video output during boot, @jock suggestions are the way to go, and yes that is invasive and would involve low level changes that would require building a custom image. If you are looking to change the boot logo as you indicated elsewhere, then look at my followup post to that. If you are looking to do something else, you need to be more specific in your question. Otherwise Jock and I are wasting our time trying to guess what you are trying to accomplish.

I am about to comment on things I don't know nearly enough about to offer good suggestions, but here I go anyway. There are a lot of different issues tied up together in this thread and each person commenting is focused on different issues. While it is true they all are valid issues, I think we are talking past each other some of the time. 1) First I think is the original issue of the thread dealing with the fact that the "xu4 + incremental patches" builds are not detecting the kernel version number correctly. And a proposal has been put forth to handle/workaround this corner case. 2) Second, much of the discussion has been on the deeper issues of overall package structure (issues that extend back to the old build framework as well). These issues still need more discussion. 3) Third, is a new issue introduced by the new artifact caching strategy. How to cache the artifacts in a way that provides maximum reuse. Due to the current implementation of including the cache hash in the name of the .deb, the last two issues become tied together. But I'm not sure they need to be. What we need is a way to use both a local and remote cache to find the .deb's. There are other ways to do this than including the hash in the file name. For example on the local cache the hash could be the parent directory name. So instead of: ../debs/linux-image-current-meson64_6.1.13-S1ac8-De511-Pb8ce-C072bHfe66-B60c8_arm64.deb it could be: ../debs/S1ac8-De511-Pb8ce-C072bHfe66-B60c8/linux-image-current-meson64_6.1.13_arm64.deb This leaves the .deb package format/name independent from the caching mechanism. Thus separating issues 2 and 3 above. Yes it does mean that it is more difficult to find the .debs you build locally. That may be an acceptable tradeoff to gain the new caching functionality, but that could be alleviated by creating soft links/hard links in ../debs to the files as they are created. (Currently as there could be multiple different .deb's with the same name, in different hash directories. This is due to "changes" that don't involve a kernel version number bump. In this case the ../debs directory would have a link to the last version created, which essentially mirrors the behavior of the old master code) For the remote cache the cache key could be created in a similar manner that separates the hash and filename as well. Then we still have to sort out the design surrounding issue 2, but I think that discussion becomes simpler (but still very complex) than is currently is, with trying to squeeze our artifact cache on top of the debian packaging.

@madade Why do you ask for help again when you haven't provided the information that Igor asked of you. He asked you for four things: You only provided an answer to one request. Which hardware revision (picture please)? Where does booting end? (capture of the console output of the boot) Try another sd card. (Just because a card works in some circumstances, doesn't mean it will work for this purpose, sbc's are finicky when it comes to sd cards at times)

I noticed today that there are no 23.02 images for the rockpi-4c. The images exist for the 4a, 4b and 4cplus variants but not the 4c. The 22.11 images are the latest for the 4c. The reason I noticed is that on the downloads page for the rockpi4 it is still showing 22.11 as the current images because that page is showing the 4c info, with links provided to the other variants. The fact that it still showed 22.11 caught my eye.

So I had some more time today, I restored my test x96 mini box back to android, then downloaded the current jammy 23.02 build: Armbian_23.02.2_Aml-s9xx-box_jammy_current_6.1.11.img.xz, installed it onto sd card using balenea, copied u-boot-s905x-s912 -> u-boot.ext, edited the extlinux.conf to use: FDT /dtb/amlogic/meson-gxl-s905w-p281.dtb Inserted the sd card, pressed and held reset button, plugged in power, waited about 2 seconds, released the reset button and it booted into Armbian jammy. So it works for me. Things to check for: are you sure you are using a quality sd card? Are you sure you have properly copied the u-boot.ext? While I don't think it would be an issue with the android firmware you are using, especially as you have tried different ones, the one I am using (don't know where I got it, as I downloaded it years ago) is of size: 1,566,582,416

With the current release (23.2) Armbian has moved to using the Plymouth package for the boot screen (for most if not all boards). I personally don't know much about it, but the resource files are in /usr/share/plymouth/themes/armbian

Why do you mention android roms? The reset button has nothing to do with installing android roms.

@Wilson The only suggestions I have, are when using the amlogic usb tools, that you try all of the usb ports on your box and that you try different versions of the tool. I've had cases where only older versions worked with some of my older boxes. But it does tend to be finicky. And sometimes pushing the reset button as part of the process has helped me.

@maka armbian-install is the command in a standard Armbian build (as of 22.11 and later) that installs from sd card to emmc or other storage. Since that is what the author of this post was doing there is nothing to indicate that he is using a non-armbian build. Although your point that armbian-install is used for a different purpose in non-armbian builds is a good one, based on the content of this thread it didn't seem to me there was any indication that the author was not using an armbian build, but it is a possibility.

recovery mode has nothing to do with using the amlogic usb burning tool. Have you tried different usb ports? Also, I've had some boards only work with specific versions of the amlogic usb burning tool.

I don't have this box (nor any s912 based box), so I can only suggest you search the archives for similar issues. I know I have seen threads discuss similar issues (can't boot headless without an hdmi connected for other sbc's, and if I recall correctly the workaround was to buy some sort of null hdmi connector, which tricks the box into thinking an hdmi is connected). Also, it could be a dtb issue, I would suggest trying all of the s912 based dtbs.

How long are you holding the reset button. Try different lengths of time between 2 and 10 seconds. It sounds like you are holding it too long and it is booting into android recovery). If you are seeing repeated booting, you are holding it too long.

The aml-s9xx-box builds don't use a boot.ini file.

This is expected behavior. Each distribution is modifying the boot environment in different incompatible ways. That is why the install instructions (https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus) say if you have tried to install other distributions, you will need to restore to a clean android firmware before installing armbian.