Sérieusement les UUID rendent les configurations bien moins lisibles et bien plus difficile à modifier dans un environnement de récupération. Si on fait les choses à la main il vaut mieux utiliser des LABEL qui sont tout aussi robustes et bien plus lisibles. En ce qui concerne la modification des liens symboliques c'est une mauvaise piste de toute façon car ils sont dans le mauvais sens donc tout ce qu'on obtiendrait c'est un uuid qui pointe vers le mauvais périphérique. Si vous n'utilisez pas du tout sda et sdb il y a peut-être moyen de les désactiver. Sur une VM de test avec un disque de 32 Go, j'ai ajouté un disque de 10 Go en sata0, un autre de 20 Go en sata1 et j'ai passé le disque système de 32 Go en sata2. Avec ça j'obtiens : root@debian:~# mount / mount: /: /dev/sdc2 déjà monté sur /. root@debian:~# dmesg | grep ata..00 [ 1.832456] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 [ 1.833078] ata2.00: applying bridge limits [ 1.834568] ata2.00: configured for UDMA/100 [ 1.846910] ata7.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [ 1.847450] ata7.00: 20971520 sectors, multi 16: LBA48 NCQ (depth 32) [ 1.848063] ata7.00: applying bridge limits [ 1.848677] ata8.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [ 1.849213] ata8.00: 41943040 sectors, multi 16: LBA48 NCQ (depth 32) [ 1.849760] ata8.00: applying bridge limits [ 1.854225] ata7.00: configured for UDMA/100 [ 1.855070] ata9.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [ 1.855709] ata9.00: 67108864 sectors, multi 16: LBA48 NCQ (depth 32) [ 1.857002] ata9.00: applying bridge limits [ 1.857661] ata8.00: configured for UDMA/100 [ 1.858348] ata9.00: configured for UDMA/100 Le nombre de secteurs me permet de les différencier. Dans /etc/default/grub : GRUB_CMDLINE_LINUX_DEFAULT="quiet libata.force=7.00:disable,8.00:disable" Puis : root@debian:~# update-grub root@debian:~# reboot root@debian:~# mount / mount: /: /dev/sda2 déjà monté sur /. root@debian:~# dmesg | grep ata..00 [ 1.767024] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 [ 1.767685] ata2.00: applying bridge limits [ 1.770767] ata2.00: configured for UDMA/100 [ 1.784921] ata9.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [ 1.785514] ata9.00: 67108864 sectors, multi 16: LBA48 NCQ (depth 32) [ 1.786105] ata9.00: applying bridge limits [ 1.786747] ata8.00: FORCE: horkage modified (disable) [ 1.787356] ata8.00: unsupported device, disabling [ 1.787927] ata8.00: disabled [ 1.788572] ata7.00: FORCE: horkage modified (disable) [ 1.789158] ata7.00: unsupported device, disabling [ 1.789771] ata7.00: disabled [ 1.790447] ata9.00: configured for UDMA/100 Et voilà sdc redevenu sda. @+ Hugues ------- Original Message ------- Le vendredi 21 avril 2023 à 00:26, ajh-valmer <ajh.valmer@free.fr> a écrit : > > > On Thursday 20 April 2023 22:42:48 Th.A.C wrote: > > > Et je confirme que c'est une très mauvaise idée : > > > Voici les 2 fautifs (liens symboliques) : > usb-iDRAC_LCDRIVE_20120430-0:0 -> ../../sda > > usb-iDRAC_Virtual_Floppy_20120430-0:1 -> ../../sdb > > wwn-0x600508e0000000004422b6a2821d890b -> ../../sdc > > > qui prennent sda et sdb sur 2 ports USB. > > Ce n'est pas "une très mauvaise idée" que de vouloir rétablir > le disque dur en /dev/sda car les 6 autres partitions sont > estampillées sda. > Sur mes autres ordinateurs, c'est pareil, le disque dur est sda, > et sdb si deuxième disque dur. > > Bonne nuit à tous.
Attachment:
publickey - hlarrive@pm.me - 0xE9429B87.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature