| ||||||||
Astucien ![]() | Bonjour, Il y a différents OS sur mon PC : WinXP, Win7, Debian Lenny, Debian Squeeze, Archlinux et Manjaro (version simplifiée de Archlinux) Description de mon problème : J'allume le PC et je lance une des Windows (obligé pour le boulot) puis quand j'ai fini ce que j'avais à faire, je ferme Windows avec l'option "redémarrer" pour booter sur l'une ou l'autre des Debian. Inévitablement, arrivé à la 4ème ligne : waiting for /dev to be fully populated... le prompt clignote 2 ou 3 fois puis disparaît et plus rien ne se passe. A ce stade, je suis complètement bloqué : clavier inerte mais la LED qui indique les accès aux disques est allumée en permanence. Il n'en est pas moins que - même si j'attends longtemps (il y a parfois des timeout très longs) - je n'ai d'autre choix que d'éteindre le PC manuellement en tenant enfoncé le bouton de mise en marche. Je rallume ensuite le PC et boote directement sur une des Debian et là, pas de problème : le boot se déroule correctement. C'est aussi le cas si j'ai éteint complètement Windows auparavant : le boot des Debian se déroule sans problème directement. J'en déduis que si on n'éteint pas complètement le PC, les Windows gardent la main sur les disques et en bloquent l'accès si on ne redémarre pas un ou l'autre des Windows. Bizarrement, je ne rencontre pas ce problème avec Archlinux ou Manjaro. Quelqu'un aurait-il une explication ? voire une solution ? Merci d'avance
| |||||||
Publicité | ||||||||
| ||||||||
![]() ![]() | Bonjour Mimile, il fût un temps où des HOWTO disaient de démarrer sous Windows (DOS) pour initialiser une carte de son, puis redémarrer sous Linux pour l'utiliser. L'initialisation par Windows restant après le redémarrage et même après l'arrêt de l'ordinateur. Je pense que ton problème vient de périphériques dont la mémoire est volatile et dont le firmware doit être copié vers cette mémoire à chaque démarrage par le pilote pour pouvoir lui attribuer des ressources telles une IRQ, une zone de lecture et d'écriture en mémoire vive, etc. Si un de ces périphérique contient le firmware de Windows et que le module Linux ne peut y copier son propre firmware, Udev qui initialise le matériel ne peut lui attribuer de ressources, d'où l'attente d'un "timeout" qui prolonge le démarrage des fois à l'infini. Tu dois savoir que plusieurs périphériques ne doivent être branchés qu'après que leur pilote ait été installé. Sinon, le firmware n'est pas disponible et le matériel en question ne peut répondre à l'offre de ressources du système. Sous Windows, on le demande souvent et ça s'applique aussi aux autres systèmes d'exploitations. J'ai une carte USB Bluetooth dont la mémoire est volatile. Si ce périphérique est branché avant que j'allume l'ordinateur, ni le BIOS, ni Linux toutes distributions, ni Windows ne le détectent. Il n'existe pas tant que je ne l'ai pas débranché et rebranché pour que son firmware lui soit copié. Alors, il peut accepter les ressources du système. Comme proposition, il pourrait être bon de débrancher certains périphériques amovibles si tu en as, un à la fois pour plus de certitudes, quand tu arrives à l'écran de Grub après un redémarrage depuis Windows, afin d'ifentifier le matériel qui pose problème à Debian, et ce, avant de la démarrer. Si ArchLinux n'a pas ce problème. c'est peut-être que le firmware du matériel concerné par le problème est présent dans l'initramfs et/ou que Udev a une règle précise pour ce matériel. Pour plus de précisions, il faut savoir quels périphériques posent problèmes à Debian et comparer le contenu de l'initramfs de Debian avec celui d'ArchLinux. Les paramètres passés aux noyaux respectifs ainsi que la configuration des noyaux peut aussi avoir un effet. Modifié par Logicien le 18/09/2012 17:09 | |||||||
![]() ![]() | Bonjour Paul Merci pour toutes ces précisions. Ta suggestion est certainement valable mais en fait de périphériques qu'on pourrait débrancher pour voir si le problème disparaît, il n'y a que le clavier, la souris (même pas en USB - toujours l'ancien système avec des petits connecteurs cylindriques) et l'écran. Je n'imagine pas que l'un d'eux puissent occasionner le cas de figure que tu envisages. Evidemment, il y a d'autres périphériques USB : deux imprimantes et un DD externe, mais le phénomène se produit même s'ils sont éteints. Se pourrait-il que le simple fait qu'ils soient connectés même éteints puisse jouer un rôle ?
| |||||||
![]() ![]() | Un redémarrage à chaud peut changer, comme ton problème le montre, la façon dont Linux démarre et peut-être aussi la façon dont le BIOS initialise le matériel après le redémarrage. Peut-être que le USB Legacy n'est pas activé dans le BIOS. Revoir la configuration du BIOS. De mon côté, je redémarre plus souvent que je n'arrête mes systèmes d'exploitations présentement. Le firmware de ma carte USB Bluetooth reste opérationnel après un redémarrage et je n'ai pas à débrancher et rebrancher la carte pour qu'elle soit détectée. Pour savoir si un périphérique éteint peut influencer quelque chose, tu exécutes la commande lspci et/ou lsusb afin de voir si le matériel éteint est détecté. Voir aussi en le débranchant de l'ordinateur si cela change quelque chose. Si tu démarres à froid vers Lenny ou Squeeze et redémarres à chaud vers Squeeze ou Lenny, est-ce que le démarrage vers Squeeze ou Lenny s'interrompt? Cela peut te dire si c'est vraiment Winfrooze qui est seul en cause ou si le problème a une autre source. Je pense que les différents chipsets et firmwares d'un ordinateur ne sont pas initialisés de façon complètement compatibles entre Windows et Linux, d'où la nécessité d'un démarrage à froid. Est-ce que tout ton matériel est fonctionnel après un démarrage à froid sous Lenny et Squeeze? Comme Squeeze est plus récente, je préférerais faire des tests avec Squeeze après une mise-à-jour complète. ArchLinux et Debian sont des distributions assez différentes. Elles n'ont pas le même contenu dans le répertoire /etc/udev par exemple. Identifier le problème demande d'y aller par élimination, avec patience. Modifié par Logicien le 19/09/2012 23:05 | |||||||
![]() ![]() | Salut Paul conditions : Squeeze - démarrage à froid - imprimantes et DD externe USB éteints :
Conditions : Squeeze - démarrage à froid - imprimantes et DD externe USB en marche :
Tous sont fonctionnels (la 4ème port USB 2 sert occasionnellement quand je dois me servir de mon lecteur de carte d'identité pour accéder à divers sites pour lesquels j'ai des accréditations ou pour mon lecteur de carte flash pour transférer des photos numériques sur mon PC et réciproquement). résultat de lspci (démarrage à froid) :
Le problème est que je ne peux te montrer ce qui précède qu'APRES un démarrage à froid vu que quand j'ai utilisé Win7 (ou XP) auparavant et que je fais un redémarrage à chaud, ça bloque sur "waiting for /dev to be fully populated" et que je n'ai pas d'autre choix que d'arrêter le PC à l'arraché, ce qui implique que par la suite, je fais un démarrage à froid. A noter que d'une distribution Linux à l'autre, il n'y a jamais de problème de boot similaire. J'ai la nette impression que c'est au niveau des disques que le problème se pose : d'une manière ou d'une autre, dans le cadre d'un redémarrage à chaud depuis Win7 ou WinXP, les disques restent montés ce qui bloque le boot des Debian (je ne comprends pas bien le sens de "populated" mais /dev me fait penser à la dénomination habituelle des disques : /dev/sda, /dev/sdb, etc...). Reste le mystère Archlinux qui se contrefiche de savoir quel OS a fonctionné auparavant : que ce soit W7 ou XP, elle monte les disques sans commentaire. Ceci explique qu'Archlinux - une vraie rolling release - soit la distribution Linux qui, depuis que je l'ai découverte, a ma préférence et, de ce fait, qui est celle que j'utilise essentiellement. On ne s'ennuie vraiment pas avec cette distribution qui, de plus, est la seule qui arrête complètement mon PC (en 2 secondes) - alors que les Debian n'y arrivent pas, le PC restant sous tension et l'écran continuant de recevoir un signal puisqu'il continue d'afficher les lignes relatant l'arrêt des services et autres fonctions : il reste sur powerdown ou power off ou quelque chose comme ça, j'entends encore le léger ronronnement d'un moteur électrique (le ventilo ou les disques ?) et il me faut appuyer brièvement sur le bouton de mise en marche pour que tout s'arrête effectivement.
Modifié par Mimile le 23/09/2012 15:34 | |||||||
![]() ![]() |
Oui, les gens ont du mal à s'habituer à systemd, mais pour ça, c'est vraiment bien. | |||||||
![]() ![]() | Pour Udev, peupler le répertoire /dev consiste à créer des fichiers de périphériques, des noeuds (en anglais des nodes, d'où la commande mknod), qui seuls permettent d'accéder au matériel. Peut-être qu'en désactivant le Quick Power On Self Test dans la configuration du BIOS, cela permettrait d'initialiser complètement le matériel au redémarrage comme au démarrage lors du Power-on self-test afin de faire en quelque sorte, un 'redémarrage à froid'. Je ne sais toujours pas si un redémarrage depuis une de tes distributions Linux vers Lenny ou Squeeze crée un gel ou non. Peut-être que Systemd y est pour quelque chose dans le fait qu'ArchLinux et Manjaro ne gèlent pas après un redémarrage depuis Windows. Udev est intégré à Systemd. Debian est encore avec Sysvinit par défaut. Modifié par Logicien le 24/09/2012 00:56 | |||||||
![]() ![]() | Mimile a écrit : Je confirme que je peux passer d'une distribution Linux à une autre (quelles qu'elles soient) sans jamais rencontrer de problème de boot, que mes périphériques soient - ou non - en marche Pour le surplus, je n'ai pas, dans mon BIOS, d'option Quick Power on Self Test ou quelque chose d'approchant (pour mémoire, mon PC est quasiment un ancêtre puisqu'il va sur ses 10 ans !) Si je veux utiliser Squeeze après W7 ou XP, je contourne le problème en démarrant Arch (très rapide) et au premier écran d'accueil, je redémarre sur Squeeze et ça passe. En ce qui concerne l'arrêt complet du PC, je me demande si ce n'est pas une question de noyau car dans un de mes messages sur le forum Arch, j'ai écrit quelque chose comme ; "depuis qu'on est passé au noyau 3.?.?.?, j'obtiens l'arrêt complet du PC" ce dont je déduis qu'auparavant Arch rencontrait le même problème. A noter que quand j'ai écrit ce message, c'était à l'époque de rc.conf, initscripts et sysvinit - donc bien avant que j'entende parler de systemd. Cela dit, durant la courte période où j'ai installé LMDE qui disposait aussi d'un noyau 3, je rencontrais aussi ce problème d'arrêt inabouti. J'envisage d'installer la dernière Linux Mint à la place de Manjaro (sans intérêt par rapport à ma Arch) pour voir si elle rencontrera aussi ce cas de figure.
Modifié par Mimile le 24/09/2012 10:27 | |||||||
![]() ![]() |
Manjaro, vu la rapidité de réinstallation, et la qualité de son environnement Cinnamon, ça vaut le coup. Mais bon, Arch doit être réservé à une élite ? Ou alors, on ne réinstalle jamais et on garde des bugs incompréhensible.
| |||||||
![]() ![]() | Salut Esclapion, Je suis partiellement d'accord avec toi. - que Arch soit destinée à une "élite", on peut l'admettre dans la mesure où elle est d'un abord plus complexe que des distributions "grand public" comme ubuntu (et ses variantes), Linux Mint, Mandriva et même Debian qui s'installent toutes seules. - Cela dit, l'élite en question permet, grâce à des tutoriaux très accessibles et à un forum francophone hyper-réactif, à de modestes linuxiens comme moi , dépourvus de toute formation informatique, de l'utiliser sans trop de difficultés, à condition, évidemment, de connaître le B-A BA des commandes Linux et des notions générales communes à toutes les distributions (fstab, grub.cfg, etc...). Pour le surplus, je ne comprends pas bien le sens de ta phrase :
En ce qui concerne, Arch, je ne rencontre aucun bug : au contraire, elle fait ce que les diverses distributions Debian que j'ai testées (Lenny, Squeeze, Wheezy, LMDE et aussi, si j'ai bonne mémoire Mandriva 2008), ne parviennent pas à faire : 1) prendre la suite de W7 ou XP après un redémarrage à chaud sans freezer et 2) éteindre le PC complètement. Je n'ai donc aucune raison de réinstaller Arch (qui, de plus, boote beaucoup plus rapidement que toutes les autres et s'arrête le temps de compter jusqu'à 2). Ceci étant, comme apparemment, les problèmes (bugs incompréhensibles) que je rencontre avec les diverses Debian ne semblent pas concerner grand monde, je finis par me demander s'ils ne sont tout simplement pas dus à l'ancienneté de mon PC (10 ans) - j'ai posté sur le forum Debian au sujet de ces 2 problèmes sans obtenir de réponse apportant une solution. En ce qui concerne Manjaro, je l'ai installée suite à l'enthousiasme dont tu avais fait preuve en annonçant sa sortie. Tout comme Arch, elle n'est pas gênée dans son boot après un redémarrage à chaud de Windows et arrête le PC correctement. Mais, à l'analyse, elle fait double emploi avec Arch tout en étant à mon sens moins aboutie (par exemple, pour installer mes imprimantes, j'ai dû moi-même installer cups et ses accessoires, ce qui n'est pas à la portée d'un Ubuntien ou d'un Mintien lambda pour qui il suffit de brancher son imprimante pour qu'elle s'installe toute seule). Comme je l'ai dit, je pense installer la dernière mouture de Linux Mint (pas la LMDE) pour voir si avec son nouveau noyau, les problèmes évoqués ici subsistent. Je ne manquerai pas d'en faire retour. Amicalement,
| |||||||
![]() ![]() | Mimile (demi-mille ? tu as déjà posté sur le problème d'extinction de Debian et ses ami(e)s. Je ne vais pas investiguer de nouveau ce cas, moi dans le fichier /etc/default/halt, j'ai # Default behaviour of shutdown -h / halt. Set to "halt" or "poweroff". HALT=poweroff c'est pour couper le courant à l'arrêt. NETDOWN=no c'est pour dire au script halt que ce n'est pas nécessaire que les interfaces réseaux soit éteintes complètement à l'arrêt, tel que brièvement expliqué dans le script /etc/init.d/halt lui-même: # Make it possible to not shut down network interfaces, NETDOWN=no m'évite des blocages liés au réseau à l'arrêt. Le wake-on-lan c'est le BIOS qui le gère de toutes façons dans sa configuration. J'aimerais savoir si l'arrêt de tes Debian et ses ami(e)s coupe le courant avec ce contenu du fichier /etc/default/halt. Si je comprend bien ce que tu a dis il y a deux messages, après avoir redémarré depuis Windows, si tu utilises Grub d'ArchLinux pour démarrer Squeeze ou Lenny , aucune ne bloque. Quand tu utilises les chargeurs Grub de Squeeze ou Lenny pour démarrer Squeeze ou Lenny suite à un redémarrage depuis Windows, ça bloque. Il faut regarder la version de Grub d'ArchLinux et les paramètres que Grub passe aux noyaux Linux de Lenny et Squeeze. La comparaison avec les versions de Grub de Lenny et Squeeze et les paramètres qu'ils passent à leurs noyaux Linux contient peut-être des éléments de solutions. Modifié par Logicien le 24/09/2012 22:29 | |||||||
![]() ![]() | Salut Paul, Je sais que j'ai déjà posté sur ces sujets mais jusqu'à présent aucune solution n'a été trouvée. Si j'ai reposté, c'est parce que je me suis rendu compte qu'Archlinux ne rencontrait pas les problèmes évoqués. Cela dit, rien de neuf sous le soleil ... (Sous Squeeze), j'avais ceci :
A tout hasard, j'ai ajouté : NETDOWN=no puis j'ai éteint Squeeze ; même résultat qu'auparavant : après l'affichage final "poweroff', le PC reste sous tension. Pour être précis, je n'utilise que le grub.cfg de Squeeze qui démarre Archlinux (et les autres OS) comme ceci (extrait) :
Ce que j'ai voulu dire, c'est qu'après avoir utiliser une des Windows et que je veux redémarrer sur Squeeze (qui va d'office bloquer sur la ligne "waiting for /dev to be populated), je fais un détour par Arch - qui boot sans problème - pour aussitôt redémarrer, ce qui m'affiche mon menu grub de Squeeze et à ce moment, Squeeze peut booter normalement. Mais en aucun cas, je n'utilise le grub d'Arch.
| |||||||
![]() ![]() | Mimile, ne serait-il pas plus simple d'éteindre Windows avant d'utiliser Lenny/Squeeze? Ce gel de Lenny/Squeeze démontre l'incompatibilité Windows/Linux lors des redémarrages à chauds. J'ai eu le cas inverse, un écran bleu de la mort en redémarrant sous Windows après être démarré sous Linux. Un périphérique amovible en était la cause. Je n'avais pas ce problème lors d'un démarrage à froid sous Windows. Peut-être ne trouverons-nous jamais la solution Mes recherches porteraient sur la comparaison entre ArchLinux/Lenny/Squeeze des fichiers de configurations contenus dans les répertoires /etc/modprobe.d/ et /etc/udev/. Sous ArchLinux, ces répertoires sont presque vides, alors que sous Debian il en existent quelques-uns. Les options passées aux noyaux Linux par Grub méritent aussi un examen. Si tu veux continuer à analyser, la sortie de la commande dmidecode (à installer si nécessaire; apt-get install dmidecode) me permettrait de mieux connaitre ton ancêtre d'ordinateur. Je remarque que l'APM (Avanced Power Management) n'est plus activé dans les noyaux et les modules d'ArchLinux et Debian. L'arrêt avec coupure du courant ne peut se faire sous Linux qu'avec l'ACPI. As-tu installé et activé le démon acpid sous Debian et ArchLinux? Les énigmes sont des sources de motivations | |||||||
![]() ![]() | Bonjour Paul, Je te cite :
Eteindre Windows implique d'arrêter le PC puis le rallumer aussitôt, ce qui est généralement déconseillé pour éviter que des pics de voltage se produisent sur des composants électroniques par encore tout-à-fait déchargés. Et, serait-ce une impression (il faudrait que je chronomètre) mais un arrêt complet de XP ou de Seven me paraît beaucoup long qu'un redémarrage à chaud (peut-être parce qu'ils n'arrêtent pas tout ce qu'il faudrait - ce qui expliquerait mon problème). On sait très bien que Microsoft est parfaitement égocentrique et je suppose que ses concepteurs n'ont pas (voulu ?) imaginer qu'on puisse redémarrer Windows pour booter sur un autre OS. Bref, voici le contenu de /etc/modprobe.d sous Squeeze : Sous Arch (systemd), au boot, il y a une ligne : starting acpid daemon Et : [okapi@Archibald ~]$ lsmod | grep acpi A moins que ce qui précède t'inspire une solution, je te suggère d'en rester là, car même sur le forum debian, je n'ai pas eu de réponse constructive. A bientôt Modifié par Mimile le 29/09/2012 14:53 | |||||||
![]() ![]() | La sortie de la commande dmidecode va permettre, si le lien reste, de mieux connaître ton ordinateur, puisque qu'il est généralement question de lui dans tes messages. Si je voulais cette sortie, c'était en autres pour m'assurer que l'ACPI est bien supporté par ton ordinateur. Je suppose que tes distributions Linux arrêtent l'ordinateur par ACPI. Chez moi, les paquets acpi suivant sont installés dpkg -l *acpi* ii acpi 1.6-1 amd64 displays information on ACPI devices Assure-toi que les paquets en gras sont installés et que la ligne MODULES="all" est décommentée dans le fichier /etc/default/acpid . Assure-toi aussi que le démon est démarré avec le système grâce à la commande ls /etc/rc?.d | grep acpi Chez moi cela donne S01acpi-fakekey S'il y a un K plutôt qu'un S , alors, il faut exécuter les commandes update-rc.d acpid enable update-rc.d acpi-fakekey enable Chez moi, lorsque je ferme ma session graphique et que je presse sur le bouton d'alimentation, l'arrêt se fait avec coupure de courant. Un desperado serait de démarrer en mode administrateur, soit avec l'option S (pour Single) passée au noyau Linux afin de voir si la commande shutdown -P now fonctionne. Elle peut être essayée aussi en mode multi-utilisateurs. Ce n'est pas que je suis inspiré, c'est que j'ai l'imagination de mes connaissances. Je vais donc en rester là, puisque tu dis que d'autres n'ont pas trouvé de solution et que les essais suivant qui pourraient me venir en tête pourraient être hors de portée pour toi et sans garantie de succès.
Modifié par Logicien le 29/09/2012 15:02 | |||||||
![]() ![]() | Salut Paul, Je te cite :
A priori chez Archlinux, ils n'apprécie pas trop qu'on utilise pastebin pour soumettre un problème relatif à un autre OS car je viens de vérifier : le lien est mort. J'ai donc installé dmidecode sur Squeeze (j'y suis actuellement), et pour ne pas allonger démesurément ma réponse en te fournissant la totalité, j'ai exécuté : dmidecode | grep acpi qui me renvoie sous le rubrique BIOS information
Si tu veux l'entièreté du rapport, je l'ai uploadé sur zshare : http://www2.zshare.ma/ovphk4b2n3uy J'ai ensuite exécuté : sudo dpkg -l *acpi* qui renvoie :
Beaucoup moins étoffé que le tien ... Ensuite, j'ai décommenté MODULES="all" dans /etc/default/acpid et enfin :
pas de "K" à l'horizon Je reboote et vérifie si ça résoud le problème le problème de l'arrêt complet. Je reviens dans deux minutes. EDIT : me revoilà : hélas aucun changement : toujours arrêt incomplet du PC qui reste sous tension et qui nécessite une légère pression sur le bouton de mise en marche pour l'éteindre complètement. Bon, je te suggère d'en rester là car ça me gonfle (comme disent les jeunes d'aujourd'hui) de chercher (et de t'ennuyer) pour un détail somme toute secondaire. Encore merci pour tes efforts et à bientôt pour de nouvelles (més)aventures
Modifié par Mimile le 30/09/2012 12:00 | |||||||
Publicité | ||||||||
| ||||||||
|
Sujets relatifs | ||||||||||||||||||||||||||||||||
|