Wheezy -> Jessie, serveur distant

Bonjour,

Hier j’ai effectué les manipulations suivantes pour passer de Wheezy à Jessie :
[ol][li]Désactivation des fichiers sources & preferences inutiles/supplémentaires[/li]
[li]Mise sur liste noire des paquets systemd (https://quentin.demouliere.eu/index.php?article39/mise-a-jour-de-debian-wheezy-vers-debian-jessie)[/li]
[li]apt-get update[/li]
[li]apt-get upgrade[/li]
[li]apt-get dist-upgrade[/li][/ol]

J’installe les nouvelles configurations proposées des paquets qui changent auxquels je ré-applique mes modifications.
Je complète ensuite la procédure par un redémarrage pour partir sur de nouvelles bases saines (les machines ne redémarrent habituellement jamais, sauf pour des besoins de noyaux ou des patchs critiques).

Sur mon serveur secondaire, tout s’est bien passé.

Sur mon primaire, j’avais oublié la liste noire avant mon premier “upgrade”. Je l’ai appliquée ensuite, en effectuant un nouvel “upgrade” avant le “dist-upgrade”. J’ai vérifié que les 2 seuls paquets systemd étaient libsystemd0 (nécessaire pour certains paquets applicatifs) et le paquet *-login, présent lui aussi sur la machine secondaire quand bien même celle-ci utilise sysvinit. Pas d’inquiétude jusqu’alors.

Mon problème est que la machine principale refuse de démarrer. Pas d’entrée de log dans /var/log/messages ou /var/log/dmesg, le boot ne semble même pas arriver à monter les disques…
J’ai tenté d’ajouter init=/lib/sysvinit/init à mon code de boot par crainte que systemd n’aie été configuré dans grub suite à ma fausse manipulation lors du premier “upgrade”, sans succès.

La machine est distante, donc pas d’accès à la console locale…
Pour accéder aux logs, je démarre sur l’option de secours de mon hébergeur qui charge une distribution en RAM et me permet de monter les disques à la main, où je vais ensuite fouiller les fichiers pour tenter de comrpendre ce qui s’est passé.

Cette machine est très importante.
Comment diagnostiquer le problème/la rétablir ?

Merci par avance pour l’aide que vour pourriez m’apporter…

Salut,

Serait plus juste.

[code][07:24:10] ~ # cat /etc/apt/preferences.d/00-no-systemd.pref
Package: systemd
Pin: release o=Debian
Pin-Priority: -1

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1

Package: libpam-systemd
Pin: release o=Debian
Pin-Priority: -1

Package: libsystemd-daemon0
Pin: release o=Debian
Pin-Priority: -1

Package: libsystemd-id128-0
Pin: release o=Debian
Pin-Priority: -1

Package: libsystemd-journal0
Pin: release o=Debian
Pin-Priority: -1

Package: udisks2
Pin: release o=Debian
Pin-Priority: -1

[07:24:26] ~ #[/code]

Tu (re)trouveras les infos de démarrage (kernel) en [mono]syslog[/mono] et [mono]kern.log[/mono].

Si je ne m’abuse, [mono]systemd[/mono] et ses acolytes ne voient le jour que sur un [mono]apt-get dist-upgrade[/mono] ou [mono]aptitude-full-upgrade[/mono].

Ces retours, stp.

$ dpkg -l |grep systemd $ dpkg -l |grep sysvinit

[quote=“Berbe”]La machine est distante, donc pas d’accès à la console locale…
Pour accéder aux logs, je démarre sur l’option de secours de mon hébergeur qui charge une distribution en RAM et me permet de monter les disques à la main, où je vais ensuite fouiller les fichiers pour tenter de comrpendre ce qui s’est passé.[/quote]
Je suis donc incapable de lancer des commandes inspectant son environnement, j’ai juste accès à la configuration et aux logs a posteriori par un boot de secours (distribution “live”) d’où je monte mes disques.

Je n’ai aucune entrée depuis l’arrêt initial de la machine suite à la mise à jour dans :
[ul][li]messages[/li]
[li]dmesg[/li]
[li]syslog[/li]
[li]kern.log[/li][/ul]

Pas évident pour déboguer…

[EDIT]
Après avoir fait un chroot sur la partition système :

[code]# dpkg -l | grep systemd
ii libsystemd-login0:amd64 215-17 amd64 systemd login utility library (deprecated)
ii libsystemd0:amd64 215-17 amd64 systemd utility library

dpkg -l | grep sysvinit

ii sysvinit 2.88dsf-59 amd64 System-V-like init utilities - transitional package
ii sysvinit-core 2.88dsf-59 amd64 System-V-like init utilities
ii sysvinit-utils 2.88dsf-59 amd64 System-V-like utilities[/code]

Durant la rédaction j’avais oublié ce détail, que importe.
Pour reprendre la main il te suffit de chrooter (une procédure on ne peut plus simple) ton système selon le File System en place, via ton accès ssh (root).
Depuis le mode rescue, ces retours seront utiles pour le dit chroot.

[code]# mount

blkid

fdisk -l

parted -l ### << si ce dernier est installé[/code]

[quote=“Berbe”]

[EDIT]
Après avoir fait un chroot sur la partition système :

[code]# dpkg -l | grep systemd
ii libsystemd-login0:amd64 215-17 amd64 systemd login utility library (deprecated)
ii libsystemd0:amd64 215-17 amd64 systemd utility library

dpkg -l | grep sysvinit

ii sysvinit 2.88dsf-59 amd64 System-V-like init utilities - transitional package
ii sysvinit-core 2.88dsf-59 amd64 System-V-like init utilities
ii sysvinit-utils 2.88dsf-59 amd64 System-V-like utilities[/code][/quote]
Nous nous sommes croisés.
[mono]systemd[/mono] n’est pas au rendez-vous, c’est déjà un début.
Puisque le chroot est en place, tu accèdes aux logs antérieurs au mode rescue et du dist-upgrade, selon la configuration par défaut ou non de [mono]logrotate[/mono].

Suivant les conseils que l’on m’a donné, j’ai suivi ceci : https://www.debian.org/releases/jessie/amd64/release-notes/ch-upgrading.fr.html#purge-removed-packages.
Il reste 4 paquets faisant de la résistance (une sombre histoire de fichier dovecot-common qui devraient être attachés à dovecot-core).

Je n’aime pas trop trafiquer mon système en chroot, je ne connais pas l’étendue de ce qui n’est pas initialisé, et créer les points de montage à la main pour cacher la misère ne m’aide guère à me mettre à l’aise.

Comment faire sans log ? Je ne sais pas à quelle étape mon système est coincé ni ce qui ne va pas…

[quote=“Berbe”]Je n’aime pas trop trafiquer mon système en chroot

Comment faire sans log ? Je ne sais pas à quelle étape mon système est coincé[/quote]
Sur une machine distante et sans un [mono]chroot[/mono] opérationnel, je ne vois vraiment pas comment tu vas pouvoir récupérer une installation endommagée sans avoir recours au service technique de ton fournisseur.

[quote=“BelZéButh”]

[code]# mount

blkid

fdisk -l

parted -l ### << si ce dernier est installé[/code][/quote]

?