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
Il est possible (et recommandé pour éviter les ennuis, à moins de savoir ce qu’on fait) de marquer les swaps existants comme « ne pas utiliser » afin qu’ils ne soient pas reformatés.
On peut partager et reformater un swap existant sans problème dans certains cas à condition de ne pas utiliser l’hibernation :
- swap dans un volume logique LVM
- swap dans une partition identifiée dans fstab et resume par autre chose que son UUID ou LABEL (PARTUUID, PARTLABEL, /dev/disk/by-id/*…)
Non, c’est dans bullseye car c’est lui le fautif.
Dans son /etc/fstab, supprimer
# swap was on /dev/sda6 during installation
UUID=8d00f33a-97a6-4720-9f57-1bde573defaf none swap sw 0 0
Restaurer l’UUID originel du swap avec
swaplabel -U a60e99a1-f916-4b26-8025-b7ca9f334606 /dev/sda6
Inutile de toucher à l’initramfs.
Bonsoir tout le monde,
Sous Bullseye donc.
J’ai supprimé les deux lignes dans /etc/fstab.
Puis j’ai fait
swaplabel -U a60e99a1-f916-4b26-8025-b7ca9f334606 /dev/sda6
Commande inconnue. Je l’ai donc fait avec sudo, et là message d’erreur. J’ai rebooté, et refait la commande avec sudo et là c’est passé.
Par contre, depuis ces manips’, si j’éteinds Bullseye, il est long à s’éteindre, mais surtout, lorsque je démarre ensuite mon PC (avec le bouton on/off), il boot directement sur Bullseye sans passer par Grub. Pour retrouver le menu Grub, il faut que je fasse redémarrer plutôt que éteindre. Là j’ai de nouveau le menu Grub et choisir le démarrage entre Bullseye, Windows 10 et Buster.
Y’a un truc. Merci.
Ça ressemble à une mise en veille hybride plutôt qu’un arrêt, comme ce que fait la fonctionnailté « démarrage rapide » de Windows. Je ne vois pas le rapport avec la modification du swap. Ça fait pareil en arrêtant avec poweroff en root ?
Effectivement avec sudo poweroff le PC s’éteint bien.
Par contre, au démarrage, toujours pas de Grub qui s’affiche et boot direct sur Bullseye.
EDIT :
Dans /Paramètres/Energie/Action du bouton d’extinction j’ai passé la valeur de « Mettre en veille » à « Eteindre » ça devrait être mieux de ce point de vue là.
EDIT2 :
Finalement non, ça ne change rien sur le processus arrrêt/marche.
Est-ce que les écrans du BIOS sont affichés normalement, avec possibilité d’entrer dans le setup ?
Ça n’affecte que l’action du bouton, pas l’arrêt via le menu arrêter/redémarrer/suspendre/hiberner…
Bonsoir tout le monde, bonsoir @PascalHambourg
Ce soir… tout semble fonctionner 
De mes essais, j’ai l’impression que lorsque j’éteins l’ordi, il ne faut pas que je le rallume trop vite (sinon, il démarre direct sur Bullseye), et si j’attends 1mn ou 2mn, j’arrive sur Grub. Faut que je refasse des essais pour être complètement sûr. Mais le comportement de la machine me semble désormais plus fiable.
Oui quand j’ai Grub, non quand j’ai le démarrage direct sur Bullseye.
Oups, oui effectivement. Merci pour la précision.
Je vais donc pouvoir maintenant envisager la copie de mon ancien /home vers le /home de ma nouvelle installation Bullseye ?
QQ chose comme
cp -R /media/christian/28565d69-8adc-489c-a3fa-e6cd941c934a /home
/media/christian/28565d69-8adc-489c-a3fa-e6cd941c934a étant mon ancien /home monté sur Bullseye.
Mais il y a sans doute des choses à voir avec les droits de l’ancien système Buster (2 utilisateurs) et le nouveau système (1 seul pour l’instant, mais je peux aussi créer le 2ème utilisateur).
Merci.
J’utilise plutôt cp -a pour préserver les permissions et autres attributs.
Et il faut suffixer le répertoire source par /. pour copier son contenu et non le répertoire lui-même dans le répertoire de destination.
A faire en root sans session utilisateur ouverte. Attention à la collision entre les répertoires de même nom de l’ancien et du nouveau systèmes.
L’UID et le GID numériques des fichiers d’un utilisateur de l’ancien système doivent correspondre avec ceux de l’utilisateur de même nom du nouveau système. Sinon il faudra ajuster l’un ou l’autre. Le premier utilisateur créé par l’installateur Debian a l’UID et le GID 1000, le second 1001 et ainsi de suite.
Ok, donc
cp -a /media/christian/28565d69-8adc-489c-a3fa-e6cd941c934a/. /home
Et loggué en root via l’un des terminals par ctrl+alt+F3 depuis la fenêtre de login de Gnome.
J’ai aussi besoin de récupérer mes clés GPG et SSH, mais pas de souci à priori puisqu’elles sont stockées dans ~/.gnupg et ~/.ssh de mon /home actuel.
Oui, c’est bien le cas pour mes 2 utilisateurs, 1000 et 1001 dans Buster, ça devrait donc aller.
Je ferais tout ça demain soir je pense.
« /home actuel », c’est l’ancien ou le nouveau ? Si l’utilisateur a le même nom dans les deux systèmes, la copie va écraser les fichiers de même emplacement et nom du nouveau système.
Oui GPG et SSH sont dans le /home Buster. Quand la copie va se faire je devrais les retrouver dans le /home de Bullseye.
Bonjour,
je pense que ce que veut dire @PascalHambourg est que si vos 2 home s’appellent /home/userx par exemple, la copie va écraser ce qui se trouve dans /home/userx sur le système actuel. Par exemple /home/userx/Documents ou /home/userx/.config.
Oui, tout à fait. Comme c’est un système nouvellement installé, mon nouveau /home Bullseye est vide, ça ne me dérange donc pas Je copie de Buster à Bullseye pour récupérer mes données, mon nouveau système étant l’hôte d’accueil.
Vous n’avez fait aucune configuration dans aucune application?
Il risque d’y avoir des conflits, par exemple Firefox si vous l’utilisez risque de vous demander de créer un nouveau profil, après vous pourrez y copier les données de l’ancien.