# Erreur lancement OMV **URL:** \ **Category:** Support Debian\ **Created:** [Juin 27, 2021, 4:07 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872 "2021-06-27T16:07:03Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 27, 2021, 4:07 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/1 "2021-06-27T16:07:03Z")
Bonjour, Lorsque j’installe OMV version `openmediavault_5.5.11-amd64` ou version `openmediavault_6.0-amd64` Je reçois le message d’erreur suivant au lancement : ![Message_erreur](https://www.debian-fr.org/uploads/default/original/2X/0/06f9923fc12ae7cff6cde3bdabc98d17277105ee.jpeg) Le BIOS de ma machine [Shuttle NC10U](http://global.shuttle.com/products/productsDetail?productId=2425) possède la dernière version 104 Processeur présent Celeron 4205U J’ai essayé d’installe le système sur le M2, le disque dur 2.5 et sur une clé USB mais lors du démarrage le message d’erreur apparait en boucle Avez vous déjà rencontré ce type d’erreur ? Merci d’avance pour votre aide Bonne soirée ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 27, 2021, 4:42 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/2 "2021-06-27T16:42:04Z")
Au lancement de l’installateur ou du système installé ? Que se passe-t-il durant les 63 secondes de démarrage qui précèdent ? J’ai déjà vu des messages d’erreur ACPI qui sont généralement sans gravité, mais c’est la première fois que je vois « reboot » au démarrage. ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 27, 2021, 4:53 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/3 "2021-06-27T16:53:54Z")
Bonjour Pascal, Merci pour votre aide L’installation de OMV 5.5 ou 6 se passe bien, aucun message d’erreur Le message apparait en boucle au moment du démarrage, je peux indiquer les identifiants root Je peux essayer de faire une mini vidéo, avec un lien WeTransfer, je ne sais pas si c’est autorisé Je peux me connecter en root, redémarrer, arrêter la machine, je n’ai pas essayé d’autre ligne de commande Je n’ai cependant pas testé d’accéder à OMV depuis l’adresse réseau attribué Le message « reboot: system halted » est présent quand j’ai exécuté la commande « sudo halt » ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 27, 2021, 5:32 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/4 "2021-06-27T17:32:33Z")
Pouvant me connecter depuis l’adresse IP, si besoin je pense que je pourrai fournir des logs Voici une mini vidéo du lancement de OMV [Vidéo](https://we.tl/t-zZP7qwuQew) ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 28, 2021, 6:35 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/5 "2021-06-28T06:35:18Z")
Je préfèrerais la sortie de `dmesg` ou le contenu de /var/log/kern.log. En attendant, tu peux essayer ``` echo disable > /sys/firmware/acpi/interrupts/gpe6D ``` ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 28, 2021, 8:21 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/6 "2021-06-28T08:21:05Z")
Bonjour Pascal, Voici le rapport suite à la commande dmesg Ne pouvant joindre le fichier .txt directement sur le forum, j’ai fais un lien wetransfer > **[WeTransfer | Send Large Files Fast](https://wetransfer.com/downloads/cb169d2be99547e615b5cf4ef4a31e1920210628081931/f9a217)** > > The simple, quick and secure way to send your files around the world without an account. Share your files, photos, and videos today for free. La commande ```auto echo disable > /sys/firmware/acpi/interrupts/gpe6D ``` a bien supprimé l’affichage en boucle du message Merci pour votre aide Bonne journée ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 28, 2021, 10:40 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/7 "2021-06-28T10:40:45Z")
Remarques rapides car j’ai peu de temps. Il ne fallait pas essayer d’insérer le log comme fichier joint mais inclus dans le message comme texte préformaté. C’est plus pratique à lire que d’aller chercher un fichier joint. Exemple avec un extrait : ```auto [8.139323] igb 0000:01:00.0 enp1s0: igb: enp1s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [8.247002] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready [8.563401] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GLAN.GPEH], AE_NOT_FOUND (20200925/psargs-330) [8.563529] ACPI Error: Aborting method \_GPE._L6D due to previous error (AE_NOT_FOUND) (20200925/psparse-531) [8.563636] ACPI Error: AE_NOT_FOUND, while evaluating GPE method [_L6D] (20200925/evgpe-515) ``` D’après le log les messages commencent après l’activation de l’interface ethernet gérée par le pilote igb. C’est peut-être juste une coïncidence, mais « GLAN » m’avait fait penser au réseau (Gigabit LAN). Pour le moment je ne sais qu’en penser. Tant mieux si la commande est efficace, mais j’ignore quels sont ses éventuels effets de bord. Son effet est volatil jusqu’à l’arrêt du système. Pour le rendre permanent, il faut soit l’exécuter à chaque démarrage, soit (pas sûr, à tester) ajouter le paramètre suivant à la ligne de commande du noyau : ``` acpi_mask_gpe=0x6D ``` ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 28, 2021, 11:17 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/8 "2021-06-28T11:17:48Z")
Merci d’avoir pris de votre temps pour regarder Désolé, je prends note pour l’insertion des Logs, j’ai voulu éviter de mettre un grand bloc dans la conversation Avec votre remarque cela me fait penser que j’avais essayé une installation de Debian 10 en version graphique et lors de celle-ci, il me demandé de lui fournir `rtlwifi/rtl8188efw.bin` mais j’avais bien le réseau à la fin de l’installation sans ajouter le fichier .bin si c’est lié c’était plus intuitif avec version graphique À la suite de l’exécution de la commande ```auto echo disable > /sys/firmware/acpi/interrupts/gpe6D ``` dans l’immédiat il n’y a pas eu d’effet de bord, simplement l’arrêt été plus longue La commande ```nohighlight acpi_mask_gpe=0x6D ``` est serait à ajouter dans le fichier ```nohighlight GRUB_CMDLINE_LINUX_DEFAULT ``` ? Merci pour votre aide et votre oeil de lynx ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 28, 2021, 4:43 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/9 "2021-06-28T16:43:47Z")
Dans le fichier /etc/default/grub, plutôt dans la valeur de GRUB\_CMDLINE\_LINUX pour s’appliquer aussi en mode dépannage. Il faut ensuite exécuter `update-grub` pour appliquer le changement. rtl8188efw.bin est un firmware pour un contrôleur wifi. D’après les logs du noyau il est bien présent : ``` [4.995370] rtl8188ee: Using firmware rtlwifi/rtl8188efw.bin [4.997950] rtl8188ee 0000:02:00.0: firmware: direct-loading firmware rtlwifi/rtl8188efw.bin ``` En tout cas je ne pense pas que ce firmware a un rapport avec les erreurs ACPI. ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 28, 2021, 5:38 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/10 "2021-06-28T17:38:58Z")
J’ai modifié la la valeur de `GRUB_CMDLINE_LINUX_DEFAULT`, ``` # If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT= acpi_mask_gpe=0x6D GRUB_CMDLINE_LINUX="" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" # Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' #GRUB_GFXMODE=640x480 # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux ``` Lors du redémarrage après le `update-grub` le message réapparait en boucle Peut on mettre `acpi=off` sur la valeur `GRUB_CMDLINE_LINUX_DEFAULT` ou est ce mauvais pour le système et le matériel ? Merci pour votre aide ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 28, 2021, 5:55 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/11 "2021-06-28T17:55:21Z")
> [@Val1](#): > > `GRUB_CMDLINE_LINUX_DEFAULT= acpi_mask_gpe=0x6D` Pas bon. Il ne fallait pas enlever tout ce qui était après le signe = mais insérer le paramètre entre les " " existants. D’autre part il ne faut pas d’espace entre le signe = et la valeur, sinon c’est interprété comme ``` GRUB_CMDLINE_LINUX_DEFAULT= acpi_mask_gpe=0x6D ``` donnant une valeur vide à GRUB\_CMDLINE\_LINUX\_DEFAULT et la valeur 0x60 à une nouvelle variable acpi\_mask\_gpe qui ne sert à rien dans ce fichier. Mets plutôt : ``` GRUB_CMDLINE_LINUX_DEFAULT="quiet" GRUB_CMDLINE_LINUX="acpi_mask_gpe=0x6D" ``` > [@Val1](#): > > Peut on mettre `acpi=off` sur la valeur `GRUB_CMDLINE_LINUX_DEFAULT` ou est ce mauvais pour le système et le matériel ? Ce n’est pas mauvais pour le matériel mais ça désactive toutes les fonctionnalités liées notamment à la gestion de l’alimentation, donc on ne le fait qu’en dernier recours. ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 28, 2021, 6:22 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/12 "2021-06-28T18:22:48Z")
Oups désolé, c’est la première fois que je fais des modifications aussi délicate Suite à la bonne modification, ``` GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet" GRUB_CMDLINE_LINUX="acpi_mask_gpe=0x6D" ``` ça fonctionne impec après le `update-grub` et un redémarrage le message d’erreur n’apparait plus Un immense merci à vous pour votre aide ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 28, 2021, 6:40 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/13 "2021-06-28T18:40:06Z")
Si je peux abuser de votre temps et votre aide, par curiosité et pour comprendre un peu plus le choix de la commande si possible `Acpi` -\> Pour le service posant problème je suppose `Mask` -\> Pour masquer ? `Gpe=0x6D` -\> Je pense que c’est du au fait que cette valeur est dans la ligne d’erreur `ACPI Error: Aborting method \_GPE._L6D due to previous error (AE_NOT_FOUND) (20200925/psparse-531)` ? Merci pour votre aide ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 28, 2021, 9:58 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/14 "2021-06-28T21:58:39Z")
Oui, grosso modo. GPE = General Purpose Event, ça a l’air d’être une sorte d’interruption ACPI. 6D est le numéro en hexadécimal de l’interruption qui pose problème. Il se pourrait que le contenu du fichier /proc/acpi/wakeup permette d’identifier le périphérique GLAN mentionné. ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 29, 2021, 4:56 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/15 "2021-06-29T16:56:30Z")
Bonjour Pascal, Merci pour les explications pour la commande, c’est top J’ai fait un `nano /proc/acpi/wakeup` pour voir le contenu du fichier : ``` Device S-state Status Sysfs node PS2K S3 *disabled PS2M S3 *disabled RP01 S4 *disabled PXSX S4 *disabled RP02 S4 *disabled PXSX S4 *disabled RP03 S4 *disabled PXSX S4 *disabled RP04 S4 *disabled PXSX S4 *disabled RP05 S4 *disabled PXSX S4 *disabled RP06 S4 *disabled PXSX S4 *disabled RP07 S4 *enabled pci:0000:00:1c.0 PXSX S4 *enabled pci:0000:01:00.0 RP08 S4 *disabled PXSX S4 *disabled RP09 S4 *enabled pci:0000:00:1d.0 PXSX S4 *disabled pci:0000:02:00.0 RP10 S4 *disabled PXSX S4 *disabled RP11 S4 *disabled PXSX S4 *disabled ``` J’ai vu qu’avec un `lspci` on avez le détail des périphériques PCI ``` 00:00.0 Host bridge: Intel Corporation Device 3e35 (rev 0c) 00:02.0 VGA compatible controller: Intel Corporation Device 3ea1 (rev 02) 00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 0c) 00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30) 00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30) 00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30) 00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller (rev 30) 00:17.0 SATA controller: Intel Corporation Cannon Point-LP SATA Controller [AHCI Mode] (rev 30) 00:1c.0 PCI bridge: Intel Corporation Device 9dbe (rev f0) 00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port (rev f0) 00:1d.4 PCI bridge: Intel Corporation Device 9db4 (rev f0) 00:1f.0 ISA bridge: Intel Corporation Device 9d85 (rev 30) 00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30) 00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30) 01:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01) 03:00.0 Non-Volatile memory controller: Silicon Motion, Inc. Device 2263 (rev 03) ``` Si je dis pas de bêtise apparemment ça serait la carte wifi ? Bonne soirée et merci de votre aide Désolé pour mon retour tardif ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 29, 2021, 5:30 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/16 "2021-06-29T17:30:35Z")
> [@Val1](#): > > J’ai fait un `nano /proc/acpi/wakeup` pour voir le contenu du fichier Il ne faut pas utiliser un éditeur comme nano pour visualiser le contenu d’un fichier (et d’autant plus un pseudo-fichier comme tout ce qui est dans /proc et /sys), mais un simple `cat` ou un « pager » comme `more`, `less` ou `most` pour faire défiler si nécessaire (ce qui n’est pas le cas ici). Le contenu du pseudo-fichier est décevant, les noms de la colonne « device » ne sont pas parlants comme sur d’autres machines et le nom « GLAN » des messages ACPI n’y figure pas. Pour comparer avec ma machine : ``` Device S-state Status Sysfs node LID S3 *enabled platform:PNP0C0D:00 SLPB S3 *enabled platform:PNP0C0E:00 UART S3 *disabled pnp:00:05 EXP0 S4 *disabled pci:0000:00:1c.0 EXP1 S4 *disabled EXP2 S4 *disabled pci:0000:00:1c.2 EXP3 S4 *disabled PCI1 S4 *disabled pci:0000:00:1e.0 DOCK S4 *disabled platform:dock.1 USB0 S3 *enabled pci:0000:00:1d.0 USB1 S3 *enabled pci:0000:00:1d.1 USB3 S3 *enabled pci:0000:00:1d.3 USB7 S3 *enabled pci:0000:00:1d.7 AC9M S4 *disabled pci:0000:00:1e.3 ``` où on reconnaît certains périphériques : LID (couvercle/écran), SLPB (sleep button), UART (port série), USB\* (contrôleurs USB), AC9M (modem AC97). Les cartes réseau n’y figurent pas. > [@Val1](#): > > J’ai vu qu’avec un `lspci` on avez le détail des périphériques PCI Oui, mais les identifiants de bus PCI des cartes réseau ethernet et wifi figuraient déjà dans les logs du noyau (dmesg), donc je n’avais pas besoin de lspci. Ils figurent bien dans le fichier wakeup mais avec le nom « PXSX » qui ne m’évoque rien. ---
**Author:** ![anon90668717](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/3e96dc/32.png) [@anon90668717](https://www.debian-fr.org/u/anon90668717)\ **Post date:** [Juin 29, 2021, 5:36 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/17 "2021-06-29T17:36:28Z")
> [@PascalHambourg](#): > > Il ne faut pas utiliser un éditeur comme nano pour visualiser le contenu d’un fichier Et depuis quand? Faut pas confondre « il n’est pas conseillé » avec « il ne faut pas » Si tu veux visualiser avec des couleurs tu peux utiliser nano ou vim en $USER si les permissions le permettent ---
**Author:** ![Val1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/e19b73/32.png) [@Val1](https://www.debian-fr.org/u/Val1)\ **Post date:** [Juin 29, 2021, 7:17 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/18 "2021-06-29T19:17:45Z")
D’accord, c’est certainement du à la conception de la machine, si vous vous avez les infos Cela restera un mystère à moins qu’une autre commande existe pour les infos manquante Ok pour l’éditeur, je n’ai jamais utiliser les autres, je suis très très novice, vim me parle un peu mais très vaguement J’utilise nano car il est plutôt simple mais je prends note ça peut toujours etre utile Bonne soirée ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Juin 29, 2021, 7:39 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/19 "2021-06-29T19:39:08Z")
> [@anon90668717](#): > > Et depuis quand? Faut pas confondre « il n’est pas conseillé » avec « il ne faut pas » > Si tu veux visualiser avec des couleurs tu peux utiliser nano ou vim en $USER si les permissions le permettent Le plus judicieux à mon humble avis est d’utiliser _view_ plutôt que de l’ouvrir avec nano, vim … Surtout pour simplement visualiser. ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Juin 29, 2021, 9:08 UTC](https://www.debian-fr.org/t/erreur-lancement-omv/84872/21 "2021-06-29T21:08:14Z")
Bonjour > [@Val1](#): > > … J’utilise nano car il est plutôt simple mais je prends note ça peut toujours etre utile Si tu veux utiliser **`nano`** pour visualiser un fichier, utilise le mode **`view`** : ```auto nano --view nomDuFichierAvisualiser ``` ou bien, la même chose mais en option courte : ```auto nano -v nomDuFichierAvisualiser ``` * * * Un extrait de la page _man_ de la commande **`nano`** : ```plaintext … -v, --view Uniquement visualiser le fichier et interdire l'édition : mode lecture seule. Ce mode permet à l'utilisateur d'ouvrir d'autres fichiers pour les visualiser, à moins que l'option --restricted ne soit aussi passée. … ```