Cyril Brulebois a écrit 609 commentaires

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

Ça fait des années que certaines configurations globales sont déployées sous /usr. Quelques exemples :

• /usr/share/fontconfig/conf.avail/10-autohint.conf
• /usr/share/X11/xorg.conf.d/40-libinput.conf
• /usr/share/X11/xorg.conf.d/70-wacom.conf

Et il est possible de changer du comportement par défaut en créant/modifiant/adaptant ces fichiers sous /etc en tant qu'admin local.

C'est exactement la même chose avec les configurations systemd et udev, les règles par défaut sont catapultées sous (/usr)/lib/{systemd,udev} et les admins locaux peuvent adapter sous /etc.

Pour l'aspect « textuel » d'/etc, je vois des zip, des clés publiques/privées (SSH, X.509), des trousseaux GPG, et des choses vraiment binaires comme /etc/ld.so.cache ou du Berkeley DB pour les fichiers de postfix. J'ai un peu la flemme de sortir les vieilles sources d'UNIX pour voir à quel point ce « Editable Text Configuration » est un backronym, mais au moins la page wikipedia FHS suggère qu'il y a débat… :)

Debian Consultant @ DEBAMAX

Vu d'ici, la différence i386 vs. amd64 devrait être absolument sans rapport.

Je soupçonne plutôt l'existence ou l'absence d'un fichier, lien, autre, quelque part, que ça soit une vieille règle udev ou quelque chose de similaire, qui a pu provoquer ce souci. Vu le nommage « moderne » que tu avais avant la mise à jour, j'imagine que tu n'avais pas de net.ifnames qui traîne…

En regardant la page de wiki NetworkInterfaceNames j'imagine que tu as pu avoir un 70-persistent-net.rules… mais si c'est bien ça, pourquoi est-il ignoré avant la mise à jour ?

Il y a peut-être la réponse dans tes logs. :)

Debian Consultant @ DEBAMAX

Tu aurais les logs de la mise à jour ? Typiquement, sous /var/log/apt/, fichiers term.log*.

J'ai du mal à voir comment l'installation d'un noyau a pu « oublier » de déployer vmlinuz & friends dans /boot, surtout sans laisser de message d'erreur explicite, et un statut « pas content » au niveau dpkg… ENOSPC chemin faisant ?

Note que les deux commandes apt-get et apt gère la commande reinstall (pour install --reins(in)tall). ;)

Debian Consultant @ DEBAMAX

Au passage, attention à /proc/sysrq-trigger.

Debian Consultant @ DEBAMAX

À tout hasard, la pagination (via more, less, most, etc. ou bien un pager interne à systemctl) a été activée pour une raison ou pour une autre, et il suffit de faire q (ou équivalent en fonction de l'outil) pour en sortir ?

Debian Consultant @ DEBAMAX

Mon premier réflexe serait de vérifier si la box-bidule propose des baux statiques. 1 MAC = 1 IP (× 2) et hop ? C'est le genre de réglage qui ne devrait pas facilement sauter lors d'une mise à jour future de la box, ça ferait une manip one-shot ?

Debian Consultant @ DEBAMAX

Tu as des mécanismes en place pour empêcher les pisteurs de remonter tout plein d'infos sur ton téléphone, ta navigation, etc. chez les data brokers ? Tu peux choisir d'interdire la localisation précise, l'accès à tes contacts, le fait de passer un coup de fil, etc. et l'application fonctionne quand même ?

Debian Consultant @ DEBAMAX

Ça se passe comment dans cet environnement, pour tout ce qui est pisteurs/permissions ?

Le rapport d'Exodus Privacy m'inciterait bien à ne jamais songer à installer une telle application sur mon téléphone, quel que soit l'environnement. (J'ai fait le tour des applis des grands groupes bancaires français il y a quelques temps, c'est le même niveau d'indécence environ partout.)

Debian Consultant @ DEBAMAX

C'est comme les rapports de bogue, c'est plus simple si on est complet dès le début… préciser la banque ne coûterait pas trop cher et ça éviterait de jouer aux devinettes.

Je serais toi, je me renseignerais sur le lecteur CAP qui est probablement un lecteur de carte à puce (chez CE) ou le lecteur PASS CyberPlus (chez BP). Chez CM/CIC j'ai opté pour le boîtier DIGIPASS pour éviter d'avoir à utiliser la moindre application (modulo 29 € à l'acquisition).

Debian Consultant @ DEBAMAX

J'ai l'impression qu'il y a une grosse confusion.

Pour commencer, à propos du « si c'est possible » : À ma connaissance, sur architecture PC, une machine estampillée Windows 8 doit pouvoir laisser la possibilité de désactiver Secure Boot et/ou d'enrôler une MOK (Machine Owner Key).

Quant à « OS signé par Microsoft » c'est un beaucoup trop gros raccourci. Il faut que le chargeur de démarrage soit signé par une autorité de confiance, c'est très différent d'un système d'exploitation complet. On trouve souvent le composant shim qui fait effectivement un tour pour se faire tamponner cryptographiquement, mais le reste peut être signé par d'autres clés (par exemple Debian Secure Boot CA). Cela inclut (mais n'est pas limité à) : GRUB, le noyau Linux, fwupd, etc. Des modules complémentaires (module patché, module propriétaire nvidia, etc.) peuvent être signés par l'administrateur local grâce à la MOK, qu'il conviendra d'enrôler dans le firmware (cf. mokutil).

Debian Consultant @ DEBAMAX

Sur tout un tas de distributions, dont je pense Kubuntu, Secure Boot ne devrait pas poser de problème, tu peux donc le laisser activé.

Si tu démarres avec Secure Boot activé, ça sous-entend démarrer en mode UEFI (plutôt que BIOS = Legacy = CSM…), et ça veut dire avoir une partition ESP (EFI System Partition) sur le système déployé. Le système d'installation de ta distribution devrait faire le boulot pour toi.

Debian Consultant @ DEBAMAX

Cf. logrotate(8) :

maxsize size

Log files are rotated when they grow bigger than size bytes even
before  the additionally specified time interval (daily, weekly,
monthly, or yearly).  The related size option is similar  except
that  it  is  mutually exclusive with the time interval options,
and it causes log files to be rotated  without  regard  for  the
last  rotation  time,  if specified after the time criteria (the
last specified option takes the precedence).   When  maxsize  is
used, both the size and timestamp of a log file are considered.

Debian Consultant @ DEBAMAX

À tout hasard, si la piste Secure Boot se confirme (bootctl peut aider, indépendamment de vboxconfig), un coup de MOK + signature des modules out of tree ?

Debian Consultant @ DEBAMAX

Sous Thunar 4.16.8 (Debian bullseye), j'ai un View > Side Pane > Shortcuts (Ctrl+B) qui semble commander la disparition/la réapparition de ladite barre latérale. Au hasard, le problème est apparu après un Ctrl+V qui aurait dérapé ? :)

Debian Consultant @ DEBAMAX

Sinon, pour la détection, mettre les infos %b/%B en regard de %s via stat peut être une idée, mais je ne suis pas sûr de comprendre l'intérêt de courir après ces fichiers en particulier.

Édition : j'ai tendance à utiliser indifféremment l'un ou l'autre pour préallouer des fichiers, mais fallocate est un outil bien plus complet que truncate.

Debian Consultant @ DEBAMAX

Extrait de la page de manuel de truncate :

NAME
       truncate - shrink or extend the size of a file to the specified size

SYNOPSIS
       truncate OPTION... FILE...

DESCRIPTION
       Shrink or extend the size of each FILE to the specified size

       A FILE argument that does not exist is created.

       If  a  FILE  is larger than the specified size, the extra data is lost.
       If a FILE is shorter, it is  extended  and  the  sparse  extended  part
       (hole) reads as zero bytes.

Exemple :

kibi@tokyo:~$ truncate -s 1T toto
kibi@tokyo:~$ ls -l toto
-rw-r--r-- 1 kibi kibi 1099511627776 Jun  4 20:25 toto
kibi@tokyo:~$ du -h toto
0   toto

Voire aussi l'option --sparse de rsync, ou les outils qui manipulent des images disque (au sens qemu-img), avec lesquels ça peut être une bonne idée de ne pas prendre de la place si on n'en a pas (encore) besoin.

Je ne sais pas trop pourquoi tu n'es pas content des « pages wiki habituel[le]s », mais après l'avoir seulement survolée, https://wiki.archlinux.org/title/Sparse_file semble intéressante, tout comme https://en.wikipedia.org/wiki/Sparse_file qui est en lien à la fin…

Debian Consultant @ DEBAMAX

Je pense que ça dépend beaucoup de l'implémentation au niveau du firmware UEFI.

Vu récemment sur une permanence LUG, un système qui disait oui-oui à toute modification des paramètres via efibootmgr, mais qui s'obstinait à chaque fois à démarrer Windows, quelle que soit la configuration spécifiée. Sur une install party, j'ai également vu des firmwares qui se vautraient avec des erreurs mémoire quand on essayait de manipuler les entrées, par exemple pour… les afficher ! (Genre efibootmgr était OK mais efibootmgr -v explosait dans tous les sens.)

Voir également le besoin assez classique d'utiliser l'astuce du removable media path.

Bref, sur le papier, ça pourrait être une excellente piste. Dans la réalité, les implémentations sont… tout autant plein de bogues que l'étaient les BIOS historiques. :(

Debian Consultant @ DEBAMAX

Oh, je crois reconnaître un client CM/CIC avec un Digipass ? :)

Debian Consultant @ DEBAMAX