Vous n'êtes pas identifié(e).
Si c'est que certains attributs ne sont pas supportés par le SSD, alors il doit être possible de configurer /etc/smartd.conf pour ne pas les demander.
Dernière modification par raleur (21-11-2020 13:59:22)
Il vaut mieux montrer que raconter.
Hors ligne
Quel est le problème ?
Aujourd'hui aucun. Mais si un disque se mettait à développer un problème de lecture par exemple, et que les erreurs ne se reportent pas sur le bon à cause du fait qu'un disque n'est pas toujours celui qu'on pense et qui nous est signalé, je te laisse imaginer l'embrouille.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Si vous comparez les première et deuxième colonnes, vous constatez qu'elles sont en non-concordance d'une sortie à l'autre. Le bon ordre (du fstab, qui s'appuie sur les uuid, qu'on nous a vantées comme plus robustes -- mais ce n'est pas le cas, la preuve...) devrait être :
Je vous laisse imaginer l'embrouille dans gparted, qui s'appuie sur les "/dev/...", tout comme lsblk ou blkid dont voilà la sortie :
quand elle devrait être :
En gros, il n'y a que le sdc qui soit toujours correct, .
Alors j'ai une piste (forcer une histoire de after/before dans le fstab, j'ai pas tout bien compris, faudra que je fasse des tests dans une machine virtuelle) mais j'ai une autre urgence ces jours-ci.
Alors comme la machine n'est toujours pas en prod' (cinq mois et demi qu'elle a été achetée...), qq jours de plus ou de moins n'y changeront rien.
Un dernier mot : pour avoir ce bel affichage, je me suis créé un alias msd='findmnt | grep sd | grep -v gvfsd | grep -v nsdelegate ' qui me facilite bien la vie,
Dernière modification par jpt (23-11-2020 10:58:34)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Alors j'ai une piste (forcer une histoire de after/before dans le fstab, j'ai pas tout bien compris
avait foiré, parce que ce n'était pas clair du tout, alors je me suis acharné, j'ai lu des posts des discussions des tutos des trucs des machins, bref, la dernière machine virtuelle a l'air de tenir le choc pendant que la machine physique, toujours pas en prod', vient de me refaire le gag, au bout d'une dizaine de reboots sans accrocs.
Voilà quelques remarques, l'une est très intéressante car, bien que raleur explique (et il a raison et j'en apporte la preuve) que sda sdb sdc etc. c'est aléatoire, d'autres continuent, ici comme dans les man, à utiliser ces identifiants.
La bonne question c'est comment faire autrement s'il ne faut plus les utiliser ? Et là, silence radio sur les fréquences…
Bref, voilà ce que j'ai pu noter ce soir, après avoir découvert cette commande (source) ce matin
parted /dev/sdb print all free
donc les erreurs sont aléatoires, cool…
Les erreurs vues par
et par
Un petit dernier pour la route :
Fait pour servir et valoir ce que de droit,
La suite quand la machine virtuelle aura fait des dizaines de reboots sans anicroches.
En attendant, méditez sur l'exemple suivant, qui permet de remettre le second disque à zéro :
et que va-t-il se passer le jour où sdb sera le premier disque ? (source)
Dernière modification par jpt (21-04-2021 18:14:13)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
la machine susceptible ne me change plus les noms des disques ou plutôt, j'ai toujours sda1 monté sur /, sdb1 sur /data et sdc1 sur /dbck, ce que je voulais.
La solution a consisté à écrire correctement deux fichiers data.mount et dbck.mount, à les mettre dans /etc/systemd/system, et à les activer, après avoir longuement étudié ce boxon de systemd.
Sûrement pas. systemd n'a rien à voir dans le nommage des disques. Mais libre à toi de perdre ton temps à combattre les moulins...
Il vaut mieux montrer que raconter.
Hors ligne
systemd n'a rien à voir dans le nommage des disques. Mais libre à toi de perdre ton temps à combattre les moulins...
Oui, j'ai écrit "disques" quand il est question de partitions, mettons ça sur le compte de la fatigue et de la lassitude.
Et je n'ai pas perdu mon temps, j'ai appris pendant ces recherches plein de choses sur la bestiole, tiens, regarde :
Cependant, par défaut, il semble que le systemd-fstab-generator ne tient pas compte de l’ordre dans lesquels les filesystems sont déclarés ce qui peut provoquer des problèmes d’ordonnancement des montages !
https://blog.zwindler.fr/2017/01/03/eme … e-systemd/
With the introduction of systemd in RHEL 7 the boot process has become a lot faster because many services and processes are now started in parallel.
One of those consequences is the lack of consistent order in which filesystems are mounted. Their order for mounting is no longer guaranteed based on the entries in /etc/fstab. Filesystems are now just another systemd unit. Because systemd defaults to parallel units execution process startup, specific target units startup order is not consistent.
https://www.golinuxcloud.com/mount-file … r-systemd/
With systemd being a parallelized system (part of why systemd-enabled systems boot faster that upstart-enabled or older init-type systems), you typically want to take extra care with your unit-files. Specifically, you'll want to make sure that your layered mounts' unit-files use appropriate dependency-directives — Requires and/or Before/After directives. Absent their use, you can end up in a situation where a lower-level mount happens after a higher-level mount (e.g., /opt/oracle/data mounts before /opt/oracle creating a situation where /opt/oracle effectively hides the content of /opt/oracle/data).
Wouldn't systemd provide an implicit dependencies in this case ?
Sort of. But only in as much as you get from alphabetical ordering. E.g., if you have the layered-mounts /var (var.mount), /var/log (var-log.mount), and /var/log/audit (var-log-audit.mount) systemd should initiate them a few msec apart and — in that order — simply because of the service-directory's scan-order. That said, you open yourself to unexpected results and race-conditions by not over-specifying the dependencies. Which is to say, 99.999% of the time, things will work as expected, but there can be times where they don't and then you'll be pulling your hair out wondering why.
https://dev.to/adarshkkumar/mount-a-vol … stemd-1h2f
Enfin quoi, je ne les ai pas inventées, ces notes :
In fine, rendons à César ce qui lui appartient et à systemd les commentaires qu'il a suscités :
I hate systemd. Old good Debian 8.x was nice. Debian 10 and systemd. I may switch to FreeBSD.
1er commentaire de l'article https://www.cyberciti.biz/faq/how-to-en … ux-system/
This excellent question (and its answers) is an interesting example of how systemd violates the long-standing (and brilliant) design principles of Unix & Co... (most experienced users will just consider that complete bloat). I begin to see more clearly why Linus Torvalds is so vehemently critical of systemd.
https://askubuntu.com/questions/795226/ … -systemctl
Unfortunately, network-online.target is inconsistently implemented and otherwise unreliable. It's best not to rely on it.
https://superuser.com/questions/1538274 … il-success (avril 2020)
systemd is the best example of Suck.
There is a menace which is spreading like a disease throughout the Linux world, it is called systemd.
https://suckless.org/sucks/systemd/
et de la même page, tout en bas, juste pour passer une bonne nuit :
Practical systemd
Here is what happens on a stock Arch Linux system, powered by systemd, when a non-root user tries to restart the system:
In contrast, here is the equivalent error message on a system powered by runit:
And on the oldest and best, Slackware:
systemd is driving "just google the problem" attitude, because how the hell are you expected to troubleshoot this kind of error otherwise?
On ne s'en lasse pas ! Dommage qu'il nous faille vivre avec ce machin, maintenant.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Oui, j'ai écrit "disques" quand il est question de partitions
Peu importe puisque les noms de périphériques des partitions sont dérivés de ceux des disques. Partition n° 3 du disque sdb = sdb3.
Cependant, par défaut, il semble que le systemd-fstab-generator ne tient pas compte de l’ordre dans lesquels les filesystems sont déclarés ce qui peut provoquer des problèmes d’ordonnancement des montages
Ça n'a strictement aucun rapport avec le nommage des disques et des partitions. Et il y a à boire et à manger dans les liens que tu cites. D'après la page de manuel de systemd.mount, systemd crée des dépendances automatiques entre les montages en fonction de leurs chemins ; par exemple, il monte /var avant /var/log. L'ordre de montage entre points de montage indépendants est sans importance. Le seul véritable problème que j'ai vu rapporté dans ces articles est l'absence de dépendance automatique des montages de type "bind", ce qui est quand même un cas assez particulier.
Enfin quoi, je ne les ai pas inventées, ces notes :
Puisque tu reviens encore sur ton obsession du nommage non persistant des disques, je le répète aussi : c'est normal, prévu comme ça, on ne peut rien y faire et de toute façon cela ne gêne en rien une saine gestion des disques basée sur les identifiants persistants qui existent.
Dernière modification par raleur (24-04-2021 13:39:33)
Il vaut mieux montrer que raconter.
Hors ligne
Puisque tu reviens encore sur ton obsession du nommage non persistant des disques, je le répète aussi : c'est normal, prévu comme ça, on ne peut rien y faire et de toute façon cela ne gêne en rien une saine gestion des disques basée sur les identifiants persistants qui existent.
Peut-être, peut-être, mais je ne me lasserai pas de répéter que tous les vieux bouquins et magazines des débuts de Linux ne causaient que comme ça (j'ai encore à côté de moi "Le système Linux" 3e édition chez O'Reilly qui confirme, et je te passe tous les Linux Mag', Login: et autres Misc…) et tu n'as rien dit à propos de ce que j'avais déjà écrit :
En attendant, méditez sur l'exemple suivant, qui permet de remettre le second disque à zéro :
dd if=/dev/zero bs=1M of=/dev/sdb
et que va-t-il se passer le jour où sdb sera le premier disque ? (source)
Parce qu'avant de maîtriser un nommage qui n'évolue plus depuis quelques jours, j'ai parfois eu le cas de sdb attribué au "petit" disque, ce petit étant le ssd système qui boote et fait la suite. Tu vois la cata ?
une saine gestion des disques basée sur les identifiants persistants qui existent.
Euh, à ce jour je n'ai jamais vu un post ou une réponse à une question qui s'appuie sur ces identifiants…
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
tous les vieux bouquins et magazines des débuts de Linux ne causaient que comme ça
Les choses changent que tu le veuilles ou non, et il vaut mieux s'adapter plutôt que s'accrocher au passé.
Avant il n'y avait pas d'initrd/initramfs, les noyaux génériques devaient avoir tous les pilotes de supports de stockage (IDE, SCSI, RAID...) et de systèmes de fichiers courants en dur. Une fois chargé ça occupait de la mémoire pour rien. Avant il n'y avait pas udev et il fallait spécifier explicitement tous les modules à charger au démarrage. Avant il n'y avait pas GRUB mais LILO qui devait être réinstallé à chaque mise à jour du noyau ou de l'initramfs.
que va-t-il se passer le jour où sdb sera le premier disque ?
Ça n'arrivera pas puisque par définition sdb est le second disque. Et si ta notion de premier ou second disque diffère de celle du noyau, demande-toi en quoi elle est plus légitime ou logique. C'est peut-être arbitraire, mais au moins c'est clair : le premier disque détecté est sda, le second est sdb, etc. Si ça ne te convient pas parce que c'est imprévisible, udev crée des liens symboliques dont les noms sont basés sur des identifiants prévisibles :
- modèle et numéro de série ou WWN dans /dev/disk/by-id/
- connexion physique dans /dev/disk/by-path/
- UUID ou labels dans /dev/disk/by-{,part}{uuid,label}/
Le paquet grub-pc mémorise le disque dans lequel il a installé le chargeur d'amorçage sous sa forme /dev/disk/by-id/* pour être sûr de le réinstaller sur le bon disque même si l'ordre change. On peut le voir avec
Parce qu'avant de maîtriser un nommage qui n'évolue plus depuis quelques jours, j'ai parfois eu le cas de sdb attribué au "petit" disque
Il n'y a aucune garantie que cela ne se reproduira pas. Au lieu de chercher à l'éviter, ce qui est voué à l'échec, tu ferais mieux de chercher comment en tenir compte pour ne pas en être affecté.
Il vaut mieux montrer que raconter.
Hors ligne
Les choses changent que tu le veuilles ou non, et il vaut mieux s'adapter plutôt que s'accrocher au passé.
Je veux bien m'adapter à ce qui est mieux, pour le reste, puisque c'était mieux avant, bref...
Le paquet grub-pc mémorise le disque dans lequel il a installé le chargeur d'amorçage sous sa forme /dev/disk/by-id/* pour être sûr de le réinstaller sur le bon disque même si l'ordre change. On peut le voir avec
debconf-show grub-pc
Exact. Je peux récupérer la ligne :
mais ça m'avance à quoi ?
jpt a écrit :que va-t-il se passer le jour où sdb sera le premier disque ?
Ça n'arrivera pas puisque par définition sdb est le second disque.
Ah ouais ! Ça n'arrivera pas ? Comme tu le dis si bien, le premier disque détecté est sda, le second est sdb, etc.
Alors tant que le premier disque détecté est le petit ssd, ça me va.
Mais il est arrivé des fois où le premier disque détecté a été l'un des deux mécaniques, et des fois le premier disque détecté a été l'autre mécanique. Et pour moi c'est monstrueux, inqualifiable et ingérable dans des outils comme parted, gparted, fdisk, sfdisk, etc.
Bon, depuis 15 jours ça n'arrive plus. Avant, ça pouvait être 2 ou 3 fois par jour…
Allez, tiens, une commande toute simple trouvée là (c'est pas vieux, c'est de mars 2021) : dd if=/dev/sda of=/dev/sdb
Copy the contents from the if= drive /dev/sda to the of= drive /dev/sdb.
Tu veux bien me l'écrire en mode secure, stp ?, genre dd if=premier_disk of=second_disk mais attention !, pas le premier_disk détecté puisque ça c'est aléatoire, non, celui que moi j'appelle le premier_disk, et ici pour moi c'est le petit (240 G) ssd.
Quelque chose m'a mis sur la piste, une piste poussiéreuse, mal entretenue, pleine d'ornières (on se croirait dans Les routes de l'impossible en Afrique à la saison des pluies, ), je veux parler de ls -lGg /dev/disk/by-<TAB> et là, on trouve
dans une machine (le host physique) et dans une autre (une virtuelle) j'ai by-partlabel en plus. Dunno why.
Alors si on zappe le label puisque pas fiable, le partuuid parce qu'on va pas compliquer et le path parce que ça n'apporte rien, il reste by-uuid :
et à moins de se faire un tableau des uuid's (puisque les sdXY sont fluctuants) pour savoir qui est qui, c'est limite inexploitable et il ne reste plus qu'une option :
sauf que là je ne sais pas du tout pourquoi les premières lignes (j'ai viré celle du cdrom) ata-gnagnagna, très intéressantes car human-readables, sont dupliquées dessous en mode wwn-0x500blabla dont je ne sais pas ce que ça signifie et qui ne me serviront à rien.
Dommage, ça brouille la lecture, et aussi, ça n'existe pas dans la machine virtuelle :
Alors quoi ? Parce que cette sortie devrait être facilement parsable à coups de awk.
Bah,
On y voit plus clair,
Allez, la bonne nouvelle c'est que dd if=/dev/disk/by-id/<TAB> fonctionne, la mauvaise c'est que ça fonctionne MAL !
Le décodage de ci-dessus montre que la deuxième ligne = sdb, la troisième = sdb1 et la dernière sdb2 mais alors, où sont passées les 4 lignes qui concernent sda et sdc ?
Totalement inutilisable, ça !
Par contre, en forçant à la mano, on peut y arriver :
2 propositions valides, ok.
Donc à part utiliser le parsing de la sortie "by-id" dans un tableau à garder sous la main pour utiliser dd avec les sdXY, je ne vois pas trop comment faire autrement et simplement.
On a connu plus agréable.
Et j'attends toujours de savoir comment les grands gourous font (je ne vois rien sur le web)...
Noté pour mémoire : un truc sympa, mais uniquement utilisable par copier/coller ou pour des scripts :
Bon dimanche,
Dernière modification par jpt (25-04-2021 12:29:13)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
mais ça m'avance à quoi ?
C'est un exemple concret de ce qu'on peut utiliser pour identifier un disque de façon fiable.
je veux parler de ls -lGg /dev/disk/by-<TAB>
C'est précisément ce dont je parlais dans mon message précédent.
dans une machine (le host physique) et dans une autre (une virtuelle) j'ai by-partlabel en plus. Dunno why.
Je suppose que /dev/disk/by-partlabel n'est créé que si un partlabel est défini pour au moins une partition. Cf. blkid. Le format de table de partition DOS/MBR ne supporte pas les partlabels.
Alors si on zappe le label puisque pas fiable, le partuuid parce qu'on va pas compliquer et le path parce que ça n'apporte rien
Je n'ai pas dit que les labels n'étaient pas fiables mais que leur unicité était moindre que celle des UUID, à moins de les choisir très soigneusement (mais la lisibilité va à l'encontre de l'unicité). De toute façon un disque entier partitionné n'a ni label ni UUID (sauf cas particulier de format non standard comme les images ISO-hybrides). Il a un PTUUID (identifiant contenu dans la table de partition) mais cet attribut n'est pas utilisé par udev pour créer un lien dans /dev/disk. Un disque entier non partitionné peut avoir un UUID ou un label. Mais les labels, UUID et PTUUID sont des identifiants du contenu et non du contenant, et sont effacés ou modifiés si on efface, repartitionne ou formate le disque.
Quant au PARTUUID, il n'est défini que pour une partition, pas un disque entier.
Pourquoi dis-tu que le path n'apporte rien ? Il peut servir à identifier le disque qui est connecté à tel port de tel contrôleur, indépendamment de son modèle.
je ne sais pas du tout pourquoi les premières lignes (j'ai viré celle du cdrom) ata-gnagnagna, très intéressantes car human-readables, sont dupliquées dessous en mode wwn-0x500blabla dont je ne sais pas ce que ça signifie
Les liens "ata-*" sont basés sur le modèle et le numéro de série du disque. Les liens "wwn-*" sont basés sur le WWN (world wide name), un identifiant unique défini par le constructeur sur le même principe que l'adresse MAC des interfaces réseau.
Je suppose que tu as compris que les liens qui finissent en "-part*" pointent vers les partitions.
Dommage, ça brouille la lecture, et aussi, ça n'existe pas dans la machine virtuelle
Tu n'es pas obligé de les utiliser. Les liens wwn ne sont créés que pour les disques qui ont un WWN. Apparemment tes disques virtuels n'en ont pas.
Le décodage de ci-dessus montre que la deuxième ligne = sdb, la troisième = sdb1 et la dernière sdb2 mais alors, où sont passées les 4 lignes qui concernent sda et sdc ?
Regarde mieux, il y a 4 lignes et deux colonnes, soit 8 liens en tout. Le compte est bon.
Si tu trouves que ces liens ne sont pas assez pratiques, tu peux en créer avec des règles udev, par exemple /dev/ssd (et surtout pas /dev/sdd !) qui pointerait toujours sur le SSD identifié par son modèle+numéro de série ou son WWN.
Dernière modification par raleur (25-04-2021 17:48:13)
Il vaut mieux montrer que raconter.
Hors ligne
jpt a écrit :Le décodage de ci-dessus montre que la deuxième ligne = sdb, la troisième = sdb1 et la dernière sdb2 mais alors, où sont passées les 4 lignes qui concernent sda et sdc ?
Regarde mieux, il y a 4 lignes et deux colonnes, soit 8 liens en tout. Le compte est bon.
Deux colonnes, ah b0rd3l ! À force d'avoir le nez sur le guidon j'ai raté les paysages,
Si tu trouves que ces liens ne sont pas assez pratiques, tu peux en créer avec des règles udev, par exemple /dev/sdd qui pointerait toujours sur le SSD identifié par son modèle+numéro de série ou son WWN.
Ne compliquons pas les choses, j'ai la tête qui va exploser, ce soir !
Merci à toi, pour les wwn (première fois que j'entendais parler de ça -- faut dire aussi qu'avec l'ancienne machine j'ai vécu 8 ans dans la peau d'un user et pas du tout dans celle d'un sysadmin), et pour le reste.
Je vais m'en dépatouiller à partir de là et des disk/by-id.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Dernière modification par raleur (25-04-2021 17:55:03)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par jpt (25-04-2021 19:02:41)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Et voilà ce que ça donne dans la vieille machine (2 disques) :
Enjoy,
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Mébon, ce n'est utile que si les disques sont de modèles différents, ou qu'on connaît leurs numéros de série par coeur.
Il vaut mieux montrer que raconter.
Hors ligne
Mébon, ce n'est utile que si les disques sont de modèles différents,
ce qui est le cas dans la vieille machine, mais qui dit vieille machine gagne
lsblk: colonne inconnue : serial
et du coup
Bah,
ou qu'on connaît leurs numéros de série par cœur.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Accordez-moi qu'avec ce comportement, on marche sur la tête.
Alors d'accord, tant qu'on travaille avec les points de montage, ça ne devrait pas avoir d'incidence.
Mais l'histoire ne sera pas la même avec tous les outils qui travaillent avec /dev/sdXY où il risque d'y avoir du sport et des déconvenues.
Exemple avec man swapon, extrait de la Debian 10.7 :
avec man sfdisk
man partx (que je découvre ce jour) :
Maintenant, cet outil n'est peut-être pas très fiable, ou c'est moi qui commence à ne plus avoir confiance en rien : en m'inspirant de la première commande indiquée ci-dessus, je fais
Allons bon ! mais c'est la partoche de swap, alors je tente
Pas mieux, et pourtant
C'est cet outil qui foire ou quoi ? Autre disque, même déconvenue :
C'est lassant.
Et cet abruti de ggl qui, sur recherche de bug partx, me remonte des pages de bug party ! En rajoutant linux devant la string, c'est mieux et ça fait peur : cet outil (partx) n'a pas l'air bien fiable, je vous laisse faire vos propres recherches.
En ce qui me concerne, je ne sais plus ce que je dois faire.
Analyser les logs ?
Un résumé édité de /var/log/messages du boot d'hier soir, (je peux tout fournir mais ça n'apportera rien de plus) :
Tout découle d'un sac de nœuds entre 3.86 et 4.36, or tout ce qui s'y trouve c'est trois bricoles ACPI et la prise en compte du dvd (sur scsi 5:0:0:0, ça ne devrait pas concerner les trois disques) :
kern.log contient les mêmes lignes, debug ne contient rien d'intéressant et syslog n'a pas l'air bien complet.
Si quelqu'un a une idée…
Dernière modification par jpt (19-05-2021 09:11:05)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
l'histoire ne sera pas la même avec tous les outils qui travaillent avec /dev/sdXY
Quand tu veux utiliser un tel outil sur une clé ou un disque USB, tu as pris l'habitude de vérifier le nom de périphérique /dev/sd* correspondant parce que tu sais qu'il est variable, n'est-ce pas ? Et bien il faut faire de même avec tous les disques "SCSI" (PATA, SATA, USB...).
C'est cet outil qui foire ou quoi ?
Non, j'ai l'impression que c'est toi qui n'as pas compris ce que partx fait. Si tu lui demandes de chercher une table de partition dans une partition normale, il y a de grandes chances qu'il n'en trouve pas. Si tu lui demandes de chercher une table de partition dans un disque partitionné, il va en trouver une. C'est comme fdisk et ses amis.
et ça, une demi-seconde plus tard, c'est pas bon
Quand finiras-tu par admettre qu'il n'y a pas de nommage "bon" ou "pas bon" mais différents nommages qui dépendent de l'ordre de détection variable et qu'il faut prendre en compte, que tu le veuilles ou non ?
Il vaut mieux montrer que raconter.
Hors ligne
Non, j'ai l'impression que c'est toi qui n'as pas compris ce que partx fait.
là, je me suis contenté d'appliquer une commande trouvée dans le man de l'outil.
Quand finiras-tu par admettre qu'il n'y a pas de nommage "bon" ou "pas bon" mais différents nommages qui dépendent de l'ordre de détection variable et qu'il faut prendre en compte, que tu le veuilles ou non ?
J'ai du mal, j'ai énormément de mal à admettre qu'un disque détecté comme le premier dans une liste va devenir le dernier une demi-seconde plus tard dans une autre liste.
Je ne m'y ferai jamais.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
je me suis contenté d'appliquer une commande trouvée dans le man de l'outil.
Mais as-tu compris ce qu'elle fait ? Sinon il est normal que tu ne comprennes pas son résultat.
Il vaut mieux montrer que raconter.
Hors ligne
Mais as-tu compris ce qu'elle fait ?
Qu'est-ce qu'il y a à comprendre de plus que ce que dit le man ? D'une vieille version (vieille machine) :
EXAMPLES
partx --show /dev/sdb3
partx --show --nr 3 /dev/sdb
partx --show /dev/sdb3 /dev/sdb
All three commands list partition 3 of /dev/sdb.
et donc j'ai repris la 1re commande et ai remplacé b3 par a2, j'ai le droit ? Je pense que oui, et je m'attendais à voir les infos de la partition 2 de /dev/sda, au lieu du message d'erreur.
En fait, en comparant les 2 man (vieille machine vs nouvelle), c'est le petit tiret du 6 après --show qui fait la différence :
Vieille machine :
Conclusion : le man a été mis à moitié à jour.
(et si j'ai pris cet exemple, c'était juste pour montrer que les outils "bas niveau" travaillent avec les identifiants sdXY et qu'il est donc impensable pour moi que les informations y afférentes fluctuent)
PS : je viens de démarrer la nouvelle machine, pas de bol elle est tombée en marche. Donc sans le tiret du 6, elle fonctionne correctement :
Conclusion de la conclusion : même les man's ne sont plus aussi fiables qu'avant -- ne pas s'étonner que tout parte en sucette, alors…
Dernière modification par jpt (20-05-2021 08:15:46)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Je crois que c'est assez clair.
Dernière modification par Tawal (20-05-2021 08:45:03)
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
Hors ligne