Convertir partition depuis support GPT en MBR

Résolu
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 - Modifié le 15 déc. 2024 à 19:26
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 - 22 déc. 2024 à 22:13

Bonjour à tou.te.s :D,

Quelle est la bonne méthode pour convertir une partition Debian au format Ext4 depuis un support avec une table de partition GPT sur une machine avec EFI en vue de l'intégrer sur un disque MBR pour être utilisé sur une machine avec BIOS ?

J'ai testé plein de méthodes différentes sans succès.

Finalement j'ai réussi en élaborant ma propre méthode (voir dessous) :D mais j'ai une latence inexpliquée du noyau au démarrage et je ne suis pas convaincu qu'il n'y a pas d'autres effets de bord ...

---

Pour mettre en place avec succès, j'ai synchronisé en miroir les fichiers de la partition Debian du support avec rsync vers une partition Ext4 sur un disque qui utilise une table de partition MBR. Une fois fait, j'ai tenté d'installer le chargeur GRUB avec grub-install ... sans succès. Comme au  démarrage, le système était bloqué sur grub rescue>, j'ai tenté l'outil boot-repair-disk qui a réparé globalement (je peux fournir le journal) et l'a rendu fonctionnel.

A noter : en réalité mon premier essai a abouti à un système en lecture seule, que j'ai pu corriger en actualisant dans /etc/fstab l'identifiant de la partition à monter au démarrage qui est déterminé par blkid ; également depuis ce même fichier,j'ai du désactiver le fichier d'échange mémoire SWAP qui pointait vers une partition inexistante puisque non clonée, pour la refaire à posteriori.

Remarque : j'ai volontairement réduit les explications au minimum, mais je peux tout à fait détailler n'importe quel point.

---

Je ne sais pas si je suis assez clair ...

D'autre part j'ai d'autres questions sur la différence entre GPT et MBR.

Si quelqu'un.e peut m'accorder un peu de son temps pour m'aider, ce serait vraiment cool :D !

Avec adelphité,

lnj


Linux / Firefox 115.0


A voir également:

4 réponses

mamiemando Messages postés 33506 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 janvier 2025 7 819
Modifié le 18 déc. 2024 à 15:19

Par contre je ne suis pas sûr que tu as lu ma question juste avant, qui elle t'était adressé :D

Alors je suppose que la question à laquelle tu fais référence est "Même pour le dossier /boot et grub ?" #12

Réponse courte

En fait il faut distinguer deux choses :

  • ce qu'on configure soi-même (et où on ne se préoccupe pas de MBR ou GPT)
  • ce que GRUB fait seul en arrière boutique et qui impactera le fichier final /boot/grub/grub.cfg et dans lequel on pourra voire des nuances selon qu'on utilise GPT ou MBR.

La considération GPT ou MBR est propre à la table des partitions (définies au début du disque, et en charge de définir chaque partition hébergée par le disque - taille, position, système de fichiers). Ainsi, cette information réside dans l'en-tête du disque dur et en dehors de ses partitions de données.

Réponse détaillée

Si on ouvre /boot/grub/grub.cfg, on voit quand on utilise GPT des lignes "insmod part_gpt" qui comme charge le module GRUB (rien à voir avec un module noyau, on est avant le chargement du noyau quand on est dans grub). Ce module permet à GRUB de lire des partitions GPT.

Du coup la question qu'on peut se poser, c'est comment GRUB s'y est pris. Comme indiqué au début de /boot/grub/grub.cfg ce fichier est généré par la commande :

sudo update-grub

Cette commande est appelée implicitement à chaque fois que tu installes ou désinstalles un nouveau noyau (et donc en particulier, quand tu as installé Linux ou lors de certaines mises à jour).

Si on regarde le contenu de /usr/sbin/update-grub (on retrouve le chemin de l'exécutable avec sudo which update-grub) on voit que ce script appelle grub-mkconfig. Ce dernier se base :

  • sur des squelettes de fichiers de configuration GRUB (voir /etc/grub.d/) ;
  • le fichier de configuration /etc/default/grub (le seul endroit où l'on est sensé intervenir) ;
  • d'éventuelles extensions /etc/default/grub.d définies dans /etc/default/grub.d/ .

En l'occurrence, /boot/grub/grub.cfg stipule clairement que bon nombre de "insmod part_gpt" sont dus aux squelettes définis dans /etc/grub.d/. C'est donc là qu'on va creuser. On en ouvre un arbitraire et dans le début l'instruction :

# Include the GRUB helper library for grub-mkconfig.
. /usr/share/grub/grub-mkconfig_lib

C'est ce script auxiliaire qui engendre les instructions inmod part_gpt qui apparaissent à terme dans /boot/grub/grub.cfg. En effet, si on ouvre /usr/share/grub/grub-mkconfig_lib, on voit :

  partmap="`"${grub_probe}" --device $@ --target=partmap`"
  for module in ${partmap} ; do
    case "${module}" in
      netbsd | openbsd)
        echo "insmod part_bsd";;
      *)
        echo "insmod part_${module}";;
    esac
  done

Cet extrait de code montre que grub-probe (i.e. /usr/sbin/grub-probe) détermine de quels modules sont nécessaires au bon fonctionnement de GRUB (en particulier, part_gpt pour des disque GPT) sont nécessaires.

Si la question est maintenant, comment GRUB fait la distinction, c'est tout simplement, de la même manière que fdisk & co, en regardant la manière dont est définie la table des partitions de tes disques durs.

Si tu veux aller encore plus loin et voir comment c'est implémenté, il faudrait regardé le code qui a généré l'exécutable /usr/sbin/grub-probe et comme il s'agit d'un binaire, il faut regarder son code sources (ou celui d'un outil de partitionnement de disques) ou les spécifications concernées, qui sont présentées la page wikipedia sur GPT. On voit en particulier que l'information qui dit "GPT ou pas" est en dehors des partitions (ce qui est assez normal, puisque ces considérations sont propres à la table des partitions en charge de définir les partitions.)

Bonne chance

1
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 56
18 déc. 2024 à 22:36

Merki mamiemando ! Tu m'étonneras toujours avec tes connaissances :D !

Si on ouvre /boot/grub/grub.cfg, on voit quand on utilise GPT des lignes "insmod part_gpt" qui comme charge le module GRUB

Oui, donc comme je synchronise tel quel le contenu de ma partition GPT sur une partition MBR, grub.cfg étant dédié à GPT, lors du boot MBR la commande sera exécutée et donc ne permettra pas l'amorçage ... sans doute le "pourquoi" du système qui n'amorce pas et qui m'oblige à réparer avec un outil comme boot-repair-disk.

Ca commence à s'éclaircir ...

Si le problème est uniquement du à cette commande, je vais bien rigoler d'avoir perdu tout ce temps ...

Je fais des tests et fais un retour :D

0
mamiemando Messages postés 33506 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 janvier 2025 7 819 > lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025
19 déc. 2024 à 16:09

Merki mamiemando ! Tu m'étonneras toujours avec tes connaissances :D !

Ahah merci :-) mais je n'ai pas de mérite j'ai juste lu le code :D

Oui, donc comme je synchronise tel quel le contenu de ma partition GPT sur une partition MBR, grub.cfg étant dédié à GPT, lors du boot MBR la commande sera exécutée et donc ne permettra pas l'amorçage ... sans doute le "pourquoi" du système qui n'amorce pas et qui m'oblige à réparer avec un outil comme boot-repair-disk.

En effet, dans ton cas, il faut redéployer GRUB. Pour cela, lance depuis le linux installé sur ton disque dur :

sudo update-grub

Si ton Linux n'est pas amorçable, tu peux t'en sortir avec un outil boot-repair ou un live CD te permettront de faire un chroot (pour faire comme si on avait démarré normalement), et de là, redéployer GRUB. Si tu n'es pas familier de ce genre de manipulation, je te recommande d'utiliser boot-repair qui te guidera. Et si tu ne t'en sors pas, n'hésite pas à demander plus de précisions ;-)

Bonne chance

0
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 56
Modifié le 22 déc. 2024 à 23:07

Bon alors j'ai réussi à convertir une partition d'un disque avec une table de partitions GPT en MBR

=> résolu ! Célébration :D !

Dans quel but ? Pouvoir isoler en p2v un système Debian problématique sur une machine physique afin de l'éprouver en machine virtuelle (ici avec Qemu/KVM/libvirt).

Je vous propose ici ma méthode native, qui n'utilise pas l'outil boot-repair-disk et qui n'est certainement pas la voie académique ou souhaitable, mais qui fonctionne dans mon cas.

En conséquence, je ne peux donner aucune garantie qu'elle fonctionnera dans un autre cas et/ou sur une autre machine et/ou avec un autre système d'exploitation et/ou une autre architecture de virtualisation.

---

Conditions de mon test :

  • support NVM Express table de partitions GPT 120GB sur machine EFI
  • système à isoler Debian 12, 12/20GB libre
  • Qemu/KVM v5.2.0 et libvirtd v7.0.0

Pour le problème de latence évoqué au début, voir le fil résolu : Latence du noyau au démarrage

SUPPORT_SOURCE_GPT=/dev/nvme0n1
SUPPORT_VIRTUEL_SOURCE_GPT=/dev/nbd0
SUPPORT_VIRTUEL_FINALE_MBR=/dev/nbd1
IMAGE_SOURCE_GPT=image_source_gpt.qcow2
IMAGE_FINALE_MBR=image_final_mbr.qcow2
PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT=\
$( echo ${SUPPORT_VIRTUEL_SOURCE_GPT}p5 )

# Note : pour connaitre le numéro de partition voir détails
#   des images

# Attention : les supports NVME et NBD sont identifiés par 
#  des numéros qui ne sont pas des numéros de partitions
#  (ex : /dev/sda5 correspondrait à /dev/nbd0p5)

# Cloner le support NVME dans un fichier image (p2v)
dd if=$SUPPORT_SOURCE_GPT of=$IMAGE_SOURCE_GPT \
  bs=64K conv=noerror,sync status=progress
#> 128019136512 octets (128 GB, 119 GiB) copiés, 1123 s, 114 MB/s
#> 1953669+1 enregistrements lus
#> 1953670+0 enregistrements écrits
#> 128035717120 octets (128 GB, 119 GiB) copiés, 1124,81 s, 114 MB/s

# Tester si le module NBD est actif
lsmod | grep -c nbd
#> 1
# => actif

# Activer module NBD si non actif
modprobe nbd max_part=8

# Charger l'image source dans un support virtuel
qemu-nbd -f raw \
  -c $SUPPORT_VIRTUEL_SOURCE_GPT $IMAGE_SOURCE_GPT

# Créer l'image finale (>= taille fichiers partition isolée)
qemu-img create -f qcow2 $IMAGE_FINALE_MBR 15G
#> Formatting 'image_source_gpt.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib #> size=16106127360 lazy_refcounts=off refcount_bits=16

# Charger l'image finale dans un support virtuel
qemu-nbd -c $SUPPORT_VIRTUEL_FINALE_MBR $IMAGE_FINALE_MBR

# Formater l'image finale
parted -a cylinder $SUPPORT_VIRTUEL_FINALE_MBR \
  -s "mklabel msdos"
parted $SUPPORT_VIRTUEL_FINALE_MBR \
  -s "mkpart primary ext4 1 100%"
lsblk -lpf \
  --output NAME,TYPE,FSTYPE,SIZE \
  $SUPPORT_VIRTUEL_FINALE_MBR \
| grep " part "
#> /dev/nbd1p1 part         15G
partition_virtuelle_finale_mbr=$( 
  lsblk -lp $SUPPORT_VIRTUEL_FINALE_MBR \
  | awk '/ part / { print $1 }' 
)
mkfs.ext4 -F $partition_virtuelle_finale_mbr
#> mke2fs 1.46.2 (28-Feb-2021)
#> Rejet des blocs de périphérique : complété
#> ...                        
#> Superblocs de secours stockés sur les blocs :
#>     32768, 98304, ...
#> ...                        

# Détail des images
lsblk -f \
  --output NAME,TYPE,FSTYPE,SIZE,PARTLABEL \
  $SUPPORT_VIRTUEL_SOURCE_GPT $SUPPORT_VIRTUEL_FINALE_MBR
#> NAME     TYPE FSTYPE   SIZE PARTLABEL
#> nbd0     disk        119,2G
#> ├─nbd0p1 part vfat     100M EFI system partition
#> ├─nbd0p2 part           16M Microsoft reserved partition
#> ├─nbd0p3 part ntfs    69,8G Basic data partition
#> ├─nbd0p4 part ntfs     536M
#> ├─nbd0p5 part ext4    18,6G DEBIAN
#> ├─nbd0p6 part swap     977M
#> └─nbd0p7 part ext4    29,3G BACKUP
#> nbd1     disk           15G
#> └─nbd1p1 part ext4      15G

# Synchroniser fichiers support source -> support final
mkdir -p mnt/{gpt,mbr}
mount $PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT mnt/gpt/
mount $partition_virtuelle_finale_mbr mnt/mbr/
rsync -aP mnt/gpt/ mnt/mbr/
# => ici la synchronisation a été effectuée en 8 minutes

# Références au UUID du disque source et au fichier SWAP ?
# Note : UUID = Universally Unique IDdentifier
uuid_gpt=$(
  blkid -s UUID -o value \
    $PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT
)
uuid_mbr=$(
  blkid -s UUID -o value $partition_virtuelle_finale_mbr
)
uuid_swap=$(
  awk \
'     BEGIN { FS = "(=| +)" } ;    '\
'     /^[^#].+ swap / { print $2 } '\
    mnt/mbr/etc/fstab
)
grep -rlE "$uuid_gpt|$uuid_swap" mnt/mbr/ \
| grep -Ev "/var/|\.log"
#> mnt/mbr/etc/initramfs-tools/conf.d/resume
#> mnt/mbr/etc/fstab
#> mnt/mbr/boot/grub/x86_64-efi/grub.efi
#> mnt/mbr/boot/grub/x86_64-efi/load.cfg
#> mnt/mbr/boot/grub/x86_64-efi/core.efi
#> mnt/mbr/boot/grub/grub.cfg
# => resume (veille), fstab (montages auto), GRUB (amorçage)

# Désactiver le fichier de veille
sed -i 's/^\( *[^#]\)/# \1/' \
  mnt/mbr/etc/initramfs-tools/conf.d/resume

# Mettre à jour le fichier des montages automatiques
fstab_gpt=$(
  sed -e 's/^\( *[^#]\)/# \1/' mnt/mbr/etc/fstab
)
fstab_mbr=$(
  grep "$uuid_gpt" mnt/mbr/etc/fstab \
  | sed "s/$uuid_gpt/$uuid_mbr/g"
)
echo -e "$fstab_gpt\n\n# Disque MBR\n$fstab_mbr" \
  > mnt/mbr/etc/fstab

# Rendre le support MBR amorcable
grub-install --boot-directory mnt/mbr/boot \
  $SUPPORT_VIRTUEL_FINALE_MBR
#> Installation pour la plate-forme i386-pc.
#> Installation terminée, sans erreur.

# Mettre à jour le fichier de résolutions de noms
hosts_avant=$(
  sed -e 's/^\( *[^#]\)/# \1/' mnt/mbr/etc/hosts
)
hostname_mbr=$( cat mnt/mbr/etc/hostname )
echo -e "$hosts_avant\n\n127.0.1.1\t$hostname_mbr" \
  > mnt/mbr/etc/hosts

# Modifier le système final
for f in /proc /sys ; do mount -B $f mnt/mbr$f ; done
mount --rbind /dev mnt/mbr/dev/
chroot mnt/mbr/
#
# Entrée dans l'environnemnet chroot
#
# Désactiver le chargement du SWAP au démarrage
# (voir fil CCM "Latence du noyau au démarrage")
#
update-initramfs -u
#> update-initramfs: Generating /boot/initrd.img-6.1.0-23-amd64
#
# Mettre à jour GRUB ...
# ... sans les autres périphériques locaux
# https://unix.stackexchange.com/questions/634150/hide-devices-in-chrooted-environment/634655#634655
#
chmod a-x /usr/bin/os-prober
update-grub
chmod a+x /usr/bin/os-prober
exit
#
# Sortie de l'environnement chroot
#
for f in /proc /sys /dev ; do umount -lf mnt/mbr$f ; done
#
# Au démarrage de ma VM, j'ai eu une erreur :
#   "unable to allocate pty: No such device"
# https://askubuntu.com/questions/1449413/sudo-unable-to-allocate-pty-no-such-device/1503585#1503585
mount none -t devpts /dev/pts

# Démontage et déchargement des supports
umount -l mnt/mbr
umount -l mnt/gpt
rmdir -p mnt/{gpt,mbr}
qemu-nbd -d $SUPPORT_VIRTUEL_SOURCE_GPT
#> /dev/nbd0 disconnected
qemu-nbd -d $SUPPORT_VIRTUEL_FINALE_MBR
#> /dev/nbd1 disconnected

# Désactiver module NBD si non activé automatiquement
rmmod nbd

En espérant que ça puisse servir à d'autres :D

Avec adelphité,

lnj


1
mamiemando Messages postés 33506 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 janvier 2025 7 819
16 déc. 2024 à 13:06

Bonjour,

D'autre part j'ai d'autres questions sur la différence entre GPT et MBR.

Le modèle GPT résout plusieurs limitations propres au modèle MBR, comme expliqué ici. C'est pourquoi quand tu as le choix, GPT est toujours un meilleur choix. GPT est supporté par Windows >= 7 et tout Linux raisonnablement récent.

Le seul cas où GPT ne peut pas être utilisé (et donc, où MBR est imposé), c'est pour les systèmes d'exploitation tellement anciens qu'ils ne supportent pas GPT (Windows <= XP). Plus de détails ici.

Même si à mon avis ce n'est a priori pas une bonne idée, sous Linux, tu peux utiliser gdisk de GPT vers MBR, comme expliqué ici. Veille alors à redéployer grub une fois la conversion faite, comme expliqué ici.

Bonne chance

0
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 56
Modifié le 16 déc. 2024 à 14:35

Coucou Mamiemando :D

En fait, si j'ai besoin de convertir en MBR c'est parce que je dois faire de la p2v depuis une machine en EFI sur un support qui permet un dual-boot Windows/Debian, Windows imposant GPT il me semble (en tout cas il est comme ça en l'état). Particulièrement, j'ai besoin de virtualiser Debian.

Aussi, jusqu'à récemment la virtualisation libvirt ne gérait pas les instantanés sur GPT et j'en ai besoin (ça bouge depuis libvirt v10.1.0 and Virtual Machine Manager v4.1.0, mais dans l'urgence je ne vais pas m'atteler à refaire une installation pour ça).
 

0
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 56
Modifié le 16 déc. 2024 à 14:32

sous Linux, tu peux utiliser gdisk de GPT vers MBR, comme expliqué ici. Veille alors à redéployer grub une fois la conversion faite, comme expliqué ici.

 J'ai déjà testé cette méthode qui s'exécute sans erreur MAIS j'obtiens un disque avec une unique partition qui prend toute la place. Bon techniquement je sais que les données sont toujours là, mais elles ne sont pas accessibles, les tables MBR/EBR ont tout cassé leur accès.

Aussi le support dual-boot en GPT est partitionné en 7 partitions (4 pour Windows 10, 1 pour Debian, 1 pour les sauvegardes locales et la dernière pour le SWAP Linux) => comme MBR limite à 4 partitions principales, il faut que gdisk sache de lui-même quelles partitions convertir en primaire et lesquelles en étendue. J'ai lu aussi que certains systèmes (Windows seulement ?), ne peuvent pas démarrer hors d'une partition principale.

0
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 56
16 déc. 2024 à 14:31

Aussi

Bonjour,

D'autre part j'ai d'autres questions sur la différence entre GPT et MBR.

Une des questions que je me pose et à laquelle je n'arrive pas à trouver de réponse, c'est la différence au niveau système (donc des fichiers), qu'est ce qui différencie une installation Debian sur une machine avec EFI de celle avec MBR ?

Je me dis que si je comprends la différence, ça m'éviterait de passer par boot-repair-disk et éventuellement de ne pas avoir lesdits, effets de bord.

0
mamiemando Messages postés 33506 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 janvier 2025 7 819 > lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025
16 déc. 2024 à 14:57

[...] c'est la différence au niveau système (donc des fichiers), qu'est ce qui différencie une installation Debian sur une machine avec EFI de celle avec MBR ?

Il n'y en a pas, c'est au niveau de la table des partitions que ça se joue, ni au niveau des systèmes de fichiers eux-mêmes, ni au niveau de leur contenu. Comme expliqué plus haut, cela aura un impact sur ce que tu peux faire (e.g. taille maximum d'une partition). Pour un système installé, tu verras de petites différences dans les résultats retournés par les outils de types fdisk ou gdisk et sur la manière dont sont indexés tes devices, mais sinon tu n'en verras pas.

ça m'éviterait de passer par boot-repair-disk et éventuellement de ne pas avoir lesdits, effets de bord.

Concernant boot-repair, celui-ci n'est utile que pour installer ou réinstaller grub et se cantonne à ce rôle. C'est donc une considération indépendante de GPT ou MBR. Il n'y a pas d'effet de bord. Soit grub est bien installé, soit il est mal installé :-)

0
castorlivide > lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025
Modifié le 16 déc. 2024 à 16:10

Bonjour

c'est la différence au niveau système (donc des fichiers),

Oui, il suffit de dire ça, car le système de fichiers est "en dessous" de EFI ou de MBR, qui sont écrits dessus ou dedans ce système de fichiers qui est une "couche" sur le matériel avant l'organisation en MBR ou EFI des fichiers et de leur localisation sur disques par des tables. 

Entre EFI et MBR même la taille maxi que l'organisation est capable de gérer diffère, donc la table EFI de localisation diffère de celle pour MBR. 

EFI s'exonère aussi de cette limitation des 4 partitions principales.

Windows a été créé au début, en se reposant sur l'existance de la partition principale MBR, (il s'en sert pour interdire parfois l'accès aux disques sur lequel il est installé mais c'est une autre histoire, c'est peut-être pourquoi il refuse parfois de s'installer; microsoft pourrait perdre un peu de contrôle sur ses licences, et c'est son contrôle qui assure parfois la sécurité promise). 

Remarque:

-Windows et linux ne mettent pas le système de démarrage au même endroit, on peut avoir les 2 pour un seul disque en double boot: l'outil de réparation démarrage de grub agit dans sa partition; l'outil de réparation démarrage de windows dans la sienne.

-Il semble que grub sait se réparer et permet de modifier une ligne ensuite pour appeler windows, ce qui fait un plus pour le gestionnaire pour modifier ses installations à postériori sur le disque qui a démarré le système et sans arrêter l'ordinateur sous linux, plus facilement.

-Le 64 bits total (disparition du 32bits) est lié, ou on impose EFI quant il est là.

-j'obtiens un disque avec une unique partition, 

EFI virtualise les partitions ou les disques, il gère la totalité du disque et est capable de déplacer des partitions voire de les créer en plusieurs petits morceaux à différents endroits. On voit donc tout, c'est bien un seul grand espace pour lui.

Dans une VM, c'est pire, tout est virtuel et traité comme un grand espace entier. [Pensons au raid, qui est un peu similaire. Il y a ce qu'on voit, et il y a du physique, et on voit pas le physique].

0
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 56
Modifié le 20 déc. 2024 à 12:10

Ahah merci :-) mais je n'ai pas de mérite j'ai juste lu le code :D

 En tout cas pour l'aide que tu m'apportes et aux autres ... ;D

---

Alors j'ai bien avancé et m'apprête à faire un retour sur ma méthode.

J'ai réussi à convertir une partition depuis un disque GPT en MBR sans passer par un outil de réparation :D

Toutefois, j'ai toujours l'effet de bord annoncé précédemment, à savoir environ 30s où il ne se passe rien. Le curseur blanc clignote sur fond noir. Juste après viennent toutes les écritures ininterrompues avant d'arriver sur l'accueillant (= greeter)

[coup_de_gueule=debut]Depuis peu, j'ai décidé d'utiliser d'avantage les mots français, pas par identité nationale (je me sens terrien, point), mais par agacement de l'usage massif de l'anglais/américain pour tout et n'importe quoi ;D[coup_de_gueule=fin]

J'ai donc fait un audit sur l'activité après amorçage (boot) et j'ai constaté que ce qui prend du temps c'est le noyau (kernel). Mais je ne sais pas comment creuser d'avantage.

$ sudo systemd-analyze plot > analyse.svg

 Sans zoom on voit une longue barre en gris en haut de 33s ...

Analyse sans zoom

... qui est concernée par le noyau :

analyse avec zoom

Saurais-tu m'aider pour savoir ce qu'il se passe pendant ces 33s ?


0
mamiemando Messages postés 33506 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 janvier 2025 7 819
20 déc. 2024 à 12:52

Difficile à dire. De plus, je pense que ça mériterait d'ouvrir une nouvelle discussion vu que c'est éloigné de la question initiale. J'essaye d'y répondre rapidement mais si tu as besoin de plus d'élément, merci d'ouvrir une nouvelle discussion.

  • Si le noyau est anormalement lent (par rapport à d'habitude, sur cette machine), c'est vraisemblablement qu'une de ses fonctionnalité a un problème et finit par abandonner (timeout).
  • Essaye de regarder si les logs (/var/log) révèlent quelque chose, en particulier /var/log/boot.log ou /var/log/kern.log s'ils existent. Les éventuelles erreurs permettront de déterminer non seulement la cause, mais également de trouver comment les personnes qui ont été confrontées à ce problème s'y sont prises pour le résoudre.
  • Il se peut que ce soit dû à un bug. Il arrive que certain.e.s rencontrent des problème avec des versions spécifique (voir cette discussion). Tester avec d'autres noyaux (même plus anciens) permettrait de voir si c'est ce qui se passe ici.
  • Si le problème persiste, il faudrait "profiler" le noyau (voir par exemple cette discussion). Malheureusement c'est lourd à mettre en œuvre, car quelle que soit la méthode, il faut recompiler le noyau (donc au lieu de juste en déployé un pré-compilé avec un paquet linux-image, il faudrait le recompiler comme expliqué ici).

Bonne chance

0
lenainjaune Messages postés 691 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 6 janvier 2025 56 > mamiemando Messages postés 33506 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 janvier 2025
Modifié le 20 déc. 2024 à 18:38

Effectivement même si le problème est complètement lié à ce fil, il a sa place dans un nouvel espace.

J'ai donc créé ce nouveau fil : Latence du noyau au démarrage ... pour dire que le problème est résolu et présenter ma démarche :D !

Par ailleurs, je ne sais pas comment le marquer comme "résolu" vu que c'est moi qui l'ai résolu !

Ma méthode pour convertir la partition GPT en MBR va suivre ... dans ce fil ;D

1