Bonjour,
Je viens de redémarrer un micro-serveur et je n’ai plus grand chose ; plus de réseau notamment 
C’est une Jessie stable.
Elle indique de partout « Failed to start LSB »
Le paquet lsb n’est pas installé ; c’est vérifié.
Comment je fais pour la réparer avec un CD ou un DVD ?
Comment se fait la procédure du chroot ?
La machine est en RAID6.
Merci
J’ai installé le paquet lsb et ses dépendances avec le mode rescue d’une Jessie sur DVD
Cela ne ma pas créé les éléments du répertoire /lib/lsb qui étaient demandés.
J’ai copié " à l’arrache " /lib/lsb avec une clef usb Fat32 et d’une autre distro.
J’ai l’impression que ça fonctionne…
Mais les droits de /lib/lsb sont de travers 
Merci MicP
Comment j’aurai pu faire en rescue pour implanter /lib/lsb ?
J’ai caché mon message car j’ai réalisé que le problème pourrait être plus compliqué que ça.
Mais si tu démarre avec un cd d’installation debian jessie netinstall (peut-être les autres aussi),
Il y a un menu rescue avec accès à un menu chroot
J’avais récement fait une série de captures d’écran montrant un chroot depuis netinstall,
mais je ne retrouve plus le fil. C’était peut-être sur un autre forum…
Mais si c’est un serveur qui utilise plusieurs systèmes de fichiers, il faudra peut-être les monter pour pouvoir procéder à une installation d’application.
Ton message que tu as caché me permet de rétablir les droits sur /lib/lsb -R ; je l’ai reçu dans mon email.
J’ai trouvé une Netinstall avec le mode rescue (comme indiqué dans un de mes messages ci-dessus)
Je n’ai pas utilisé de chroot
J’ai monté mes volumes logiques un par un (pas pratique le shell :P) après avoir précisé celui racine et le mode automatique du Raid en interactif.
Je n’ai coché que « Automatique » et aucune partition ; peut-être que l’ensemble aurait été monté correctement en cochant en plus toutes les partitions de mon Raid ; je ne sais pas.
En fait, ce qui reste, c’est quel paquet installe l’arborescence /lib/lsb ?
Installer le paquet lsb n’a pas suffit.
Je n’ai pas encore les notions relatives à LSB en tête mais le serveur avait un gros uptime et j’ai fait un update et un upgrade et puis là, au redémarrage, des erreurs pour de nombreux démarrages de services ; et rien d’utilisable.
C’est plutôt gênant ces “nouveautés” dont on ne peut pas se passer.
M’enfin bon… si c’est pour une bonne cause
Je ne m’occupe que très peu du système de ce micro-serveur quand il tourne ; j’ai systemd comme des coups de marteau en tête et je suis plutôt fan de Gentoo.
Merci de m’aider d’autant 
Je viens de te transmettre un MP
[quote=“r2mi, post:6, topic:71621”]
c’est quel paquet installe l’arborescence /lib/lsb
[/quote] Ils sont installés avec le système, ils ne sont pas dans un paquetage particulier.
Effectivement, ce paquetage n’est pas installé sur mon système bien que l’arborescence /lib/lsb soit présente
Ils sont installés avec le système, ils ne sont pas dans un paquetage particulier.
Même le système est composé de paquets.
Je ne suis pas un pratiquant de Debian mais il doit bien y avoir une commande qui indique le paquet responsable pour un des fichier de /lib/lsb
Merci MicP
Le topic est solved
Curieusement, /lib/lsb/init-functions.d/40-systemd ne fait pas partie du paquet.
Je puis penser que le paquet lsb-base est initalement conçu pour openrc et non systemd ;
ce n’est qu’une idée.
/lib/lsb/init-functions.d/40-systemd au jour de l’écriture ; Merci à MicP
# -*-Shell-script-*-
# /lib/lsb/init-functions
_use_systemctl=0
if [ -d /run/systemd/system ]; then
if [ -n "${DPKG_MAINTSCRIPT_PACKAGE:-}" ]; then
# If we are called by a maintainer script, chances are good that a
# new or updated sysv init script was installed. Reload daemon to
# pick up any changes.
systemctl daemon-reload || true
fi
# Redirect SysV init scripts when executed by the user
if [ $PPID -ne 1 ] && [ -z "${init:-}" ] && [ -z "${_SYSTEMCTL_SKIP_REDIRECT:-}" ]; then
case $(readlink -f "$0") in
/etc/init.d/*)
_use_systemctl=1
# Some services can't reload through the .service file,
# but can through the init script.
prog=${0##*/}
service="${prog%.sh}.service"
if [ "$(systemctl -p CanReload show $service 2>/dev/null)" = "CanReload=no" ] && [ "${1:-}" = "reload" ]; then
_use_systemctl=0
fi
;;
esac
else
export _SYSTEMCTL_SKIP_REDIRECT="true"
fi
fi
systemctl_redirect () {
local s
local rc
local prog=${1##*/}
local command=$2
case "$command" in
start)
s="Starting $prog (via systemctl)"
;;
stop)
s="Stopping $prog (via systemctl)"
;;
reload|force-reload)
s="Reloading $prog configuration (via systemctl)"
;;
restart)
s="Restarting $prog (via systemctl)"
;;
esac
service="${prog%.sh}.service"
# Don't try to run masked services. Don't check for errors, if
# this errors, we'll just call systemctl and possibly explode
# there.
state=$(systemctl -p LoadState show $service 2>/dev/null)
[ "$state" = "LoadState=masked" ] && return 0
[ "$command" = status ] || log_daemon_msg "$s" "$service"
/bin/systemctl $command "$service"
rc=$?
[ "$command" = status ] || log_end_msg $rc
return $rc
}
if [ "$_use_systemctl" = "1" ]; then
# Some init scripts use "set -e" and "set -u", we don't want that
# here
set +e
set +u
if [ "x$1" = xstart -o \
"x$1" = xstop -o \
"x$1" = xrestart -o \
"x$1" = xreload -o \
"x$1" = xforce-reload -o \
"x$1" = xstatus ] ; then
systemctl_redirect $0 $1
exit $?
fi
fiDésolé pour les lecteurs : j’ai confondu l’apparence des messages privés avec les messages de ce fil.
Merci à r2mi d’avoir reporté les messages et remis de l’ordre dans ce fil.
pas facile le web 3.0
Je réalise que j’avais oublié de te la donner celle là :
dpkg -S nomDuFichierContenuDansLePaquetDontOnRechercheLeNom
pour dpkg
-S
est l’option courte de
--search
Donc :
dpkg -S
donnera le même retour que :
dpkg --search
La solution à ce problème d’attributs consiste à créer un fichier tar.gz contenant les fichiers avant de le copier sur le système de fichiers FAT plutôt que d’y copier directement les fichiers qui perdront leurs attributs car le système de fichiers FAT ne peut pas les utiliser.
La décompression du fichier tar.gz sur un système de fichiers ext(2 ou3 ou 4) recréera les fichiers contenus avec leurs attributs et propriétaire.
Bonjour et Merci MicP pour cette indication. C’est utile.
Mais avec le serveur en rade et moi en panique, j’ai fait au plus … simple ?
J’ai remis lsb-base avec un –reinstall
Après, pour savoir comment j’ai pu perdre /lib/lsb - qui ne date pas d’hier certainement, il me semble que c’est une mauvaise manip ; un couper inutile et de travers (à la place d’un copier)
Je ne suis pas certain et je n’en saurai rien.
C’est réparé et c’est l’essentiel.
Merci à toi Mic
Bonjour r2mi
Merci pour le retour.
[quote=“r2mi, post:17, topic:71621”]
pour savoir comment j’ai pu perdre /lib/lsb -
[/quote]Je ne sais plus très bien moi non plus depuis quelle version ces fichiers existaient à cet emplacement.
Il est possible (il me semble) qu’ils aient été installés depuis la version whezzy (Debian 7).