Oui à condition de faire une installation en mode BIOS/legacy et pas UEFI si l’ordinateur supporte les deux, ainsi que l’ancienne installation de Debian.
Oui, mon ordi support les deux.
Là, j’ai un doute, j’espère avoir laissé BIOS/Legacy. Y’a un moyen de vérifier ?
La condition ne concerne pas l’ancienne installation de Debian.
1 J'aime
Bonjour à toutes et tous,
Mon nouveau disque SSD 1To dédié à ma nouvelle Debian arrive cet après-midi.
Je vais pouvoir reprendre les opérations dans les prochains jours, je vous redis 
Une suggestion de partionnement type pour un disque de 1To sur une machine avec 8Go de RAM en plus de la partition de 1Mo au format GPT ?
Il n’y a pas de partitionnement type. Ça dépend des usages et des besoins.
Première étape : définir le découpage du système (tout dans /, /home séparé, /var séparé, /var/log séparé, /tmp séparé ou en tmpfs…)
Deuxième étape : répartir l’espace disque entre les différentes parties.
Troisième étape : sélectionner la technologie de stockage : partitions standard, LVM…
Quatrième étape : sélectionner le type de système de fichiers pour chaque partie (ext4, btrfs, xfs…)
C’est là que mes connaissances vont se trouver limitées 
Mon usage est bureautique, c’est-à-dire essentiellement traitement de texte, tableur, du Web avec le navigateur FF, du courrier électronique chiffré avec Thunderbird, de la lecture de vidéos avec VLC, messagerie Signal, de la création de livres photos avec CEWE, et ça doit être l’essentiel.
J’envisageais de reprendre le même type de partitionnement qu’actuellement, soit / d’un côté et /home séparé. Évidemment, le gros du stockage se fera sur /home, mais j’aurais besoin d’un / plus grand que l’actuel qui est trop petit (10Go) et me pose plein de soucis pour l’installation de nouveaux logiciels et les mises à jour Debian.
$ df
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
udev 4023652 0 4023652 0% /dev
tmpfs 810716 18008 792708 3% /run
/dev/sda5 9480420 8896340 79456 100% /
tmpfs 4053572 62128 3991444 2% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 4053572 0 4053572 0% /sys/fs/cgroup
/dev/sda7 88268040 74910396 8850764 90% /home
tmpfs 810712 40 810672 1% /run/user/1000
Donc, sur un disque 1To, peut-être qq chose comme
GPT : 1Mo
/ : 200Go
/home : 800Go
Pour le reste, partitions standards et ext4 me semblent suffisant pour mon usage.
200 Go pour / ça me paraît beaucoup (sauf s’il y a des images disque de machines virtuelles à stocker dans /var/lib, mais dans ce cas je suggèrerais un volume séparé), mais pourquoi pas si tu as la certitude de ne jamais avoir besoin de plus de 800 Go dans /home.
N’oublie pas une partition de swap de la taille de la RAM pour l’hibernation.
En réalité, c’est une autre commande qui est arrivée. Il va falloir patienter encore un peu 
Ok, je résume :
GPT : 1 Mo
/ : 150 Go
/home : 866 Go
swap : 8 Go
[EDIT : correction pour swap]
Pas /swap mais swap. Ce n’est pas un système de fichiers, ça ne se monte pas, il n’y a pas de point de montage. Si tu pensais à un fichier de swap,
- c’est une mauvaise idée, les fichiers de swap sont une violation du système de fichiers
- l’installateur Debian ne sait pas faire.
Oui, désolé pour l’erreur et la confusion.
Bonsoir à toutes et tous,
Le SSD 1To est arrivé, ouf. Je regarde ça la semaine prochaine je pense, je ne suis pas dispo en cette fin de semaine. Je vous redis.
Me souviens pas avoir vu à l’installation la création d’une « partition GPT ».
Il s’agit en fait de la partition d’amorçage BIOS (BIOS boot) qui sert à l’installation de GRUB pour l’amorçage BIOS (grub-pc) sur un disque partitionné au format GPT. Elle est indispensabe dans certains cas (/boot en LVM ou RAID par exemple) et recommandée dans tous les cas.
Je voulais dire que le terme « partition GPT » est incorrecte.
J’avais compris. Il s’agissait à l’évidence de la part de @Chre d’un abus de langage ou d’une confusion entre le type de partition « BIOS boot » et le type de table de partition « GPT » dans lequel il s’inscrit, que j’aurais dû relever. Merci de l’avoir fait. Comme je me sens d’humeur à pinailler, je tiens à souligner que tes deux affirmations ne sont pas équivalentes.
est vrai. L’installation expert permet seulement de créer une table de partition GPT. En revanche
est discutable. Lorsqu’on demande à fdisk d’afficher la table de partition du MBR protecteur d’un disque au format GPT, il affiche bien une partition de type « GPT », raccourci pour désigner la « partition de protection GPT » (type hexa EE) :
fdisk -lt dos /dev/sda
Disk /dev/sda: 111,8 GiB, 120034123776 bytes, 234441648 sectors
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sda1 1 234441647 234441647 111,8G ee GPT
J’en profite pour revenir sur le choix du format GPT que j’avais recommandé par principe mais qui n’est pas forcément pertinent pour @Chre dans le cas présent. En effet le SSD a une taille inférieure à 2 Tio et le nombre de partitions prévu est de seulement 3 (/, /home et swap), ne nécessitant pas le recours à une partition étendue (à éviter) avec une table de partition DOS. D’autre part certains BIOS buggés ont besoin qu’une partition du MBR ait l’indicateur d’amorçage (drapeau « boot ») activé, ce qui est plus facile à faire avec une table de partition DOS qu’avec une table de partition GPT.
Bonsoir tout le monde,
Merci pour toutes ces précisions, mais il y a des subtilités qui m’échappent. Je reviendrais avec mes questions quand j’aurais l’installeur sous les yeux.
J’ai été retardé, mais je compte attaquer le sujet ce samedi 18/09.
Bonsoir à toutes et tous,
SSD installé, et installeur en mode graphique et avancé.
Je peux saisir le partitionnement suivant :
SCSI2 (0,0,0)(sdb) - 1.0 TB ATA Samsung SSD 870
> 1.0 MB Espace libre
> N° 1 150.0 GB f ext4 /
> N° 2 16.0 GB f swap swap
> N° 3 834.2 GB f ext4 /home
> 728.6 kB Espace libre
C’est OK ?
Merci.
Bonsoir,
J’ai donc procédé à ce partitionnement, puis installé l’OS et activé GRUB (sans le mode EFI sur support amovible) sur le disque principal. Au reboot, je vois bien Bulleseyes, Buster et MS Windows 10.
Pas de soucis pour démarrer Bullseye et Windows 10. Des erreurs au boot de Buster, mais après avoir patienté, il a démarré aussi. J’essaie de récupérer les messages exacts que j’ai eu au boot.
J’imagine qu’avant de migrer mes données de Buster à Bullseye, il y a des vérifications à faire pour mon installation. Merci.
EDIT :
[...]
[1.881135] ACPI BIOS Error (bug): Could not resolve [\_SB.PCIO.SATO.SPT4._GTF.DSSP], AE_NOT_FOUND[...]
[1.881204] ACPI Error: Method parse/execution failed \_SB.PCIO.SAT0.SPT4._GTF, AE_NOT_FOUND[...]
Gave up waiting for suspend/resume device /dev/sda5: clean, 237194/610800 files, 2133373/2441216 blocks
A start job is running for /dev/disk/by-uuid/a60e99a1-f916-4b26-8025-b7ca9f334606 (44s / 1min 30s)
[...]
Le temps de démarrage est long à cause de cette erreur A start job is running qui stoppe le boot pendant 1mn30. Mais ce n’est peut-être pas si grave après avoir transféré toutes les données sur la nouvelle Debian Bullseye puisque Buster sera alors inutile puis supprimé ?
Contre ces erreurs ACPI a priori sans gravité, tu peux essayer d’ajouter le paramètre suivant à la ligne de command du noyau : libata.noacpi=1
Il a peut-être échappé à ton attention que lors du partitionnement pour bullseye le swap du système buster avait été marqué par défaut comme utilisé et inévitablement reformaté, lui attribuant un nouvel UUID inconnu du système buster le rendant introuvable par celui-ci. C’est un gros défaut de l’installateur Debian. Pour le vérifier, tu peux
- regarder s’il y a deux swaps définis dans le fichier /etc/fstab de bullseye, un sur chaque disque
- comparer l’UUID du swap défini dans les fichiers /etc/fstab et /etc/initramfs-tools/conf.d/resume de buster (qui serait a60e99a1-f916-4b26-8025-b7ca9f334606) avec l’UUID actuel de la partition de swap de /dev/sda (en supposant que c’est l’ancien SSD), visible avec
blkid.
Si c’est bien le cas, il faut sous bullseye :
-
supprimer la ligne de ce swap dans /etc/fstab
-
si l’UUID (actuel) de ce swap est déclaré dans /etc/initramfs-tools/conf.d/resume (ça ne devrait pas être le cas car l’installateur devrait avoir sélectionné le plus grand swap, donc celui du nouveau SSD), il faut
-
mettre l’UUID du swap du nouveau SSD à la place
-
désactiver le swap de l’ancien SSD avec
swapoff /dev/sda6 -
reconstruire l’initramfs pour utiliser le nouveau swap au réveil avec
update-initramfs -u
-
-
remettre l’UUID d’origine du swap de l’ancien SSD (présent dans /etc/fstab de buster) avec
swaplabel -U a60e99a1-f916-4b26-8025-b7ca9f334606 /dev/sda6
Après cela, il ne devrait plus y avoir de délai au démarrage de buster.
Bonsoir,
Merci @PascalHambourg
Oui, j’ai vu ça, le reformatage de mon swap existant. Mais j’avais testé des configurations différentes, mais j’avais toujours cette étape. Je l’ai donc validée. C’est donc bien cela qui s’est passé.
Je commence par faire l’état des lieux :
Bullseye :
/etc/fstab (extrait, uniquement les swap)
# swap was on /dev/sda6 during installation
UUID=8d00f33a-97a6-4720-9f57-1bde573defaf none swap sw 0 0
# swap was on /dev/sdb1 during installation
UUID=c8a3585d-a9c5-4fea-ba37-0868cbd654fc none swap sw 0 0
Et
$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=c8a3585d-a9c5-4fea-ba37-0868cbd654fc
Buster : (je complète après mon reboot)
/etc/fstab
# swap was on /dev/sda6 during installation
UUID=a60e99a1-f916-4b26-8025-b7ca9f334606 none swap sw 0 0
/etc/initramfs-tools/conf.d/resume
$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=a60e99a1-f916-4b26-8025-b7ca9f334606`
Et
$ sudo blkid
/dev/sda6: UUID="8d00f33a-97a6-4720-9f57-1bde573defaf" TYPE="swap" PARTUUID="bf904aec-06"
/dev/sdb1: UUID="c8a3585d-a9c5-4fea-ba37-0868cbd654fc" TYPE="swap" PARTUUID="45371eb6-b775-4b61-8ca8-b273c1506ee1"
Voilà pour l’état des lieux.
Pour la suite, j’ai un doute. Le problème de délai de boot étant sur Buster, c’est plutôt Buster que je dois corriger ?
C’est effectivement le cas. Je ne dois donc pas exécuter les commandes suivantes que tu donnes ?
EDIT : merci @MicP pour la mise en forme
1 J'aime