ALPHA : Debian 12, problème lors d'une fresh install (add "non-free" et base de données)

Bad · Août 19, 2023, 9:17

Bonjour à tous,

Aujourd’hui j’ai tenté une fresh install de Jeedom sur Debian 12.
Suite au post Impossible de démarrer mariadb lors de l'installation Jeedom sur Debian 12,
je m’attendais à rencontrer des problèmes et je n’ai pas été déçu

Déjà, je suis parti sur un ISO Debian 12.1.0 disponible ici.

Ensuite, il faut bien télécharger l’installeur de l’alpha et lancer une installation de l’alpha :

wget https://raw.githubusercontent.com/jeedom/core/alpha/install/install.sh
chmod +x install.sh
./install.sh -v alpha

Lors de l’étape 2, premier « blocage » :

Starting step 2 - packages
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
software-properties-common is already the newest version (0.99.30-4).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Adding component(s) 'non-free' to all repositories.
Press [ENTER] to continue or Ctrl-c to cancel.

Il faut donc faire ENTRER, bien que normalement il n’y a rien à faire lors de l’install.
Je suggère donc de modifier l’installer ici :

github.com

jeedom/core/blob/9525df5e597f2616928a48364437e9848dce3d94/install/install.sh#L66

      
        
              apt-get update
              apt-get -f install
              apt-get -y dist-upgrade
              echo "${VERT} Step 1 - Install done ${NORMAL}"
            }
            
            
step_2_mainpackage() {
              echo "---------------------------------------------------------------------"
              echo "${JAUNE}Starting step 2 - packages${NORMAL}"
              apt-get -y install software-properties-common
              add-apt-repository non-free
              apt-get update
              apt_install ntp ca-certificates unzip curl sudo cron
              apt-get -o Dpkg::Options::="--force-confdef" -y install locate tar telnet wget logrotate fail2ban dos2unix ntpdate htop iotop vim iftop smbclient
              apt-get -y install usermod
              apt-get -y install visudo
              apt-get -y install git python python-pip
              apt-get -y install python3 python3-pip
              apt-get -y install libexpat1 ssl-cert
              apt-get -y install apt-transport-https
              apt-get -y install xvfb cutycapt xauth

et de transformer la ligne en :

add-apt-repository -y non-free

Sinon, jusque ici, tout va bien !

Le vrai premier problème apparait lors de l’étape 6 :

Starting step 7 - mariadb customization
● mariadb.service - MariaDB 10.11.3 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/mariadb.service.d
             └─override.conf
     Active: activating (auto-restart) (Result: exit-code) since Sat 2023-08-19 17:12:05 CEST; 12ms ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 29076 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 29077 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 29079 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [>
    Process: 29177 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
   Main PID: 29177 (code=exited, status=1/FAILURE)
     Status: "MariaDB server is down"
        CPU: 118ms

Aug 19 17:12:05 jeedom-last-alpha-12 systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Aug 19 17:12:05 jeedom-last-alpha-12 systemd[1]: mariadb.service: Failed with result 'exit-code'.
Aug 19 17:12:05 jeedom-last-alpha-12 systemd[1]: Failed to start mariadb.service - MariaDB 10.11.3 database server.
Cannot start mariadb - Cancelling

En effet, d’après les logs, mariadb ne démarre pas, car InnoDB ne semble pas/plus supporté ?!

Aug 19 17:10:40 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:40 0 [Note] Starting MariaDB 10.11.3-MariaDB-1 source revision  as process 28308
Aug 19 17:10:40 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:40 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
Aug 19 17:10:40 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:40 0 [Note] InnoDB: Number of transaction pools: 1
Aug 19 17:10:40 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:40 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
Aug 19 17:10:40 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:40 0 [Note] InnoDB: Using liburing
Aug 19 17:10:40 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:40 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
Aug 19 17:10:40 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:40 0 [Note] InnoDB: Completed initialization of buffer pool
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [ERROR] InnoDB: File ./ib_logfile0 was not found
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [Note] InnoDB: Starting shutdown...
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [ERROR] Plugin 'InnoDB' init function returned error.
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [Note] Plugin 'FEEDBACK' is disabled.
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [Warning] 'innodb-large-prefix' was removed. It does nothing now and exists only for compatibility with old my.cnf files.
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [ERROR] Unknown/unsupported storage engine: InnoDB
Aug 19 17:10:41 jeedom-last-alpha-12 mariadbd[28308]: 2023-08-19 17:10:41 0 [ERROR] Aborting
Aug 19 17:10:41 jeedom-last-alpha-12 systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE

Rien de bien méchant, une recherche Google plus tard, j’ajouter à la ligne 204 du script d’installation :

echo "default-storage-engine=myisam" >> /etc/mysql/conf.d/jeedom_my.cnf

C’est ensuite à l’étape 10 que l’installation coince :

Starting step 10 - Jeedom install
[START INSTALL]
****Install jeedom at (2023-08-19 17:24:58)****

Installation of Jeedom
Installating database...***ERROR*** 
SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown storage engine 'InnoDB'
SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown storage engine 'InnoDB'
[...]
SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown storage engine 'InnoDB'

OK
PHP Fatal error:  Uncaught PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'jeedom.config' doesn't exist in /var/www/html/core/class/DB.class.php:84
Stack trace:
#0 /var/www/html/core/class/DB.class.php(84): PDOStatement->execute()
#1 /var/www/html/core/class/config.class.php(192): DB::Prepare()
#2 /var/www/html/core/class/translate.class.php(51): config::byKeys()
#3 /var/www/html/core/class/translate.class.php(207): translate::getConfig()
#4 /var/www/html/core/class/translate.class.php(102): translate::getLanguage()
#5 /var/www/html/core/class/translate.class.php(81): translate::exec()
#6 /var/www/html/core/class/translate.class.php(220): translate::sentence()
#7 /var/www/html/core/config/jeedom.config.php(23): __()
#8 /var/www/html/core/php/utils.inc.php(84): require_once('...')
#9 /var/www/html/core/php/core.inc.php(27): include_file()
#10 /var/www/html/install/install.php(53): require_once('...')
#11 {main}
  thrown in /var/www/html/core/class/DB.class.php on line 84
Error during install : 
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'jeedom.config' doesn't exist
[...]
[END INSTALL ERROR]
Cannot install Jeedom - Cancelling

Je n’ai pas analysé plus profondément la source du problème, mais le « petit fix » de l’étape 6 n’est pas adéquat/suffisant, car il reste des traces d’InnoDB.

Probablement quelque chose à voir avec cette ligne, que j’investiguerai plus tard :

/var/www/html/core/class/DB.class.php:651:                              $_table['engine'] = 'InnoDB';

Bad

Loic · Août 20, 2023, 8:00

Salut,

Merci pour les tests, j’ai appliqué tes corrections pour déjà éliminé une partie du problème. Reste le soucis inodb je pense ca vient de la : File ./ib_logfile0 was not found. Avant debian12 on pouvait supprimer ces fichiers et mariadb les refaisaient au démarrage mais ca semble plus être le cas sauf que je trouve pas d’ou vient la suppression…

D’ailleurs a mon default Storage Engine sert pas a grand chose ca permet de démarrer car il est plus sur inonde qui lui ne peut pas démarrer car il lui manque son ib_logfile

Edit : j’ai changé un truc dans l’installation, pas de myisam par défaut mais surtout je ne spécifie plus la taille des logs a voir si ca corrige le soucis.

Edit 2 : si ca marche pas peut être faire innodb_force_recovery = 1 dans le Jeedom.cnf mais je crois faut l’enlever après (ce qui est quand meme pas très pratique)

Bad · Août 20, 2023, 8:14

Je suis en train de tester, merci pour les modifs !

Autre modif qui me semble importante : j’ai relancé l’étape 7 et l’installeur m’a mis 2x le contenu attendu dans le fichier /etc/mysql/conf.d/jeedom_my.cnf, donc juste remplacer ça :

github.com

jeedom/core/blob/alpha/install/install.sh#L200-L201


      
          echo "thread_cache_size = 16" >> /etc/mysql/conf.d/jeedom_my.cnf
          echo "tmp_table_size = 48M" >> /etc/mysql/conf.d/jeedom_my.cnf

par ça :

echo "[mysqld]" > /etc/mysql/conf.d/jeedom_my.cnf

devrait faire le job (et tant qu’à faire, il y a pleins d’espaces en fin de ligne dans le fichier install.sh).
Je poursuis dans l’install.

EDIT1 : Etape 7 KO

Aug 20 10:15:17 jeedom-last-alpha-12 systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Aug 20 10:15:17 jeedom-last-alpha-12 systemd[1]: mariadb.service: Failed with result 'exit-code'.
Aug 20 10:15:17 jeedom-last-alpha-12 systemd[1]: Failed to start mariadb.service - MariaDB 10.11.3 database server.

Je regarde d’où ça vient.
Ok, je fix le démarrage de mariadb avec la modif suivante :

rm /var/lib/mysql/ib_logfile* /var/lib/mysql/ibdata* &> /dev/null (et pas besoin du touch)
Le RM est à moitié présent en stable, mais pas en alpha, enlevé par ce commit :

EDIT2 : Suite à ces modifs, l’install se passe bien
Je retry depuis le debut de la fresh install une dernière fois.

Loic · Août 20, 2023, 9:52

Voila j’ai poussé les modifications mais va falloir que je fasse des tests car en docker le rm empêche mariadb de démarrer…

Bad · Août 20, 2023, 9:54

Ok, je confirme que après ces 2 changements (ajout du rm et suppression du touch),
l’installation se termine bien. Full log : log_install_alpha_debian12.txt (313,0 Ko)

A noter les choses suivantes :

Script d’install :
Le script étant en anglais, les variables des couleurs mériteraient de passer en anglais aussi.
Il reste de caractères d’espacement en fin de ligne un peu partout.
Etape 1 : différents packages ne sont pas résolu :

E: Unable to locate package usermod
E: Unable to locate package visudo
E: Package 'python' has no installation candidate
E: Package 'python-pip' has no installation candidate
E: Package 'libav-tools' has no installation candidate
E: Package 'mbrola' has no installation candidate

Etape 1 : l’ajout du dépôt tainté non-free est utilisé uniquement pour les packages pico et snmp :
- Pico pourrait être remplacé ou supprimé (TTS utile dans le Core?), car peu utilisé par le Core,
- SNMP tout simplement supprimé, car inutilisé.

[...] bookworm/non-free amd64 libttspico-data all 1.0+git20130326-13 [4,156 kB]
[...] bookworm/non-free amd64 libttspico0 amd64 1.0+git20130326-13 [141 kB]
[...] bookworm/non-free amd64 libttspico-utils amd64 1.0+git20130326-13 [10.3 kB]
[...] bookworm/non-free amd64 snmp-mibs-downloader all 1.5 [5,163 kB]

Etape 6 : l’url de téléchargement du zip pourrait être changée pour éviter une redirection :
https://github.com/jeedom/core/archive/alpha.zip → https://codeload.github.com/jeedom/core/zip/refs/heads/alpha
Etape 8 : le log d’erreur de Apache est écrit dans /var/log/apache2/error.log,
cf /etc/apache2/apache2.conf:134:ErrorLog ${APACHE_LOG_DIR}/error.log.
Il serait intéressant de rajouter un sed dans le script d’installation pour commenter cette ligne.

Sinon à part ça, le système à l’air fonctionnel (sans plugin pas testé avec).
Pas d’erreur dans les logs (tous en niveau debug), même après un reboot.

Bad

Loic · Août 20, 2023, 10:02

Merci pour les retours :

nom des couleurs : fait
package non résolu : normal c’est pour garder la retrocompatibilité
non free : justement le core se sert de pico tts il en a besoin, le snmp sert pas effectivement (sauf pour les plugins monitoring a voir si ca php-snmp a besoin du package snmp)
changement d’url : fait
pour le apache j’ai pas trop compris normalement il est dans /var/www/html/log

Niveau test que j’avais moi j’avais eu des erreurs aléatoire de class not found (Ajax en particulier) et des soucis de perte de connexion a la db.

Bad · Août 20, 2023, 10:16

Merci pour ces modifs super rapides

ErrorLog ne peut être défini qu’une fois dans toute la configuration d’Apache, ce n’est pas le cas :

root@jeedom-last-alpha-12:/var/log# grep -rn ErrorLog /etc/apache2/
/etc/apache2/sites-available/default-ssl.conf:12:       ErrorLog ${APACHE_LOG_DIR}/error.log
/etc/apache2/sites-available/000-default.conf:4:        ErrorLog /var/www/html/log/http.error
/etc/apache2/apache2.conf:128:# ErrorLog: The location of the error log file.
/etc/apache2/apache2.conf:129:# If you do not specify an ErrorLog directive within a <VirtualHost>
/etc/apache2/apache2.conf:134:ErrorLog ${APACHE_LOG_DIR}/error.log

Suite à l’installation de Jeedom, il est dans apache2.conf et 000-default.conf.
Il faudrait le supprimer de apache2.conf, avec par exemple lors de l’étape 8 :

sed -i -e "s%^ErrorLog%#ErrorLog%g" /etc/apache2/apache2.conf

J’ai une stack qui tourne depuis le 6 aout, d’apres les logs je n’ai pas eu de souci avec la bdd.
Ajax, il me semble en effet en avoir vu passer.

~~Je rebuild la stack de zero pour check ça en vitesse~~ => il faut attendre le build sur DockerHub.

En tout cas, je pense que c’est plutôt bon pour Debian 12, merci encore !

Bad

Loic · Août 20, 2023, 10:54

J’ai ajouté le sed.

Merci a toi pour tous les tests et les corrections c’est top.

Pour le docker la build est en cours mais c’est assez long.

Bad · Août 20, 2023, 10:57

J’étais justement en train de le tester, il semble qu’il y a un problème avec le sed

EDIT : Apache ne démarre pas s’il n’a pas de ErrorLog en global, donc il faut modifier le sed :

github.com

jeedom/core/blob/0e173c7acd83186bbfb8f56c586fd6568da4b907/install/install.sh#L276-L276

      
        
            sed -i -e "s%^ErrorLog%#ErrorLog%g" /etc/apache2/apache2.conf

en

sed -i -e "s%\${APACHE_LOG_DIR}/error.log%${WEBSERVER_HOME}/log/http.error%g" /etc/apache2/apache2.conf

ET supprimer la ligne :

github.com

jeedom/core/blob/0e173c7acd83186bbfb8f56c586fd6568da4b907/install/apache_default#L4-L4

      
        
            ErrorLog WEBSERVER_HOME/log/http.error

ET ce sed ne sert plus à rien :

github.com

jeedom/core/blob/alpha/install/install.sh#L242-L242

      
        
            sed -i -e "s%WEBSERVER_HOME%${WEBSERVER_HOME}%g" /etc/apache2/sites-available/000-default.conf

Loic · Août 20, 2023, 11:18

Voila c’est tout corrigé. Merci

Bad · Août 20, 2023, 11:36

De rien, merci pour ton temps <3
Je testerai certainement encore le docker quand il sera build.

system · Août 21, 2023, 11:36

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.