DietPi OS for ROCK64

[skyway]

The web interface is by default disabled since Kodi 19, but can be enabled via GUI.

Since my keyboard isn't being recognized, i've edited this file:

Code:

advancedsettings.xml

and inside i've put:

Code:

<advancedsettings>
    <services>
        <esallinterfaces>true</esallinterfaces>
        <webserver>true</webserver>
        <zeroconf>true</zeroconf>
    </services>
        <loglevel hide="attribute">3</loglevel>
        <webserverpassword default="true">kodi</webserverpassword>
        <webserverport default="true">8081</webserverport>
        <webserverusername default="true">kodi</webserverusername>
        <webskin default="true">webinterface.default</webskin>
</advancedsettings>

Still doesn't work. So i uninstalled and installed back, but still the problem remains.
Is this kodi on dietpi reliable?
Since the start, no matter what i have also these messages

Code:

failed to open zone.tab
libva info: VA-API version 1.10.0
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)

[MichaIng]

I'm not sure how to enable the web interface like that, would need to search docs myself. Generally you can check via ss -tlpn which processes are listening on which TCP port.

Note that this is not a "kodi on dietpi" but the official Debian Kodi package. You can do apt install kodi instead, we additionally only assure that members of input and tty groups have R/W access to all input and console devices (not relevant when you run Kodi as root user, which I'd recommend while debugging to rule out other permission issues) and create a desktop icon, if a desktop is installed. Only on RPi and Odroids special packages are installed to make better use of their GPU.

How did you find out about the missing addons repository when inputs did not work?

So if input does not work when executing the kodi or kodi --standalone command as root user from a regular local console, then it is either an issue with the Armbian kernel (which I doubt, if the keyboard works on the console), the Debian Bullseye input libraries or their Kodi package, or a combination of those. Since the ROCK64 is not officially supported by Armbian (through it works generally fine, the most used PINE64 SBC running DietPi), it makes sense to report this to the Debian bug tracker then: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=kodi

But we should gather more info first. Could you please paste the output of the following command:

Code:

dmesg -l emerg,alert,crit,err
dmesg | tail -10

This is to check for kernel errors and the last 10 kernel messages, just in case we find something related to input devices when running Kodi.

[skyway]

for once i  gained access with keyboard..that happend when i've ran

Code:

kodi --window=gbm

but after restart, that didn't work .. it seems it has a mind of it's own
Will try again, uninstalling, installing and get through kodi & kodi --standalone, and get back.
Also on my tv, randomly i see a message displayed "Unsuported", and i restart, after that all goes well..

[MichaIng]

Hmm, interesting, GBM should be used automatically when you start Kodi form console. Only when it is started within an X session, hence from desktop or terminal emulator, it runs in X server mode.

[luminosity7]

Has anyone installed DietPi recently for Rock64 v3?  I recently dowloaded and burned DietPi_ROCK64-ARMv8-Bullseye.7z to a sd card.  The Rock64 doesn't boot. The red indicator light flashes but nothing happens. Any help would be greatly appreciated. Have to say as a noob i am a little bummed as both DietPi and Ambian didn't work.

[Chubber]

Has anyone installed DietPi recently for Rock64 v3?  I recently dowloaded and burned DietPi_ROCK64-ARMv8-Bullseye.7z to a sd card.  The Rock64 doesn't boot. The red indicator light flashes but nothing happens. Any help would be greatly appreciated. Have to say as a noob i am a little bummed as both DietPi and Ambian didn't work.

I am in the same situation. Is there an archive of previous builds? My next move is to try the Ambian build.

[MichaIng]

Generally, we do not keep older images. Do you have a UART adapter to check serial console logs?

[Chubber]

Generally, we do not keep older images. Do you have a UART adapter to check serial console logs?

Unfortunately not. I've tried to ssh in but I'm not getting a connection either. I guess I'll need the UART adapter sooner or later.

[Chubber]

Generally, we do not keep older images. Do you have a UART adapter to check serial console logs?

Unfortunately not. I've tried to ssh in but I'm not getting a connection either. I guess I'll need the UART adapter sooner or later.

I was able to finally ssh in but I still can't get any love on the hdmi port.

[MichaIng]

I just added ROCK64 to our image build script and generated new images. It's still (latest) Armbian kernel and U-Boot packages, but freshly partitioned image file + rootfs via debootstrap. Probably the more recent U-Boot works more reliable: https://dietpi.com/downloads/images/testing/

If the Bullseye image does not boot, the Bookworm one won't either, which differs only in userland.

EDIT: Ah I just saw now that you were able to SSH into the system with the old image, but no HDMI output? Also finishing first run setup, including kernel upgrade does not help with this?

EDIT2: Ah lol, here it was reported at Armbian: https://forum.armbian.com/topic/24146-th...lled-hdmi/
Do you see the same error(s) in dmesg -l emerg,alert,crit,err?