Discussion :

[Jipété]

Bonjour,

Pour des besoins ponctuels de tests, j'envisage de mettre en place un script qui va analyser la sortie de mount (filtrée sur "/dev/sd" pour voir l'ordre des disques car systemd sur ce coup-là c'est du grand n'importe quoi.)
J'ai une piste pour forcer une certaine régularité dans le nommage des disques mais il faut que je teste ça intensément, d'où le script.

Et dans le script il y a un contrôle :
- disques en vrac --> on loggue et on arrête le script -- facile.
- disques ok --> on loggue et on reboote -- comment arrêter le script si besoin ?

Parce que si ma combine de forçage des noms est bonne, la machine ne va plus s'arrêter de rebooter et ça, non ! Faut quand même que je puisse reprendre la main, de temps en temps.

J'avais donc pensé à un appui sur une touche pendant la séquence de boot (qui va activer mon script), mais est-ce qu'une touche peut être prise en compte alors qu'il n'y a pas encore d'utilisateur loggué ?
C'est la question qui me turlupine -- oui, je sais, je n'ai qu'à tester, mais si de base la réponse est négative, à quoi bon passer du temps dessus ?

Vous feriez comment, vous ?
Merci pour les retours,

[N_BaH]

Bonjour,

([...]voir l'ordre des disques car systemd sur ce coup-là c'est du grand n'importe quoi.)

il me semble que systemd fait avec ce que lui donne "le BIOS", sinon ça ferait ça sur toutes les machines.

pour ton script , utilise les UUID, ou des labels (ces derniers pouvant être définis après formatage)

[Jipété]

il me semble que systemd fait avec ce que lui donne "le BIOS", sinon ça ferait ça sur toutes les machines.

il fait avec ce que le bios lui donne, oui, mais il fait ça en parallèle (c'est le but) et à quelques poullièmes de nanosecondes près je me retrouve des fois avec sdb1 monté sur / alors que ça devrait être sda1.
Et le plus dément, c'est que si df ou parted ou mount ou d'autres remontent n'importe quoi, ls / va m'afficher les bons fichiers de la racine, que la partition qui y est montée soit sda1 ou sdb1 -- un mystère complet.

Et ça doit faire ça sur toutes les machines multi-disques, c'est connu sur le web (pas de liens sous la main). Je propose qu'on ne fasse pas une digression vers systemd, je pense avoir trouvé une manière de rédiger les fichiers .mount qui devrait convenir, d'où le test intense.

pour ton script, utilise les UUID, ou des labels (ces derniers pouvant être définis après formatage)

Même remarque que précédemment.

La question porte bien sur la manière d'arrêter un test lancé au boot, par un utilisateur pas encore loggué.

[disedorgue]

Perso, la piste que je suivrais, c'est de me baser sur la séquence de boot:
2 boot possible, le défaut, fait le test intensif, l'autre ne le fait pas et me donne la main pour pouvoir débrancher le test.

[N_BaH]

sur de nombreuses de mes machines, il y a plusieurs disques, et ce désordre erratique n'est apparu qu'une seule fois.
donc, ça existe. c'est décrit sur le net. mais ça ne concerne pas toutes les machines.
tu le sais, les manifestations de l'existence d'un événement, qui nous touche aussi, provoque un effet loupe, qui donne l'impression de masse et de proximité. Mais ce n'est qu'une impression. « it's just an illusion »


si, finalement, le montage est correct, alors quel est le problème ?
si tu as des scripts qui se réfère au nommage des disques (sda sdb ...) réécris-les en les faisant se référer aux UUID; ils sont disponibles dans l'absolu (càd même après transfert d'une machine à une autre).

dans le brouillard, je n'avance pas.

[Jipété]

Perso, la piste que je suivrais, c'est de me baser sur la séquence de boot:
2 boot possible, le défaut, fait le test intensif, l'autre ne le fait pas et me donne la main pour pouvoir débrancher le test.

Je ne vois pas bien ce que tu veux dire. Ce que je pense, moi, c'est de ne rien changer, juste rajouter un script qui se lance au boot et qui va regarder qui est monté sur / puis test : c'est sda1 (= ok) alors reboot, et comme ça ad vitam æternam ou tout au moins, jusqu'à un test en erreur (sdb1 monté sur /), tout ça dans une machine virtuelle, avant de passer à la vraie vie.

Mais si ma correction est bonne, il n'y aura plus d'erreur et ça serait bien que je puisse prendre la main histoire d'arrêter proprement la machine avant d'aller au dodo.

Et donc mon interrogation c'est comment prendre la main s'il n'y a pas d'erreur. L'idée d'appuyer sur une touche, c'est pour signaler au test qu'il ne doit pas rebooter,

mais ça ne concerne pas toutes les machines.

si tu as des scripts qui se réfèrent au nommage des disques (sda sdb ...) réécris-les en les faisant se référer aux UUID; ils sont disponibles dans l'absolu (càd même après transfert d'une machine à une autre).

D'accord.
Mais la mienne est concernée, et je ne voudrais pas qu'un jour, voulant remettre à zéro un disque de données je me retrouve à le faire sur le disque système avec pourtant dd if=/dev/zero of=/dev/sdb juste le jour où systemd a croisé sdb et sda, loi de Murphy oblige, tu vois le truc ?
Et je ne sais pas comment faire travailler dd ou parted ou tout un tas d'autres outils avec des uuid quand leur man spécifie /dev/sdx…

Donc il me faut bosser et étudier et tester jusqu'à ce qu'il n'y ait plus ce genre d'inversion.

[Jipété]

Ah la la…

Je recommence depuis le début : systemd gère en parallèle le mount des disques quand il y en a plusieurs, résultat, des fois sda1 est le petit disque système (ce qui est correct) et des fois sda1 est un gros disque de data (comment ça boote ensuite est un mystère pour moi).

Pour stabiliser ce fonctionnement aléatoire, foutraque et pifométrique, chacun y va de ses combines sur le web, entre les bidouilles dans fstab et la création de fichiers .mount, paramétrés avec des flags "after", "before", "requires", bref, la cuisine (imbouffable !) de systemd.

En ce qui me concerne, je pense qu'avec mes fichiers .mount je suis bon. Mais avant de crier victoire, il faut tester, tester, et encore tester.
Et comme le nom des disques est déterminé au boot (ou reboot), ben c'est ce que je dois faire, un grand nombre de fois.

Si par exemple un boot prend 15 secondes, je pourrai en faire 4 par minute, soit 240 à l'heure. Et si au bout de 4 heures aujourd'hui, de 4 heures demain et pareil après-demain et le jour qui suit, je n'ai pas eu de changement de nom, je considérerai que mon fix (mes fichiers de mount) est correct : plus qu'à le mettre en prod' dans la machine de la vraie vie.

Mais pour rebooter la machine 240 fois en une heure, autant faire tourner un script, prévu pour démarrer au boot, tester le nom des disques et s'arrêter si un changement de nom apparaît par rapport à ce qui est prévu ou faire rebooter la machine si les noms sont corrects.

Le question est : comment arrêter ce script s'il ne s'arrête pas tout seul (sur détection d'un défaut), étant entendu qu'il n'y a pas de user loggué pendant le boot ?

[Christophe]

La solution est l'utilisation des UUID ou des labels, comme déjà indiqué. En général ce problème survient plutôt avec les périphériques USB. Si comme tu le dis, systemd gère en parallèle le montage, c'est pas surprenant que tu es ce problème. systemd doit prendre le 1er device libre, et si il met un temps différent à faire ses traitements parallèles pour x raisons, tu te retrouve avec cette situation de devices dont l'ordre a changé.

Tu pars dans une mauvaise direction. Utiliser les UUID ou les labels est sûr et rapide, utiliser ta solution va te prendre un temps inconnu et un résultat inconnu.

[Jipété]

Utiliser les UUID ou les labels est sûr et rapide,

Sauf quand ça part en vrac -- ne me demandez pas pourquoi, mais c'est comme ça, je l'ai constaté. Et je vous l'ai montré : des fois sdb1 est monté sur /, là où devrait être monté sda1, dont la connexion par fstab n'a pas bougé depuis l'installation de la machine.

Alors peut-être que les manières de les connecter ont été écrites par des singes et avec les pieds, et que google m'a remonté celles-là en premier, toujours est-il que ce que j'ai mis en place n'est pas fiable à 100 %.

À partir de cette constatation, j'en ai conclu qu'il me fallait agir autrement, et mine de rien, ça fait des mois que je suis là-dessus, pas à temps complet je vous rassure, mais les études des tutos du web et leur compilation pour synthèse vers quelque chose de compréhensible, reproductible et maintenable n'est pas une mince affaire.

---
et pour mon script, j'ai pensé qu'en fin d'exécution, si les disques sont correctement nommés (et donc reboot à venir pour re-test), je lui rajoute 15 secondes à ne rien faire, ce qui me permettra de me logguer en ssh depuis la machine à côté et hop !, kill du process du script par son id remontée par une ligne en plus dans le .bashrc et ça ira bien.

[N_BaH]

des fois sdb1 est monté sur /, là où devrait être monté sda1, dont la connexion par fstab n'a pas bougé depuis l'installation de la machine.

montre-le nous ton /etc/fstab.

[disedorgue]

Et avec aussi le résultat de la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

systemctl status *mount | sed -n '/\/etc\/fstab/,/Where:/p'

[Jipété]

montre-le nous ton /etc/fstab.

Le voici, mais il est plein de commentaires car je ne l'utilise plus pour les gros disques -- ceci étant dit, j'ai conservé les lignes, comme ça on peut voir ce que j'ai tenté :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
cat /etc/fstab
# info moi : "discard" pour trimmer les ssd -- présent d'origine, et probablement 
# pas une bonne idée, voir https://www.spinics.net/lists/raid/msg40924.html, donc zappé
 
### ssd
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
#UUID=99dc8d6c-8674-4c7d-b27f-7cd860bdd63f /              ext4    defaults,noatime,discard 0 1
UUID=99dc8d6c-8674-4c7d-b27f-7cd860bdd63f /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
 
 
#### premier dd, sdb -- les datas
##/dev/sdb1 : 1,6 To
##/dev/sdb1	/data_large	ext4	relatime,rw,auto,users,exec	0	2
## 11-10/2020, suite conseils Alain suite micmac sda1<>sdb1, passage aux uuid.
## 11/11/2020 : mais ça ne change rien... Création d'un nouveau noyau avec 6 modifications, à suivre...
#UUID=83452e91-8384-45c3-b2c7-4315904d03fa	/data_large	ext4	relatime,rw,auto,users,exec	0	2
 
#### second  dd, sdc -- les sauvegardes des datas
##/dev/sdc1 : 1,6 To
##/dev/sdc1	/dbck_large	ext4	relatime,rw,auto,users,exec	0	2
#UUID=0e65ae8e-d816-4ffc-a210-e616717de2fe	/dbck_large	ext4	relatime,rw,auto,users,exec	0	2
 
## lsblk -f
## |--sdb1 ext4   data        83452e91-8384-45c3-b2c7-4315904d03fa    1,5T     1% /data_large
##
## |--sdc1 ext4   backup      0e65ae8e-d816-4ffc-a210-e616717de2fe    1,5T     0% /dbck_large
 
# (désolé, le forum accepte les codes des caractères semi-graphiques dans la fenêtre de saisie mais pas à l'affichage)
 
# 25/12/2020 :
### premier dd, sdb -- les datas ##########################################################
##/dev/sdb1 : 1,6 To
#####/dev/sdb1	/data_large	ext4	relatime,rw,x-systemd.requires-mounts-for=/,auto,users,exec	0	2
 
### second  dd, sdc -- les sauvegardes des datas ############################################
##/dev/sdc1 : 1,6 To
#/dev/sdc1	/dbck_large	ext4	relatime,rw,x-systemd.requires-mounts-for=/data_large,auto,users,exec	0	2
#####/dev/sdc1	/dbck_large	ext4	relatime,rw,x-systemd.requires-mounts-for=/,auto,users,exec	0	2
 
# /                                     /dev/sda1        ext4       rw,noatime
# |-/data_large                         /dev/sdb1        ext4       rw,nosuid,nodev,relatime
# |-/dbck_large                         /dev/sdc1        ext4       rw,nosuid,nodev,relatime
#
# mais pâté le 27/12 ! c'est sdc1 qui est monté sur "/" ! 
# et le 28 au soir c'est sdb1 qui est monté sur / 
# en fait c'est le ssd qui est nommé sdb1 (vu grâce à df) et systemd n'en a rien à foutre de l'uuid...
# et l'option x-systemd.requires-mount-for est inefficace, on dirait bien.
#
# 26/02/2021 : toujours aussi merdique -- ce matin encore, sdb1 est monté sur /

Ce qui est intéressant, c'est cette dernière ligne car en février j'avais basculé en mode service_qui_lance_un_script_de_montage
Vous voulez voir ce script ? Y a qu'à demander :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#!/bin/bash
 
### premier dd, sdb -- les data
##/dev/sdb1 : 1,6 To
mount -t ext4 -o rw,nosuid,nodev,relatime LABEL=data /data_large
 
### second  dd, sdc -- les sauvegardes des data
##/dev/sdc1 : 1,6 To
mount -t ext4 -o rw,nosuid,nodev,relatime LABEL=backup /dbck_large

Et avec aussi le résultat de la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

systemctl status *mount | sed -n '/\/etc\/fstab/,/Where:/p'

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 3h 51min ago
    Where: /
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 3h 51min ago
    Where: /tmp

Et dans la foulée, je propose ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
$ systemctl status *mount | sed -n '/\/etc\/fstab/,/What:/p'
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 4h 0min ago
    Where: /
     What: /dev/sda1
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 4h 0min ago
    Where: /tmp
     What: tmpfs

Maintenant, plus qu'à attendre que lors d'un reboot ça soit sdb1 qui soit monté sur "/", et je relancerai ces deux commandes…

[Jipété]

Bonsoir,

Bonne, très bonne nouvelle : j'ai réussi à avoir un fichier fstab (pour sda1, monté sur /) et deux fichiers .mount (pour sdb1, monté sur /data, et sdc1, monté sur /dbck) sans plus de problèmes, la preuve c'est que depuis hier mes tests de reboot si sda1 est bien monté sur / en sont à 867 itérations et 0 (zéro, oui oui !) erreur si je fais abstraction des deux boulettes qui m'ont mis des bâtons dans les roues :

1^re boulette, le contrôleur de disque où était connecté sda était un "contrôleur IDE" quand les deux disques complémentaires étaient branchés sur un "contrôleur SATA". Le fait de mettre tout ce petit monde sur SATA a réglé le souci des montages aléatoires, hé ouais

2^e boulette, mais je n'en ai pas parlé car ça date d'hier, ça a été réglé aujourd'hui et ça dépend de VirtualBox, qui permet des choses engendrant des catastrophes : voulant gagner du temps et de l'espace disque, j'ai eu la mauvaise idée de partager les 2 gros disques de test entre plusieurs machines mais si ça fonctionne le temps de la configuration, ça ne survit absolument pas à un simple arrêt de l'interface de VB, qui se relance en déclarant "inaccessible" la machine qui tente d'accéder aux disques d'une autre machine.
VB pourrait le dire avant de nous laisser faire ce genre de bêtise, enfin, de bêtise : il me semble que ça fonctionne dans les vieilles versions de VB, et tant qu'il s'agit de disques de données et qu'une seule machine est allumée à la fois, pourquoi n'est-ce pas possible ? Bah…

Il y a un point qu'il faudra que je creuse : ça fonctionne donc parfaitement bien avec une Debian/Xfce, alors que j'ai eu de gros soucis avec une Debian/Lxde pourtant correcte au niveau du contrôleur de disques. Je vais un peu fouiner ces jours-ci, ça a peut-être un rapport avec les fichiers .mount, et comme j'en tiens deux bons, hé hé hé !

Bon, je parle, je parle, et les itérations en sont maintenant à 915 -- je crois que je tiens le bon bout.
Parce que le temps de poster et d'éditer ce post, le compteur est à 935.

[disedorgue]

Cool, si on suppose un reboot par jour, tu as environ dans les 3 ans avant de rencontrer le problème si tu dois le rencontrer

[Jipété]

Cool, si on suppose un reboot par jour, tu as environ dans les 3 ans avant de rencontrer le problème si tu dois le rencontrer

Et ce matin, démarrage sans aucun souci et le compteur de reboot de la machine virtuelle pour tests en est à 1147 ! Encore deux ou trois jours comme ça pendant lesquels la machine vit sa vie et moi la mienne dans le host et je pourrai considérer que c'est gagné !

Me restera plus qu'à mettre ça (pas le test, hein, juste les fichiers .mount) en prod dans la machine physique.

[Jipété]

Yep !

Il y a un point qu'il faudra que je creuse : ça fonctionne donc parfaitement bien avec une Debian/Xfce, alors que j'ai eu de gros soucis avec une Debian/Lxde pourtant correcte au niveau du contrôleur de disques. Je vais un peu fouiner ces jours-ci, ça a peut-être un rapport avec les fichiers .mount, et comme j'en tiens deux bons, hé hé hé !

Ce que je me suis empressé de faire, en espérant vous annoncer une bonne nouvelle mais hélas, le sort s'acharne sur LXDE : j'avais réussi à réparer la machine en utilisant les .mount de la XFCE et, ma foi, les deux tournaient ensemble tip-top dans le host depuis 14 h environ, jusqu'à ce que cette Lx me refasse le coup de son caca nerveux :



et là, il n'y a rien d'autre à faire à part power off. EDIT : petit oubli, on est là au 72^e reboot. /EDIT

Vu qu'on est au tout début du boot, il n'y a rien dans les logs, donc à part faire tourner les tables pour en savoir plus, je n'ai pas d'autre idée... À moins que quelqu'un ici en ait une ?
Je précise que la machine doit être bien à jour puisqu'au premier démarrage de ce matin, le système des unattended upgrades a pris le contrôle et ce pendant bien une heure-une heure et demie.

Ce qui n'a pas empêché ce misérable plantage,

Et pendant ce temps la Xfce continue sa vie, à l'instant 1848 reboots depuis hier.

Je laisse l'autre un peu allumée en l'état, des fois qu'une réponse lumineuse survienne…

[Jipété]

Ah ben tiens, voilà, après une après-midi jardinage, j'allume la babasse et paf !, c'est sdb1 qui est monté sur / alors hop !, les commandes de disedorgue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ systemctl status *mount | sed -n '/\/etc\/fstab/,/Where:/p'
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 21s ago
    Where: /
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 21s ago
    Where: /tmp
$ systemctl status *mount | sed -n '/\/etc\/fstab/,/What:/p'
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 36s ago
    Where: /
     What: /dev/sdb1
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 36s ago
    Where: /tmp
     What: tmpfs

et je résume ça comme ça, sans le tmpfs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
     dans un cas | dans l''autre
Where: /         | /
 What: /dev/sda1 | /dev/sdb1

et moi, je ne trouve pas ça normal, la preuve avec un script écrit il y a des années et des années, et jamais pris en défaut, machines physiques comme virtuelles, et dont voilà le résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
espace occupé "=", espace libre "|"
  sdb1 :     191 Gb [=|||||]
  sda2 :     191 Gb [||||||]  lol ! sda2 c''est la partoche de swap, normalement
  sda1 :    1640 Gb [========|||||||||||||||||||||||||||||||||||||||||||||||||]
  sdc1 :    1640 Gb [======|||||||||||||||||||||||||||||||||||||||||||||||||||]

Note curieuse : les première et deuxième lignes indiquent une taille identique de 191 Gb, c'est normal.

Quand tout va bien, le script donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  sda1 :     191 Gb [=|||||]
  sdb1 :    1640 Gb [========|||||||||||||||||||||||||||||||||||||||||||||||||]
  sdc1 :    1640 Gb [======|||||||||||||||||||||||||||||||||||||||||||||||||||]

Le cœur du script c'est l'analyse de df | grep "/dev/sd" par awk.

Et ce qui est bizarre, c'est que dans ce contexte que je considère comme foireux, ls -Al / me remonte les bonnes données de la racine, tout comme ls -Al /data_large et ls -Al /dbck_large.

À n'y rien comprendre.

[N_BaH]

mauvais rendu du graphisme de la sortie de lsblk

non. ce n'est pas ça. c'est toi qui ne sais pas choisir la bonne option.

[Jipété]

non. ce n'est pas ça. c'est toi qui ne sais pas choisir la bonne option.

Quoi ???????????????????,

Mais je ne savais même pas qu'elle existait, cette option !

Et d'ailleurs (venant d'une autre machine), voilà un test simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931,5G  0 disk 
├─sda1   8:1    0   9,3G  0 part [SWAP]
├─sda2   8:2    0  83,8G  0 part /
├─sda3   8:3    0   9,3G  0 part /var
└─sda4   8:4    0 829,1G  0 part /datas
sdb      8:16   0 931,5G  0 disk 
├─sdb1   8:17   0 821,2G  0 part /media/sdb1
└─sdb2   8:18   0 110,4G  0 part /media/sdb2

Pourquoi est-ce que j'aurais besoin d'une option quand dans l'éditeur c'est correct ? C'est l'affichage du forum qui a un souci, c'est tout :

[LittleWhite]

J'ai vaguement suivi le problème, mais j'aimerai faire une hypothèse : et si les deux disques contiennent tous les deux, deux systèmes parfaitement opérationnels. Par contre, c'est au niveau du BIOS/GRUB (dans mon hypothèse, il y a un GRUB sur chaque disque), il prends le premier qu'il "trouve" et ce n'est pas un truc stable (dans le sens, cela dépend peut être du temps de démarrage pris par le disque).