WhiteCat a écrit 705 commentaires

En 2013 est apparu une RFC qui dévoile un nouveau protocole : multicast DNS.
Le but de ce protocole est de pouvoir faire de la résolution de noms sur un réseau local, là où un serveur DNS n'existe pas par exemple. Typiquement un LAN à la maison.

Or ce protocole spécifie que son "champ d'application" est limité au domaine en .local.
Autrement dit, les implémentations de ce protocole s'occuperont de faire de la résolution de noms uniquement sur des appareils qui disposent d'un nom sur ce domaine.

Et c'est là que c'est malheureux car depuis 2 ou 3 décennies, Microsoft a pu documenté ici ou là des tutos, documentation, etc. avec des déploiement d'AD en .local.
Ce TLD étant "libre", il n'y avait a priori pas de problèmes (mêmes si j'entends de plus en plus aujourd'hui que c'est une mauvaise idée d'utiliser un TLD qui n'existe pas, mais bref).
Or du jour au lendemain, ce TLD est officiellement déclaré comme spécifique à un protocole (en l’occurrence mDNS) !

Et donc aujourd'hui les OS qui veulent se conformer à la RFC pour couvrir le multicast DNS doivent faire ce qui est indiqué dans cette RFC, qui dit que les noms en .local doivent être résolues en priorité par un résolveur mDNS.

Extraits de la RFC :
"This document specifies that the DNS top-level domain ".local." is a
special domain with special semantics, […], and names within
this domain are meaningful only on the link where they originate."

"Any DNS query for a name ending with ".local." MUST be sent to the
mDNS IPv4 link-local multicast address 224.0.0.251"

"Using ".local" as a private top-level domain conflicts with
Multicast DNS and may cause problems for users.
[…] Because of this, we recommend against using ".local" as
a private Unicast DNS top-level domain. We do not recommend use
of unregistered top-level domains at all, but […] the following
top-level domains have been used on private internal networks
without the problems caused by trying to reuse ".local." for this purpose:
.intranet.
.internal.
.private.
.corp.
.home.
.lan."

Aaaahh les fameux domaines .local !
J'ai presque toujours vu les AD Windows des boites configurés comme ça alors que c'est une TLD réservé au multicast DNS. Bravo à Microsoft et aux admins… :-)

Bref, je suis quasiment sûr que tes machines sont configurées pour checker en 1er le multicastDNS avant le DNS, comme c'est le cas par exemple sur ma Fedora par exemple :

$ cat /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns

Sur Fedora la résolution DNS est faite en dernier !
Le module mdns4_minimal ne fait que de la résolution d'adresses en .local. Vu qu'il ne trouve rien en mDNS correspondant à tes entrées, il stoppe complètement la résolution à cause du "[NOTFOUND=return]". Donc le DNS n'est jamais cherché.

Normalement en enlevant le "mdns4_minimal [NOTFOUND=return]" de la ligne, tes résolutions DNS devraient fonctionner, par exemple :

$ cat /etc/nsswitch.conf
hosts: files resolve [!UNAVAIL=return] myhostname dns

Personnellement, mon Pixel 3 utilise le GPS, Glonass et Galiléo simultanément.
En tout cas c'est ce qu'indique l'application "GPSTest" que j'ai installé sur mon tél depuis le Play Store.

Si tu appuis sur Échap au moment du POST, tu n'as pas les messages de la carte mère ou du chargement de l'OS qui s'affiche ?

Sinon, si tu peux démarrer sur une clé USB Linux bootable, tu peux lancer cette commande depuis le shell :
$ systemctl reboot --firmware-setup

Chez moi ça a rebooté le PC et est aller directement dans le BIOS. Mais apparemment ça ne fonctionne pas forcément sur tous les PC. À essayer quand même !

Mais où vois-tu cette valeur de ~75 IOPS dans les sorties des commandes ? Je suis curieux je n'y vois que des valeurs en ko/s.

C'est la colonne "tps" (transfer per second) de la commande iostat.

https://en.wikipedia.org/wiki/IOPS
https://coderwall.com/p/utc42q/understanding-iostat

Je ne suis pas sûr de voir le rapport avec le sujet :-/

Ceci étant dit, les distrib' 32 bits sont censées pouvoir booter sur des CPU 64 bits.
Si ça ne marche pas, c'est un bug, pas un problème intrinsèque.

Essayes avec une Fedora plus ancienne, comme la Fedora 27 ou 28.

A priori le support de ce genre de machine a été mis en place dans Fedora à partir de F27 (https://fedoraproject.org/wiki/Changes/32BitUefiSupport) ou bien F28 (https://bugzilla.redhat.com/show_bug.cgi?id=1474861) je ne suis pas sûr.

Mais en tout cas peut-être que dans les versions plus récentes de Fedora ce support fonctionne moins bien (faute de testeur ?).

Ah oui OK merci, c'était juste ça…
Je débute en Ansible et Yaml ! ^{^}

Bonjour,

Comment tu constates que ton service ne s'arrête pas proprement lors d'un reboot ?

J'utilise pas d'appli GUI qui nécessite de droits root donc je t'avoue que j'ai pas été confronté à ce soucis. À vrai dire je ne savais même pas que Wayland posait problème pour ça !

Le fait qu'il ne s'allume pas ou oui c'est une chose, le pire problème c'est quand la LED était éteinte mais qu'en fait le pavé numérique était bien actif ou vice versa…

Bug que j'ai eu pendant des années et jamais corrigé.

Mais je me rends compte que je ne semble plus avoir ce problème depuis quelques temps, peut-être que c'est finalement le fait d'avoir passé sous Wayland qui n'a pas le même problème que Xorg (?).

J'ai indiqué "pvresize", je voulais bien sûr dire "lvresize" :-)

Son fournisseur lui a bien agrandi son disque (150 Go -> 300 Go).
C'est pas au fournisseur d'aller dans la VM pour agrandir les partitions et filesystem après…

Au vu de ton précédent post (que tu as mis en lien) et la capture d'écran, c'est bon ton fournisseur t'as agrandi ton disque : tu as 300 Go maintenant. Et tu as bien redimensionné ton Physical Volume à 300 Go.

Maintenant, il ne te reste plus qu'à redimensionner depuis ton OS (dans l'ordre) :
1) Ton Logical Volume (avec la commande "pvresize")
2) Puis le système de fichiers qui est dessus (avec la commande "resize2fs" si ton filesystem est de type ext4)

À noter que la 2e commande peut-être faite automatiquement avec une option supplémentaire de "pvresize" en fait…

PS : ça ne me choque pas que ton fournisseur de fasse payer pour ce genre d'opérations. Je ne connais pas ton contrat avec eux, mais j'imagine qu'ils ont juste mis à disposition une VM et basta. Tu en fais ce que tu veux, c'est pas à eux de gérer ce qu'il y a de dedans… Les partitions et filesystem c'est pas leur problème !

Bonjour,

Avec "efibootmgr" tu peux voir les entrées UEFI qui sont configurées sur ta machine.
Ce programme permet aussi de dire sur quelle entrée booter au prochain boot. Et j'ai déjà vu sur certaines machines qu'il y avait une entrée pour aller directement dans le BIOS. Il faudrait donc changer avec efibootmgr la prochaine entrée UEFI à charger.

Sur ma machine perso qui est assez ancienne (génération Sandy Bridge) j'ai pas cette entrée malheureusement :

# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* Fedora
Boot0001* UEFI: INTEL SSDSC2BW240H6

Mais si toi par chance tu l'as, tu pourrais changer le NextBoot :
# efibootmgr --bootnext 0002
(par exemple si chez toi "Boot0002" correspond à l'entrée pour aller dans le BIOS)

Elle est ou la transparence reseau sous wayland? Oui pour moi c'est fondamental cela.

C'est à dire ? Tu fais quoi avec ?

Attention, avec le DD, le block size utilisé peut fortement accélérer ou ralentir le processus de copie

+1
C'est même carrément déterminant.

Le block size (bs) par défaut est de 512 octets. Il faut au minimum le mettre à bs=1M pour avoir des bonnes performances de copies.

Perso, à chaque fois que je fais un dd d'un HDD, je mets en bs=4M.
Entre 2M, 4M, 8M ou plus, je n'ai jamais vraiment constaté de grosses différences.

Un dd sur un système online, j'oserai jamais perso. Je sais que le résultat sera foireux… D'ailleurs, techniquement, ça ne sera même pas un vrai clone vu qu'il y aura forcément des divergences.

Un clonage via dd en offline est le plus approprié. Si ton HDD a un débit pas trop naze, en 2 heures c'est fait.
C'est la méthode la plus simple (une commande à lancer) et la plus fiable pour cloner.

Je suis sûr que c'était juste une tournure, un abus de langage ;-)
Il parle bien de pilote.

Donc je trouve que AMD marche bien avec du matériel ancien et un système stabilisé

C'est une idée que tu te fais à mon avis, à cause de ta mauvaise expérience.
Car les RX400 / RX500 / Vega, ça fait des mois et des mois que Phoronix les testent sans soucis. Ces générations sont probablement mêmes les mieux supportées par AMD car en développement actif.
Moi-même j'ai une RX 570, elle tourne au poil sous Fedora. Tous mes jeux Steam passent sans broncher. Avant j'avais une R9 380X, c'était pareil, aucun soucis.

En libre et très performant, c'est encore du domaine de l'utopie

C’est faux.
Que ce soit AMD ou Intel, leurs pilotes officiels sont les pilotes libres.
Et les benchmarks Phoronix le montrent, ils sont globalement du même niveau que les pilotes Windows : Phoronix - Additional Windows 10 vs. Ubuntu 18.04 NVIDIA/AMD Graphics Benchmarks

J'ai rien reçu :'(

Voilà les termes et conditions pour le pack Fortnite :
https://www.nvidia.com/fr-fr/geforce/campaigns/fortnite-bundle/terms-conditions/

Donc le code est normalement valide jusqu'au 1er mars 2019. Donc quel est le problème ?

Sinon, il est indiqué "Cette offre ne peut pas être remplacée, échangée, vendue ou substituée contre de l’argent ou un autre produit". Mais ce n'est pas marqué qu'on ne peut pas la "donner" :p

PS : j'ai pas reçu ton code par mail :'(

Tu trouveras mon mail ici :
https://drive.google.com/file/d/1QxKS3kt4wboc4BUXmKAsjmOPmu-TiNc3/view?usp=sharing

Je suis intéressé par le code pour Fortnite :-)