Emile “iMil” Heitor ‘s home

Un upgrade kernel, et une regression. De nouveau, impossible de graver et symptomes similaires :

Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error

etc etc etc.

Evidemment, rien à voir avec l’application (gnomebaker en l’occurence), c’est wodim / ex-cdrecord qui perd le fil. Car en effet, si l’erreur est reproductible, elle n’apparait jamais au même moment de la gravure, ce qui a eu pour effet de cramer une bonne dizaine de CDs vierges.
Finalement, après quelques tests, plusieurs gravures ont fonctionné avec les parametres suivants :

Ajouter :

combined_mode=libata

Au menu.lst en parametre au noyau

Ajouter :

options libata atapi_enabled=1

Au fichier /etc/modprobe.d/options

Et finalement ne pas laisser la detection de vitesse de gravure, avec un graveur 40x, la gravure s’effectue (pour le moment) sans problèmes à 32x.

Je deteste ce genre de bidouille…

Impossible de graver après un upgrade en Hardy ? symptomes de ce type :

Errno: 5 (Input/output error), test unit ready scsi sendcmd: fatal error

ou :

/dev/scd0 is not a cdrom device

ou encore :

failed to IDENTIFY port is slow to respond, please be patient

Ou finalement, un cdrecord -scanbus désesperemment muet ?

La solution est cachée ici et ici. Ajoute l’argument combined_mode=ide à / aux la / les ligne(s) kernel du menu.lst et tout reviendra dans l’ordre.

update

Rapide le Héron, un upgrade proposé ce soir me fait passer en 2.6.24-17 et corrige le problème. Classe.

Comme mentionné dans le post précedent, afin de pouvoir démarrer des kvm NetBSD, je me disais qu’une upgrade tranquille en Gutsy et son noyau 2.6.22 seraient du meilleur effet. Je n’ai de cesse de le répéter: naif. Je suis naif.

Je vois défiler l’apt-get dist-upgrade (du moins son pendant clicka-graphico-convi), et pressens moult emmerdes à la lecture de beaucoup trop d’unmet dependancies… mais bon, c’est démarré, c’est démarré, advienne que pourra.

Et c’est l’heure du reboot.
Et ça merde à plein tubes.

[ 227.335011] device-mapper: table: 254:1: linear: dm-linear: Device lookup failed

Ça, plein de fois. Je me décompose devant ce reboot misérable. Bon, honnètement, un minimum de recherche m’apprend que c’est le package evms qui met le bordel. J’étais pas en mode apprentissage, donc, j’ai jugé qu’un # dpkg --purge evms serait suffisant dans l’immediat.

Reboot, 2.6.22 fonctionnel.
# ifconfig -a

humm… eth1 ? bizarre.
# rmmod atl1 && modprobe atl1 (atl1 c’est le driver de ma NIC)… eth2.
Je deteste ce genre de truc.
Finalement, c’est vck sur #gcu qui m’informe que de nouvelles regles udev du type persistent-net.rules s’occuppent de gérer “intelligemment” l’association MAC – device. Moui. Bah en attendant, 75-persistent-net-generator.rules s’amusait à incrémenter le fichier 70-persistent-net.rules. J’ai reglé l’histoire en collant dans ce dernier une rule custom :

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1c:fc:80:a3:36", NAME="eth0"

Voila, ça, c’est reglé.
Hm.
Pas de X.
Prévisible.

J’ai une carte nvidia. Oui je sais, nvidia, mal, driver propriétaire, j’irai cramer en enfer et ce simple fait anihile tout ce que j’ai pu réaliser. Mais en attendant, j’ai une nvidia. Une GeForce 6600 pour être précis. Et devine quoi ? le driver X n’est plus nvidia-glx, mais nvidia-glx-new. Evident hein ?

Pour finir, de manière assez incompréhensible, l’upgrade m’a réinstallé Xgl (ou au moins réactivé), un petit # dpkg --purge xserver-xgl a reglé l’histoire.

Ah, un dernier truc, les applets relous.
Je sais pas pour vous hein, mais moi, /etc/network/interfaces, ça m’allait très bien. Alors le Network-Manager de mes deux là, c’est killall -9 nm-applet et trash du démarrage dans “sessions”. Et je ne vais meme pas m’attarder sur cette merde intersidérale qu’est trackerd pour lequel ils ont du se tromper de déscription, je pense qu’il s’agit simplement d’un consommateur de disque / CPU qui tourne sous forme d’applet. killall.

Moyennant tout ce beau merdier, ma Gutsy tourne, et mon NetBSD kvm aussi :)