logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

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

gannick
Membre
Inscription : 25-09-2019

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

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-2681TYPE=“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 :
91ead77b5ae1ea89f3b0b7524e382cce7f4c8e9f.jpeg

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

Et au tout début du boot :
956420bb194740824ea89790559d3e98aecbe1a4.jpeg

Merci d'avance pour vos lumières !

Hors ligne

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

bendia
Chadministrateur
Distrib. : openSUSE Tumbleweed, Buster
Noyau : Linux 5.9.1-2-default + Linux 4.19.0-12-amd64
(G)UI : Gnome + Console et un peu Fluxbox
Inscription : 20-03-2012
Site Web

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

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 wink
https://debian-facile.org/viewtopic.php?id=24901

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


Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.

En ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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. smile

Hors ligne

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

framend
Modo-Moule zébrée
Lieu : .$_ENV["HOME"]
Distrib. : Debian «Sid»
Noyau : uname -r
(G)UI : sway
Inscription : 17-11-2018

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

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.

“It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is.” - Bruce Lee (philosophe)

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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 ! big_smile big_smile Bah quand on ressort du mon Windows, c'est rapidement moins simple même avec de la bonne volonté ! wink

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 ! smile

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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

Hors ligne

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

framend
Modo-Moule zébrée
Lieu : .$_ENV["HOME"]
Distrib. : Debian «Sid»
Noyau : uname -r
(G)UI : sway
Inscription : 17-11-2018

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

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… zen.gif)

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. smile


“It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is.” - Bruce Lee (philosophe)

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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. smile


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)

Hors ligne

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

framend
Modo-Moule zébrée
Lieu : .$_ENV["HOME"]
Distrib. : Debian «Sid»
Noyau : uname -r
(G)UI : sway
Inscription : 17-11-2018

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

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 ?

“It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is.” - Bruce Lee (philosophe)

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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...

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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 ! smile

Hors ligne

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

framend
Modo-Moule zébrée
Lieu : .$_ENV["HOME"]
Distrib. : Debian «Sid»
Noyau : uname -r
(G)UI : sway
Inscription : 17-11-2018

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

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… big_smile


“It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is.” - Bruce Lee (philosophe)

Hors ligne

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

Jean-Pierre Pinson
Adhérent(e)
Lieu : Orléans
Distrib. : Debian Sid 64bits Ordi.: Thinkpad T400
Noyau : de cerise
(G)UI : xfce
Inscription : 04-03-2017

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

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 ?

Debian sid
Bureau : xfce
Ordinateur : Thinkpad T400 libreboot

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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 ! big_smile 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).

Hors ligne

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

Jean-Pierre Pinson
Adhérent(e)
Lieu : Orléans
Distrib. : Debian Sid 64bits Ordi.: Thinkpad T400
Noyau : de cerise
(G)UI : xfce
Inscription : 04-03-2017

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

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)


Debian sid
Bureau : xfce
Ordinateur : Thinkpad T400 libreboot

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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,

Hors ligne

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

gannick
Membre
Inscription : 25-09-2019

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

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… big_smile


Maintenant que j'ai sauvé ma Debian, je peux te répondre ! smile 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à ?
yikes

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

Hors ligne

Pied de page des forums