Problème de résolution DNS en ligne de commande

Support Debian
#1

Bonjour,

je fais joujou avec la console rescue de mon install Debian pour essayer de récupérer les microcodes qui me manquent mais quand je fais un apt-get, j’ai ce retour :
« Ne parvient pas à résoudre < deb.debian.org > »

resolvconf est bien présent dans /etc/, le fichier resolv.conf ne contient que l’IP (V4) de ma BOX.

Jusque là, rien d’anormal pourtant quand je fais un ping sur debian-fr.org, par exemple, le retour est « nom de service inconnu ».

Ma Box est hors de cause puisque je suis en ligne sur le forum à partir de ma partoche Ubuntu, donc les DNS lui sont correctement accessibles.

Comme d’hab dans ce genre de situation, le blême doit être tellement énorme que je ne le vois pas.

J’ai beau m’enfiler des tasses de café, je ne vois pas comment régler ça.

Merci de votre aide, ça m’évitera de passer au whisky :rofl:

Je précise que les dépôts non-free et contrib sont bien présents dans le sources.list et que j’ai utilisé la version « firmware » de l’installateur.

#2

Qu’affichent ip addr et ip route ?
Le réseau n’est pas forcément activé automatiquement en mode rescue, ça dépend du mode de configuration.

Si tu démarres en mode rescue juste pour ne pas lancer l’interface graphique, il est plus commode de démarrer en runlevel 2, 3 ou 4 (traduits en multi-user.target par systemd).

#3

Je démarre en mode rescue parce que le boot normal bloque. J’ai fait un journalctl -xb pour noter les erreurs. Les voici dans l’ordre d’apparition :
do_IRQ: 1.55 No irq handler for vector
[drm:radeon_pci_probe [radeon]] ERROR Blablabla…
[drm:amdgpu_pci_probe [amdgpu]] ERROR Blablabla…
wdat-wdt: can’t request region for ressource => suit une adresse mémoire segment:offset
kernel:kvm disabled by bios
usb 6-4: firmware: failed to load ar3k/athrBT_0x…
Bluetooth: loading patch file failed

Le dump se termine par : « The unit systemd-pgckd.service entered the ‹ dead › state. »

Pour faire un ip addr et un ip route, il faut que je reboote sur Debian, donc je viendrai compléter plus tard en me loguant depuis ma bécane de secours mais c’est clair que c’est un problème de réseau. Pourtant, l’install s’est bien passée à partir d’un iso netinst…

Pour le moment, je dois rester sur Ubuntu, j’ai des trucs urgents à faire.

[EDIT à partir de ma bécane de secours]
Les retours de « ip addr » et celui de « ip route » sont bien stockés sur ma partoche Debian mais je ne sais plus comment faire pour transférer ça sur une clé USB.

J’ai bien monté ma clé comme on doit faire mais je ne me souviens plus comment on copie un fichier en ligne de commande… Et ça me casse de chercher. La console me rappelle de vieux souvenirs, c’est amusant un moment mais à l’époque, les clés USB n’existaient pas.

cp * => ma_cle OK mais mon Q pour la syntaxe exacte, mes essais ont tous planté.

Il y a de quoi dire VIVE WINDOWS ! Mais je n’irai pas jusque là :roll_eyes:

Bon, c’est l’heure de prendre mes gouttes et d’aller au lit…
[/EDIT]

#4

Tu ne serais pas en Belgique ?
J’avais eu çà là bas avec les DNS menteurs de Proximus.
J’avais résolu avec Nextdns (qui me sert aussi comme alternative à pi-hole) même si d’aucuns préfereraient un soluce qui ne soit pas five-eyes :wink:

#5

Si éénmaal, sur le réseau fibre de Proximus mais avec un autre portail, Edpnet.

#6

Tiens, intéressant : même si Edpnet utilise le réseau Proximus, il doit avoir ses propres serveurs DNS.
Qui par conséquent doivent avoir les mêmes contraintes par les autorités.

Il te reste à utiliser Nextdns ou autre outil de dns non censuré…

#7

Une chose m’étonne cependant : je n’ai aucun problème de DNS avec mon tel Androïd, ma partition Ubuntu ni avec ma bécane de secours sous Windaube 10.
Lorsqu’un accès est refusé à cause de la localisation, il y a un message. Par exemple, je ne peux pas recevoir TF1 ni même RTL en streaming.
L’Europe ? mon Q, oui. Les Brits ont eu bien raison de se barrer.
A la réflexion, je pense qu’il s’agit plutôt d’un problème de configuration et que le réseau ne se charge pas en mode rescue.
D’ailleurs, la commande :
ip route > ip_route
retourne un fichier vide.

#8

CA Y EST, J’AI TROUVE !

service network-manager restart

en ligne de commande et ça fait la rue Michel. Le module râle un peu parce que les IP sont en V4 mais ça roule quand même et ça mouline sur les MAJ.

Et un problème de résolution résolu…

#9

Solution de repli : papier et crayon.

Et tu as besoin d’une clé USB pour copier un fichier vide ?

C’est ce que j’écrivais dans ma première réponse. Les interfaces gérées par NetworkManager ou définies en « auto » dans /etc/network/interfaces ne sont pas activées en mode rescue parce que les services respectifs network-manager et networking ne sont pas démarrés. Seules les interfaces définies en « allow-hotplug » dans /etc/network/interfaces sont activées parce que c’est fait via udev lors de leur détecteur et pas via le service networking.

#10

C’est vrai et c’est logique. Sur le moment, je m’étais focalisé sur la gestion de la clé USB, le post de @nam1962 m’a fait sortir de ma torpeur de vieillard quasi-grabataire :thinking:

Et logique parce que si c’est le réseau qui fout le Bronx, une fois démarré… Ça peut aller jusqu’à boucler sur des reboots.

Note que ma commande n’est pas la bonne mais je ne me souviens plus de la commande de démarrage initial.

Peut-être que c’est service network-manager start ?

Dans le doute, j’ai fait comme je connais, je sais bien qu’un « man service » aurait pu me renseigner mais ça me casse.

#11

restart fait stop et start, donc ça revient au même si le service n’est pas démarré.

#12

Oui mais je trouve que c’est moins propre.