Repartitionnement - Suite et (heureuse) fin

Le 14/04/2018 à 12:35, Jo Engo a écrit :

Je note, avant de tout oublier, si ça vous intérese, lisez,

Merci pour le retour.


--
jp willm
http://perso.orange.fr/willms/index.html

Le 14/04/2018 à 12:35, Jo Engo a écrit :

- j'ai supprimmé la partition /opt dont je n'ai pas l'usage et j'ai
oublié de rectifier fstab regimbage au démarrage, il (debian) me demande
le mot de passe de root que j'ai dû définir puis oublier ^^ vu que je me
sers de sudo, je ne me souviens plus de comment je m'en suis sorti en

C'est le danger de sudo, c'est pour cela qu'il faut initialiser "root"
avec un mot de passe non trivial mais le noter soigneusement.

Cependant on a toujours la possibilité de booter d'un live CD et de
venir effacer le mot de passe root dans le fichier /etc/shadow

Le 15-04-2018, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5ad328f0$0$7197$426a74cc@news.free.fr>) :

Le 14/04/2018 à 12:35, Jo Engo a écrit :

- j'ai supprimmé la partition /opt dont je n'ai pas l'usage et j'ai
oublié de rectifier fstab regimbage au démarrage, il (debian) me demande
le mot de passe de root que j'ai dû définir puis oublier ^^ vu que je me
sers de sudo, je ne me souviens plus de comment je m'en suis sorti en

C'est le danger de sudo, c'est pour cela qu'il faut initialiser "root"
avec un mot de passe non trivial mais le noter soigneusement.

Cependant on a toujours la possibilité de booter d'un live CD et de
venir effacer le mot de passe root dans le fichier /etc/shadow

Ou plus simplement corriger directement /etc/fstab à partir du live CD
puisque c'est le vrai problème.

Ceci dit j'ai également constaté ce comportement que je qualifierai de
stupide de la part de Debian mais qui est probablement un comportement
qu'on retrouve chez les autres "grandes" distributions (je crois que
systemd est le véritable coupable mais je n'ai pas vérifié):
- L'OS refuse du booter si une partition renseignée dans /etc/fstab
est inaccessible par l'OS (genre partition inexistante sur le disque
ou point de montage manquant).

Autant ça peut se justifier pour une parition "système" (/, /usr/, /var/,
/lib, etc) auquel cas le système crashera de toutes façons, autant pour
une partition /home/user/pr0n j'ai des doutes quant à la pertinence de
ce comportement.

Je comprends bien que le risque est de démarrer un système avec une
partition manquante et donc que des traitements automatisés *pourraient*
faire des dégats mais pour moi c'est se tromper de problème.

Si un traitement flingue un système (ou des corrompt datas) parce qu'il
lui manque le système de fichiers sur lequel il doit travaille alors c'est
le traitement qui est fautif et qui doit être corrigé.

Empecher le système de booter pour si peu c'est emmerder le sysadmin
plus que nécessaire et se laver facilement les mains en lui refilant le
bébé.

--
Maintenant voila ton père déguisé en indien
Avec une plume dans le fion et ses cartes d'Indochine.
S'il veut refaire sur moi ce qu'il a fait au Tonkin,
Bientôt je ne serai plus qu'une vieille tache d'hémoglobine.
-- H.F. Thiéfaine, Enfermé dans les cabinets

Le 15/04/2018 à 13:33, Doug713705 a écrit :

Ceci dit j'ai également constaté ce comportement que je qualifierai de
stupide de la part de Debian mais qui est probablement un comportement
qu'on retrouve chez les autres "grandes" distributions (je crois que
systemd est le véritable coupable mais je n'ai pas vérifié):
- L'OS refuse du booter si une partition renseignée dans /etc/fstab
est inaccessible par l'OS (genre partition inexistante sur le disque
ou point de montage manquant).

Il me semble que ce comportement est apparu avec systemd. Auparavant
l'échec d'un montage était ignoré.

Autant ça peut se justifier pour une parition "système" (/, /usr/, /var/,
/lib, etc) auquel cas le système crashera de toutes façons, autant pour
une partition /home/user/pr0n j'ai des doutes quant à la pertinence de
ce comportement.

Et comment le système sait-il que ce montage n'est pas essentiel si
l'administrateur ne lui a pas dit en ajoutant l'option "nofail" dans fstab ?

lui manque le système de fichiers sur lequel il doit travaille alors c'est
le traitement qui est fautif et qui doit être corrigé.

Pas d'accord. C'est le rôle du système d'init de tout mettre en place
pour que les traitements puissent fonctionner. Chacun son rôle, sinon on
n'a pas fini...

Le 15-04-2018, Pascal Hambourg nous expliquait dans
fr.comp.os.linux.configuration
(<pavf3u$28ot$1@saria.nerim.net>) :

Le 15/04/2018 à 13:33, Doug713705 a écrit :

Ceci dit j'ai également constaté ce comportement que je qualifierai de
stupide de la part de Debian mais qui est probablement un comportement
qu'on retrouve chez les autres "grandes" distributions (je crois que
systemd est le véritable coupable mais je n'ai pas vérifié):
- L'OS refuse du booter si une partition renseignée dans /etc/fstab
est inaccessible par l'OS (genre partition inexistante sur le disque
ou point de montage manquant).

Il me semble que ce comportement est apparu avec systemd. Auparavant
l'échec d'un montage était ignoré.

Le bon vieux temps ;-)

Autant ça peut se justifier pour une parition "système" (/, /usr/, /var/,
/lib, etc) auquel cas le système crashera de toutes façons, autant pour
une partition /home/user/pr0n j'ai des doutes quant à la pertinence de
ce comportement.

Et comment le système sait-il que ce montage n'est pas essentiel si
l'administrateur ne lui a pas dit en ajoutant l'option "nofail" dans fstab ?

On pourrait peut-être inverser le problème.
En l'absence de nofail, ne pas reporter les éventuelles erreurs.
En présence nofail et si le device n'est pas dispo alors on arrête tout.

Du coup il faudrait renommer nofail en qqchose comme halt_on_fail.

lui manque le système de fichiers sur lequel il doit travaille alors c'est
le traitement qui est fautif et qui doit être corrigé.

Pas d'accord. C'est le rôle du système d'init de tout mettre en place
pour que les traitements puissent fonctionner. Chacun son rôle, sinon on
n'a pas fini...

Mais init n'a aucun moyen de savoir ce que sont ces traitements, ni
quelles sont les éventuelles conséquences de leur dysfonctionnements.

De mon point de vue la séquence pourrait être un truc comme:
- Montage des partitions
- Demarrage des services
- Un service a besoin que telle partition soit montée pour s'éxécuter
(pré-requis)
- La partition concernée n'est pas montée
- Le service n'est pas démarré (*mais* le système est malgré tout up et
on peut investiguer dessus sansavoir à retrouver un mot de passe root
que personne n'utilise. Sur de l'urgent c'est toujours relou.

Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
service défaillant plutôt que d'empécher le démarrage du système complet
pour un problème lié à un seul des services qu'il héberge.

--
Nous vivions nos vertiges dans des vibrations folles
Et gerbions nos enzymes en nous gueulant : moteur !
Mais entre deux voyages, entre deux verres d'alcool,
Nous n'avions pas le temps de décompter nos heures.
-- H.F. Thiéfaine, Exil Sur planète fantôme

Doug713705 , dans le message <pavhd6$1mr$1@golgoth99.redatomik.org>, a
écrit :

Il me semble que ce comportement est apparu avec systemd. Auparavant
l'échec d'un montage était ignoré.

Le bon vieux temps ;-)

Je n'ai pas l'impression que ce soit vrai.

Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
service défaillant plutôt que d'empécher le démarrage du système complet
pour un problème lié à un seul des services qu'il héberge.

Tu as raison.

Et tu sais quel projet a pour objectif de réaliser exactement ça ?
systemd.

Le 15/04/2018 à 14:43, Doug713705 a écrit :

Le 15-04-2018, Pascal Hambourg nous expliquait :

Et comment le système sait-il que ce montage n'est pas essentiel si
l'administrateur ne lui a pas dit en ajoutant l'option "nofail" dans fstab ?

On pourrait peut-être inverser le problème.
En l'absence de nofail, ne pas reporter les éventuelles erreurs.
En présence nofail et si le device n'est pas dispo alors on arrête tout.

L'ennui, c'est que ça a été défini d'une certaine façon et je pense que
ça date de bien avant systemd puisque la page de manuel de mount
mentionne l'option "nofail" depuis au moins Debian 6 "Squeeze" (c'est ce
que j'ai de plus ancien encore installé, flemme de regarder avant).

Pas d'accord. C'est le rôle du système d'init de tout mettre en place
pour que les traitements puissent fonctionner. Chacun son rôle, sinon on
n'a pas fini...

Mais init n'a aucun moyen de savoir ce que sont ces traitements, ni
quelles sont les éventuelles conséquences de leur dysfonctionnements.

J'hésite entre deux réponses :

a) Ce n'est pas le problème d'init. Il se contente de monter ce qu'on
lui dit de monter, et si ça échoue, il boude et l'administrateur se
débrouille.

b) Là encore, on peut informer l'init de cette dépendance. Il me semble
que systemd permet de définir des dépendances entre unités, et crée une
unité pour chaque montage.

Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
service défaillant plutôt que d'empécher le démarrage du système complet
pour un problème lié à un seul des services qu'il héberge.

Ça se défend. Voir ma réponse b).

Le 15-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad34e2e$0$12248$426a74cc@news.free.fr>) :

Doug713705 , dans le message <pavhd6$1mr$1@golgoth99.redatomik.org>, a
écrit :

Il me semble que ce comportement est apparu avec systemd. Auparavant
l'échec d'un montage était ignoré.

Le bon vieux temps ;-)

Je n'ai pas l'impression que ce soit vrai.

J'avoue que mon avis est basé sur des impressions plus que des faits.

Cependant, avant une petite mésaventure sur une Debian récente sur laquelle
j'avais supprimé une partition en oubliant de modifier le fstab, il ne
m'était *jamais* arrivé de voir un système se bloquer pour un problème
de partition "anodine" manquante.

C'était d'autant plus dommage que le mot de passe root faisait 42 chars
de long et que le clavier était en qwerty.

Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
service défaillant plutôt que d'empécher le démarrage du système complet
pour un problème lié à un seul des services qu'il héberge.

Tu as raison.

C'est toujours bon de l'entendre dire :D

Et tu sais quel projet a pour objectif de réaliser exactement ça ?
systemd.

Ah mais je ne dis pas qu'il ne peut pas y avoir de bonnes idées parmi cet
amoncellement de n'importe quoi plus ou moins brinquebalant appelé
systemd ;-)

Par ailleurs il ne faudrait que quelques lignes de bash (probablement
moins de 10 lignes) pour obtenir le même comportement avec SysV ou un init
BSD-style.

Pour le coup attendre systemd pour résoudre ce "problème" c'est juste WTF!

--
Mais je remonte mon col, j'appuie sur le starter
Et je vais voir ailleurs, encore plus loin ailleurs...
-- H.F. Thiéfaine, Autoroutes jeudi d'automne

Doug713705 , dans le message <pavkon$1mr$2@golgoth99.redatomik.org>, a
écrit :

Cependant, avant une petite mésaventure sur une Debian récente sur laquelle
j'avais supprimé une partition en oubliant de modifier le fstab, il ne
m'était *jamais* arrivé de voir un système se bloquer pour un problème
de partition "anodine" manquante.

Je ne me rappelle pas un problème de ce genre non plus. L'information
est-elle fiable ?

Ah mais je ne dis pas qu'il ne peut pas y avoir de bonnes idées parmi cet
amoncellement de n'importe quoi plus ou moins brinquebalant appelé
systemd ;-)

Non, l'amoncellement de n'importe quoi plus ou moins brinquebalant,
c'est SysV init.

Par ailleurs il ne faudrait que quelques lignes de bash (probablement
moins de 10 lignes) pour obtenir le même comportement avec SysV ou un init
BSD-style.

Il faudrait largement plus de dix lignes pour obtenir quelque chose qui
marche à moitié dans les cas faciles. On le sait, les gens ont essayé.

Le 15-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad3bf1c$0$7184$426a34cc@news.free.fr>) :

Cependant, avant une petite mésaventure sur une Debian récente sur laquelle
j'avais supprimé une partition en oubliant de modifier le fstab, il ne
m'était *jamais* arrivé de voir un système se bloquer pour un problème
de partition "anodine" manquante.

Je ne me rappelle pas un problème de ce genre non plus. L'information
est-elle fiable ?

Vue de mes yeux et résolue par moi même en supprimant la ligne fstab concernée
le tout après un facedesk de circonstance.

Ah mais je ne dis pas qu'il ne peut pas y avoir de bonnes idées parmi cet
amoncellement de n'importe quoi plus ou moins brinquebalant appelé
systemd ;-)

Non, l'amoncellement de n'importe quoi plus ou moins brinquebalant,
c'est SysV init.

C'est vrai, rien ne vaut un système init BSD-style :)

Par ailleurs il ne faudrait que quelques lignes de bash (probablement
moins de 10 lignes) pour obtenir le même comportement avec SysV ou un init
BSD-style.

Il faudrait largement plus de dix lignes pour obtenir quelque chose qui
marche à moitié dans les cas faciles. On le sait, les gens ont essayé.

Je ne parle pas de faire une bouse générique autant imbitable que non
maintenanble mais d'un script maison adapté à la situation rencontrée et
pas à celle du voisin.

En essayant de résoudre tous les cas Systemd échouera sur les mêmes éccueils
notamment le plus gros:
- Définir tous les cas possibles.

Il est totalement incensé de vouloir résoudre tous les cas et fournir un
outil qui n'en résoudra que 99% est un remède pire que le mal car il
rendra difficle voire impossible la résolution du dernier pourcent.

La seule solution envisageable est de laisser le sysadmin en charge du
bouzin faire ce pourquoi il a été engagé.

Enfin, c'est mon point de vue.
--
Orgie de silence et de propreté ou celui qui aurait encore
Quelque chose à dire préfère se taire plutôt que d'avoir
À utiliser leurs formulaires d'autorisation de délirer...
-- H.F. Thiéfaine, Autorisation de délirer