Séquence de boot trop longue (avec un échec par timeout)

gannick · 25-09-2019 20:01:43

J’ai installé Debian 10 après avoir téléchargé l’image la plus à jour et avoir installé la plupart des composants via le réseau (filaire, j’y reviendrai).

J’ai ensuite installé les drivers de ma carte Wifi (trouvé sur https://doc.ubuntu-fr.org/wifi_bt_mt7630e). Ma carte Wifi est une MEDIATEK MT7630e. Le Wifi est stable et fonctionnel, bien que certains semblent avoir eu des soucis.

Toute l’installation de la Debian s’est faite sur une seule partition, et l’installateur m’a fait une Swap de presque 8Go.

Puis j’ai installé une Linux Kali. Initialement la dernière version (2019-3), mais j’ai découvert que mon driver Wifi ne fonctionnait PAS DU TOUT avec le noyau déployé (5.20 alors que sur la Debian 10 j’ai un noyau 4.19). Donc j’ai viré la Kali 2019-3 et installé la 2019-2.

Je pense que la Kali a vu la partition Swap de la Debian parce qu’il l’a formaté mais je n’ai qu’une seule partition Swap.

Le fait d’avoir une partition Swap pour 2 versions de Linux peut-il causer des soucis ? Notamment les soucis que je rencontre au démarrage avec la Debian ?

En tapant dmesg voici ce qui apparaît en rouge :

[  143.331693] r8169 0000:02:00.0: firmware: failed to load rtl_nic/rtl8168g-3.fw (-2)

[  143.333993] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware  

[  156.419840] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[ 1092.628464] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[ 1094.256610] fuse init (API version 7.27)

[ 1098.392960] rfkill: input handler disabled

[ 1102.890862] clipit[1400]: segfault at 411 ip 00007fb4e24787c9 sp 00007ffec29b6830 error 4 in libX11.so.6.3.0[7fb4e2462000+8a000]

[ 1102.890876] Code: 00 41 55 41 54 55 53 48 89 fb 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 87 68 09 00 00 48 85 c0 74 02 <ff> 10 ba 04 00 00 00 be 77 00 00 00 48 89 df e8 a3 af fe ff 48 89

[ 1103.602826] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[ 1611.655091] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[ 1611.713565] rfkill: input handler enabled

[ 1722.053151] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[ 1737.062431] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[ 1737.078420] rfkill: input handler disabled

[ 1747.508099] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[ 5785.605872] PM: suspend entry (deep)

Sur Kali :

/dev/sdb4: UUID="AC944D6root@kali:~# swapon > result.txt

NAME TYPE SIZE USED PRIO

/dev/sda3 partition 7,9G 0B -2

root@kali:~# blkid >> result.txt

/dev/sda1: LABEL=“DATA” UUID=“52D62941D6292727” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“3cbc37dd-55fe-476c-8741-4a1fad0cf786”

/dev/sda2: UUID=“feee1f3d-5d9d-4690-9d2f-c3eb0f1d6946” TYPE=“ext4” PARTUUID=“470a4ecd-250b-43f8-83fd-c37b63b4ffd2”

/dev/sda3: UUID=“ec084865-62fc-4111-a3c4-c3fc8ce62123” TYPE=“swap” PARTUUID=“8be6ac21-a3c4-42bb-b855-3aeb104cf246”

/dev/sda4: UUID=“7207-2681” TYPE=“vfat” PARTUUID=“5353ee50-bbe9-48d9-915e-c532b22b912a”

/dev/sda5: UUID=“1754ee99-ceef-4086-9e1e-e6ea1917eb77” TYPE=“ext4” PARTUUID=“761b912c-b9da-4057-a20f-c1213614a919”

/dev/sdb1: LABEL=“SYSTEM” UUID=“2415-B38F” TYPE=“vfat” PARTLABEL=“EFI system partition” PARTUUID=“800e0568-dba1-463d-9282-8aade5260c55”

/dev/sdb3: LABEL=“OS” UUID=“6C6218E16218B236” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“6e32b630-e16e-4468-871c-9a3c7ddcb836”

/dev/sdb4: UUID=“AC944D69944D36DC” TYPE=“ntfs” PARTUUID=“56589750-413b-43d1-9988-883134aac417”

/dev/sdb2: PARTLABEL=“Microsoft reserved partition” PARTUUID=“ae46948f-0716-4b48-8592-90f72b57755e”

/dev/sdc1: LABEL=“DDDD” UUID=“709A63219A62E358” TYPE=“ntfs” PARTUUID=“c3072e18-01"9944D36DC” TYPE=“ntfs” PARTUUID=“56589750-413b-43d1-9988-883134aac417”

/dev/sdb2: PARTLABEL=“Microsoft reserved partition” PARTUUID=“ae46948f-0716-4b48-8592-90f72b57755e”

/dev/sdc1: LABEL=“DDDD” UUID=“709A63219A62E358” TYPE=“ntfs” PARTUUID=“c3072e18-01”

Étrangement, même en étant root, je n'ai pas la commande swapon sur Debian... Sur Debian, la commande blkid me renvoie cela (mais j'ai du me connecter sur le TTY4, sinon dans la Konsole en faisant un "su", je n'avais pas cette commande !!!???) :

/dev/sda1: LABEL=“DDDD” UUID=“709A63219A62E358” TYPE=“ntfs” PARTUUID=“c3072e18-01”

/dev/sdb1: LABEL=“DATA” UUID=“52D62941D6292727” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“3cbc37dd-55fe-476c-8741-4a1fad0cf786”

/dev/sdb2: UUID=“feee1f3d-5d9d-4690-9d2f-c3eb0f1d6946” TYPE=“ext4” PARTUUID=“470a4ecd-250b-43f8-83fd-c37b63b4ffd2”

/dev/sdb3: UUID=“ec084865-62fc-4111-a3c4-c3fc8ce62123” TYPE=“swap” PARTUUID=“8be6ac21-a3c4-42bb-b855-3aeb104cf246”

/dev/sdb4: UUID=“7207-2681” TYPE=“vfat” PARTUUID=“5353ee50-bbe9-48d9-915e-c532b22b912a”

/dev/sdb5: UUID=“1754ee99-ceef-4086-9e1e-e6ea1917eb77” TYPE=“ext4” PARTUUID=“761b912c-b9da-4057-a20f-c1213614a919”

/dev/sdc1: LABEL=“SYSTEM” UUID=“2415-B38F” TYPE=“vfat” PARTLABEL=“EFI system partition” PARTUUID=“800e0568-dba1-463d-9282-8aade5260c55”

/dev/sdc3: LABEL=“OS” UUID=“6C6218E16218B236” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“6e32b630-e16e-4468-871c-9a3c7ddcb836”

/dev/sdc4: UUID=“AC944D69944D36DC” TYPE=“ntfs” PARTUUID=“56589750-413b-43d1-9988-883134aac417”

/dev/sdc2: PARTLABEL=“Microsoft reserved partition” PARTUUID=“ae46948f-0716-4b48-8592-90f72b57755e”

Sur la Kali et la Debian, la partition SWAP a bien le même UUID et le même PARTUUID. Seule change la dénomination suivant la distribution : /dev/sdb5 sur Debian, /dev/sda5 sur Kali. Cela change-t-il quelque chose ?

Et donc ce qui me chagrine parce qu'au boot la Debian reste bloquée pendant 1min30 :

Et une fois que l'étape est passée :

Et au tout début du boot :

Merci d'avance pour vos lumières !

bendia · 25-09-2019 20:43:46

gannick a écrit :

Étrangement, même en étant root, je n'ai pas la commande swapon sur Debian... en faisant un "su"

Il y a fort à parier que c'est ta manière de passer root qui pose problème
https://debian-facile.org/viewtopic.php?id=24901

Ça ne répond pas à la question principale cependant

gannick · 25-09-2019 21:03:01

bendia a écrit :

Ça ne répond pas à la question principale cependant

Alors merci pour l'explication sur le fait que je n'avais pas accès aux commandes même en root, mais sinon effectivement ça ne répond pas à la question principale.

framend · 25-09-2019 21:10:48

Peut-être un bout de la réponse ici : https://unix.stackexchange.com/question … th-mt7630e

Pas tellement le temps d'en parler ce soir, mais je repasse demain.

gannick · 25-09-2019 21:22:41

framend a écrit :

Peut-être un bout de la réponse ici : https://unix.stackexchange.com/question … th-mt7630e

Pas tellement le temps d'en parler ce soir, mais je repasse demain.

Alors en lisant la page que tu as trouvé, j'ai cliqué sur le lien suggéré par l'auteur, et ça m'amène ici : https://cateee.net/lkddb/web-lkddb/MT76x0E.html

C'est peut-être la bonne solution, mais je vais avoir besoin d'aide pour comprendre ce qu'il faut faire ! Bah quand on ressort du mon Windows, c'est rapidement moins simple même avec de la bonne volonté !

Pour le driver que j'avais trouvé sur github, j'étais aussi tombé sur un bon tuto sur un forum ubuntu. Et c'était clairement de mon niveau, il suffisait de mettre des droits et exécuter des scripts. Là ça me semble moins simple donc je veux bien un peu d'aide !

gannick · 25-09-2019 22:22:30

J'ai réglé un des gros soucis du boot (le moment ou il attendait en vain pendant 1min30).

C'était la SWAP qui n'était plus monté par la DEBIAN vu qu'en installant la KALI, l'UUID de la SWAP DEBIAN avait été remplacé par celui de la KALI.

Voici les soucis restants au boot :

root@debian-nico:~# dmesg -l err

[    0.054520] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x25 (or later)

[    1.346601] efi: EFI_MEMMAP is not enabled.

[    5.451617] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[    5.496277] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]

[    6.777298] nouveau 0000:04:00.0: DRM: Pointer to TMDS table invalid

[   30.827497] r8169 0000:02:00.0: firmware: failed to load rtl_nic/rtl8168g-3.fw (-2)

[   30.829112] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware

[   43.349021] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[   71.143579] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[   82.365951] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

Et ce que j'ai essayé mais qui n'a pas fonctionné :

root@debian-nico:~# apt-get install firmware-misc-nonfree

Lecture des listes de paquets... Fait

Construction de l'arbre des dépendances       

Lecture des informations d'état... Fait

Aucune version du paquet firmware-misc-nonfree n'est disponible, mais il existe dans la base

de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète

ou qu'il n'est disponible que sur une autre source

E: Le paquet « firmware-misc-nonfree » n'a pas de version susceptible d'être installée

root@debian-nico:~# apt-get install firmware-realtek

Lecture des listes de paquets... Fait

Construction de l'arbre des dépendances       

Lecture des informations d'état... Fait

E: Impossible de trouver le paquet firmware-realtek

framend · 25-09-2019 22:35:49

Au vu des retours de commandes et de la disponibilité des paquets actuellement je parierais (boule de cristal à l'appui) sur le fait que tu n'utilises pas les dépôts « non-free» de Debian. Donc si tu pouvais nous donner le retour de :

cat /etc/apt/sources.list

Parce qu'a priori les paquets firmware-misc-nonfree et firmware-realtek sont bels et bien disponible pour buster.
ici : https://packages.debian.org/buster/firm … sc-nonfree
et ici : https://packages.debian.org/buster/firmware-realtek

Cependant ils ne seront, encore une fois à priori, d'aucun secours pour la carte wifi. (Edit: Encore qu'aprés une brève lecture de la description des paquets, c'est possible en fait… )

Par contre la plupart des procédures d'installation de paquets via des scripts dédiés à ubuntu, bien que parfois fonctionnelles, finissent pratiquement toujours par poser des problèmes. Sous Debian la politique est plutôt: on installe prioritairement via les dépots (contrib et/ou non-free si nécessaires), et si c'est impossible on explore d'autres solutions de type compilation git ou installation via des dépots tiers ou des installeurs glanés sur le net.

Généralement on se retrouve à devoir retirer ces paquets lors de mise à niveau d'une version à une autre, par exemple. Donc le moins on en mets le mieux on se porte.

gannick · 26-09-2019 08:15:10

framend a écrit :

Au vu des retours de commandes et de la disponibilité des paquets actuellement je parierais (boule de cristal à l'appui) sur le fait que tu n'utilises pas les dépôts « non-free» de Debian. Donc si tu pouvais nous donner le retour de :
cat /etc/apt/sources.list

Parce qu'a priori les paquets firmware-misc-nonfree et firmware-realtek sont bels et bien disponible pour buster.
ici : https://packages.debian.org/buster/firm … sc-nonfree
et ici : https://packages.debian.org/buster/firmware-realtek

Cependant ils ne seront, encore une fois à priori, d'aucun secours pour la carte wifi. (Edit: Encore qu'aprés une brève lecture de la description des paquets, c'est possible en fait… https://debian-facile.org/img/smilies/xtras/zen.gif)

Bonjour Framend. Bien vu pour les dépôts non-free, je les ai rajouté et j'ai pu installé les firmware firmware-realtek, amd64-microcode et intel-microcode. Cela m'enlève pas mal de messages d'erreur au boot !

Il reste ces erreurs, cela parle-t-il ?

root@debian-nico:~# dmesg -l err

[    1.338044] efi: EFI_MEMMAP is not enabled.

[    5.164930] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[    5.207833] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]

[    6.490013] nouveau 0000:04:00.0: DRM: Pointer to TMDS table invalid

[   43.756664] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[   70.099165] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

[   80.605931] nouveau 0000:04:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]

framend a écrit :

Par contre la plupart des procédures d'installation de paquets via des scripts dédiés à ubuntu, bien que parfois fonctionnelles, finissent pratiquement toujours par poser des problèmes. Sous Debian la politique est plutôt: on installe prioritairement via les dépots (contrib et/ou non-free si nécessaires), et si c'est impossible on explore d'autres solutions de type compilation git ou installation via des dépots tiers ou des installeurs glanés sur le net.

Généralement on se retrouve à devoir retirer ces paquets lors de mise à niveau d'une version à une autre, par exemple. Donc le moins on en mets le mieux on se porte.

J'ai un script pour désintaller le driver Wifi et bluetooth installé par script (et qui modifie le noyau ?).

Je suis preneur si tu as des explications concernant le driver de ma carte Wifi parce que je ne comprends pas trop cette page dont j'ai eu le lien via ce que tu m'avais trouvé :
https://cateee.net/lkddb/web-lkddb/MT76x0E.html

A priori tout ce qui bugue et concerne “nouveau” concernerait la carte graphique NVidia. J’ai trouvé ça :
https://forums.archlinux.fr/viewtopic.php?t=19603
Mais ça ne dit pas trop comment résoudre le souci.

[EDIT :]
Il y aurait une certaine cohérence avec ce que m’a dit APT quand j’ai installé les différents firmware. Il m’a dit qu’il manquait potentiellement une liste énorme de firmware nvidia…

Est-ce que je peux essayer de suivre ce tuto ? https://wiki.debian.org/fr/Bumblebee parce que j’ai 2 cartes graphiques :

    root@debian-nico:~# lspci -nn | egrep -i “3d|display|vga”

    00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)

    04:00.0 3D controller [0302]: NVIDIA Corporation GM108M [GeForce 940M] [10de:1347] (rev a2)

Dernière modification par gannick (26-09-2019 08:35:54)

framend · 26-09-2019 11:03:46

Ok, je pense que j'entrevois mieux le problème, pour les GPU.
Les GPU nvidia ne sont pas ma tasse de thé vu que je n'en utilise pas.
Mais à priori le projet Bumblebee est plutôt bien maintenu (il me semble), et un canal irc existe sur freenode, #bumblebee.

Par contre qu'en est-il du wifi ? Le script dont tu parles à reussi à faire fonctionner ta carte ?
Le cas échéant aurais-tu un lien, pour y jetter un œil ?

gannick · 26-09-2019 11:34:01

framend a écrit :

Par contre qu'en est-il du wifi ? Le script dont tu parles à reussi à faire fonctionner ta carte ?
Le cas échéant aurais-tu un lien, pour y jetter un œil ?

Le Wifi fonctionne pour l'instant bien, même si des utilisateurs Debian 10 semblent avoir eu dans la même configuration que moi un OS totalement planté en passant sur Wifi différent de celui de la maison. Ce qui était indiqué par le lien que tu m'avais trouvé ici : https://unix.stackexchange.com/question … th-mt7630e et qui m'avait conduit ici : https://cateee.net/lkddb/web-lkddb/MT76x0E.html (mais je n'ai pas trop compris cette page, ou comment installer ce driver).

Sinon me concernant j'ai installé en suivant ce tuto : https://doc.ubuntu-fr.org/wifi_bt_mt7630e. Et ça fonctionne bien, mais quand j'ai installé une Kali avec un noyau en 5.20, le Wifi ne fonctionnait plus du tout bien (déconnexion / reconnexion toutes les 45 sec). Donc je suis inquiet lorsque le noyau Debian va être mis à jour...

gannick · 27-09-2019 08:08:53

Framend, est-ce que tu serais capable de m'expliquer si ce qui est expliqué ici https://unix.stackexchange.com/question … th-mt7630e et surtout ici : https://cateee.net/lkddb/web-lkddb/MT76x0E.html permet d'installer un driver Wifi fiable et à jour compatible avec les derniers noyaux ? Merci d'avance !

framend · 27-09-2019 10:14:40

Quelque chose doit m'échapper en l'occurence, mais ici sur un noyau 4.19.0-5 je n'ai pas ce driver.

ls /lib/modules/4.19.0-5-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x0

mt76x0.ko

Ni sur un noyau 5.2.0-2

ls /lib/modules/5.2.0-2-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x0/

mt76x0-common.ko  mt76x0u.ko

Je serais curieux de voir ce que tu as comme retour avec la même commande.

Pour moi ces documents indiquent justement que les modules sont intrégrés au kernel à partir de la version 4.20.x, c'est étrange.

Je continue l'enquête…

Jean-Pierre Pinson · 27-09-2019 14:50:56

pourquoi kali, une debian fait bien l'affaire et presque tout les paquets dispo dans les dépôts sécu de kali, sont installables pour une deb ?

gannick · 28-09-2019 12:50:21

Jean-Pierre Pinson a écrit :

pourquoi kali, une debian fait bien l'affaire et presque tout les paquets dispo dans les dépôts sécu de kali, sont installables pour une deb ?

Bonjour !

Il suffit d'aller voir ma présentation pour avoir la réponse ! L'intérêt de la Kali est que tous les outils pour faire du pentesting sont installés. Mais j'ai aussi mis une Debian 10 du coup. Et je n'ai pas eu de souci de Wifi mais le noyau est en 4.19 (il était en 5.20 sur Kali).

Jean-Pierre Pinson · 29-09-2019 18:31:06

Pour quelle raison il te faut le 5.20 ?

Et tu n'as toujours pas répondu à la question de framend !

Dernière modification par Jean-Pierre Pinson (29-09-2019 18:53:05)

gannick · 29-09-2019 22:04:49

Jean-Pierre Pinson a écrit :

Pour quelle raison il te faut le 5.20 ?

Alors pour répondre à ces 2 questions pertinentes :
1) Quand on fait un apt upgrade et apt dist-upgrade généralement le système se met à jour. Ce qui s'est passé sur la Kali passant en 5.2. Et ce qui finira par arriver sur la Debian...

Jean-Pierre Pinson a écrit :

Et tu n'as toujours pas répondu à la question de framend !

2) Vu qu'en installant Blumblebee sur ma Debian (vu que j'ai 2 CG, dont une Intel et une Nvidia) ça a totalement planté mon système (Cf le message que j'ai fait sur ce même forum quelques messages en dessous), hier soir j'essayais de le sauver plutôt que de répondre à Framend. Et d'ailleurs, j'ai réussi à le sauver tout seul. En me disant que si je virais tout ce qui était Nvidia, ça le ressusciterai (apt remove *nvidia*, et tadam, il a bien voulu redémarrer).

Mais sinon je suis preneur de conseils aussi vu que je me remets à Linux après 15 ans sans y avoir touché du tout.

Amicalement,

gannick · 29-09-2019 22:34:51

framend a écrit :

Quelque chose doit m'échapper en l'occurence, mais ici sur un noyau 4.19.0-5 je n'ai pas ce driver.

ls /lib/modules/4.19.0-5-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x0
mt76x0.ko

Ni sur un noyau 5.2.0-2
ls /lib/modules/5.2.0-2-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x0/
mt76x0-common.ko mt76x0u.ko

Je serais curieux de voir ce que tu as comme retour avec la même commande.

Pour moi ces documents indiquent justement que les modules sont intrégrés au kernel à partir de la version 4.20.x, c'est étrange.

Je continue l'enquête…

Maintenant que j'ai sauvé ma Debian, je peux te répondre ! Merci de tes recherches !

Voici ce que me retournent les commandes :

nicolas@debian-nico:~$ ls /lib/modules/4.19.0-6-rt-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x0/

mt76x0.ko

nicolas@debian-nico:~$ ls /lib/modules/4.19.0-6-rt-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76

mt76.ko           mt76x0/           mt76x2e.ko        

mt76-usb.ko       mt76x2-common.ko  mt76x2u.ko        

nicolas@debian-nico:~$ ls /lib/modules/4.19.0-6-rt-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x2-common.ko 

/lib/modules/4.19.0-6-rt-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x2-common.ko

Déjà je n'ai pas tout à fait le même noyau que toi. Mais le ls sur le répertoire mt76x0 retourne bien comme sur ta machine.

Cependant pour la 2e commande, je n'ai pas de sous-répertoire mt76x0-common.ko, mais uniquement mt76x2-common.ko. J'ai mis tous les répertoires qui étaient sous /mt76/.

Mes soucis pourraient-ils venir de là ?

[Edit]
Pour info, ma version de noyau :

nicolas@debian-nico:~$ uname -a

 

Linux debian-nico 4.19.0-6-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux

Dernière modification par gannick (29-09-2019 22:36:38)

Debian-facile

#1 25-09-2019 20:01:43

Séquence de boot trop longue (avec un échec par timeout)

#2 25-09-2019 20:43:46

Re : Séquence de boot trop longue (avec un échec par timeout)

#3 25-09-2019 21:03:01

Re : Séquence de boot trop longue (avec un échec par timeout)

#4 25-09-2019 21:10:48

Re : Séquence de boot trop longue (avec un échec par timeout)

#5 25-09-2019 21:22:41

Re : Séquence de boot trop longue (avec un échec par timeout)

#6 25-09-2019 22:22:30

Re : Séquence de boot trop longue (avec un échec par timeout)

#7 25-09-2019 22:35:49

Re : Séquence de boot trop longue (avec un échec par timeout)

#8 26-09-2019 08:15:10

Re : Séquence de boot trop longue (avec un échec par timeout)

#9 26-09-2019 11:03:46

Re : Séquence de boot trop longue (avec un échec par timeout)

#10 26-09-2019 11:34:01

Re : Séquence de boot trop longue (avec un échec par timeout)

#11 27-09-2019 08:08:53

Re : Séquence de boot trop longue (avec un échec par timeout)

#12 27-09-2019 10:14:40

Re : Séquence de boot trop longue (avec un échec par timeout)

#13 27-09-2019 14:50:56

Re : Séquence de boot trop longue (avec un échec par timeout)

#14 28-09-2019 12:50:21

Re : Séquence de boot trop longue (avec un échec par timeout)

#15 29-09-2019 18:31:06

Re : Séquence de boot trop longue (avec un échec par timeout)

#16 29-09-2019 22:04:49

Re : Séquence de boot trop longue (avec un échec par timeout)

#17 29-09-2019 22:34:51

Re : Séquence de boot trop longue (avec un échec par timeout)

Pied de page des forums