====== Installing Kodi 21.2 on Raspberry Pi OS 13 Trixie ====== ===== High CPU usage ===== After a fresh installation of RaspiOS 13 Trixie and Kodi 21.1 package, I experienced an high CPU load (**load average** at about 2) with an idle system, where the Kodi process was the first on top. This were a significant worsening over the previous installation, where the load average for the idle system was **lower than 0.1**. Digging through the log files I found that the load increase corresponded to the appearance of the following kernel messages: kernel: cec-vc4-hdmi-0: message 10 timed out Indeed it seems that the LG 32LG5010 TV connected to the HDMI cable causes that timeout when it goes to standby mode. It must also be said that the CEC (remote control passthrough from TV to Kodi) do not work in this hardware combination, so I disabled the CEC controller in Kodi and solved the high CPU load. To disable the controller I stopped the Kodi process and changed the **$HOME/.kodi/userdata/peripheral_data/cec_CEC_Adapter.xml** file: ... ===== Automount problem ===== I have an external **3.5 inches 4 Tb hard disk** connected to the Pi 4 USB port using a **[[..:hardware:raspberrypi_nas_x835_sata_board|X835 board]]**. A large data partition (**/dev/sda3**) is mounted at bootstrap because there is an entry into **/etc/fstab**. The Kodi process uses the **udisks2** subsystem to automount connected devices. Since there is also a **/dev/sda2** partition on the disk, this is automatically mounted as soon as the Kodi process is started. From the **journalctl** log you can see: systemd[1]: Starting udisks2.service - Disk Manager... udisksd[1202]: udisks daemon version 2.10.1 starting dbus-daemon[694]: [system] Successfully activated service 'org.freedesktop.UDisks2' udisksd[1202]: Mounted /dev/sda2 at /media/kodi/9f259ae2-1de9-... on behalf of uid 1001 I haven't found a way to prevent automounting of just the /dev/sda3 partition using the udisks2 configuration. The only truly horrible way was to set a wrong mount parameter for that partition, causing it to fail. I.e. it is possibile to create the file **/etc/udisks2/mount_options.conf** with a bad mount option like this: FIXME This does not work: [/dev/disk/by-uuid/9f259ae2-1de9-...] automount=false It was impossibile to disable automount via the dbus subsystem too. Creating a file **/etc/udev/rules.d/99-udisks2-noauto.rules** with the following content **has no effects**: FIXME This does not work: ENV{ID_FS_UUID}=="9f259ae2-1de9-...", ENV{UDISKS_AUTO}="0" ENV{ID_FS_UUID}=="9f259ae2-1de9-...", ENV{UDISKS_IGNORE}="1" To reload the udev settings I used: udevadm control --reload udevadm trigger After all, because I don't need automount of connected devices, I removed the **udisks2** package at all. ===== USB disk spin-down problem ===== In a previous installation (RaspiOS 11 Bullseye) I managed to let the **[[..:hardware:raspberrypi_nas_smart_hard_disk|hard disk to spin-down]]** after some time of inactivity. The same configuration did not work on this new installation; it turned out that the culprit was the udisks2 subsytem. Actually the udisks can set APM options for using ATA commands (see ''man 8 udisks''), but I had no time to investigate. Simply removing the **udisks2** package solved the problem and the spin-down of the disk worked as in the [[..:hardware:raspberrypi_nas_smart_hard_disk|previous installation]]. ===== Networking ===== FIXME * Remove NetwokManager (and raspberrypi-net-mods due dependency) * Install Dhcpcd * Who launches wpa_supplicant on wlan0? apt install dhcpcd dpkg --purge network-manager raspberrypi-net-mods ===== Logging ===== The default RaspiOS 13 installation relies on **systemd-journald.service** (provided by the **systemd** package) for system logging; the **rsyslog** package is not installed at all. The default configuration places the journal on the volatile memory (see ''/usr/lib/systemd/journald.conf.d/40-rpi-volatile-storage.conf''), preserving disk space and avoiding SD card writes. In previous Raspberry Pi installations I used to remove **rsyslog** in favour of **busybox-syslogd** to have logs in volatile memory (readable with ''logread''), but now I will stay with this more modern configuration.