Werner

Oh well, that's quite some time ago. The patchset used back then has been removed/renamed already to move on. Look at 6df6d0d607abfd59169a0ef2fddbed5fcd5b58f9 The question is has this introduced upstream or with one of the patches Armbian puts on top. Quite a journey to dig through that.

This may be an issue. I know from the past Armbian and petitboot don't work well together. You need to wipe your spi to get rid of it. Then everything should work just fine. Having this package installed means nothing about the actual used boot loader. This package only provides the binaries to rewrite the boot loader if actually necessary. It is updated with package install/upgrade because doing so is rarely necessary. armbian-install can update the boot loader and will use the binaries from the package.

Where did you get this uboot? I strongly believe this is not from Armbian, hence support is impossible.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Use framework and DIY. That's what it is made for

nand-sata-install has been a symlink to armbian-install for quite a while and yes, this tool didn't receive much love. However it could be replaced soon by this:https://github.com/armbian/configng/pull/951

moved to tvboxes

split into new topic for the reason above.

moved

moved

moved to off-topic neither a supported device nor about Armbian.

Let me know. I had hopes the commiter would provide upstreaming effort proof but nothing there yet.

Need to sync tags and boards at some point again...or hopefully this will work automatically at some point. Anyway, try https://github.com/armbian/build/pull/9796

I suggest to ask at dietpi forums, since we cannot help with 3rd party os/scripts.

never heard of that kernel before

I don't have this device so I can only give generic advice. Set verbosity to 7 in /boot/armbianEnv.txt to get more details besides this unhandled SMC message. From what I've read over the years is that this device seems quite fragile and has lots of quirks in to get it halfway decently running. It would be not uncommon that (on first glance unrelated) upstream changes break something.

Moved to off-topic.

https://forum.armbian.com/terms

duplicate

I have sent a new pr. basically you do something like this: code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=orangepioneplus BRANCH=edge kernel-config This will spawn a kernel menuconfig where you can modify the kernel config. This menu also takes all necessary dependencies into account. Once everything is done the kernel config file in config/kernel is modified. If you use a tool like vscode this will automatically visualize. If you manually change the kernel config file and want to check if your settings are persistent to rewriting you can use the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } rewrite-kernel-config command similar to the one above.

hehe, yes. because on every new major kernel version the same stuff occurs: rollover and adjust the (huge) patchset to the new version. Because patches were copied, this resulted in these large line numbers. in any case, kernel rewrite addresses things like unmet dependencies, hence throwing stuff out which would not work this way anyway. to make sure it is persistent, use kernel-config to spawn a menu config and enable the necessary options. The resulting kernel config should persist.

I'd check all "edge" configs for the presence of usbip. at one of those at least a build test should occur

feel free to send pr

https://github.com/armbian/build/pull/9971

It doesn't even attempt to load which is odd. usually it tells you that it (at least) attempts to load in both success and failure cases. Everything else looks pretty normal.