Archlinux.fr [Forums]

Bonjour! J'ai un gros soucis avec Arch. Jusqu'ici tout allait bien, ensuite j'ai fait une mise à jour hier. Et depuis, Archlinux ne démarre plus.

Le démarrage se bloque à

:: Waiting for UDev uevents to be processed [BUSY]

Et plus rien ne bouge.

J'ai au début pensé que c'était dû à un soucis avec sdhci-pci, donc je l'ai blacklisté à partir de la ligne de grub (Arch ne démarre plus), mais ça reste bloqué là.

Merci d'avance de votre aide!

Est-ce que l'image fallback démarre ?
Sinon, il faudrait faire un chroot de ton Arch et réinstaller la version précédente d'udev et cie (via ARM au besoin Downgrade).

Non, le failback ne démarre pas non plus, il bloque au même endroit.

Mais faire un chroot serait la seule manière?

Je viens juste de tout réinstaller à partir de zéro, et il me refait pareil. =/


EDIT:
J'ai essayé d'ajouter acpi=off à la fin de la ligne de kernel de grub, et ça démarre. Mais avec une résolution minable. Le problème pourrait venir de là?

delta01 a écrit :Mais faire un chroot serait la seule manière?

Oui, dans la mesure où réinstaller Arch en entier ne résout que très rarement quelque chose.

delta01 a écrit :J'ai essayé d'ajouter acpi=off à la fin de la ligne de kernel de grub, et ça démarre. Mais avec une résolution minable. Le problème pourrait venir de là?

Probablement.
Il faudrait que tu récupères le log le plus pertinent, /var/log/boot ou /var/log/everything.log.
Puis, en attendant, rétrograder udev et plus si besoin.

Voilà ce que j'ai récupéré de /var/log/boot et everything.log (en démarrant avec acpi=off)

boot: http://pastebin.com/Uv2LP9fR

everything (trop gros pour pastebin): http://www.mediafire.com/?1zk19r3fk6sqsgk


J'ai essayé:
/var/cache/pacman/pkg/
pacman -U <nom_du_fichier_du_paquet>

Il réinstalle udev, mais ça ne change rien.

J'ai essayé de downgrader udev avec le frozen du 06 avril 2011, mais il me dit que plusieurs paquets sont en conflit.

Et si j'essaie de mettre tout le système à cette date, pareil.

delta01 a écrit :Voilà ce que j'ai récupéré de /var/log/boot et everything.log (en démarrant avec acpi=off)

Ben justement, les logs sans le acpi=off seraient intéressants (si bien sûr y a des trucs dedans). Le boot se fera certainement écrasé, mais c'est moins grave (faudrait récupérer ce log avant de redémarrer en montant juste ta partition via un livecd quelconque, sinon tant pis), pour le everything, tu devrais en avoir une sauvegarde, il y en a plusieurs, regarde selon les dates.

delta01 a écrit :J'ai essayé de downgrader udev avec le frozen du 06 avril 2011, mais il me dit que plusieurs paquets sont en conflit.

Via ARM ça devrait le faire pourtant. Du genre ?

Euh désolé mais j'ai pas vraiment compris quand est-ce que je dois récupérer les logs?
Je démarre sans le ACPI=off, du coup bah ça démarre pas et je dois éteindre. Ensuite avec un live-CD, je vais chercher les fichiers?

Pour pacman -Syyuu :

Je ne suis pas très doué pour interpêter ces messages ^^'

delta01 a écrit :Euh désolé mais j'ai pas vraiment compris quand est-ce que je dois récupérer les logs?
Je démarre sans le ACPI=off, du coup bah ça démarre pas et je dois éteindre. Ensuite avec un live-CD, je vais chercher les fichiers?

C'est ça. Ou tu démarres sans et tu récupères le everything.log précédent si c'est possible -- ils sont numérotés + date (dans ce cas, on aura pas le boot, mais c'est moins grave).

delta01 a écrit :Pour pacman -Syyuu :

Vu les paquets indiqués, tu remontes beaucoup trop loin (j'imagine que tu as pris l'exemple du wiki). Prends la date de juste avant ta mise à jour à problème.

Pour les fichiers, J'ai qu'un seul everything.log dans /var/log/
Après avoir redémarrer sans le ACPI=off, puis attendu 5mn sur le blocage de udev et éteint la machine. Il n'y a rien de plus dans les fichiers...

J'avais pas pris l'exemple du wiki, mais un frozen qui était déjà dans mon mirrorlist (il était commenté).
On peut le faire avec n'importe quelle date? Donc si je mets http://arm.konnichi.com/2012/01/17/$repo/os/$arch/ ça devrait aller?
Je vais essayer ça.


Merci de ta patience! =)


EDIT: J'ai remis le système au 17/01. Ça démarre enfin comme il faut. Merci beaucoup.

Juste pour info, il n'a pas touché à udev, mais au noyau et à ndiswrapper.

Je suppose que les mises à jour finiront par régler ce soucis, et qu'un jour je pourrais avoir la dernière version du noyau?

delta01 a écrit :Pour les fichiers, J'ai qu'un seul everything.log dans /var/log/

C'est pô bien, surtout pour ces histoires (soit tu n'as pas installé logrotate, soit tu n'as pas lancé crond dans ton rc.conf... soit tu n'en veux peut-être pas et c'est ton droit ).

delta01 a écrit :Juste pour info, il n'a pas touché à udev, mais au noyau et à ndiswrapper.

Je suppose que les mises à jour finiront par régler ce soucis, et qu'un jour je pourrais avoir la dernière version du noyau?

C'est possiblement une régression, donc ça peut disparaître. Ça dépend aussi si le bug remonte (et pour le faire remonter autant avoir le log).

Regarde si ça peut te dépanner https://bbs.archlinux.org/viewtopic.php?id=92189

@FoolEcho Euh nan j'ai fait aucun des deux trucs que tu as dit. C'est censé faire quoi au juste? J'ai jamais entendu parler de ça.
Si j'ajoute crond (dans DAEMONS() je suppose?), que je remets les dépôts, fais les mises à jour, démarre, plante, éteinds le pc, remet le dépôt frozen, remet le système à la date du 17. Est-ce que ça va? J'aurai les fichiers?

@xanataz Merci mais j'utilise pas nouveau, ça plante trop souvent. J'ai gardé celui d'intel (J'ai une carte graphique nVidia et un chipset intel).

delta01 a écrit :C'est censé faire quoi au juste? J'ai jamais entendu parler de ça.

logrotate permet de conserver les anciens logs justement (par défaut, il en conserve 4 il me semble). C'est une dépendance optionnelle de crond (cependant il est dans base, donc tu devrais l'avoir -- ou alors il a été rajouté récemment ?) et il faut donc lancer ce service.

delta01 a écrit :Si j'ajoute crond (dans DAEMONS() je suppose?), que je remets les dépôts, fais les mises à jour, démarre, plante, éteinds le pc, remet le dépôt frozen, remet le système à la date du 17. Est-ce que ça va? J'aurai les fichiers?

Oui.

Je viens juste de suivre à la lettre ce que j'ai dis, et je n'ai qu'un seul everything.log ...

J'ai ça dans mon rc.conf:

# DAEMONS
DAEMONS=(syslog-ng crond dbus @wicd gdm)

... ... je n'y avais bêtement pas pensé avant, mais ça ne doit pas fonctionner du fait que ça bloque à udev et comme les services ne démarrent qu'après, y a forcément aucune rotation des logs possibles... Pas le choix: pour obtenir le log, il faut que tu plantes la machine et que tu utilises un livecd pour le récupèrer en montant la partition qui renferme /var (prends essentiellement everything.log ainsi que /var/log/boot).

N'hésite pas à les poster qu'on voit un peu ce qu'il se passe.

J'ai le même problème, sauf que j'attends et atteinds le timeout de udev et que le système se lance. Dans mon cas c'est l'initialisation de la carte Wifi (ipw2200) qui merdoie. Le module est chargé cependant le périphérique n'est pas vu par le système, une sombre histoire de J'ai tenté de démarrer avec une option kernel noacpi pour rigoler un coup, puis avec irqpoll car il y avait une histoire d'IRQ spaghetti mais le résultat fût décevant, et je ne suis retrouvé avec l'interface loopback seulement.

J'avais de grands espoirs en la nouvelle version de udev (178) mais rien ne fit. Je retrouve tout de même ma belle interface lorsque je fais un modprobe à la main.

Salut, désolé de la réponse tardive, j'étais en examens.

J'ai attendu 15 minutes montre en main avec le "Waiting for udev...", rien n'a bougé =X C'est quoi le timeout? On peut le régler?

Par contre, comme y'a rien qui boot, j'suis obligé d'éteindre le pc, mais y'a aucun everything.log =/ (Ai regardé avec un liveCD Arch et un liveCD Ubuntu).

> C'est quoi le timeout? On peut le régler?

C'était une option qui existait il y a encore peu : http://projects.archlinux.org/initscrip ... =a1aee1e36

Je vais expliquer ma solution à ce problème un peu génant : j'ai localisé le module en faute, pas difficile car je n'avais plus de wifi. Je l'ai mis en blacklist en utilisant le paramètre kernel modprobe.blacklist=ipw2200, puis je l'ai chargé avec rc.local ('modprobe ipw2200'). C'est à l'arrache et ça fonctionne. \o/

Il faut dans ton cas arriver à déterminer quel est le module en cause, peut-être en ajoutant avec l'option debug dans le ligne de paramètres du kernel.

MEIN GOTT !

C'est xanataz qui avait raison! oO"

Merci mimas, j'ai trouvé grace à toi. Avec debug dans la ligne de kernel j'ai pu voir que ça merdait à cause de nouveau.

J'y aurai jamais pensé étant donné qu'il n'est pas installé et que j'utilise le pilote INTEL. (J'ai deux carte graphiques, et vu les habituels soucis de nouveau, j'ai préféré utiliser l'intel).

J'ai donc ajouté nouveau dans le blacklist, et ça démarre! \o/
Mais je ne le relance pas dans rc.local, car je ne m'en sert pas.

Mais quelqu'un sait pourquoi il bloque mon démarrage alors qu'un
yaourt nouveau

Me renvoie qu'aucun paquet contenant ce mot n'est installé?

En fait, j'utilise CTKArch, et j'ai entendu que son créateur avait activé nouveau dès qu'une carte nvidia existe. Je pensais qu'une fois désinstallé, ça ne poserait plus ce soucis (et jusqu'ici ça n'en a pas posé). Est-il possible de le désactiver? Pour peu que quelqu'un sache où c'est allé se planquer.


EDIT: La marche suivie pour les suivant:

Dans grub:
Appuyer sur E en sélectionnant Archlinux.
Editer la ligne Kernel (la 2e).
Ajouter à la fin: debug
ENTER
B (pour booter avec la ligne modifiée).

Là, voir qu'est-ce qui bloque le démarrage.

Ensuite, redémarrer en liveCD.
Et modifier /boot/grub/menu.lst
Et ajouter sur la ligne de kernel: Suivi du nom du module qui bloque le démarrage.

Si le module est important, le rajouter dans rc.local.