Cyril Brulebois a écrit 652 commentaires

Les logs d'un client qui parle à un serveur, ça ne donne qu'une partie de la conversation. Je suggère donc d'aller regarder s'il y a des infos dans /var/log/auth.log ou journalctl -u ssh. Si pas de piste évidente, augmenter la verbosité côté sshd et recommencer.

Debian Consultant @ DEBAMAX

Même les miroirs en ftp.<country-code>.debian.org comme ftp.fr.debian.org peuvent être KO pendant des jours entiers, ça arrive. Par exemple en raison de #1008108 (le rapport a été ouvert plusieurs jours après le début du problème, ça a dû durer une semaine, peut-être même une dizaine de jours).

Cependant, deb.debian.org devrait être suggéré par défaut dans la plupart des cas, et il y a une importante redondance derrière.

Debian Consultant @ DEBAMAX

À tout hasard, une mise à jour du firmware ?

https://fwupd.org/lvfs/devices/com.lenovo.ThinkPadN1QRN.firmware

Je ne connais pas le process d'acceptation/revue/etc. sur cette plateforme, mais une semaine d'écart entre la date annoncée sur cette page et ce que tu as constaté ne me semblerait pas incohérent.

Je tenterais sudo journalctl -u 'fwupd*' pour voir s'il s'est passé des choses de ce côté-là.

Debian Consultant @ DEBAMAX

https://doc.ubuntu-fr.org/squid-deb-proxy est probablement un bon point de départ ?

Debian Consultant @ DEBAMAX

Aucun souci, ça n'est pas forcément évident comme gymnastique. J'ai notamment en tête l'énorme table sous « 5.3. Alternative Function Assignments » du BCM2711… il m'avait fallu un peu de temps pour vraiment comprendre ce qu'il se passait. Je joue avec ça sur d'autres modèles, et ça m'arrive de fabriquer des DTBO. D'ailleurs, j'ai quelques articles à publier sur le blog de ma boîte, mais il me reste à les écrire…

Debian Consultant @ DEBAMAX

Jetons un œil à la doc sur la console série.

Cela confirme bien deux consoles sur le Pi Zero. Note la distinction entre primary UART et secondary UART.

En utilisant les device tree overlays, il est possible de changer la configuration de différents pins, et donc de récupérer la main sur une console série qui ne serait pas activée par défaut.

Attention aux différences entre UART et mini-UART cependant, en fonction des besoins, ça peut ou peut ne pas convenir.

Debian Consultant @ DEBAMAX

CIDR date de 1993. :o)

Debian Consultant @ DEBAMAX

Ce qui suit n'a valeur que d'anecdote, mais si ça peut aider à orienter un choix…

La théorie veut que TESE soit sympa parce que s'il y a des erreurs, c'est de la faute de l'URSSAF et c'est à eux de corriger (les bulletins sont d'ailleurs régulièrement republiés, mais sans notification, donc il faut surveiller/télécharger les éventuelles mises à jour à la main…). C'est par ailleurs un service gratuit.

En pratique, je me suis retrouvé avec quelques milliers d'euros disparus (prélevés par eux mais non redistribués aux organismes concernés), il a fallu relancer de nombreuses fois ces différents organismes, passer du temps à synthétiser des documents pour démontrer l'ampleur des problèmes, etc. pour enfin récupérer les fonds manquants (et l'URSSAF n'a absolument pas aidé), plusieurs années après.

Si je pouvais adresser un conseil à un Cyril de 2015, ce serait de déléguer la paie au comptable, dès le tout premier euro. Comme le dit rycks, il y a la notion de risque. J'y ajouterais l'aspect tranquillité d'esprit, ne pas avoir besoin de courir après différents interlocuteurs, sans même parler des évolutions réglementaires constantes…

Debian Consultant @ DEBAMAX

Les lignes citées montrent deux choses :

• un lancement en tant que root ;
• un lancement en tant que user non privilégié.

En fonction de comment la session root a été ouverte, c'est assez classique de ne pas avoir la variable d'environnement DISPLAY, et/ou le cookie qui va bien (historiquement ~/.Xauthority mais ça peut être déporté dans un autre répertoire, en fonction du gestionnaire de connexion graphique, auquel cas ne pas perdre XAUTHORITY est également important).

Ça me semble n'avoir aucun rapport avec un éventuel changement introduit entre Debian 10 et Debian 11…

Debian Consultant @ DEBAMAX

L'utilitaire winecfg permet de changer les paramètres de compatibilité (version de Windows, DirectX, intégration au bureau, etc.), je commencerais par vérifier si bouger des paramètres (de manière globale ou spécifiquement pour ton application, ce qui devrait être équivalent puisque tu en as une seule…) permet de refaire fonctionner ton programme.

Debian Consultant @ DEBAMAX

Oui, ça peut être trouvé facilement dans src/ls.c.

Extrait du paquet coreutils de Debian stable (Bullseye) :

    case LS_LS:
      /* This is for the 'ls' program.  */
      if (isatty (STDOUT_FILENO))
        {
          format = many_per_line;
          set_quoting_style (NULL, shell_escape_quoting_style);
          /* See description of qmark_funny_chars, above.  */
          qmark_funny_chars = true;
        }
      else
        {
          format = one_per_line;
          qmark_funny_chars = false;
        }
      break;

Et la page de manuel de la fonction qui va bien : isatty(3).

Debian Consultant @ DEBAMAX

> En général un affichage sous forme de liste requiert l'argument -l à la commande ls…

Non, pour plusieurs raisons :

• -l permet d'avoir des détails ; ceux-ci sont affichés ligne par ligne, mais ça n'est pas la signification première de cette option.
• -1 correspond à ce que tu mentionnes, à savoir une ligne par élément.

Par ailleurs, ls détecte automatiquement si sa sortie est connectée à un terminal et ajuste sa sortie en fonction (par exemple pour afficher les résultats en un certain nombre de colonnes en fonction de la taille des éléments trouvés et de la taille du terminal). Si une redirection est détectée, ls se comporte comme si l'option -1 avait été passée.

Exemple trivial : comparer la sortie de ls /etc et celle de ls /etc | cat (magie !).

Debian Consultant @ DEBAMAX

Attention, bs=512 signifie une taille de bloc de 512 octets.

Cela peut être vérifié dans la page info :

‘bs=BYTES’
     Set both input and output block sizes to BYTES.  This makes ‘dd’
     read and write BYTES per block, overriding any ‘ibs’ and ‘obs’
     settings.  In addition, if no data-transforming ‘conv’ operand is
     specified, input is copied to the output as soon as it’s read, even
     if it is smaller than the block size.

La page de manuel précise la taille par défaut :

bs=BYTES
    read and write up to BYTES bytes at a time (default: 512); overrides ibs and obs

(Pour la petite histoire, un bloc UNIX signifie 512 octets, alors que sous Linux, c'est plutôt 1024. Cf. la variable d'environnement POSIXLY_CORRECT, prise en compte par différents utilitaires classiques.)

Debian Consultant @ DEBAMAX

Cela fait des mois, peut-être années en fait, que je trouve Firefox ultra pénible pour ce qui est sélection de périphériques. C'est le cas pour le microphone mais aussi pour la webcam (casque Bluetooth, caméra USB en haut de l'écran externe). Le ressenti (je n'ai pas cherché à déboguer), c'est que la gestion du branchement à chaud est soit inexistante soit boguée. D'où mon utilisation systématique de Chromium pour toute visio : j'ai toujours le choix parmi les différents périphériques (c'est moins pénible de démarrer un Chromium pour quelques dizaines de minutes que redémarrer mon navigateur principal.)

Debian Consultant @ DEBAMAX

À quoi ressemblent ton entrée de crontab et ton script ?

Debian Consultant @ DEBAMAX

Tu peux regarder la grosse différence entre les paquets locales et locales-all :

kibi@tokyo:~$ apt-cache show locales locales-all | egrep '^(Package|Installed-Size):'
Package: locales
Installed-Size: 16014
Package: locales-all
Installed-Size: 221935

Écrire les locales demandées via /etc/locale.gen permet d'éviter à gérer les interactions qui seraient provoquées via dpkg-reconfigure locales mais cela permet bien d'activer ce qui est voulu, plutôt que de désactiver tout ce qui ne l'est pas.

Debian Consultant @ DEBAMAX

Un grep rapide dans les sources suggère cette option sous cache_peer :

        no-netdb-exchange
                        Disables requesting ICMP RTT database (NetDB).

inspiré par :

$ sed -n '/^NAME.*netdb/,/^$/p' src/cf.data.pre
NAME: netdb_filename
TYPE: string
DEFAULT: stdio:@DEFAULT_NETDB_FILE@
LOC: Config.netdbFilename
IFDEF: USE_ICMP
DOC_START
    Where Squid stores it's netdb journal.
    When enabled this journal preserves netdb state between restarts.

NAME: netdb_low
TYPE: int
DEFAULT: 900
LOC: Config.Netdb.low
DOC_START
    The low water mark for the ICMP measurement database.

NAME: netdb_high
TYPE: int
DEFAULT: 1000
LOC: Config.Netdb.high
DOC_START
    The high water mark for the ICMP measurement database.

NAME: netdb_ping_period
TYPE: time_t
LOC: Config.Netdb.period
DEFAULT: 5 minutes
DOC_START
    The minimum period for measuring a site.  There will be at
    least this much delay between successive pings to the same
    network.  The default is five minutes.
DOC_END

Debian Consultant @ DEBAMAX

Si ça peut donner un point de comparaison, j'utilise Ungoogled Chromium via Flatpak sur Debian 11 (pour Teams…), et j'ai bien accès aux deux webcams (interne et externe), et à toutes les entrées/sorties son (dont l'enceinte Bluetooth et la connectique jack 3.5 mm).

Debian Consultant @ DEBAMAX

Ce que tu décris est plutôt vrai en général mais ça ne s'applique pas au cas d'apache2 :

• En août, Debian 11.0 est sortie avec la version 2.4.48-3.1.
• Le 8 octobre, c'est la version 2.4.51-1~deb11u1 qui est incorporée via bullseye-security.

Concernant le security-tracker, l'info n'est pas présente à l'heure actuelle, mais un verdict classique est « no-dsa » dans les notes, pour les bogues ne nécessitant pas une correction via une suite de sécurité, avec l'annonce de sécurité correspondante. Dans ce cas, c'est souvent via proposed-updates que le paquet est incorporé, avant intégration lors d'une point release ultérieure.

Debian Consultant @ DEBAMAX

Comme le mentionne Gil, le système d'installation suit tes instructions, donc tu peux très bien réutiliser la partition existante, lui attribuer le point de montage /boot, et la formater ou non.

Je n'ai pas de réponse définitive pour ta question initiale (cohabitation de la même partition pour deux systèmes), mais j'aurais tendance à penser que ça peut amener des soucis : versions de GRUB différentes, config différente, et probable « le dernier qui lance update-grub gagne ».

Pour ton besoin spécifique, je pense que je garderai une copie de la partition à portée de main (à remettre en place via un système live au besoin), et je partirais d'une partition formatée.

Une autre question est : installation BIOS ou UEFI ? Dans le second cas, la partition ESP ne devrait pas poser problème, puisqu'il y a un répertoire vendor qui permet de faire cohabiter tout le monde (ici, j'ai typiquement EFI/debian dedans), mais il faudra bien penser à déclarer une partition ESP, sans la formater.

Debian Consultant @ DEBAMAX

Au moins pour Secure Boot, la chaîne de démarrage supportée est : firmware UEFI → shim → GRUB → Linux.

Je ne vois pas trop ce qu'apporterait le fait de virer GRUB de l'équation, Secure Boot ou non.

Debian Consultant @ DEBAMAX

Oui et non.

debian-installer va très fortement inciter à mettre en place ce genre de choses (/boot séparé, en clair), mais GRUB sait déverrouiller un espace LUKS depuis longtemps (fonctionnalité dite « cryptodisk »). Avec l'arrivée du format LUKS2, ça n'était à nouveau plus vrai… J'avais donné une présentation aux mini-DebConf Marseille et Hambourg 2019 à ce sujet, dans laquelle je brossais un panorama rapide des petits challenges à résoudre. J'ai été occupé à d'autres choses après ces deux présentations, mais quelqu'un d'autre a travaillé dessus… Je n'ai pas encore essayé de mon côté.

Au passage, suite à discussion avec le mainteneur de cryptsetup à Hambourg, cette documentation est née :
Full disk encryption, including /boot: Unlocking LUKS devices from GRUB.

Bref, il y avait (pour LUKS) et il devrait y avoir (pour LUKS2) ce qu'il faut dans GRUB pour déverrouiller des espaces de stockage LUKS, qui peuvent à leur tour contenir du LVM, etc., et c'est un manque d'intégration côté debian-installer qui explique cette impression d'obligation d'avoir un /boot séparé, en clair.

Debian Consultant @ DEBAMAX

GRUB supporte tout de même plein de systèmes de fichiers (dont XFS)…

kibi@tokyo:/tmp/grub2-2.04$ ls grub-core/fs/
affs.c     cbfs.c         ext2.c    hfsplus.c      minix2.c     newc.c      proc.c      tar.c     xfs.c
afs.c      cpio_be.c      f2fs.c    hfspluscomp.c  minix3_be.c  nilfs2.c    reiserfs.c  udf.c     zfs
archelp.c  cpio.c         fat.c     iso9660.c      minix3.c     ntfs.c      romfs.c     ufs2.c
bfs.c      cpio_common.c  fshelp.c  jfs.c          minix_be.c   ntfscomp.c  sfs.c       ufs_be.c
btrfs.c    exfat.c        hfs.c     minix2_be.c    minix.c      odc.c       squash4.c   ufs.c

Pour le chargeur de démarrage qui « voit » les autres systèmes, ça dépend très probablement des choix faits au niveau de la distribution et/ou de l'administrateur local. Par exemple sous Debian, il faut que le paquet os-prober soit installé pour que les autres OS soient visibles.

Pour LVM, oui, GRUB sait faire tout seul :

kibi@tokyo:/tmp/grub2-2.04$ ls grub-core/disk/
AFSplitter.c  cryptodisk.c     geli.c    ldm.c       mdraid1x_linux.c   pata.c           uboot
ahci.c        diskfilter.c     host.c    loopback.c  mdraid_linux_be.c  raid5_recover.c  usbms.c
arc           dmraid_nvidia.c  i386      luks.c      mdraid_linux.c     raid6_recover.c  xen
ata.c         efi              ieee1275  lvm.c       memdisk.c          scsi.c

Enfin, pour les 4 partitions primaires, c'est une limitation historique, mais seulement si le partitionnement est de type msdos (aka. MBR). Si GPT est utilisé, il y a largement de la place pour numéroter plein de partitions. :)

Debian Consultant @ DEBAMAX

J'envisageais de faire une petite rétrospective “d-i vs. Debian 11” sur le blog de ma boîte, comme je travaille trop et ne rédige pas assez, c'est encore sur une todo-list… → C'est parti pour quelques réponses en commentaire sur cette dépêche, en te remerciant pour les questions.

Tu peux jeter un œil aux annonces publiées sur la liste debian-devel-announce@, à savoir une annonce par version publiée (Alpha ou RC). Dans chacune, j'essaie de reprendre les changements dans les composants individuels qui peuvent être impactants pour les utilisateurs (plus rarement les développeurs) du système d'installation, et de les résumer à destination des utilisateurs avancés.

Par exemple, pour le cycle de publication de Debian 11 :

• D-I Bullseye Alpha 1
• D-I Bullseye Alpha 2
• D-I Bullseye Alpha 3
• D-I Bullseye RC 1
• D-I Bullseye RC 2
• D-I Bullseye RC 3

C'est donc le debian-installer de la RC 3 qui est utilisé pour Debian 11.0, puisque nos développements de dernière minute n'ont pas explosé en vol.

C'est principalement de la maintenance corrective, ou ce qui semble maintenant s'appeler du « maintien en condition opérationnelle ». La base de code n'est pas toute récente, elle pourrait bénéficier de simplifications, réécritures, etc. (notamment en ce qui concerne la gestion des différentes architectures) mais globalement le système d'installation actuel a une certaine flexibilité (mode texte, mode graphique, installation par SSH ou console série, démarrage par le réseau, etc.), et les investissements en temps/énergie pour le maintenir en état sont relativement raisonnables. À titre personnel, j'aurais aimé avoir plus de temps à y consacrer pendant ce cycle de publication, et les évolutions pour la gestion des micrologiciels sont arrivées bien tard (cf. introduction de l'annonce D-I Bullseye RC 3), mais elles ont fini par arriver…

Cela étant dit, il ne s'agit pas que de corriger les problèmes quand ils apparaissent. Comme cela peut être constaté en parcourant les annonces mentionnées ci-dessus, il y a régulièrement de petites améliorations à gauche à droite dans tel ou tel composant, à la demande d'utilisateur, ou parce que telle technologie de stockage/réseau/autre propose des options supplémentaires, etc.

Dans les évolutions nécessaires durant le nouveau cycle de publication (Debian 12), il y a le passage de GTK 2 à GTK 3 ou 4. Les premiers paquets GTK 3 n'étaient pas utilisables directement dans le contexte du système d'installation, donc cela a traîné. Simon McVittie a indiqué que le passage à GTK 3+ supposera de revoir l'architecture. Nous ne sommes pas passés loin de la catastrophe à forcer de rester sur GTK 2, d'où mes chaleureux remerciements en introduction de l'annonce D-I Bullseye RC 2 (cf. les entrées cdebconf et gtk+2.0 pour plus de détails).

J'ai également des patches qui traînent depuis des années pour proposer, par exemple à mi-chemin du cycle de publication, des images d'installation de stable qui utiliseraient le noyau de stable-backports afin de simplifier l'installation sur du matériel tout récent, mais il faudrait changer quelques composants (comme base-installer) pour avoir une intégration propre. J'espère que Steve McIntyre (debian-cd) et moi (debian-boot) arriverons à trouver le temps d'intégrer cela dans les mois qui viennent. Note : Il s'agit des noms historiques, debian-cd s'occupe « bien évidemment » de produire les images d'installation pendant que debian-boot s'occupe de produire le système d'installation à intégrer dans lesdites images.

Peut-être aurons-nous aussi un jour une nouvelle résolution générale concernant les micrologiciels, et peut-être pourrons-nous proposer des images qui ne soient plus marquées au fer rouge de l'aspect unofficial. Cela étant, je ne considère pas qu'une telle évolution relève des prérogatives de l'équipe du système d'installation (debian-boot) ou de celle qui gère les images d'installation (debian-cd), et Steve semble d'accord sur ce point : c'est au niveau du projet tout entier que cela devrait être discuté, et validé. Cf. mon premier message sur le rapport de bogue #989863.

Il y a plus ou moins régulièrement des personnes qui veulent révolutionner le système d'installation. Elles sont libres de proposer des alternatives, et c'est ensuite au projet Debian en général et à l'équipe qui gère le site web, etc. de voir ce qui est mis en avant et comment. Je note qu'un certain nombre de telles propositions reposent sur des images autonomes (« live ») que nous avons déjà du mal à produire… Nous avons d'ailleurs déjà une alternative à D-I (Calamares).

Pour ma part, je contribue à maintenir l'existant depuis bientôt 10 ans (mon tout premier message sur debian-devel-announce@ date de mai 2012), et bien qu'imparfait, cela permet d'installer Debian de versions majeures en versions majeures… Ce n'est pas forcément fascinant côté utilisateur, mais il me semble que cette constance colle plutôt à la réputation de stabilité de Debian.

Debian Consultant @ DEBAMAX

Je pensais plutôt aux logs du système avant/après la mise à jour, à comparer avant et après correction.

Je vois typiquement ceci ici (installation Debian 11 standard, pas de migration) dans /var/log/{kern,syslog}* et/ou dmesg (en fonction de l'uptime/du logrotate) :

Aug 17 14:45:15 tokyo kernel: [    1.640746] e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) a0:8c:fd:2a:bd:8a
Aug 17 14:45:15 tokyo kernel: [    1.640748] e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
Aug 17 14:45:15 tokyo kernel: [    1.640797] e1000e 0000:00:1f.6 eth0: MAC: 12, PHY: 12, PBA No: FFFFFF-0FF
Aug 17 14:45:15 tokyo kernel: [    1.641487] e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0

ou bien (installation Debian 10 standard, pas de migration) :

Aug 16 15:52:58 hamburg kernel: [    1.558838] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 2c:44:fd:2b:a9:8f
Aug 16 15:52:58 hamburg kernel: [    1.558839] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
Aug 16 15:52:58 hamburg kernel: [    1.558869] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 0100FF-0FF
Aug 16 15:52:58 hamburg kernel: [    1.695614] e1000e 0000:00:19.0 eno1: renamed from eth0

(Ici j'ai cherché le eth0 historique qui se retrouve renommé en autre chose, mais je t'invite à chercher les deux noms dans les logs en question.)

Debian Consultant @ DEBAMAX