Au chargement de ma machine (SSD), j’ai un arrête très long (env. 30 secondes) pour remplir /dev
Il y a déjà quelques temps que je l’observe.
je n’avais pas ce problème avant.
La ligne est
[mono]wating for /dev to be fully populated[/mono]
Merci.
Tu dis avoir 2 disques dans un autre poste (ssd + hdd sata) : Ca donne quoi si tu debranche le hdd ?
Peut être que c’est lui qui a du mal a se faire connaître de udev (pour une raison à identifier s’il s’avère que c’est bien le cas, raison qui peut être un signe avant coureur de panne imminente).
C’est une idée, je testerai.
EDIT : non, même chose, une trentaine d esecondes.
Doit y en avoir un particulierement long à se charger ?Doit y en avoir un particulierement long à se charger ?
/dev comme devices, périphériques.
Débranche tous les périphériques qui ne soient pas essentiels au bon fonctionnement, tout particulièrement les périphériques usb superflus au démarrage (clavier usb, souris usb, stockage usb,webcam usb, clé wifi usb, cable imprimante usb, hub usb, $VA_SAVOIR_QUOI*USB …) puis teste son comportement.
Teste le démarrage en rebranchant les périphériques un à un pour trouver celui qui retarde le processus.
En voilà des idées, pourtant simples, auxquelles je n’ai pas pensées. Putain, qu’est-ce que ça sera quand je serai vieux 
Mais regarde tout de même les logs, sur la gauche, entre crochets tu as le nombre de secondes écoulées depuis lechargement du noyau, cela te permet de savoir si un module met du temps à se charger. Regarde le syslog aussi.
Ben non !
Rien vu d’anormal dans les logs : messages, dmesg, syslog.
débranché souris usb, clavier, imprimante et DD sata (second DD)
Rien de mieux.
Je n’ai pas testé en supprimant la RJ45 de la box car elle a toujours été présente.
Sur d’autres distribs, pas ce problème, que ce soit une stable ou une Buntu.
Par contre, dans les toutes dernières lignes de boute, j’ai une ligne orangée (alerte en principe) que je n’arrive pas à lire , défile trop vite.
Comment relire les lignes de boute ? J’ai su mais sais pu
Pour la lecture au boute, j’ai retrouvé avec “recherche”, un fil de 2010 un certain … ricardo répondait à une memande 
arrêt défilement : Ctrl S
reprise défilement : Ctrl Q
ou sinon, installation de bootlogd.
Tout ce qui a défilé sera écris dans un log que tu peux aller lire tranquillement une fois le sustème démarré (/var/log/bootlog je crois).
J’ai rencontré ce problème, que j’ai résolu un peu par miracle en utilisant systemd à la place de init. La ligne qui va bien dans /etc/default/grub :
Je n’ai par contre aucune idée de la raison pour laquelle ce problème a disparu (avec moults autres).
Normalement, si Ricardo est à jour de ses updates SID, il est déjà passé sous systemd…
[quote=“dric64”]ou sinon, installation de bootlogd.
Tout ce qui a défilé sera écris dans un log que tu peux aller lire tranquillement une fois le sustème démarré (/var/log/bootlog je crois).[/quote]
Voilà, c’est ça que je cherchais et que j’avais lu quelque part ici, merci, j’installe demain.
[quote=“Dunatotatos”]J’ai rencontré ce problème, que j’ai résolu un peu par miracle en utilisant systemd à la place de init. La ligne qui va bien dans /etc/default/grub :
Je n’ai par contre aucune idée de la raison pour laquelle ce problème a disparu (avec moults autres).[/quote]
Je regarde cette ligne demain mais en effet, j’ai systemd, seulement, bien qu’à jour, je suis fâché avec [mono]apt-get dist-upgrade[/mono] qui m’installe toujours un wagon de paquets provocant des dépendances insolubles.
Je n’utilise que apt-get ugrade. De ce fait est certainement dû le décalage des versions ?
systemd:
Installé : 208-8
Candidat : 215-5+b1
Probablement. Je ne fais que des dist-upgrades, et :
ced@DELL64:~$ apt-cache policy systemd
systemd:
Installé : 215-5+b1
Candidat : 215-5+b1
Table de version :
*** 215-5+b1 0
900 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status
208-8 0
800 http://ftp.fr.debian.org/debian/ jessie/main amd64 Packages
44-11+deb7u4 0
700 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages
700 http://security.debian.org/ wheezy/updates/main amd64 Packages
Qu’entends tu par “apt-get dist-upgrade qui m’installe toujours un wagon de paquets provocant des dépendances insolubles” ? Je n’ai pas l’impression d’avoir ce genre de problème. Le seul truc qu’il m’arrive de refuser, c’est de supprimer un paquet pour résoudre une dépendance si je ne vois pas son remplaçant dans la liste des mises à jour.
Sitôt après mes MAJs hebdomadaires, j’ai l’habitude de passer un petit coup de “fix-aptitude-dependencies” (le script de Syam) là : https://www.debian-fr.org/aptitude-gestion-des-dependances-et-orphelins-t35575.html
Je sais, c’est aptitude et non apt-get.
Or, actuellement, en rechargeant via “upgrade”, le résultat est ‘clean’.
Si je fais avec “dist-upgrade”, j’ai un bordel insoluble de dépendances non satisfaites.
EDIT :
Installé bootlogd.
Rien vu d’anormal et l’alerte dont je parlais plus haut ne concerne qu’un ‘jail’ de Fail2ban, sans importance et que j’ai modifié.
j’ai refait un essai en débranchant tout, y-compris la Box et un miniserveur de videosurveilance.
donc pratiquement plus rien de connecté sauf l’écran et j’ai toujours la même attente de /dev.
je laise tomber car en fait, ça ne me dérange pas plus que ça : 30 " une fois par jour, c’est acceptable.
C’est un phénomène connu, une solution consiste à précharger les pilotes “permanents” sans faire appel à udev :
http://www.debian-administration.org/article/620/Booting_Debian_in_14_seconds
Cela n’est pas très simple… J’avoue que je préfère attendre les 30 secondes… et utiliser l’hibernation au lieu de l’arrêt, sauf quand il vaut mieux réinitialiser le système complètement (changement de lieux, donc de connections réseau, par exemple).
Merci du lien
En effet, rien que la lecture de la page me prends 1 heure, alors ce n’est pas demain que je vais tester ce truc.
Je préfère, moi aussi, attendre 30" de + au boute.