M7 vers M8, Erreurs : udevadm CRYPTSETUP_2.0 [Réglé]
Màj laborieuse redémarre sur "???" muets ou boucle en erreur
Retours d'expériences
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Reprise du message précédent
Quitte à revenir sur les anciens postes, pourquoi 12 partititions ? Pourquoi la racine ne fait que 1Go5 ?
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Normalement, l'initrd n'aurait jamais du être construit avant la mise à jour de la librairie cryptsetup.
Tonin Membre non connecté
-
- Voir le profil du membre Tonin
- Inscrit le : 02/07/2013
- Groupes :
Code BASH :
Consulter https://termbin.com/ycx1rpm -qa --last
Pour situer la date du "crash" qui n'en est pas vraiment un.
Code BASH :
journalctl -S "2021-07-30 14:52:00"
Code TEXT :
juil. 30 14:52:27 cftw.ddns.info systemd-journald[537]: Journal stopped -- Reboot -- août 01 06:33:44 cftw.ddns.info kernel: microcode: microcode updated early to revision 0xea, date = 2021-01-25
Combler le "trou de mémoire"
De quoi éclaircir cette histoire de "crash" : dans mes premiers posts où je raconte la chronologie, il y a trois points de suspensions [...] qui attestent un trou de mémoire. J'ai retrouvé quelques notes depuis (ci-dessous). Elles reprennent le début de l'histoire avant les [...] dans l'étape #A1# où est comblé le trou de mémoire. (En espérant ne pas avoir trop romancé, dans la confusion du feu de l'action parallèle). Je pense que c'est en #A1# que le système devient "non sain" et le init de biais :
Code TEXT :
#A1# su -c 'mgaapplet-upgrade-helper --new_distro_version=8' Échec de l'installation : conflit avec paquets hdf5_10-1 et postgresql13-plpgsql-13 less /root/.MgaOnline/gurpmi_upgrade_to_8_Adw27DYs.log désinstallation de ces paquets avant nouvelle tentative via mcc La désinstallation s'est bien déroulée mais a enchainé directement avec l'installation de paquets mga8 ! #A2# 3 transactions d'installation ont échoué Une erreur est survenue pendant l'installation des paquetages : postgresql-plpgsql >= 12.0 est nécessaire pour postgis-3.0.2-2.mga8.x86_64 libproj.so.19()(64bit) est nécessaire pour osm2pgsql-1.4.0-3.mga8.x86_64 libgdal.so.27()(64bit) est nécessaire pour mapnik-3.0.23-5.mga8.x86_64 libproj.so.19()(64bit) est nécessaire pour lib64mapnik3.0-3.0.23-5.mga8.x86_64 postgresql11-server = 11.12-1.mga8 est nécessaire pour postgresql11-contrib-11.12-1.mga8.x86_64 #A3# Afin de poursuivre la mise à jour, les paquetages suivants doivent être désinstallés : ///Les détails des problèmes de dépendance qui justifient la désinstallation ont été supprimés (mais disponible à la demande)/// java3d-1.5.2-15.mga7.x86_64 lib64php_common7-7.4.21-1.mga7.x86_64 lib64wx_gtk2u_adv3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_aui3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_core3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_gl3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_html3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_propgrid3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_qa3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_ribbon3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_richtext3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_stc3.0_0-3.0.4-7.mga7.x86_64 lib64wx_gtk2u_xrc3.0_0-3.0.4-7.mga7.x86_64 pgadmin3-1.22.2-3.mga7.x86_64 #A4# Vérouillage écran non désactivable. L'installation a-t-elle pu se terminer ? Dans le doute, poursuite d'éventuelles mise à jour via la console : urpmi --auto-update #A5# Quelques gros paquets ne trouvent pas assez de place sur partition /usr. Que faire ? #A6# Dévérouillage de l'écran à nouveau possible. Reprise de la main sur l'interface graphique. Message indiquant que l'installation s'est terminée correctement. Il reste à contrôler des fichiers de configuration : systemd-246.15-1.mga8.x86_64:/etc/systemd/journald.conf sddm-0.19.0-15.1.mga8.x86_64:/etc/sddm.conf openssh-server-8.4p1-2.1.mga8.x86_64:/etc/ssh/sshd_config php-ini-8.0.8-1.1.mga8.x86_64:/etc/php.ini phpmyadmin-5.1.1-1.mga8.noarch:/etc/phpmyadmin/config.inc.php --> voir les fichiers update_systemd, update_... pour les détails. En bref, rpmnew gardé en fichier principal. Des modifications à partir des fichiers diff seront réalisées. #A7# Redémarrer pour glibc et Cie.
C'est suite à cette séquence que le init altéré m'a empêché de démarrer mon système "non sain".
Il s'est passé quelque chose à la fin de #A1# qui a dû laisser en plan la mise à jour du init. Patatras...
Je dispose encore des listes des quelques 300 paquets désinstallés en deux vagues : orphelins, urmpe $(rpm -qa | grep mag7). Les derniers orphelins n'ont pas été supprimés. Parmi ceux désinstallés, se trouvaient étonnamment une centaine de paquets mga8.
Édité par Tonin Le 01/08/2021 à 13h04
Tonin Membre non connecté
-
- Voir le profil du membre Tonin
- Inscrit le : 02/07/2013
- Groupes :
En 2017, lors de l'acquisition d'une nouvelle "tour" faisant office d'ordinateur personnel comme de serveur, j'ai reproduit grosso modo la table de l'ancien disque. Pourtant la découpe en partition devait déjà passer de mode, pour le grand public tout au moins. Avec l'arrivée de lUEFI, la partition /boot de l'ancienne table a été remplacée par /boot/EFI. Ainsi début 2017 j'avais ceci :
Code BASH :
lsblk
Code TEXT :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 447,1G 0 disk ├─sda1 8:1 0 499M 0 part /boot/EFI ├─sda2 8:2 0 1,5G 0 part / ├─sda3 8:3 0 8,5G 0 part [SWAP] ├─sda4 8:4 0 1,9G 0 part /tmp ├─sda5 8:5 0 2,9G 0 part /var ├─sda6 8:6 0 9,1G 0 part /usr ├─sda7 8:7 0 1,5G 0 part /opt ├─sda8 8:8 0 274,4G 0 part /home ├─sda9 8:9 0 13,8G 0 part └─ 130,8G 0 free
/sda9 servant par exemple à tester l'installation d'autres systèmes
/home est resté à 275Gio de manière à ne pas dépasser la taille d'une partition miroir sur un disque de sauvegarde.
Je me suis vite senti à l'étroit dans /var et /usr, du coup /tmp a sauté et le SWAP maigri. Sans modifier sda1, sda2, sda8, j'ai recomposé la table des partitions, restauré les données sauvegardée de /var, /usr, /opt, et le serveur est reparti.
Code TEXT :
sda 8:0 0 447,1G 0 disk ├─sda1 8:1 0 499M 0 part /boot/EFI ├─sda2 8:2 0 1,5G 0 part / ├─sda3 8:3 0 1G 0 part [SWAP] ├─sda4 8:4 0 4G 0 part /var ├─sda10 8:10 0 2G 0 part /opt ├─sda5 8:5 0 17,4G 0 part /usr ├─sda8 8:8 0 274,4G 0 part /home └─sda9 8:9 0 13,8G 0 part └─ 130,8G 0 free
Aujourd'hui les 130Gio sont comme un terrain vague, servant à accueillir d'autres partitions pour d'autres tests de systèmes, ou comme point de montage pour des dossiers dont la sauvegarde n'est pas requise et dont le gonflement est problématique pour /home. Il y aurait pas mal de choses à repenser, et s'en donner le temps et la rigueur demande des efforts.
En espérant que cette histoire d'héritage répond aux interrogations.
Code BASH :
ExtraitsdfCode TEXT :
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 499M 18M 481M 4% /boot/EFI /dev/sda2 1,5G 486M 868M 36% / /dev/sda4 3,9G 1,6G 2,1G 44% /var /dev/sda10 2,0G 624M 1,2G 35% /opt /dev/sda5 18G 14G 3,2G 81% /usr /dev/sda8 270G 268G 2,1G 100% /home /dev/sda9 14G 13G 786M 95% (non sauvegardé boinc) /dev/sda6 79G 65G 11G 87% (non sauvegardé machines virtuelles) /dev/sda7 14G 5,8G 6,8G 46% (système de test, cauldron) (vide) 26G /dev/sda12 12G 7,6G 3,8G 68% (système "sain" de secours)
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Code TEXT :
kernel-desktop-latest-5.10.52-1.mga8.x86_64 ven. 30 juil. 2021 13:21:38 [...] lib64cryptsetup12-2.3.4-2.mga8.x86_64 dim. 01 août 2021 00:08:55 cryptsetup-2.3.4-2.mga8.x86_64 dim. 01 août 2021 00:08:55
Le système a bien installé le noyau construit l'initrd puis mis à jour la librairie cryptsetup.
Pour le découpage des partitions, maintenant /tmp est monté en mémoire, donc ça retombe à zero à chaque redémarrage.
Pour var, ce sont les logs qui bouffent énormément de place. Il faut configurer systemd pour lui demander de ne garder que X Mo de log, ou Y redémarrage.
Moi, je ne mets plus que 512Mo pour l'ESP, 2Go pour /boot, 50Go pour la racine, et le reste pour /home. Et parfois, je me retrouve tout de même avec une racine pleine, mais c'est souvent à cause d'un bogue dans une application en développement par exemple ^^ Donc cas extra-ordinaire.
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Citation :
Le système a bien installé le noyau construit l'initrd puis mis à jour la librairie cryptsetup.
Je dirais peut être...
En effet, c' est probablement la date de réinstallation, puisque ici, https://www.mageialinux-online.org/forum/topic-29195-1+m7-vers-m8-erreurs-udevadm-cryptsetup_2-0.php#m290308, il y a eu réinstallation du paquet, et le log indique une installation au 1er août ( donc potentiellement ce matin ( sauf fuseau horaire différent de celui que j' ai sur le forum))
Mais effectivement, il y a de fortes chances que l' initrd ait été construit avec une cryptsetup différente de celle du noyau ( en dépit de l' horaire bizarre)...
Édité par nic80 Le 01/08/2021 à 16h19
Tonin Membre non connecté
-
- Voir le profil du membre Tonin
- Inscrit le : 02/07/2013
- Groupes :
Code BASH :
Extraits :urpmi --replacepkgs php-dom date rpm -qa --last | head -n 1
Code TEXT :
dim. 01 août 2021 17:51:43 CEST php-dom-8.0.8-1.1.mga8.x86_64 dim. 01 août 2021 17:51:39
PS : a priori les systèmes "sain" et ex-"non sain" étaient calés de la même manière sur l'horloge du matériel.
Édité par Tonin Le 01/08/2021 à 18h09
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie