Werner

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