Debian 12 est disponible depuis quelques jours. Si vous n’utilisez le système que depuis sa version 11, vous vous êtes peut-être posé la question de sa mise à jour vers la nouvelle mouture majeure. Nous vous proposons une marche à suivre, d’autant que Debian 12 introduit un changement important dans les dépôts.
L’arrivée d’une nouvelle Debian est toujours un évènement important dans le monde Linux. La réputation de solidité et de fiabilité de cette distribution n’est plus à faire, et elle sert de socle à un très grand nombre d’autres systèmes, dont le plus connu est sans conteste Ubuntu (qui sert lui-même de base à de nombreuses distributions, dont Linux Mint).
Debian 12, nommée Bookworm, apporte une longue liste d’améliorations, en plus d’une vaste modernisation, incluant le passage au noyau Linux 6.1. Vous souhaitez donc peut-être y passer dès maintenant, mais ne possédez pas une information importante : sur Debian, les mises à jour majeures ne sont pas automatiques.
La position de Debian a toujours été claire sur le sujet, préférant laisser un contrôle total aux utilisateurs, le processus pouvant être long sur des configurations chargées en applications, modifications et autres.
Voici donc un petit guide pour vous guider dans le processus. Dans tous les cas, rien ne vous empêche d’attendre que Debian 12 ait reçu une ou deux « versions à point », dans le cas où vous craindriez des erreurs de jeunesse.
Avant toute chose : sauvegardez !
Passer à une version plus récente d’un système est souvent présenté comme une étape simple, presque triviale. Une vision largement accentuée par les habitudes prises sur les environnements mobiles. Et pour cause, qu’il s’agisse d’Android ou d’iOS, le processus général est le même pour les mises à jour mineures, intermédiaires et majeures : un téléchargement suivi d’une phase d’installation plus ou moins longue.
Mais sur ordinateur (n’importe lequel), et en dépit de gros efforts sur l’expérience utilisateur, l’étape est loin d’être aussi anodine, les configurations (matérielles comme logicielles) étant beaucoup plus variées.
Avant de vous lancer dans cette opération, nous vous invitons à sauvegarder tout ce qui peut (ou doit) l’être. On parle ici des documents personnels bien sûr, mais également des photos, vidéos, fichiers de configuration, sauvegardes de jeux et autres que vous pourriez perdre si une erreur importante survenait pendant le processus.
Les solutions ne manquent pas, mais tournent essentiellement autour du stockage externe (disque, clé USB…) et du cloud. Choisissez simplement celle qui vous semble la plus naturelle et qui vous assurera de pouvoir récupérer vos données en cas de problème.
Installer toutes les mises à jour en attente
Avant de s’attaquer à Debian 12, il faut vérifier qu’il n’y a pas d’autres mises à jour en attente pour Debian 11.
Exécutez les deux commandes suivantes dans un terminal :
sudo apt update
sudo apt upgrade
la première vérifie les dépôts et met à jour la liste des nouveaux paquets en attente. La seconde récupère les mises à jour potentielles et les installe.
Si des opérations ont eu lieu dans cette étape, redémarrez l’ordinateur par sécurité (via le menu en haut à droite ou la commande sudo systemctl reboot).
Mettre à jour le fichier des dépôts
L’étape la plus importante est la modification du fichier sources.list situé dans /etc/apt/. Premièrement, il faut s’assurer que vous avez bien un compte avec des droits administrateur. Si besoin, créez-le dans la section Utilisateurs dans le panneau des Paramètres.
Deuxièmement, un changement important est intervenu dans Debian 12 : l’apparition du dépôt non-free-firmware. Il est spécifiquement créé pour les firmwares non-libres, qui ne sont donc plus mélangés avec les autres paquets propriétaires du dépôt non-free. En ajoutant ce dépôt au fichier, l’installeur de Debian va pouvoir les récupérer automatiquement.
Il existe deux manières d’accéder au fichier sources.list : soit par le gestionnaire de fichiers puis en l’ouvrant avec l’éditeur par défaut, soit en restant dans le terminal et en utilisant nano. Là encore, choisissez l’option que vous préférez, le résultat est le même.
Dans les deux cas, il faudra réaliser deux séries d’opérations : mettre en commentaire les lignes faisant référence à l’ancienne version de Debian (bullseye) et ajouter celles dédiées à la nouvelle (bookworm).
Voici les lignes à ajouter :
deb http://deb.debian.org/debian/ bookworm main
deb-src http://deb.debian.org/debian/ bookworm main
deb http://security.debian.org/debian-security bookworm-security main
deb-src http://security.debian.org/debian-security bookworm-security main
deb http://deb.debian.org/debian/ bookworm-updates main
deb-src http://deb.debian.org/debian/ bookworm-updates main
deb http://deb.debian.org/debian bookworm non-free non-free-firmware
deb-src http://deb.debian.org/debian bookworm non-free non-free-firmware
deb http://deb.debian.org/debian-security bookworm-security non-free non-free-firmware
deb-src http://deb.debian.org/debian-security bookworm-security non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates non-free non-free-firmware
deb-src http://deb.debian.org/debian bookworm-updates non-free non-free-firmware
Sur les deux captures ci-dessus, on peut voir la différence entre le fichier d’origine et les changements effectués. Enregistrez ensuite ces modifications.
Lancer le processus d’installation
Une fois le fichier sources.list modifié, et sans redémarrer la machine, entrez à nouveau la commande :
sudo apt update
Cette fois, le processus va prendre plus de temps, la liste des modifications étant beaucoup plus importante.
Pour lancer l’installation de Debian 12 (Bookworm), nous vous proposons une démarche en deux temps. D'abord, une commande qui va mettre à jour les paquets installés, sans installer ou supprimer d'autres paquets :
sudo apt upgrade --without-new-pkgs
Ensuite, la commande qui procède à l'installation complète, en mettant à jour tous les paquets et en supprimant les anciens :
sudo apt full-upgrade
La durée de l’installation dépend essentiellement de la puissance de votre machine et de la rapidité de la connexion. Il se peut que le processus s’interrompe une ou plusieurs fois pour vous poser des questions, selon votre configuration.
Redémarrer et profiter
Une fois que le terminal vous indique que l’installation est terminée, il ne reste qu’à redémarrer. Là encore, vous pouvez le faire via l’interface graphique ou avec la commande sudo systemctl reboot. Ce redémarrage sera à peine plus long, car Debian n’a pas de seconde phase de préparation pour le nouveau système.
Après quoi, vous vous retrouverez sous Debian 12. Vous le devinerez facilement en regardant l’interface de la version par défaut : la version de GNOME faisant un grand bond entre l’ancien système et le nouveau, la vue Activités affichera notamment le dock en bas.
Si vous avez installé un autre environnement de bureau ou souhaitez simplement vérifier que tout s’est bien passé, entrez les deux commandes suivantes dans un terminal :
uname -r
cat /etc/debian_version
La première affichera la version du noyau (6.1.0) et l’autre la version du système (12.0).
Commentaires (42)
#1
Barbu présent
Mieux vaut faire une mise à jour en deux temps :
ça permet d’éviter les conflits. Si des paquets avaient été installés à la mimine, ils ont moins de risques d’être supprimés
En passant, il y a moyen de faire un fichier
sources.listen mettant lesmain contrib non-free non-free-firmwareen une fois plutôt qu’en plusieurs lignes.#1.1
Exact
; j’ai suivi ce tuto et il précisait aussi cela.
#2
Ha, petite erreur…
Depuis quelques années, uname -r donne une info différente. uname -v donne la version du noyau, uname -r donne la «release» . Certaines distributions (arch par exemple) ne font pas de différence, mais dans le monde debian les deux sont décorrélés. La release ne changera qu’en cas de mise à jour incompatible du noyau (ce qui est évité autant que possible).
Debian bookworm est sortie avec un noyau 6.1.27, pas 6.1.0.
#3
Faut être vigileant sur l’espace libre disponible à la racine, enfin plus particulièrement le /var/ quelque chose :o
Quitte à faire un montage temporaire sur un autre disque / média amovible ou autre pour avoir la place de faire les upgrades
J’ai un serveur qui est toujours en Debian 10 qu’il faut que j’upgrade de deux versions
#4
De 10 à 11 j’ai eu la mauvaise surprise de pas pouvoir mettre à jour à cause de dépendances circulaires, ce qui a laissé le système dans un état ne permettant plus d’exécuter la majeure partie des commandes… et après redémarrage entraînait un retour sur un mode de récupération d’urgence où rien ne fonctionnait correctement. (Ça concernait entre autres perl)
Merci snapper pour les clichés automatiques, je suis juste revenu en arrière, mais cela ne m’a pas amusé.
#5
J’adore Debian. En termes éthiques et en termes de positionnement, stabilité, pérénnité…
#5.1
Mmmmh.
systemd?#6
J’ai gardé ma Devuan sur son disque à part. “forcée” en Daedalus quand même … Pour le moment, ça m’a juste pété l’utilitaire de gestion de StreamDeck.
Et j’ai fait une fresh install de la Debian 12 sur un autre disque. Euh :
#7
Effectivement la recommandation officielle pour la mise à niveau une fois la mise à jour du sources.list faite est :
Cf. https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html#minimal-upgrade
#8
Le gros soucis concerne les dépôts tiers ajoutés, avant de mettre à jour le système, il faut bien vérifier qu’ils sont disponibles sur bookworm.
Si ce n’est pas le cas, mieux vaut attendre sagement !
#9
Bonjour, merci à vous deux, l’article a été mis à jour en conséquence
#10
Le fais d’avoir une Debian en WSL change-t-il la manière d’upgrader la version ?!
#10.1
Non, je viens d’upgrader en WSL, avec la même procédure
#11
Bon, ce n’est pas une réussite pour cette mise à jour, j’ai pleins de bugs graphiques et mon dual boot a disparu… :‘(
#11.1
Pour les bugs graphiques, testes de remettre en affichage X11 et pas wayland.
Pour le dualboot, n’est ce pas du “juste” au changement par défaut de comportement de grub, il se peut que l’option ne soit pas coché pour détecter les autres os.?
Il y a une option à remettre dans grub puis faire un grub update.
GRUB_DISABLE_OS_PROBER=false dans /etc/default/grub
https://debian-facile.org/viewtopic.php?id=32591
#11.2
Merci d’avoir pris le temps de me répondre.
Concernant la partie graphique, il y a eu un échec lors de la mise à niveau des pilotes nvidia. J’ai dû réinstallé les pilotes et la partie dkms après évidemment avoir rajouté les dépôts contrib.
Et concernant le dual-boot, effectivement le problème venait de cette ligne à dé-commenter, d’ailleurs je ne comprends toujours pas pourquoi ils ne posent pas la question quelque part.
Enfin bref, problèmes résolus !
Je trouve la barre de menu inférieur très moche et pas pratique.
#11.3
Tu as fait une upgrade donc, je suppose que lors de l’upgrade il a dû te demander si tu voulais remplacer le fichier de conf de grub, et tu pouvais voir les différences entre les deux fichiers non?
(comme il le fait pour tout fichier de conf).
Je n’ai pas trop creusé ce qui était fait lors d’une installation, après ça m’étonne que ce cas ne soit pas traité lors de l’upgrade mais ça reste possible car spécifique.
#12
Merci
#13
J’ai fait la màj hier sur mon portable: KDE a fait un grand bon en avant par la même occasion.
Le système semble plus réactif, mais plus lent au démarrage (surtout KDE), l’ordi me donne la main en un peu plus de 40s contre 20 avant (ceci dit, je démarre très rarement à froid, il est souvent en hibernation)
Pas vraiment, du moment que les nouvelles sources existent si tu n’utilises pas les dépôts standards. Il faut regarder dans le sources.list et dans les fichiers présents dans /etc/apt/sources.d si il y a des dépôts non conventionnels ou des serveurs non conventionnels (exemples: les serveurs microsoft - qui semblent à jour, ou pour metasploit - à jour aussi, ou des backports)
Ceci dit, j’ai un peu la même question pour mon kimsufi chez OVH: le noyau est custom OVH, quel risque à mettre à jour?
#13.1
OVH a abandonné les noyaux custom y-a un moment.
A mon avis, le risque est grand (très) pour un serveur d’autant plus que c’est du physique sans support (Kimsufi).
Perso je commande un nouvelle machine, j’installe l’OS, configure les applis puis je migre les données dessus et changement IP failover.
Bien plus sur et ça permet de renouveler le matériel de temps en temps.
#13.2
J’ai fais pas mal d’upgrade de kimsufi/so you start sans soucis.
Que ça soit sous debian ou sous proxmox.
Il est clair que l’idéal reste ta solution de changer de serveur, mais selon les promos etc ce n’est pas forcément réalisable. (ou alors il faut attendre une future promo pour changer.
#14
Mis à jour vers Bookworm de deux vieux ordis i386.
Pas de problème sauf quand j’ai voulu installer mozillavpn. Le paquet ne serait pas disponible.
Un retard ? Mes sources.list à vérifier ? J’ai lâché le truc provisoirement.
#14.1
Ben, non, toujours pas moyen de trouver le paquet mozillavpn. Protonvpn s’installe, lui, sans problème et fonctionne. Problème Debian ou Mozilla ?
#15
La commande hostnamectl est bien aussi pour tout résumer avec des infos sur la distribution et le noyau au format liste
#15.1
Merci pour le rappel de cette commande qui donne même la version du bios actuelle.
Tu as tout à fait raison, j’ai pourtant veillé à comparer chaque version avant de la valider et pourtant il ne me semblait pas que le conf du grub m’ait été proposé. Toutefois le problème est résolu.
Entièrement d’accord avec ces remarques et cette manière de faire plus complète, mais un peu moins libriste.
#16
Est-ce que quelqu’un a réussi à upgrade un Raspberry Pi 1B (32 bits) vers bookwork?
#17
Ah cool !!!
Merci beaucoup pour cette synthèse car faut avouer que le mode d’emploi fourni par debian est super complet et tellement complet que finalement on s’y perd, d’autant plus que je suis plus habitué à Mageia pour mes laptops mais beaucoup moins pour Debian sur mon fixe. Va quand même falloir que je vérifie les dimensions du disques car ma debian est installée sur un LVM avec un volume pour /home, un pour /var et un pour /usr
#18
Ces cycles de mise à jour majeures sont l’une des raisons pour lesquelles je me tourne de plus en plus vers de la rolling release comme Manjaro.
Principalement utilisateur de Fedora aujourd’hui, chaque opportunité que j’ai eu de réinstaller un PC (car j’ai la flemme de le faire en temps normal) m’a fait le mettre sur Manjaro pour ne plus avoir à subir le cycle de montée de version majeure. Même si depuis des années celui de Fedora passe comme papa dans maman, on est jamais à l’abri d’un risque ou d’une régression. Même si généralement ça se passe bien, ça reste un événement.
La rolling release ne protège pas non plus des risques de régression ou cassage, mais elle retire “l’angoisse” de l’upgrade majeure. Accessoirement ça évite aussi de se poser des questions sur la durée de support.
#18.1
Perso je le vois à l’opposé.
Une rolling release c’est justement comme une migration Majeure assez souvent (quand tu as plus de 1.5go de maj d’un coup avec monté de version du bureau, du kernel etc, ça reste l’équivalent d’une majeure) mais dont tu ne contrôles pas le moment ou ça se produit.
Et cela t’obliges aussi à bien te renseigner voir tous les changements. Donc il faut avoir du temps pour suivre ce qui se passe.
(exemple si tu avais un dual boot sur manjaro, ben la perte du dualboot windows à cause du changement sur grub, tu te le prends d’un seul coup, ce n’est pas grand chose, mais si tu fais ça le soir, le lendemain tu as besoin pour le taf de windows ben tu découvres ça… )
Alors certes normalement le gap est moins grand (après ça dépend les montées de versions entre 2 freeze et la durée entre 2 versions) , mais le risque est pour moi le même.
A l’inverse une distrib freezée, tu sais que tu es tranquilles toute la durée de vie de ta version (normalement vu que tu n’as que des correctifs mineurs), et que le problème ne se pose que lors du passage à N+1, du coup tu sais que tu te prévoies du temps, tu fais ta sauvegardes qui va bien etc.
Perso c’est toujours pour ça que je préfère des distribs freezée, avec des cyles de vie de 6 Mois/1 ans.
Leap était le compromis idéal pour moi pour ça pour cette même raison, chaque année, l’été je pouvais prévoir ma maj tout en étant 100% tranquille le reste du temps, pouvoir faire toute smes majs chaque soir sans avoir aucun doute.
Le choix entre les deux, dépend principalement de l’usage que l’on a de son ordinateur (usage Taf?), et du temps qu’on a pour réparer, et de si tu fais tes majs tous les jours, ou quand tu as du temps etc.
#18.2
Comme je disais, le rolling release a aussi son lot de risques et de régression. Mais pourtant, sans suivre l’historique des changements, en deux ans sur d’autres machines je n’ai jamais eu un seul incident de mise à jour. Mon PineBook Pro acheté en 2020 a son master d’origin sur Manjaro et n’a jamais connu d’incident de mise à jour.
Là où par exemple sur Fedora je dois systématiquement réinstaller le driver Nvidia entre deux versions majeures. Et le temps d’indispo de la machine à chaque fois est aussi un des irritants qui me font préférer l’autre méthode.
Perso j’ai une vision plus cattle que pet de mes machines. Ayant toutes les données importantes synchronisées sur kDrive, réinstaller un OS ça ne prend que quelques minutes. Comme je disais, c’est surtout par flemme que j’attend d’avoir une vraie raison de réinstaller le PC. Typiquement c’est comme ça que j’ai basculé mon HTPC de Fedora à Manjaro, l’upgrade majeure a foiré dessus. Ce fut la première et dernière fois que je l’ai lancée via PackageKit en mode graphique. Plus jamais
Sinon dans mon cas, toutes mes machines sont sous Linux. Je n’ai qu’un seul PC de jeu ayant Windows et il n’a pas de dual boot. Donc les soucis de dual boot perdu ne me concernent pas
#18.3
J’ai évoqué le cas du dual boot, pour montrer un cas récent, juste que parfois c’est une configuration qui change qui peut poser problème.
J’ai un amis qui s’y connait peu qui avait un dual boot windows manjaro qui a justement eu le cas.
Et il a fallut chercher pour comprendre l’origine du problème qui provenait d’un changement de conf par défaut de grub.
Dans ce cas précis rien de grave, mais il peut y avoir pas mal d’autres cas.
Nvidia en rolling release ça pose souvent problème en général, s’il y a bien un cas ou j’éviterais à tout prix d’être en rolling release, c’est bien avoir un gpu nvidia.
Pour en avoir eu pas mal dans le passé, perso mon choix est fait)
(j’éviterais à tous prix d’avoir un gpu nvidia pour linux mais ça c’est un autre problème
Après comme tu le dis, réinstaller n’est pas un soucis pour toi, forcément une rolling release n’est plus un pb dans ce cas précis. :)
Réinstaller n’est pas un problème en soit pour moi non plus (il y a les backups qui vont bien), c’est juste de prévoir le temps pour le faire, d’ou l’intérêt justement des distribs freezée, ou je sais que quand je fais la maj à la N+1 j’ai du temps pour rattraper en cas de pb.
Pour moi c’est un peu ça la différence entre la distrib freeze et la rolling release.
La rolling release tu subits les montées de versions (et donc les arrivées de bugs/maintenances à faire), là ou sur une freeze tu le fais quand tu veux.
Ce qui n’est valable bien sûr que si on reste sur du full stable et dépôt de base, si on mixte du ppa etc, et qu’on bricole pour avoir des trucs plus récents là forcément, on perd l’intéret de la distrib freeze.
Les deux ont leurs avantages/inconvénients.
#18.4
Après si j’ai choisi Manjaro c’est aussi parce que la distrib n’est pas non plus trop en mode “cutting edge” comme l’est sa parente Arch et garde un petit temps.
D’ailleurs j’ai même eu un souci sur Fedora récemment… Tordu qui m’a fait péter un câble au début jusqu’à ce que je comprenne la cause.
La molette de ma souris logitech qui freeze le système. Apparemment y’aurait des soucis avec le Kernel 6.3.4 et le Unified receiver de Logitech, mais là c’était méchant. Pire encore, ça ne s’est produit que sur un modèle précis de souris
#18.5
Certains te diront que arch n’est pas moins stable, ou que manjaro a aussi de gros défauts et régressions comparé à arch.
Après avec des snapshots ça permet d’être un peu plus tranquille mais bon on garde quand même ce risque là.
J’ai un pote qui utilisait tumbleweed pourtant reconnue comme stable qui a tout pété récemment sans trop savoir pourquoi. (je pense qu’il a du manquait de place dans son découpage de partition et qu’avec les snaps automatique ça s’est mordu les pieds mais le tout sans alerte)
j’avoue que manjaro j’aime pas mal aussi, mais je n’ai jamais réussi à basculer dessus.
J’aimais bien manjaro architect mais qui a été arrêté, et calamares est toujours infoutu de faire une installation en LVM encrypt… Et ce depuis de nombreuses années.
Après sous manjaro c’est pareil, je trouve qu’il manque des paquets “critiques” qui nécessitent d’activer AUR, avec le risque en découlant.
(exemple seafile client n’est même pas présent dans les dépôts de base)
#19
Concernant l’upgrade vers Debian 12 et grub, l’installateur donne le choix de conserver son fichier de conf, d’utiliser le nouveau ou de visualiser les différences (cf. ce tuto).
#20
Je me permets plusieurs remarques concernant le
sources.list.Il serait pertinent de rajouter la suite
contribpartout (elle contient des logiciels libres mais qui dépendent de logiciels qui ne le sont pas). Et comme le suggère Kiroha, on peut fusionner certaines lignes.Même si l’utilisation de HTTP sans TLS n’est pas un problème majeur pour l’intégrité et l’authenticité des paquets, on peut quand même faire du TLS :-)
Et pour le commun des mortels qui ne modifient pas de paquets Debian, les
deb-srcsont inutiles, donc j’aurais plutôt conseillé de ne pas les mettre ou de les mettre commentées (avec un#au début de la ligne).En bref, je mettrais :
Et pour ceux qui veulent ne pas faire comme les autres, il est possible de remplacer ça par un fichier
/etc/apt/sources.list.d/debian.sources(le dossier et l’extensionsourcessont importants) avec, pour un résultat équivalent au précédent :#21
/home, OK, mais quel intérêt de séparer /var et /usr de la partition /, en 2023 et sur un PC perso ? Ça m’échappe un peu…
Il y fut peut-être jadis : il y a plein de paquets autrefois dans les dépôts qui ont été déplacés sur AUR parce que leur mainteneur ne voulait plus s’en occuper (coucou Celestia, Stellarium, abcde…). Donc, le fait d’être sur AUR ne veut pas dire que ça n’a jamais été dans les dépôts auparavant : faut voir le journal des changements apportés au PKGBUILD pour le savoir.
EDIT : je viens de voir, seafile n’a en effet jamais été dans les dépôts.
#22
/usr et /var sont accédés régulièremernt donc ça peut-être judicieux de les mettre sur une partition plus rapide (sur un vieux disque dur une partition en amont sur le disque) mais bon en 2023 / tout en entier n’est pas si gros, donc je suis assez d’accord avec ta remarque sur le fond.
#22.1
Là, je vais enchaîner sur le fait qu’installer un OS sur un HDD et non un SSD depuis les dix dernières années, c’est chercher les coups de bâton…
(Mais je plaide coupable : je pensais pas que mes deux PC achetés en 2009 sauraient gérer des SSD en disques systèmes quand je les ai passés sous Linux, en 2015 et 2017…)
Pour donner un exemple, sur mes Arch, mon partitionnement est celui suggéré par F. Bezies sur des HDD de 1 Tio :
– /dev/sd×1 : /boot (512 Mio)
– /dev/sd×2 : swap (4 Gio)
– /dev/sd×3 : / (20 Gio sur le portable, 40 Gio sur le fixe)
– /dev/sd×4 : /home (le reste, soit environ 900 Gio)
Oui, ça fait une racine située près du début du disque. Je sais pas si j’y aurais gagné (de manière humainement perceptible) à la mettre en 2e position en échangeant avec le swap, voire en 1ère en y incluant /boot. Ce sont des SATA 5 400 tr/min : au bout d’un moment, c’est le matériel qui devient limitant.
#23
Perso sur les portables je laisse le partitionnement par défaut, les données du /home étant synchro sur kDrive. Je n’ai plus de SWAP sur disque également histoire d’éviter des écritures inutiles sur le SSD, la SWAP en RAM avec pages mémoire compressées fait bien le taff.
Par contre sur un PC fixe, j’ai toujours l’habitude d’un disque système de capacité moindre (256GB sur ma machine actuelle) et à côté d’un disque data de 1TB. Le /home se trouve sur le disque système, mais les données du kDrive sont sur le data et il y a un lien symbolique pour les retrouver rapidement. Les chemins par défaut type Documents, Musics, etc, sont eux aussi des liens symboliques vers leur emplacement sur le stockage cloud.
Evidemment tout est en SSD
La dernière machine à avoir encore un HDD dont je dispose (outre mon vénérable portable Asus de 2005 avec son disque 5400rpm en IDE, :oui: :oui: qui tournait bien mieux sur la RC de Windows 7 que sur son XP d’origine avant de finir sur Ubuntu) est mon ancien PC de jeux qui était une config préfaite de materiel.net avec un HDD de 1TB à laquelle j’avais ajoutée 2 SSD pour faire mon setup usuel. Depuis cette machine est sous Manjaro et me sert à faire mumuse avec StableDiffusion.
D’ailleurs la carte mère de mon PC principal a aussi deux ports pour des disques nvme, faudrait que j’en profite un jour…
#24
Je ne parle pas spécialement de disque-dur (c’était un exemple) moi perso j’ai des bouts en tmpsfs /var/tmp par exemple qui normalement et supposé survivre à un reboot, mais pas chez moi :)
Pour ton partitionnement boot est obligatoire, swap me semble beaucoup trop petit: (la partition swap est utilisée aussi pour mettre en cache les accès disques), séparer “/” de “/home” n’a pour moi aucun sens si c’est sur le même disque.
Chez moi
Les 3 derniers sont des reliquats de l’époque où j’ai installé le SSD vers 2009 (on avait encore peur de la durée de vie des SSD à l’époque), j’aurais dû laisser tout ça sur le SSD.
Quand j’ai besoin de perf en IO (compilation) j’utilise un tmpfs extrêmement rapide qui peut déborder sur le swap (et là ça ralenti d’un coup :-/ ). Pour les très gros paquets (Firefox, Thunderbird, LibreOffice, WebKit) qui consomment trop de ram à la compilation, j’ai configuré une règle pour désactiver complètement tmpfs : ça compile lentement sur le disque-dur.
#25
Un très bon point de Bookworm : l’implantation de PipeWire : l’amélioration du son, volume et précision, me semble indiscutable.
#26
T’en fais pas pour ton SSD, il est fait pour encaisser : même en y allant comme un bourrin, il durera plus longtemps qu’un disque mécanique utilisé dans les mêmes conditions. Le coup des « écritures inutiles » n’est plus un problème depuis au moins 15 ans : la techno des SSD a très bien progressé depuis les tout premiers modèles pour qu’il n’y ait plus lieu de se soucier de ça. Exemple : Adrien D (Linuxtricks) a utilisé un SSD en usage assez intensif (compilations sur Calculate Linux basée sur Gentoo, installations de VM…) quotidiennement sur un PC portable pendant 10 ans (durée de vie moyenne d’un disque mécanique), et il n’a perdu que 5% de capacité dans l’intervalle. C’est donc pas un peu d’écriture de swap de temps en temps qui risque de tuer un SSD prématurément.
Swap de 4 Gio car je n’ai que 4 Gio de RAM (et même quand Vivaldi décide de taper allègrement dedans, je n’ai jamais dépassé les 1 à 1,5 Gio maxi ; allouer plus d’espace en swap est donc totalement inutile à ce jour car j’en ai déjà plus qu’il m’en faut).
Séparer / de /home peut toujours avoir son utilité en cas de réinstallation de l’OS, pour que les logiciels conservent leurs réglages. Mais dans le cas d’Arch, c’est vrai que ça risque peu d’arriver puisque ce n’est pas une distro « fixed ».