Bonjour à tous,

Après une mise à jour de Debian Testing, ma carte wifi n'est plus reconnue

Je précise que je n'ai installé aucun paquet bogué, je les fige systématiquement.

Le retour des commandes

root@testing:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 54:ee:75:1e:a0:ec
inet adr:192.168.1.26 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::56ee:75ff:fe1e:a0ec/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3611 errors:0 dropped:0 overruns:0 frame:0
TX packets:3308 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:2146976 (2.0 MiB) TX bytes:452378 (441.7 KiB)
Interruption:59 Adresse de base:0xa000

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3234 errors:0 dropped:0 overruns:0 frame:0
TX packets:3234 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:934321 (912.4 KiB) TX bytes:934321 (912.4 KiB)





root@testing:~# find /lib/modules -iname *rtl8723be*
/lib/modules/3.16-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be
/lib/modules/3.16-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko
/lib/modules/3.16.0-4-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be
/lib/modules/3.16.0-4-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko




root@testing:~# dpkg -l *firmware*
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
+++-==============================-====================-====================-==================================================================
un firmware-crystalhd <aucune> <aucune> (aucune description n'est disponible)
un firmware-linux <aucune> <aucune> (aucune description n'est disponible)
ii firmware-linux-free 3.3 all Binary firmware for various drivers in the Linux kernel
ii firmware-realtek 0.43 all Binary firmware for Realtek wired and wireless network adapters


Apparemment le firmware-realtek est bien installé, car j'ai ce retour quand j'ai essayé de le réinstaller

root@testing:~# apt-get install firmware-realtek
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
firmware-realtek est déjà la plus récente version disponible.


Je soupçonne la mise à jour de linux-image (c'est bien le noyau ?)
Malheureusement, je n'ai plus l'ancien noyau dans le menu de démarrage pour tester
Comme je me sers rarement du wifi, je n'avais pas vu que ma carte avait disparu

iwconfig

-----------------

et si tu essayais un petit :

ifconfig wlan0 up

et redemarre ..

le retour

root@testing:~# ifconfig wlan0 up
wlan0: ERROR while getting interface flags: Aucun périphérique de ce type

root@testing:~# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

Je ne suis pas très calée, mais si ma carte wifi n'est pas reconnue, je ne vois pas comment je pourrais la configurer. Je pense que le problème est ailleurs, mais où ?

vérifie que tu n'as pas de probléme de firmware

Si tu regardes le retour d'une de mes commandes dans mon premier message, le firmware est bien installé. Il est marqué par ii

Dans Synaptic --> firmware-b43-installer

sinon :

$ lspci

m_n, je regrète de devoir te dire que le paquet firmware-b43-installer n'est nécessaire que pour les cartes réseaux sans fil Broadcom. Or, milou32 a une carte sans fil Realtek.

milou32, il faudrait que tu précises avec quelle version du noyau Linux ta carte sans fil n'est pas reconnue en affichant dans ce cas la sortie de la commande

uname -a

Peut-être que la version du noyau Linux n'est pas compatible avec la version du firmware installé. Affiche aussi la sortie de la commande

dmesg|grep -i -e rtl8723be -e firm -e microcode

C'est le dernier noyau qui a été installé il y a deux ou trois jours

root@testing:~# uname -a
Linux testing 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

root@testing:~# dmesg|grep -i -e rtl8327be -e firm -e microcode
[ 0.608277] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

En listant les noyaux installés, j'ai toujours l'ancien, je voulais essayer de démarrer dessus pour voir, mais je n'ai pas les options avancées pour Debian au démarrage, donc je n'ai pas pu

Le noyau 3.2.0-4-rt-amd64 a été installé par le paquet VirtualBox-4.3 pour des besoins de compilations. Il ne doit pas être utilisé comme noyau de démarrage de la Debian stable et testing.

Tu as un problème de configuration de Grub. Il devrait démarrer le noyau et l'initramfs qui pointent depuis les liens symboliques /vmlinuz et /initrd.img. Fait depuis ta Debian testing

ls -al /

Affiche.

slt

comment se fait il que tu aies un noyau version 3.2 alors que tu devrais avoir la version 3.16 ?

Hido,

Je crois que Logicien a donné la réponse au dessus

root@testing:~# ls -al /
total 100
drwxr-xr-x 22 root root 4096 janv. 18 11:19 .
drwxr-xr-x 22 root root 4096 janv. 18 11:19 ..
drwxr-xr-x 2 root root 4096 janv. 10 15:33 bin
drwxr-xr-x 3 root root 4096 janv. 18 11:20 boot
drwxr-xr-x 19 root root 3280 janv. 21 17:18 dev
drwxr-xr-x 153 root root 12288 janv. 21 20:42 etc
drwxr-xr-x 3 root root 4096 déc. 8 17:58 home
lrwxrwxrwx 1 root root 33 janv. 18 11:19 initrd.img -> /boot/initrd.img-3.2.0-4-rt-amd64
lrwxrwxrwx 1 root root 31 déc. 8 18:41 initrd.img.old -> /boot/initrd.img-3.16.0-4-amd64
drwxr-xr-x 20 root root 4096 janv. 10 11:09 lib
drwxr-xr-x 2 root root 4096 déc. 8 17:05 lib64
drwx------ 2 root root 16384 déc. 8 16:53 lost+found
drwxr-xr-x 4 root root 4096 déc. 8 18:50 media
drwxr-xr-x 4 root root 4096 janv. 8 17:15 mnt
drwxr-xr-x 2 root root 4096 déc. 8 16:54 opt
dr-xr-xr-x 186 root root 0 janv. 21 13:31 proc
drwx------ 12 root root 4096 janv. 7 17:20 root
drwxr-xr-x 24 root root 840 janv. 21 13:37 run
drwxr-xr-x 2 root root 12288 janv. 19 13:05 sbin
drwxr-xr-x 2 root root 4096 déc. 8 16:54 srv
drwxr-xr-x 13 root root 0 janv. 21 13:31 sys
drwxrwxrwt 21 root root 4096 janv. 21 21:39 tmp
drwxr-xr-x 10 root root 4096 déc. 8 16:54 usr
drwxr-xr-x 12 root root 4096 déc. 8 17:52 var
lrwxrwxrwx 1 root root 29 janv. 18 11:19 vmlinuz -> boot/vmlinuz-3.2.0-4-rt-amd64
lrwxrwxrwx 1 root root 27 déc. 8 18:41 vmlinuz.old -> boot/vmlinuz-3.16.0-4-amd64

J'ai vérifié, Debian stable démarre bien sur le bon noyau, le 3.16 et la carte wifi est fonctionnelle.

Je n'ai pas installé VirtualBox dessus, il n'y a que la testiing

Je ne suis pas chez moi présentement. Je n'ai que la Arch à ma disposition. Les liens symboliques à la racine de l'arborescence ne pointent pas vers la dernière version du noyau et de l'initramfs installés. Là est le problème.

Je dois vérifier avec ma Debian testing. Je te donnerai une réponse plus précise plus tard.

D'accord, de toute façon, je décroche pour ce soir. Ma petite tête est pleine

Je peux tenter de donner une explication pourquoi le noyau 3.2 doit être installé sous Debian testing alors que la testing utilise un noyau 3.16 présentement.

Dans le dépôt VirtualBox, il n'y a pas de version du paquet VirtualBox pour Debian testing, Jessie. La version la plus récente VirtualBox-4.3 est compilée pour Debian stable, Wheezy.

Alors, quand vient le temps d'installer VirtualBox-4.3 pour Debian testing, il faut utiliser le noyau Linux de la Debian stable, 3.2.04 afin de compiler les modules de VirtualBox.

En conséquence, c'est plus facile d'utiliser le dépôt VirtualBox sous Debian stable. Un noyau Linux compatible avec les versions de VirtualBox disponibles pour Debian est déjà installé.

J'ai le même problème que toi milou32. Pour le résoudre, fait sous ta Debian testing en root

mv /mv initrd.img.old initrd.img /mv initrd.img.old initrd

mv /vmlinuz.old /vmlinuz

Accepte le remplacement. Cela va faire pointer les liens symboliques vers la dernière version du noyau Linux installé.

J'ai le même problème que toi milou32.

Normal

ça commence mal

root@testing:~# mv /mv initrd.img.old initrd.img /mv initrd.img.old initrd
mv: la cible « initrd » n'est pas un répertoire

Je ne sais pas si ça a un rapport, mais tu sais que c'est le Grub d'Arch qui gère mon démarrage ?

Il y a quelque chose que je ne comprend pas. Je viens de regarder les dernières mise-à-jours disponibles sous ma Debian testing et le noyau Linux le plus récent est déjà installé. C'est linux-image-3.16.0-4-amd64, alors que toi tu as une version plus récente d'installée. Ce serait linux-image-3.16.2-amd64.

Que te retournent les commandes

dpkg -l *linux-image*

ls -al /boot

ls -a /etc/apt/sources.list.d

cat /etc/apt/sources.list

tu sais que j'ai les dépôts non free dans mon sources.list que toi, je crois tu n'as pas. J'ai été obligée de les rajouter pour récupérer le firware-realtek

root@testing:~# dpkg -l *linux-image*
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
+++-==============================-====================-====================-==================================================================
un linux-image <aucune> <aucune> (aucune description n'est disponible)
ii linux-image-3.16-2-amd64 3.16.3-2 amd64 Linux 3.16 for 64-bit PCs
ii linux-image-3.16.0-4-amd64 3.16.7-ckt2-1 amd64 Linux 3.16 for 64-bit PCs
ii linux-image-3.2.0-4-rt-amd64 3.2.65-1+deb7u1 amd64 Linux 3.2 for 64-bit PCs, PREEMPT_RT
ii linux-image-amd64 3.16+63 amd64 Linux for 64-bit PCs (meta-package)

root@testing:~# ls -al /boot
total 55684
drwxr-xr-x 3 root root 4096 janv. 18 11:20 .
drwxr-xr-x 22 root root 4096 janv. 18 11:19 ..
-rw-r--r-- 1 root root 155457 déc. 9 03:09 config-3.16.0-4-amd64
-rw-r--r-- 1 root root 155429 sept. 20 19:58 config-3.16-2-amd64
-rw-r--r-- 1 root root 128766 janv. 13 00:35 config-3.2.0-4-rt-amd64
drwxr-xr-x 4 root root 4096 janv. 8 14:08 grub
-rw-r--r-- 1 root root 14480572 janv. 18 11:20 initrd.img-3.16.0-4-amd64
-rw-r--r-- 1 root root 14457591 déc. 8 18:41 initrd.img-3.16-2-amd64
-rw-r--r-- 1 root root 11054090 janv. 18 11:19 initrd.img-3.2.0-4-rt-amd64
-rw-r--r-- 1 root root 2668151 déc. 9 03:09 System.map-3.16.0-4-amd64
-rw-r--r-- 1 root root 2664913 sept. 20 19:58 System.map-3.16-2-amd64
-rw-r--r-- 1 root root 2123665 janv. 13 00:35 System.map-3.2.0-4-rt-amd64
-rw-r--r-- 1 root root 3104144 déc. 9 02:59 vmlinuz-3.16.0-4-amd64
-rw-r--r-- 1 root root 3102192 sept. 20 19:47 vmlinuz-3.16-2-amd64
-rw-r--r-- 1 root root 2895872 janv. 13 00:21 vmlinuz-3.2.0-4-rt-amd64

root@testing:~# cat /etc/apt/sources.list


# deb cdrom:[Debian GNU/Linux jessie-DI-b2 _Jessie_ - Official Snapshot amd64 kde-CD Binary-1 20141003-18:31]/ jessie main

deb cdrom:[Debian GNU/Linux jessie-DI-b2 _Jessie_ - Official Snapshot amd64 kde-CD Binary-1 20141003-18:31]/ jessie main

deb http://ftp.fr.debian.org/debian-security/ testing/updates main contrib non-free

deb http://ftp.fr.debian.org/debian/ testing main contrib non-free

deb-src http://ftp.fr.debian.org/debian-security/ testing/updates main contrib non-free

deb-src http://ftp.fr.debian.org/debian/ testing main contrib non-free

deb http://ftp.ca.debian.org/debian-security/ stable/updates main contrib non-free

deb http://ftp.fr.debian.org/debian/ stable main contrib non-free

deb-src http://ftp.fr.debian.org/debian-security/ stable/updates main contrib non-free

deb-src http://ftp.fr.debian.org/debian/ stable main contrib non-free

deb http://http.debian.net/debian/ jessie main contrib

deb http://download.virtualbox.org/virtualbox/debian wheezy contrib

Je suis chez moi présentement. Je ne ferai pas d'erreur sur les commandes comme hier. Peu importe que ta version du noyau Linux soit plus récente que la mienne, pour démarrer sur la version la plus récente fait toujours en root sous testing

rm -f /initrd.img /initrd.img.old

rm -f /vmlinuz /vmlinuz.old

ln -s /boot/initrd.img-3.16-2-amd64 /initrd.img

ln -s /boot/vmlinuz-3.16-2-amd64 /vmlinuz

Comme je l'ai expliqué plus haut, le dépôt de VirtualBox offre des versions de paquets Debian pour la branche stable. C'est plus compliqué d'utiliser le dépôt de VirtualBox avec Debian testing.

Voilà, c'est fait.
Aucun retour pour les 4 commandes, donc c'est tout bon.
Je dois redémarrer ?

Note milou32 que sous Debian et des dérivées, voir d'autres distributions aussi probablement, lorsqu'une nouvelle version du noyau Linux s'installe, la version précédente du noyau n'est pas désinstallée automatiquement.

Cela s'explique par le fait que la version précédente est généralement en cours d'exécution. Tu dois d'abord redémarrer sur le nouveau noyau pour ensuite désinstaller la version précédente si tu le veux.

Tu peux garder les deux versions les plus récentes du noyau Linux ou plus pour pouvoir avoir une ou des alternatives, mais au fil du temps, tu vas te retrouver avec pleins de versions du noyau que tu n'utilises plus.

Comme apt-get est configuré par défaut pour ne désinstaller aucun noyau, c'est à l'administratrice de le faire au besoin manuellement. Par exemple, si tu voulais désinstaller la version 3.16.0-4 après être redémarrée sur la version 3.16-2, il faudrait faire en root

dpkg -l *3.16.0-4*

et désinstaller tous les paquets marqués comme installés par ii qui concernent le noyau . Cela toucherait le paquet linux-image-3.16.0-4-amd64 et possiblement le paquet linux-headers-3.16.0-4-amd64 et parfois aussi le paquet linux-kbuild-3.16.0-4 .

Il ne faudrait surtout pas désinstaller les paquets qui concernent le noyau en cours d'exécution, ni de paquets autres que linux-image, linux-headers et linux-kbuild de la version 3.16.0-4 dans l'exemple que je te donne.

Il doit y avoir des utilitaires graphiques pour le faire, mais comme je suis arriéré, je ne connais que la ligne de commandes pour le faire.

Note aussi que sous ArchLinux, le noyau en cours d'exécution est désinstallé automatiquement lors de l'installation d'une nouvelle version de celui-ci. Il n'y a toujours qu'une version du noyau Linux d'installé avec la Arch par défaut. Ça facilite grandement le travail administratif de ce côté.

Par contre, il faut redémarrer au plus vite avec la Arch, parce-que l'image du noyau et les modules en cours d'exécution ne sont plus qu'en mémoire vive. On ne peux plus charger de nouveaux modules. Le redémarrage immédiat est le plus judicieux avec la Arch lors d'une mise-à-jour du noyau Linux.

La Arch offre l'option fallback dans le menu Grub au cas où le noyau aurait un problème à faire un démarrage normal.

J'ai redémarré, c'est bon ma carte wifi est revenue. Merci

Je dois être arriérée moi aussi . Je désinstalle les anciens noyaux de kubuntu en ligne de commande et jusqu'à maintenant je n'ai jamais eu de problèmes. Je sais qu'on peut le faire avec Synaptic, mais je trouve plus facile en ligne de commande. Je garde toujours l'ancien noyau.

Par contre, pourquoi je n'ai pas les options avancées de Debian dans le menu de démarrage pour pouvoir démarrer sur l'ancien noyau si j'ai un problème ?

J'ai édité mon message au-dessus

Gros problème, maintenant que je suis revenue sous l'ancien noyau, ma VM FreeBSD ne se lance plus.
J'ai le même message d'erreur que j'avais posté sur le forum

Si je dois choisir entre FreeBsd et ma carte wifi, je prends FreeBsd

Comme tu l'as dit plus haut, c'est Grub de ta ArchLinux qui gère les choix du menu de démarrage de Grub. L'entrée pour Debian a été ajoutée manuellement pour démarrer la version la plus récente du noyau Linux de ta Debian testing, sur laquelle on vient de faire pointer les liens symboliques.

Ces liens symboliques pointent toujours il me semble sur le dernier noyau installé. Comme Debian réinstalle Grub dans le Mbr automatiquement lors d'une mise-à-jour de Grub, pour éviter ça, on a désinstallé Grub de ta stable et de ta testing afin que ce soit Grub de la Arch qui soit utilisé sans partage.

Pour ce qui est de VirtualBox dans testing regarde en root si les modules de VirtualBox sont chargés

lsmod|grep vbox

Sinon, fait

systemctl start vboxdrv

S'il n'y a pas de message d'erreur, regarde encore s'il sont chargés

lsmod|grep vbox

Sinon, fait

systemctl setup vboxdrv

et regarde encore s'il sont chargés. Si oui, VirtualBox devrait fonctionner. Sinon, je donne à mon chat ma langue.

J'ai aucun retour à la commande lsmod|grep vbox

ça veut dire que les modules de Virtualbox ne sont pas chargés ?

J'attends ta réponse avant de continuer

Bon j'ai quand même continué, et ça a l'air mal parti. Je crois que tu vas pouvoir donner ta langue à ton chat

root@testing:~# lsmod|grep vbox
root@testing:~# systemctl start vboxdrv
root@testing:~# lsmod|grep vbox
root@testing:~# systemctl setup vboxdrv
Unknown operation 'setup'.

Et si tu fais

service vboxdrv setup

root@testing:~# service vboxdrv setup
Stopping VirtualBox kernel modules ...done.
Uninstalling old VirtualBox DKMS kernel modules ...done.
Trying to register the VirtualBox kernel modules using DKMSError! Your kernel headers for kernel 3.16-2-amd64 cannot be found.
Please install the linux-headers-3.16-2-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it's located
...failed!
(Failed, trying without DKMS)
Recompiling VirtualBox kernel modules ...failed!
(Look at /var/log/vbox-install.log to find out what went wrong)

apt-get install linux-headers-3.16-2-amd64

service vboxdrv setup

Après avoir fait apt-get install linux-headers-3.16-2-amd64

root@testing:~# service vboxdrv setup
Stopping VirtualBox kernel modules ...done.
Uninstalling old VirtualBox DKMS kernel modules ...done.
Trying to register the VirtualBox kernel modules using DKMS ...done.
Starting VirtualBox kernel modules ...done.

C'est bon VirtualBox a démarré

L'élève par sa pratique en apprend à celui qui l'aide. Depuis longtemps j'utilise Debian testing/sid. J'ai le plus souvent utilisé le dépôt de VirtualBox pour installer VirtualBox parce-que cela donne plus de possibilités.

Je m'étais toujours demandé pourquoi un noyau supplémentaire à celui en cours d'exécution était nécessaire à cette installation. J'ai trouvé la raison grâce à toi. C'est que VirtualBox n'offre que des paquets pour Debian stable.

Les modules de VirtualBox même pour le noyau de Debian testing doivent pour cette raison être compilés avec la version des sources du noyau Linux de la Debian stable. Comme la testing n'a pas besoin de cette version du noyau, elle est installée seulement pour VirtualBox stable.

Le plus beau dans tout ça, c'est que ces modules version stable de VirtualBox sont chargés par le noyau version testing après leurs compilations.

Le noyau Linux a cette capacité relative je dirais de charger des modules de numéros de versions autres que celui du noyau en cours d'exécution.

Une énigme de moins dans la tête.

Bravo Mimi.

Vraiement un très beau post ..

Bravo !!

Au moins pour une fois, c'est moi qui t'aurais aidé à comprendre quelque chose , ça change

m_n a écrit :

Vraiement un très beau post ..

Bravo !!

Très instructif