probleme GRUB au demarrage

geole · Le 08/11/2019, à 18:34

Donc il faut rebooter pour que les partitions soient enregistrées au démarrage.

syborg · Le 08/11/2019, à 18:35

geole a écrit :

A mon avis, ce paramètre
195 Hardware_ECC_Recovered 0x001a 002 001 000 Old_age Always - 40660108
est la cause principale du disfonctionnement. Il faudra que tu changes le disque pour ne plus avoir d'ennuis.

Oui c'est ce qu'il ressort aussi de l'autre discussion sur le sujet, mais des intervenants disaient qu'il ne faut pas trop de fier a cette valeur sur les disques Seagate...
Donc finalement la conclusion c'est que le disque a pris un coup irreparable ?
Pas d'autre choix que de le changer ?
Pour le remplacement tu me conseilles des modeles/marques (ou a eviter) ou tous sont equivalents ?

geole · Le 08/11/2019, à 18:45

Si les données transmises par le disque étaient de qualité, tu n'aurais pas eu perte de la description des tables de partition.

Il me semble que dans une autre discusssion, on a vu que le bios trouvait qu'il était à changer

De plus, tu as des paramètres de transmissions des données qui devraient être beaucoup meilleurs vu l'àge du disque
Alors n'attends pas que le firmware lâche définitivement alors que la mécanique n'est pas excellante.

1 Raw_Read_Error_Rate 0x000f 075 063 006 Pre-fail Always - 40660108 Fonctionnement actuel à 75% a même atteint 63%
7 Seek_Error_Rate 0x000f 074 060 045 Pre-fail Always - 28284534 Fonctionnement actuel à 74% a même atteint 60% alors qu'il sera fichu à 45%
9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 3554 Disque très jeune
183 Runtime_Bad_Block 0x0032 091 091 000 Old_age Always - 9 A déjà du faire fonctionner la séquence de réparation des secteurs deffectueux 9 fois .

RAPPEL, le 28/10, ce n'était que 5 fois
183 Runtime_Bad_Block 0x0032 095 095 000 Old_age Always - 5

Dernière modification par geole (Le 08/11/2019, à 18:58)

syborg · Le 08/11/2019, à 19:02

geole a écrit :

De plus, tu as des paramètres de transmissions des données qui devraient être beaucoup meilleurs vu l'àge du disque
Alors n'attends pas que le firmware lâche définitivement alors que la mécanique n'est pas excellante.
1 Raw_Read_Error_Rate 0x000f 075 063 006 Pre-fail Always - 40660108 Fonctionnement actuel à 75% a même atteint 63%
7 Seek_Error_Rate 0x000f 074 060 045 Pre-fail Always - 28284534 Fonctionnement actuel à 74% a même atteint 60% alors qu'il sera fichu à 45%
9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 3554 Disque très jeune
183 Runtime_Bad_Block 0x0032 091 091 000 Old_age Always - 9 A déjà du faire fonctionner la séquence de réparation des secteurs deffectueux 9 fois .

J'en reviens alors toujours a la meme question : comment se fait il que ce disque si jeune lache ?
C'est la deuxieme fois que ca m'arrive en 5 ans.. le plus probable si je change de disque c'est que recommence encore une fois.
As tu des hypotheses sur les causes ? D'autres parties du hardware pourraient elles etre mises en cause ? (ram, carte mere, proc)
Si oui comment le verifier ?
La malchance 2 fois je n'y crois pas trop...

PS : apparemment les regles du forum empechent de repondre a ma question sur les recommandations marques/modeles : c'est la 3eme ou 4eme fois que je pose la question et jamais personne ne m;a repondu quoi que ce soit...

Dernière modification par syborg (Le 08/11/2019, à 19:04)

geole · Le 08/11/2019, à 19:09

Il me semble que la partie connectique a été évoquée.
Cela va du branchement SATA de la carte-mère ( à metrtre dans une autre prise s'il y en a plusieurs), en passant par le câble, qu'il est facile de changer, en continuant par l'entrée du disque et en finissant par son cache et finalement l'écriture sur le plateau.

Dernière modification par geole (Le 08/11/2019, à 20:19)

syborg · Le 08/11/2019, à 19:18

geole a écrit :

Il me semble que la partie connectique a été évoquée.
Cela va du branchement SATA de la carte-mère ( à metrtre dans une autre prise s'il y en a plusieurs), en passant par le câble, qu'il est facile de changer, en continuant par l'entrée du disque et en finissant par son cache

son cache tu veux dire quoi ?

Sinon j'ai deja essaye de changer de port et de cable, pas de chamgements.

Dernière modification par syborg (Le 08/11/2019, à 19:25)

geole · Le 08/11/2019, à 20:09

Ce que le compteur 195 surveille

https://www.ldlc.com/fiche/PB00214983.html a écrit :

Cache : 64 Mo

https://fr.wikibooks.org/wiki/Fonctionnement_d%27un_ordinateur/Les_disques_durs a écrit :

De nos jours, le tampon de lecture/écriture est parfois remplacé par une mémoire cache. Ce cache peut mémoriser les données lues récemment, pour profiter de la localité temporelle, ou précharger les secteurs proches de ceux récemment accédés, pour profiter de la localité spatiale (sur certains disques durs, c'est carrément toute la piste qui est chargée lors de l'accès à un secteur). Autre utilité de ce cache : mettre en attente les écritures tant que la tête de lecture-écriture n'est pas libre. Ce cache en écriture pose un léger problème : les données à écrire vont attendre durant un moment avant que les plateaux soient libres pour démarrer l'écriture. Si jamais une coupure de courant se produit, les données présentes dans la mémoire tampon, mais pas encore écrites sur le disque dur, sont perdues.

https://www.ldlc.com/avis/PB00214983.html a écrit :

par SylvainD Publié le 17/07/2019
Ne pas acheter
Je l'ai commandé pour un pc gaming une fois, au bout de 2 mois et 600go dessus, il a laché, je refais confiance à Seagate, et il vient aujourd'hui de relâcher avec cette fois-ci 700go de données. En tout, une perte de 1500GO. Toujours la même opération avant qu'il lâche, cliquetis, redémarrage et error system disc not found, etc... J'ai la haine, à ce qui parait cela arrive qu'une seule fois sur 1000, mais c'est déjà énorme qu'une personne sur mille perde toutes ses données !! Je vais passer sur du 2to et encore chez Seagate, j'ai eu de bon echo. S'il relache, je passerai chez la concu, allez merci aurevoir !

Dernière modification par geole (Le 08/11/2019, à 20:12)

syborg · Le 08/11/2019, à 21:02

Ok geole merci mille fois pour ton aide depuis le debut !
Je vois en effet que ce modele peut poser probleme, je ne reprendrai plus de Seagate pour ne plus tenter le diable...
Tu soulignes le cache de 64 Mo sur ce modele, ca pose un probleme ?

J;hesite entre celui la https://www.ldlc.com/fiche/PB00134121.html et celui la https://www.ldlc.com/fiche/PB00157257.html
qui pretend etre plus robuste, mais je me demande si ca vaut le coup de mettre presque 2 fois plus cher.

Dernière modification par syborg (Le 08/11/2019, à 21:12)

geole · Le 09/11/2019, à 11:23

Bonjour

J'ai simplement indiqué que ton disque possède un cache de 64 Mo.
Il me semble que, actuellement, les disques ont des caches allant de 8 à128 Mo.
A mon avis, un cache 16 fois plus important n'améliore peut-être que de deux fois l'efficacité du disque.

Je partage assez cet avis

https://www.commentcamarche.net/faq/11079-choisir-son-disque-dur a écrit :

Cache
Le cache doit être au minimum de 16 Mo, 32 Mo étant l'idéal. Les nouveaux disques durs disposent d'un cache de 64 Mo, mais ce n'est ni plus ni moins qu'un argument marketing.

Qui est mis en pratique dans la documentation de ubuntu.

https://doc.ubuntu-fr.org/dd a écrit :

Comment choisir bs ? (block size = taille des blocs)
Un paramètre bs= correctement choisi accroitra significativement la vitesse d'exécution.
Sur du matériel moderne (moins de 5 ans) bs=4096 est un bon pari.
On peut aussi avoir : bs=16065b qui peut être meilleur. bs=32130b encore meilleur. Ces deux dernières tailles de bloc correspondent à des nombres entiers de cylindres.
Un cylindre en mode LBA = 255 têtes x 63 secteurs par piste = 16065 secteurs = 16065 x 512 octets = 16065b. Le b signifie x512 (512 octets étant la taille d'un secteur). 32130b représente un bloc de deux cylindres. Lorsque vous utilisez des tailles de blocs représentant des nombres entiers de cylindres, vous n'avez jamais à vous soucier de la copie de la dernière fraction de bloc car les partitions sont toujours faites d'un nombre entier de cylindres. Les partitions ne peuvent pas contenir de cylindres partiels. Un cylindre comprend 8 225 280 octets.

Pour le premier disque de la série blue, tu as 204 avis à lire, il est garanti deux ans
Pour le second disque de la série black, tu as 57 avis à lire, il est garanti 5 ans

Pour ton disque actuel, du point de vue garantie, il est considéré comme étant en partait état puisque le rapport smartctl n'indique pas qu'il est failing now!

syborg · Le 19/11/2019, à 15:53

Salut,
je reprends le cours de ce fil. Je sais que je devrai tres probablement changer de DD, mais je voudrais essayer de voir si celui la n'est pas recuperable tout de meme..
Je demarre depuis qq semaines sur un usb-live, et au demarrage il me propose l'option "verifier le DD". En choisissant cette option il apparait ceci :

https://zupimages.net/up/19/47/e8zf.jpg

Pouvez vous m'expliquer la signification de chacune de ces lignes ?
Sous windows quand on fait un scandisk et qu'il trouve des secteurs defectueux, il les bloque et en general ca resoud le probleme. Ne peut on pas faire qq chose de ce genre sous ext4 ?

_{Modération : merci d'utiliser des images de petite taille (300x300) ou des miniatures pointant sur ces images (Des hébergeurs comme Toile Libre ou TDCT'Pix le permettent).}

Dernière modification par cqfd93 (Le 19/11/2019, à 16:19)

geole · Le 19/11/2019, à 17:23

Bonjour

Chaque ligne commence par l'indication de l'instant de l'incident depuis le début du BOOT de ubuntu. C'est exprimé en secondes et millisecondes

Le premier paquet de lignes signifie que le bios EFI a refusé de communiquer des informations à ubuntu (Il est probablement sécurisé) sinon, il aurait répondu des lignes de ce style

a@a:~$ dmesg | grep EFI
[    1.038262] EFI Variables Facility v0.08 2004-May-17
[    1.065976] Loaded UEFI:db cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' linked to secondary sys keyring
[    1.065996] Loaded UEFI:db cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' linked to secondary sys keyring
[    1.067921] Loaded UEFI:db cert 'Toshiba Corporation Utility CA 2012: cc37e82804de6d8242718850b1af8d5f' linked to secondary sys keyring
[    1.068146] Loaded UEFI:db cert ': 4941d90e94cb9a964b1397fa859f45c7' linked to secondary sys keyring
[    1.068354] Loaded UEFI:db cert ': d786405226a5ddbb4fb3d04af46a3aa4' linked to secondary sys keyring
[    1.068370] MODSIGN: Couldn't get UEFI MokListRT

Le second paquet de lignes indique que ubuntu n'a pas pu accéder ( probablement en lecture) aux secteurs dont les numéros sont indiqués
Ce fameux disque semble ne pas avoir de secteurs défectueux mais il perd des bits de parité dans les échanges.
Il me semble que windows ne gère pas mieux ce type d'incident. Il faut lui faire faire une commande chkdsk (qu'il lance souvent automatiquemet). Elle peut inclure le traitement des zones défectueuses (Option -R). Sous ubuntu c'est séparé en deux commandes ( fsck et badblocks) http://www.delafond.org/traducmanfr/man … cks.8.html
Tu peux donc voir ce que cela donne

sudo badblocks  -b 4096  -n  -s    -v   /dev/sda

Tu peux vérifier si le problème est encore présent en faisant ces commandes

sudo dd if=/dev/sda   count=8    skip=999999     2>/dev/null | hexdump -C

en remplaçant 99999 par les numéros indiqués. Cela fera trois commandes
Si j'ai bien lu, la premiere sera

sudo dd if=/dev/sda count=8    skip=1091790720   2>/dev/null | hexdump -C

Dernière modification par geole (Le 19/11/2019, à 17:30)

syborg · Le 20/11/2019, à 15:51

Voici ce que retourne les commandes :

ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda 
/dev/sda is apparently in use by the system; it's not safe to run badblocks!
ubuntu@ubuntu:~$ sudo dd if=/dev/sda count=8    skip=1091790720   2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000
ubuntu@ubuntu:~$ sudo dd if=/dev/sda count=8    skip=942286720   2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000
ubuntu@ubuntu:~$ sudo dd if=/dev/sda count=8    skip=942286848   2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  01 00 00 00 ff c7 32 00  00 00 00 00 80 c9 6f 4c  |......2.......oL|
00000410  d6 96 4f c7 b2 95 1d c3  aa d8 22 79 00 00 00 00  |..O......."y....|
00000420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ff0  00 00 00 00 00 00 53 57  41 50 53 50 41 43 45 32  |......SWAPSPACE2|
00001000
ubuntu@ubuntu:~$

Je me demande : pourquoi le bios refuse de communiquer des infos a ubuntu ? et pourquoi le disque perd des bits de parite ?

geole · Le 20/11/2019, à 16:17

Bonjour
Tous les bios EFI ne sont pas nécessairement très coopératifs,

Ces 24 secteurs ont été parfaitement lus Mais il y a pas mal de zéros.

Je me suis trompé dans la codification en oubliant de préciser un numéro de partition. Probablement 1

sudo badblocks  -b 4096  -n  -s    -v   /dev/sda1

Pour les bits de parité, je ne sais bien pas expliquer le principe . Même avec ce document https://fr.wikipedia.org/wiki/Code_correcteur
S'il y a perte de bits, les tuyaux sont troués (un peu? beaucoup?)

Dernière modification par geole (Le 20/11/2019, à 16:18)

syborg · Le 20/11/2019, à 16:26

geole a écrit :

Bonjour
Tous les bios EFI ne sont pas nécessairement très coopératifs,

Mais avant d'avoir ces problemes au demarrage avec ce disque, ces messages ne s'affichaient pas... ca peut avoir un rapport avec les problemes de perte de bits de parite ?

geole · Le 20/11/2019, à 16:39

Non
Il est possible que les messages EFI proviennent d'une modification du logiciel EFI

syborg · Le 20/11/2019, à 17:53

geole a écrit :

Non
Il est possible que les messages EFI proviennent d'une modification du logiciel EFI

Et ce n'est pas simplement ca qui peut etre la cause de mes problemes de demarrage ?...

geole · Le 20/11/2019, à 18:07

Les modules EFI qui discutent avec le BIOS sont en tout début de la trace dans le grub donc bien avant l'affichage de l'écran noir qui n'intervient qu'après le démarrage de la partition racine

dmesg | grep efi
[    0.000000] efi: EFI v2.31 by INSYDE Corp.
[    0.000000] efi:  ACPI=0x9affe000  ACPI 2.0=0x9affe014  SMBIOS=0x9aebef98 
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[    0.068036] pci 0000:00:02.0: BAR 2: assigned to efifb
[    0.124093] Registered efivars operations
[    0.988121] efifb: probing for efifb
[    0.988133] efifb: framebuffer at 0xc0000000, using 5628k, total 5625k
[    0.988134] efifb: mode is 1600x900x32, linelength=6400, pages=1
[    0.988134] efifb: scrolling: redraw
[    0.988135] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    2.012020] tsc: Refined TSC clocksource calibration: 2594.106 MHz
[    2.990214] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS


dmesg | grep mount | head -1
[   20.276760] EXT4-fs (sda24): mounted filesystem with ordered data mode. Opts: (null)

Dernière modification par geole (Le 20/11/2019, à 18:08)

syborg · Le 20/11/2019, à 18:43

Ok. Je suis en train de faire un "badblocks" sur toutes les partitions, c'est long...

Pourrais tu m'expliquer les etapes qui se deroulent entre le moment ou on allume l'ordi et le moment ou apparait le menu de GRUB ?

Dernière modification par syborg (Le 20/11/2019, à 18:57)

geole · Le 21/11/2019, à 12:28

Bonjour.
Je ne peux que te donner quelques grandes lignes
1) Appui sur la touche de démarage électrique qui va activer le programme de boot du bios stocké dans la Read Only Memory
2) Ce programme controle
3) Les périphériques absolument nécessaires pour continuer le boot. S'ils ne fonctionnent pas, il émet des bips ( l'utilisation d'une table de traduction permet de connaitre l'erreur)
- Le processeur
- La mémoire
4 ) détection de tous les autres périphériques
- Le clavier, l'écran, la souris, le touch pad....
- Les disques internes, l'USB, le réseau. ....
5) La recherche du complément de boot fourni par l'utilisateur. Comme tu as un boot EFI, il lira tous les disques à la recherche des programmes se terminant par .EFI stockés dans des partitions FAT32.
6) Il lancera le premier de la liste. Si tu n'as pas ordonné cette liste, le programme est SHIMX64.EFI.

7) SHIMX64.EFI dialogue encore avec le bios pour se faire reconnaitre du BIOS. Il peut y avoir un refus. Il lancera ensuite le programme GRUX64.EFI.

8) grubx64.efi échangera des données standards avec le bios puis il lira le fichier /boot/grub/grub.cfg pour savoir quel O.S, tu veux lancer.

9) Le lancement de cet O.S. est entièrement tracé dans les fichiers que tu connais.

Pour aller plus loin https://fr.m.wikipedia.org/wiki/Démarra … ordinateur

Dernière modification par geole (Le 21/11/2019, à 12:42)

syborg · Le 22/11/2019, à 10:41

geole a écrit :

Bonjour.
Je ne peux que te donner quelques grandes lignes
1) Appui sur la touche de démarage électrique qui va activer le programme de boot du bios stocké dans la Read Only Memory
2) Ce programme controle
3) Les périphériques absolument nécessaires pour continuer le boot. S'ils ne fonctionnent pas, il émet des bips ( l'utilisation d'une table de traduction permet de connaitre l'erreur)
- Le processeur
- La mémoire
4 ) détection de tous les autres périphériques
- Le clavier, l'écran, la souris, le touch pad....
- Les disques internes, l'USB, le réseau. ....
5) La recherche du complément de boot fourni par l'utilisateur. Comme tu as un boot EFI, il lira tous les disques à la recherche des programmes se terminant par .EFI stockés dans des partitions FAT32.
6) Il lancera le premier de la liste. Si tu n'as pas ordonné cette liste, le programme est SHIMX64.EFI.
7) SHIMX64.EFI dialogue encore avec le bios pour se faire reconnaitre du BIOS. Il peut y avoir un refus. Il lancera ensuite le programme GRUX64.EFI.
8) grubx64.efi échangera des données standards avec le bios puis il lira le fichier /boot/grub/grub.cfg pour savoir quel O.S, tu veux lancer.
9) Le lancement de cet O.S. est entièrement tracé dans les fichiers que tu connais.
Pour aller plus loin https://fr.m.wikipedia.org/wiki/Démarra … ordinateur

Donc si j'ai bien compris, le premier bloc de lignes du message d'erreur au demarrage que j'ai poste plus haut, signifient que le BIOS refuse de dialoguer avec SHIMX64.EFI ?
Et ensuite le menu de GRUB ne s'affiche pas car le BIOS ne peut pas lire GRUBX64.EFI a cause de cette histoire de perte de bits de parite ?
C'est bien ca ?
Ce fichier GRUBX64.EFI, il se trouve sur les premiers secteurs de la partition racine (/dev/sda5 dans mon cas) n'est ce pas ?
Ou se trouve SHIMX64.EFI ?

geole · Le 22/11/2019, à 12:02

Bonjour.
Les fichiers de boot en EFI (shimx64.efi, grub.x64. efi etc...) se trouvent dans une partition FAT32. Donc, dans ton contexte, très certainement SDA1
Ce sont les fichiers de boot utilisateurs /boot/..... qui se trouvent dans la partition racine.

Il y a énormément de causes pour un écran noir. Mais la cause d'impossibilité de lire à été retenue car par, par moments, la lecture du début devient possible, et le boot se met rapidement à râler en réclamant un fichier. ( voir ta première capture d'image) et aussi le fait que tu sois amené à faire des fsck qui prouvent une mauvaise écriture (ou une mauvaise lecture).
Les autres causes d'écran noir sont quasiment liées à une installation nouvelle demandant des paramètres particuliers (nomodeset etc...)

Dernière modification par geole (Le 22/11/2019, à 12:03)

syborg · Le 22/11/2019, à 18:52

Voila le resultat de "badblocks" sur toutes les partitions : apparemment seul sda6 a des secteurs HS..

ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda1
Checking for bad blocks in non-destructive read-write mode
From block 0 to 25599
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda2
Checking for bad blocks in non-destructive read-write mode
From block 0 to 7679999
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda3
Checking for bad blocks in non-destructive read-write mode
From block 0 to 110079999
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:  36.45% done, 4:11:53 elapsed. (0/0/0 errors)
 36.46% done, 4:11:56 elapsed. (0/0/0 errors)
done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda4
/dev/sda4 is mounted; it's not safe to run badblocks!
ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda5
Checking for bad blocks in non-destructive read-write mode
From block 0 to 7679930
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda6
Checking for bad blocks in non-destructive read-write mode
From block 0 to 7679999
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 3165568 done, 19:46 elapsed. (0/0/0 errors)
3165569
3165570
3165571
3165572
3165573
3165574
3165575
3165576
3165577
3165578
3165579
3165580
3165581
3165582
3165583
3165584
3165585
3165586
3165587
3165588
3165589
3165590
3165591
3165592
3165593
3165594
3165595
3165596
3165597
3165598
3165599
3165600
3165601
3165602
3165603
3165604
3165605
3165606
3165607
3165608
3165609
3165610
3165611
3165612
3165613
3165614
3165615
3165616
3165617
3165618
3165619
3165620
3165621
3165622
3165623
3165624
3165625
3165626
3165627
3165628
3165629
3165630
3165631
done                                                 
Pass completed, 64 bad blocks found. (0/0/64 errors)
ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda7
Checking for bad blocks in non-destructive read-write mode
From block 0 to 107716607
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
ubuntu@ubuntu:~$

Dernière modification par syborg (Le 22/11/2019, à 18:53)

geole · Le 22/11/2019, à 19:14

Bonjour

Merci du retour
Il me semble que SDA4 n'a pas été traité car il était en activité

$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda4
/dev/sda4 is mounted; it's not safe to run badblocks!

==> c'estv la partition de swap
donc , il faut libérer la partition. Je pense que cette commande doit le faire

sudo swapoff -av

Je ne sais pas ce que contient SDA6, On va essayer de voir si je sais faire pointer dessus

sudo dd if=/dev/sda6   bs=4096    skip=3165569  count=1 2>/dev/null | hexdump -C

sudo dd if=/dev/sda6    bs=4096    skip=3165631  count=1 2>/dev/null | hexdump -C

Si tu as du logiciel à cet endroit, cela fait une grosse partie de zones illisibles
J'ai noté que cette partition fait 29,3 Go
Elle sera à reformater avec l'application Gnome-disk-utility en lui demandant de faire un formatage lent afin qu'il traite ce problème

Dernière modification par geole (Le 22/11/2019, à 19:29)

syborg · Le 23/11/2019, à 19:23

Oui en effet sda4 c'est le swap.
Et sda6 c'est la partition racine d'une autre distrib linux (debian).
Il me semble que tu avais dit une fois que ca peut poser probleme si deux partitions racine (sda5 et sda6 dans mon cas) partagent la meme partition /home (sda7 dans mon cas). Tu confirmes ? et si oui, quels genred e problemes ca peut entrainer ? ca peut avoir un rapport avec mes problemes de demarrage ?

ubuntu@ubuntu:~$ sudo swapoff -av
swapoff /dev/sda4
ubuntu@ubuntu:~$ sudo badblocks  -b 4096  -n  -s    -v   /dev/sda4
Checking for bad blocks in non-destructive read-write mode
From block 0 to 3327999
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
ubuntu@ubuntu:~$ sudo dd if=/dev/sda6   bs=4096    skip=3165569  count=1 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000
ubuntu@ubuntu:~$ sudo dd if=/dev/sda6    bs=4096    skip=3165631  count=1 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000
ubuntu@ubuntu:~$

geole · Le 23/11/2019, à 20:11

Bonjour
Je m'attendais à ce que les deux secteurs soient illisibles. Mais ils sont lus avec uniquement des zéros... ( Je ne sais pas s'ils les avaient déjà.)

Si tu as un même /home avec un même nom d'utilisateur, lorsque tu lances une application existante dans les deux OS. on a des paramètres d'initialisation qui peuvent ne pas être identiques et provoquer un dysfonctionnement de l'application. Donc aucun problème pour le démarrage de l'O.S.

Même plus grave, s'il y a trop de différences dans les versions des OS, la plus ancienne, pourrait me plus pouvoir lire le contenu sa partition modifiée par la plus récente. Ce cas s'est produit avec la version 16.10 ou 17.10, La version la plus ancienne disait clairement qu'il fallait réparer la partition /home et son logiciel de réparatrion disait qu'il ne savait pas le faire.

Il existe un autre problème lorsqu'ils partagent le même swap et que la fonctionnalité d'hibernation est activée, on ne peut que relancer le dernier qui a été endormi
Le paliatif étant alors d'avoir deux swap et d'indiquer clairement celui à utiliser pour hiberner ou de dire de remettre en route sans utiliser l'hibernation (option NORESUME)
comme on ajoute l'option nomodeset ( https://doc.ubuntu-fr.org/kernel#exempl … oyau_linux )
Le message d'erreur est aussi très parlant.

Dernière modification par geole (Le 23/11/2019, à 20:15)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#76 Le 08/11/2019, à 18:34

Re : probleme GRUB au demarrage

#77 Le 08/11/2019, à 18:35

Re : probleme GRUB au demarrage

#78 Le 08/11/2019, à 18:45

Re : probleme GRUB au demarrage

#79 Le 08/11/2019, à 19:02

Re : probleme GRUB au demarrage

#80 Le 08/11/2019, à 19:09

Re : probleme GRUB au demarrage

#81 Le 08/11/2019, à 19:18

Re : probleme GRUB au demarrage

#82 Le 08/11/2019, à 20:09

Re : probleme GRUB au demarrage

#83 Le 08/11/2019, à 21:02

Re : probleme GRUB au demarrage

#84 Le 09/11/2019, à 11:23

Re : probleme GRUB au demarrage

#85 Le 19/11/2019, à 15:53

Re : probleme GRUB au demarrage

#86 Le 19/11/2019, à 17:23

Re : probleme GRUB au demarrage

#87 Le 20/11/2019, à 15:51

Re : probleme GRUB au demarrage

#88 Le 20/11/2019, à 16:17

Re : probleme GRUB au demarrage

#89 Le 20/11/2019, à 16:26

Re : probleme GRUB au demarrage

#90 Le 20/11/2019, à 16:39

Re : probleme GRUB au demarrage

#91 Le 20/11/2019, à 17:53

Re : probleme GRUB au demarrage

#92 Le 20/11/2019, à 18:07

Re : probleme GRUB au demarrage

#93 Le 20/11/2019, à 18:43

Re : probleme GRUB au demarrage

#94 Le 21/11/2019, à 12:28

Re : probleme GRUB au demarrage

#95 Le 22/11/2019, à 10:41

Re : probleme GRUB au demarrage

#96 Le 22/11/2019, à 12:02

Re : probleme GRUB au demarrage

#97 Le 22/11/2019, à 18:52

Re : probleme GRUB au demarrage

#98 Le 22/11/2019, à 19:14

Re : probleme GRUB au demarrage

#99 Le 23/11/2019, à 19:23

Re : probleme GRUB au demarrage

#100 Le 23/11/2019, à 20:11

Re : probleme GRUB au demarrage

Pied de page des forums