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

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.

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.

Salut Paul

conditions : Squeeze - démarrage à froid - imprimantes et DD externe USB éteints :

okapi@Squeeze:~$ lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Conditions : Squeeze - démarrage à froid - imprimantes et DD externe USB en marche :

okapi@Squeeze:~$ lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 1058:1001 Western Digital Technologies, Inc. External Hard Disk [Elements]
Bus 001 Device 003: ID 03f0:2b17 Hewlett-Packard LaserJet 1020
Bus 001 Device 002: ID 03f0:5311 Hewlett-Packard OfficeJet 6300
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

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) :

okapi@Squeeze:~$ lspci
00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2)
00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
00:00.3 RAM memory: nVidia Corporation Device 01aa (rev b2)
00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3)
00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1)
00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3)
00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3)
00:04.0 Ethernet controller: nVidia Corporation nForce Ethernet Controller (rev c2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce AC'97 Audio Controller (rev c2)
00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2)
00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3)
00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2)
01:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1)
05:07.0 Communication controller: Conexant Systems, Inc. HSF 56k HSFi Modem (rev 01)
05:08.0 USB Controller: NEC Corporation USB (rev 43)
05:08.1 USB Controller: NEC Corporation USB (rev 43)
05:08.2 USB Controller: NEC Corporation USB 2.0 (rev 04)

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.

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.

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.

Mimile a écrit :
....

A noter que d'une distribution Linux à l'autre, il n'y a jamais de problème de boot similaire.

....

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.

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.

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 :

Ou alors, on ne réinstalle jamais et on garde des bugs incompréhensible

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
NETDOWN=no

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,
# needed to use wake-on-lan

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.

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 :

okapi@Squeeze:~$ cat /etc/default/halt
# Default behaviour of shutdown -h / halt. Set to "halt" or "poweroff".
HALT=poweroff

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) :

menuentry "Arch Linux (on /dev/sda5)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set 8d61cac4-118f-476f-9974-5d1b7800deac
linux /boot/vmlinuz-linux root=/dev/sda5 ro vga=791
initrd /boot/initramfs-linux.img
}
menuentry "Arch Linux Fallback (on /dev/sda5)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set 8d61cac4-118f-476f-9974-5d1b7800deac
linux /boot/vmlinuz-linux root=/dev/sda5 ro vga=791
initrd /boot/initramfs-linux-fallback.img
}

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 . Je ne veux pas étirer pour rien ce message.

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 et malheureusement aussi d'obsessions.

Bonjour Paul,

Je te cite :

ne serait-il pas plus simple d'éteindre Windows avant d'utiliser Lenny/Squeeze?

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 :

okapi@Squeeze:/etc/modprobe.d$ ls -l
total 32
-rw-r--r-- 1 root root 4832 27 jun 2010 aliases.conf
-rw-r--r-- 1 root root 281 23 oct 2010 alsa-base-blacklist.conf
-rw-r--r-- 1 root root 1183 23 oct 2010 alsa-base.conf
-rw-r--r-- 1 root root 622 13 déc 2010 blacklist.conf
-rw-r--r-- 1 root root 456 13 déc 2010 fbdev-blacklist.conf
-rw-r--r-- 1 root root 23 19 fév 2011 i915-kms.conf
lrwxrwxrwx 1 root root 41 22 mai 2011 linux-sound-base_noOSS.conf -> /lib/linux-sound-base/noOSS.modprobe.conf
-rw-r--r-- 1 root root 26 7 nov 2010 radeon-kms.conf
okapi@Squeeze:/etc/modprobe.d$

idem pour /etc/udev (sous Squeeze) :

okapi@Squeeze:/etc/udev$ ls -l
total 16
-rw-r--r-- 1 root root 92 2 nov 2008 hdparm.rules
-rw-r--r-- 1 root root 281 13 déc 2010 links.conf
drwxr-xr-x 2 root root 4096 25 avr 14:03 rules.d
-rw-r--r-- 1 root root 218 13 déc 2010 udev.conf
okapi@Squeeze:/etc/udev$

Sous Arch : /etc/modprobe.d contient un unique fichier : modprobe.conf qui ne contient qu'une ligne :
options nouveau modeset=1

/etc/udev contient :

okapi@Squeeze:/media/Arch_root/etc/udev$ ls -l
total 8
drwxr-xr-x 2 root root 4096 28 jui 13:15 rules.d
-rw-r--r-- 1 root root 44 27 aoû 22:26 udev.conf
okapi@Squeeze:/media/Arch_root/etc/udev$

rules.d ne contient qu'une ligne : -rw-r--r-- 1 root root 2049 28 jui 13:13 85-hplj10xx.rules
udev.conf contient deux lignes commentées :
# see udev(7) for details
# udev_log="info"

Pour ce qui est du résultat de dmidecode, c'est tellement long que je l'ai stocké ici : http://pastebin.archlinux.fr/449908
Enfin pour l'acpid, il est installé sous Squeeze mais quand je fais lsmod, il n'apparaît pas dans les modules chargés.

J'ai essayé # modprobe acpid mais je n'obtiens pas de réponse satisfaisante : FATAL no module found

Et si j'essaye :# /usr/sbin/acpid start ou restart : je n'enregistre aucune réaction : retour au prompt direct.
J'ai aussi essayé /etc/init.d/acpid et là, j'ai une réponse encourageante : starting ACPI services mais quand j'ai voulu éteindre le PC, même résultat : arrêt partiel.

Sous Arch (systemd), au boot, il y a une ligne : starting acpid daemon

Et :

[okapi@Archibald ~]$ lsmod | grep acpi
pata_acpi 2388 0
libata 146119 3 pata_acpi,pata_amd,ata_generic

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

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*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Architecture Description
+++-====================================-=======================-========

ii acpi 1.6-1 amd64 displays information on ACPI devices
ii acpi-fakekey 0.140-5 amd64 tool to generate fake key events
un acpi-support (aucune description n'est disponible)
ii acpi-support-base 0.140-5 all scripts for handling base ACPI events such as the power button
ii acpid 1:2.0.16-1 amd64 Advanced Configuration and Power Interface event daemon
ii acpitail 0.1-4 amd64 Show ACPI information in a tail-like style
ii acpitool 0.5.1-3 amd64 command line ACPI client
un eepc-acpi-scripts (aucune description n'est disponible)
ii libacpi0 0.2-4 amd64 general purpose library for ACPI
ii wmacpi 2.2~rc5-1 amd64 ACPI battery monitor for WindowMaker

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
S02acpid
S01acpi-fakekey
S02acpid
S01acpi-fakekey
S02acpid
S01acpi-fakekey
S02acpid

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.

Salut Paul,

Je te cite :

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.

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

okapi@Squeeze:~$ sudo dmidecode | grep -i acpi
ACPI is supported

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 :

okapi@Squeeze:~$ sudo dpkg -l *acpi*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Description
+++-=====================-=====================-==========================================================
ii acpi 1.5-2 displays information on ACPI devices
ii acpi-fakekey 0.137-5 tool to generate fake key events
un acpi-support (aucune description n'est disponible)
ii acpi-support-base 0.137-5 scripts for handling base ACPI events such as the power bu
ii acpid 1:2.0.7-1squeeze4 Advanced Configuration and Power Interface event daemon

Beaucoup moins étoffé que le tien ...

Ensuite, j'ai décommenté MODULES="all" dans /etc/default/acpid

et enfin :

okapi@Squeeze:~$ ls /etc/rc?.d | grep acpi
S17acpi-fakekey
S18acpid
S17acpi-fakekey
S18acpid
S17acpi-fakekey
S18acpid
S17acpi-fakekey
S18acpid

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