Forum

Bonjour,

Édité par Visiteur Le 26/02/2017 à 07h52

Pour résoudre efficacement ce problème, il faudrait l'exposer de cette manière:

https://www.alionet.org/showthread.php?18411-R%E9gl%E9-erreur-sata-au-boot

Sans connaître le nom des cartes en fonctionnement, leur âge et modèle, c'est compliqué. On remarque bien que les deux gros disques sont en gpt, qu'ata4 est un port sata à 6 giga bits/s, disque Seagate Barracuda 2 tera octets, que le microcode pour realtek-8169-ethernet est en erreur, sans compter nombre d'autes provenant du CD. La liste bug de kernel org indique que l'erreur failed to get ncq send/recv - liée à un ssd samsung, bug 72341 - est en cours d'examen (depuis longtemps, mais apparemment sans conséquences tragiques).

Comrest ? un truc intéressant (à noter, l'ironie du mec, toto chez AsusET:$smartcl -a sur un /dev/sdf !) ici :
https://forum.ubuntu-fr.org/viewtopic.php?pid=20506241

Autrement, connaître l'âge, les noms de la carte et des disques serait un plus. Les commandes lspci --verbose et lspcidrake (ioptions possibles) sont vraiment utiles (pour des observateurs extérieurs), et fournir le fichier syslog complet, c'est tout bête: ça permet d'y chercher les erreurs fatales, les contextes des sata4, des trucs comme

Sep 15 10:26:19 localhost kernel: [ 2.461603] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Sep 15 10:26:19 localhost kernel: [ 2.474137] PM: Checking hibernation image partition UUID=01234567-aaaa-bbbb-cccc-abcdef123456
Sep 15 10:26:19 localhost kernel: [ 2.831720] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 15 10:26:19 localhost kernel: [ 2.850556] ata2.00: ATA-8: WDC WD7500BPVT-60HXZT1, 01.01A01, max UDMA/133
Sep 15 10:26:19 localhost kernel: [ 2.863352] ata2.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
Sep 15 10:26:19 localhost kernel: [ 2.882529] ata2.00: configured for UDMA/133
Sep 15 10:26:19 localhost kernel: [ 2.895954] scsi 1:0:0:0: Direct-Access ATA WDC WD7500BPVT-6 1A01 PQ: 0 ANSI: 5

Bien sûr, ça peut manquer de discrétion... et mieux vaut y maquiller url et codes très perso, au modèle de l'uuid ci-dessus, et à condition de conserver l'homogénéité du pestacle en modifiant de la même façon l'ensemble des item identiques litigieux. Les graisser pour que personne ne s'y égare.

Voir aussi
root:#systemd-analyze time
root:#systemd-analyze blame

qui repèreront si le ralentissement mérite tout ce boulot (imaginer qu'un module-noyau caché siphonnerait nos données et les transmettrait à R.M.S. ?)
Bien vu pour draklog !

Précisions:
on peut se contenter de la partie du log système qui commence à l'heure du dernier démarrage (ou alors du début d'un démarrage quelconque jusqu'à l'extinction de CE démarrage-là) qui présente bien sûr l'erreur d'ata4.
On ne sait pas non plus si le même matériel a fonctionné avant Mageia 5 (Mageia ou autre distribution) sans histoire.
En passant, un cd live, disons Debian, montre-t-il les mêmes "erreurs" (splash=verbose à l'amorçage du cd pour voir les log défiler; ils seront aussi dans /var/log)

Rien à voir avec nmrk.n, mais détestable, ce "vous n'avez pas le niveau requis" qui prend vraiment le client "connu" pour un imbécile (Èviter de lire "client connu pour être un imbécile".). La modération, qui a inventé cette sirupeuse nouveauté peut, doit évidemment s'abstenir de me répondre. Le simple rétablissement des droits habituels à ceux qui ont quelque chose à dire et l'ont déjà montré me suffira.

Dans syslog, on trouve

Sep 21 07:31:02 localhost kernel: [ 3851.164417] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
...
...
Sep 21 07:31:44 localhost kernel: [ 3893.367962] EXT4-fs error (device sdc1): __ext4_get_inode_loc:3771: inode #30278192: block 121110594: comm updatedb: unable to read itable block
Sep 21 07:31:48 localhost kernel: [ 3897.287171] ata4.00: exception Emask 0x0 SAct 0x1000000 SErr 0x0 action 0x0
...
...
Sep 21 07:31:48 localhost kernel: [ 3897.288849] blk_update_request: I/O error, dev sdc, sector 968886800
Sep 21 07:31:48 localhost kernel: [ 3897.288855] ata4: EH complete

donc 46 secondes environ sur les 42.816s de systemd-analyze time, pour corriger le noeud 3771 du bloc 121110594 de sdc1, en // avec d'autres initialisations, c'est formidable ! la machine tourne avec deux secondes d'avance. Pour un si gros disque, cette correction est plutôt rapide, non ?

Et si le disque est débranché, reste-t-il des erreurs ?

Pour des raisons très ovales, pas le temps aujourd'hui. Donc rapidement: le fait de débrancher un disque qui serait (est) pointé dans /etc/fstab conduit Mageia 4 à tenter de le coller à son point de montage pendant 1 minute 30 secondes. Il faut espérer que la forme UUID= est utilisée (identifiant unique), ce qui permet de passer à autre chose si échec. Bien sûr, si ce disque est nécessaire au système (une partition obligatoire comme /tmp ou /var ou /usr), c'est l'arrêt complet (la Mageia 5 en a peut-être besoin, de ce disque... à données atlantistes)

1 minute trois cent sept millisecondes, le coût de la turpitude sm-client service ! Un coup de l'initrd n'y trouvant pas son dû, pour sûr.
================================
Le disque fautif sera électriquement éteint
cd /lib/modules/`uname -r`
depmod -a
cd ..
mkinitrd /boot/initrd-perso.img `uname -r`
cd /boot
ln -sf initrd-perso.img initrd.img
Si le noyau est une formule desktop:
ln -sf initrd-perso.img initrd-desktop.img

S'assurer que le nom des liens pointant la nouvelle image est bien le même que celui utilisé dans menu.lst (ou grub.cfg) si la technique utilisée se sert du lien plutôt que du nom complet.

Venus, et en fourrures. Ça adhère bien mieux, répondait Masoch en cherchant Saussure à son pied