J'ai acheté il y a quelques semaines un PC Aces Aspire, évidemment
équipé de windows 10, UEFI, Secure Boot ... (et un disque dur de 1 To.)
Je voudrais supprimer totalement windows 10 pour mettre Linux à la place
... mais en gardant éventuellement la possibilité de remettre windows
(pour une raison qui ne me vient pas à l'esprit pour le moment)
J'ai fait une clé de sauvegarde de windows qui m'a déjà une fois permis
de remettre le PC en configuration sortie d'usine.
Question : quelles sont les partitions windows que je peux supprimer ?
(windows utilisant 1 partition EFI, 1 partition système (pour la
restauration), 1 partition windows (pour windows, mes données, ...),
plus 1 ou 2 emplacements de quelques octets dont l'utilité m'échappe
totalement.
Ou alors ? est-ce que je peux, à partir d'un CD Live Gparted supprimer
toutes les partitions existantes, et/ou formater le disque ?
Autre question : quand je vais installer Linux, il y aura 1 partition
swap, 1 partition racine, 1 partition home ... Faudra-t-il créer une
partition EFI ? Sur quelle partition faudra-t-il mettre le programme
d'amorçage ?
Un grand merci d'avance pour vos réponses pas trop compliquées !
Autrement, j'utilise des partitions "logiques" pour moi c'est suffisant.
C'est ce qu'il y a de pire. Tous les inconvénients des partitions classiques (difficulté à redimensionner) et en plus ceux spécifiques aux partitions logiques (fragilité, numérotation variable), sans les avantages. Une bonne raison de passer à LVM ou GPT.
Bon, j'hésite, car j'ai deux SSD + un disque dur SATA 4GO, pleins de données... Si j'ai bien compris : - Il faudrait déjà en mode "live" créer une partition de type FAT32 (de 35 Mo mini pour du Linux), avec le drapeau (flag) "Boot" ou "ESP" en début de disque. - Ensuite activer UEFI dans le "BIOS" et utiliser un utilitaire comme boot-repair pour convertir le tout en mode EFI. Je suis assez casse-cou, mais là, je flippe. -- jp willm http://perso.orange.fr/willms/index.html
Le 10/09/2017 à 11:34, Pascal Hambourg a écrit :
Autrement, j'utilise des partitions "logiques" pour moi c'est suffisant.
C'est ce qu'il y a de pire. Tous les inconvénients des partitions
classiques (difficulté à redimensionner) et en plus ceux spécifiques aux
partitions logiques (fragilité, numérotation variable), sans les
avantages. Une bonne raison de passer à LVM ou GPT.
Bon, j'hésite, car j'ai deux SSD + un disque dur SATA 4GO, pleins de
données...
Si j'ai bien compris :
- Il faudrait déjà en mode "live" créer une partition de type FAT32 (de
35 Mo mini pour du Linux), avec le drapeau (flag) "Boot" ou "ESP" en
début de disque.
- Ensuite activer UEFI dans le "BIOS" et utiliser un utilitaire comme
boot-repair pour convertir le tout en mode EFI.
Autrement, j'utilise des partitions "logiques" pour moi c'est suffisant.
C'est ce qu'il y a de pire. Tous les inconvénients des partitions classiques (difficulté à redimensionner) et en plus ceux spécifiques aux partitions logiques (fragilité, numérotation variable), sans les avantages. Une bonne raison de passer à LVM ou GPT.
Bon, j'hésite, car j'ai deux SSD + un disque dur SATA 4GO, pleins de données... Si j'ai bien compris : - Il faudrait déjà en mode "live" créer une partition de type FAT32 (de 35 Mo mini pour du Linux), avec le drapeau (flag) "Boot" ou "ESP" en début de disque. - Ensuite activer UEFI dans le "BIOS" et utiliser un utilitaire comme boot-repair pour convertir le tout en mode EFI. Je suis assez casse-cou, mais là, je flippe. -- jp willm http://perso.orange.fr/willms/index.html
Pascal Hambourg
Le 10/09/2017 à 11:57, jp willm a écrit :
Bon, avec Gparted par exemple, il faut d'abord créer une partition ou plutôt une table des partitions avant de pouvoir créer des partitions et de formater celles-ci en fonction du système de fichier désiré.
Oui, sauf si la table de partition existe déjà.
C'est le GUID ?
Un GUID, c'est la même chose qu'un UUID : un IDentifiant suffisamment long pour être considéré en pratique comme Globalement/Universellement Unique. Les GUID/UUID ont de multiples usages. Le format GPT emploie des GUID pour identifier les partitions et leurs types, d'où son nom. Attention à ne pas confondre le GUID unique d'une partition, appelé PARTUUID dans les systèmes GNU/Linux, et l'UUID de son contenu, appelé simplement UUID.
Le 10/09/2017 à 11:57, jp willm a écrit :
Bon, avec Gparted par exemple, il faut d'abord créer une partition ou
plutôt une table des partitions avant de pouvoir créer des partitions et
de formater celles-ci en fonction du système de fichier désiré.
Oui, sauf si la table de partition existe déjà.
C'est le GUID ?
Un GUID, c'est la même chose qu'un UUID : un IDentifiant suffisamment
long pour être considéré en pratique comme Globalement/Universellement
Unique. Les GUID/UUID ont de multiples usages.
Le format GPT emploie des GUID pour identifier les partitions et leurs
types, d'où son nom. Attention à ne pas confondre le GUID unique d'une
partition, appelé PARTUUID dans les systèmes GNU/Linux, et l'UUID de son
contenu, appelé simplement UUID.
Bon, avec Gparted par exemple, il faut d'abord créer une partition ou plutôt une table des partitions avant de pouvoir créer des partitions et de formater celles-ci en fonction du système de fichier désiré.
Oui, sauf si la table de partition existe déjà.
C'est le GUID ?
Un GUID, c'est la même chose qu'un UUID : un IDentifiant suffisamment long pour être considéré en pratique comme Globalement/Universellement Unique. Les GUID/UUID ont de multiples usages. Le format GPT emploie des GUID pour identifier les partitions et leurs types, d'où son nom. Attention à ne pas confondre le GUID unique d'une partition, appelé PARTUUID dans les systèmes GNU/Linux, et l'UUID de son contenu, appelé simplement UUID.
Pascal Hambourg
Le 10/09/2017 à 12:12, jp willm a écrit :
Le 10/09/2017 à 11:34, Pascal Hambourg a écrit :
On peut utiliser un disque brut non partitionné
(...) pour un système de fichiers comme on le faisait avec les
disquettes et les premières clés USB.
C'est peut-être le cas quand on copie une image iso vers un clé USB à l'aide de dd ? Exemple : dd bs=4M if=/path/to/manjaro.iso of=/dev/sd[drive letter] status=progress
C'est le cas quand le fichier image contient un système de fichiers ISO 9660 "pur". Mais de plus en plus les images d'installation ou live sont dans un format "hybride" qui combine un système de fichiers ISO 9660 et une table de partition afin d'être directement amorçable aussi bien sur un disque optique qu'un disque dur ou une clé USB. Avec une image de ce type, la copie crée une table de partition sur la clé.
Je ne puis plus voir cette clé à partir de mon gestionnaire de fichiers, mais elle boot bien.
Le fait que le contenu de la clé ne soit pas visible par le gestionnaire de fichiers peut venir de sa table de partition pas toujours conforme aux standard plutôt que de l'absence de table de partition.
Autrement, j'utilise des partitions "logiques" pour moi c'est suffisant.
C'est ce qu'il y a de pire. Tous les inconvénients des partitions classiques (difficulté à redimensionner) et en plus ceux spécifiques aux partitions logiques (fragilité, numérotation variable), sans les avantages. Une bonne raison de passer à LVM ou GPT.
Bon, j'ai compris :o| J'ai déjà eu des problèmes dans le temps avec des partitions logiques, mais depuis un dizaine d'années plus rien ; enfin si, une partition illisible... le disque n'avait rien physiquement (testé), mais j'ai dû reformater la partition.
Les problème les plus graves sont liés à la structure en liste chaînée des partitions logiques, qui est fragile. Quand cette liste chaînée est corrompue, elle peut être interrompue (et les partitions logiques situées après l'interruption ne sont plus visibles) ou rebouclée (et le noyau voit des centaines de partitions, en fait toujours les mêmes qui reviennent en boucle).
S'il porte le logo "AF 512e" (Advanced Format 512B emulation), il a des secteurs physiques de 4096 octets mais des secteurs logiques de 512 octets. Sur ce type de disque, il est important d'aligner les blocs des structures de données (partitions, systèmes de fichiers...) sur des limites de secteurs physiques, c'est-à-dire des positions multiples de 8 secteurs logiques, pour ne pas dégrader les performances.
Oui et le programme d'installation le fait automatiquement je crois, car il reste parfois de bouts de disque inutilisés.
Les programmes d'installation modernes. Les anciens, qui datent d'avant l'arrivée du format avancé AF, ne savent pas qu'il peut y avoir des secteurs physiques de taille différente des secteurs logiques et alignaient les partitions sur des "cylindres" qui sont rarement alignés avec les secteurs physiques.
Mais on n'a plus besoin de cela sur de SSD. Right ?
Au contraire, on en a encore plus besoin car les SSD ont des tailles de blocs d'écriture et d'effacement encore plus grandes. C'est pour eux qu'on aligne maintenant les partitions sur des blocs de 1 Mio.
Le 10/09/2017 à 12:12, jp willm a écrit :
Le 10/09/2017 à 11:34, Pascal Hambourg a écrit :
On peut utiliser un disque brut non partitionné
(...) pour un système de fichiers comme on le faisait avec les
disquettes et les premières clés USB.
C'est peut-être le cas quand on copie une image iso vers un clé USB à
l'aide de dd ?
Exemple :
dd bs=4M if=/path/to/manjaro.iso of=/dev/sd[drive letter] status=progress
C'est le cas quand le fichier image contient un système de fichiers ISO
9660 "pur". Mais de plus en plus les images d'installation ou live sont
dans un format "hybride" qui combine un système de fichiers ISO 9660 et
une table de partition afin d'être directement amorçable aussi bien sur
un disque optique qu'un disque dur ou une clé USB. Avec une image de ce
type, la copie crée une table de partition sur la clé.
Je ne puis plus voir cette clé à partir de mon gestionnaire de fichiers,
mais elle boot bien.
Le fait que le contenu de la clé ne soit pas visible par le gestionnaire
de fichiers peut venir de sa table de partition pas toujours conforme
aux standard plutôt que de l'absence de table de partition.
Autrement, j'utilise des partitions "logiques" pour moi c'est suffisant.
C'est ce qu'il y a de pire. Tous les inconvénients des partitions
classiques (difficulté à redimensionner) et en plus ceux spécifiques
aux partitions logiques (fragilité, numérotation variable), sans les
avantages. Une bonne raison de passer à LVM ou GPT.
Bon, j'ai compris :o|
J'ai déjà eu des problèmes dans le temps avec des partitions logiques,
mais depuis un dizaine d'années plus rien ; enfin si, une partition
illisible... le disque n'avait rien physiquement (testé), mais j'ai dû
reformater la partition.
Les problème les plus graves sont liés à la structure en liste chaînée
des partitions logiques, qui est fragile. Quand cette liste chaînée est
corrompue, elle peut être interrompue (et les partitions logiques
situées après l'interruption ne sont plus visibles) ou rebouclée (et le
noyau voit des centaines de partitions, en fait toujours les mêmes qui
reviennent en boucle).
S'il porte le logo "AF 512e" (Advanced Format 512B emulation), il a
des secteurs physiques de 4096 octets mais des secteurs logiques de
512 octets. Sur ce type de disque, il est important d'aligner les
blocs des structures de données (partitions, systèmes de fichiers...)
sur des limites de secteurs physiques, c'est-à-dire des positions
multiples de 8 secteurs logiques, pour ne pas dégrader les performances.
Oui et le programme d'installation le fait automatiquement je crois, car
il reste parfois de bouts de disque inutilisés.
Les programmes d'installation modernes. Les anciens, qui datent d'avant
l'arrivée du format avancé AF, ne savent pas qu'il peut y avoir des
secteurs physiques de taille différente des secteurs logiques et
alignaient les partitions sur des "cylindres" qui sont rarement alignés
avec les secteurs physiques.
Mais on n'a plus besoin de cela sur de SSD. Right ?
Au contraire, on en a encore plus besoin car les SSD ont des tailles de
blocs d'écriture et d'effacement encore plus grandes. C'est pour eux
qu'on aligne maintenant les partitions sur des blocs de 1 Mio.
(...) pour un système de fichiers comme on le faisait avec les
disquettes et les premières clés USB.
C'est peut-être le cas quand on copie une image iso vers un clé USB à l'aide de dd ? Exemple : dd bs=4M if=/path/to/manjaro.iso of=/dev/sd[drive letter] status=progress
C'est le cas quand le fichier image contient un système de fichiers ISO 9660 "pur". Mais de plus en plus les images d'installation ou live sont dans un format "hybride" qui combine un système de fichiers ISO 9660 et une table de partition afin d'être directement amorçable aussi bien sur un disque optique qu'un disque dur ou une clé USB. Avec une image de ce type, la copie crée une table de partition sur la clé.
Je ne puis plus voir cette clé à partir de mon gestionnaire de fichiers, mais elle boot bien.
Le fait que le contenu de la clé ne soit pas visible par le gestionnaire de fichiers peut venir de sa table de partition pas toujours conforme aux standard plutôt que de l'absence de table de partition.
Autrement, j'utilise des partitions "logiques" pour moi c'est suffisant.
C'est ce qu'il y a de pire. Tous les inconvénients des partitions classiques (difficulté à redimensionner) et en plus ceux spécifiques aux partitions logiques (fragilité, numérotation variable), sans les avantages. Une bonne raison de passer à LVM ou GPT.
Bon, j'ai compris :o| J'ai déjà eu des problèmes dans le temps avec des partitions logiques, mais depuis un dizaine d'années plus rien ; enfin si, une partition illisible... le disque n'avait rien physiquement (testé), mais j'ai dû reformater la partition.
Les problème les plus graves sont liés à la structure en liste chaînée des partitions logiques, qui est fragile. Quand cette liste chaînée est corrompue, elle peut être interrompue (et les partitions logiques situées après l'interruption ne sont plus visibles) ou rebouclée (et le noyau voit des centaines de partitions, en fait toujours les mêmes qui reviennent en boucle).
S'il porte le logo "AF 512e" (Advanced Format 512B emulation), il a des secteurs physiques de 4096 octets mais des secteurs logiques de 512 octets. Sur ce type de disque, il est important d'aligner les blocs des structures de données (partitions, systèmes de fichiers...) sur des limites de secteurs physiques, c'est-à-dire des positions multiples de 8 secteurs logiques, pour ne pas dégrader les performances.
Oui et le programme d'installation le fait automatiquement je crois, car il reste parfois de bouts de disque inutilisés.
Les programmes d'installation modernes. Les anciens, qui datent d'avant l'arrivée du format avancé AF, ne savent pas qu'il peut y avoir des secteurs physiques de taille différente des secteurs logiques et alignaient les partitions sur des "cylindres" qui sont rarement alignés avec les secteurs physiques.
Mais on n'a plus besoin de cela sur de SSD. Right ?
Au contraire, on en a encore plus besoin car les SSD ont des tailles de blocs d'écriture et d'effacement encore plus grandes. C'est pour eux qu'on aligne maintenant les partitions sur des blocs de 1 Mio.
Pascal Hambourg
Le 10/09/2017 à 12:25, jp willm a écrit :
Si j'ai bien compris : - Il faudrait déjà en mode "live" créer une partition de type FAT32 (de 35 Mo mini pour du Linux), avec le drapeau (flag) "Boot" ou "ESP" en début de disque. - Ensuite activer UEFI dans le "BIOS" et utiliser un utilitaire comme boot-repair pour convertir le tout en mode EFI.
Pas sûr que boot-repair suffise. Pour ma part je ne l'utilise pas, c'est comme Gparted : je n'aime pas les trucs trop automatisés, je préfère avoir la maîtrise totale des opérations. Pourquoi veux-tu passer l'amorçage en mode EFI ? En dehors du multiboot, ça n'a pas beaucoup d'intérêt, mais des inconvénients certains.
Je suis assez casse-cou, mais là, je flippe.
Bah, si les données importantes sont sauvegardées...
Le 10/09/2017 à 12:25, jp willm a écrit :
Si j'ai bien compris :
- Il faudrait déjà en mode "live" créer une partition de type FAT32
(de 35 Mo mini pour du Linux), avec le drapeau (flag) "Boot" ou "ESP" en
début de disque.
- Ensuite activer UEFI dans le "BIOS" et utiliser un utilitaire
comme boot-repair pour convertir le tout en mode EFI.
Pas sûr que boot-repair suffise. Pour ma part je ne l'utilise pas, c'est
comme Gparted : je n'aime pas les trucs trop automatisés, je préfère
avoir la maîtrise totale des opérations.
Pourquoi veux-tu passer l'amorçage en mode EFI ? En dehors du multiboot,
ça n'a pas beaucoup d'intérêt, mais des inconvénients certains.
Je suis assez casse-cou, mais là, je flippe.
Bah, si les données importantes sont sauvegardées...
Si j'ai bien compris : - Il faudrait déjà en mode "live" créer une partition de type FAT32 (de 35 Mo mini pour du Linux), avec le drapeau (flag) "Boot" ou "ESP" en début de disque. - Ensuite activer UEFI dans le "BIOS" et utiliser un utilitaire comme boot-repair pour convertir le tout en mode EFI.
Pas sûr que boot-repair suffise. Pour ma part je ne l'utilise pas, c'est comme Gparted : je n'aime pas les trucs trop automatisés, je préfère avoir la maîtrise totale des opérations. Pourquoi veux-tu passer l'amorçage en mode EFI ? En dehors du multiboot, ça n'a pas beaucoup d'intérêt, mais des inconvénients certains.
Je suis assez casse-cou, mais là, je flippe.
Bah, si les données importantes sont sauvegardées...
jp willm
Le 10/09/2017 à 12:52, Pascal Hambourg a écrit :
Un GUID, c'est la même chose qu'un UUID : un IDentifiant suffisamment long pour être considéré en pratique comme Globalement/Universellement Unique. Les GUID/UUID ont de multiples usages.
Ok.
Le format GPT emploie des GUID pour identifier les partitions et leurs types, d'où son nom. Attention à ne pas confondre le GUID unique d'une partition, appelé PARTUUID dans les systèmes GNU/Linux, et l'UUID de son contenu, appelé simplement UUID.
Les UUID des partitions, c'est ce que me retourne blkid. -- jp willm http://perso.orange.fr/willms/index.html
Le 10/09/2017 à 12:52, Pascal Hambourg a écrit :
Un GUID, c'est la même chose qu'un UUID : un IDentifiant suffisamment
long pour être considéré en pratique comme Globalement/Universellement
Unique. Les GUID/UUID ont de multiples usages.
Ok.
Le format GPT emploie des GUID pour identifier les partitions et leurs
types, d'où son nom. Attention à ne pas confondre le GUID unique d'une
partition, appelé PARTUUID dans les systèmes GNU/Linux, et l'UUID de son
contenu, appelé simplement UUID.
Les UUID des partitions, c'est ce que me retourne blkid.
Un GUID, c'est la même chose qu'un UUID : un IDentifiant suffisamment long pour être considéré en pratique comme Globalement/Universellement Unique. Les GUID/UUID ont de multiples usages.
Ok.
Le format GPT emploie des GUID pour identifier les partitions et leurs types, d'où son nom. Attention à ne pas confondre le GUID unique d'une partition, appelé PARTUUID dans les systèmes GNU/Linux, et l'UUID de son contenu, appelé simplement UUID.
Les UUID des partitions, c'est ce que me retourne blkid. -- jp willm http://perso.orange.fr/willms/index.html
Nicolas George
jp willm , dans le message <op3h3l$2fqs$, a écrit :
Les UUID des partitions, c'est ce que me retourne blkid.
blkid donne les UUID des partitions et les UUID du contenu, quand les deux existent. Il faut lire soigneusement sa sortie.
jp willm , dans le message <op3h3l$2fqs$1@news.gegeweb.eu>, a écrit :
Les UUID des partitions, c'est ce que me retourne blkid.
blkid donne les UUID des partitions et les UUID du contenu, quand les
deux existent. Il faut lire soigneusement sa sortie.
jp willm , dans le message <op3h3l$2fqs$, a écrit :
Les UUID des partitions, c'est ce que me retourne blkid.
blkid donne les UUID des partitions et les UUID du contenu, quand les deux existent. Il faut lire soigneusement sa sortie.
jp willm
Le 10/09/2017 à 13:10, Pascal Hambourg a écrit :
C'est le cas quand le fichier image contient un système de fichiers ISO 9660 "pur". Mais de plus en plus les images d'installation ou live sont dans un format "hybride" qui combine un système de fichiers ISO 9660 et une table de partition afin d'être directement amorçable aussi bien sur un disque optique qu'un disque dur ou une clé USB. Avec une image de ce type, la copie crée une table de partition sur la clé.
Je voyais bien que les isos manjaro sont différentes des *buntus et je ne pouvais pas utiliser unetbootin pour les iso manjaro par exemple. Les choses ont peut-être évolué depuis, car unetbootin est dans les dépôts pacman.
Je ne puis plus voir cette clé à partir de mon gestionnaire de fichiers, mais elle boot bien.
Le fait que le contenu de la clé ne soit pas visible par le gestionnaire de fichiers peut venir de sa table de partition pas toujours conforme aux standard plutôt que de l'absence de table de partition.
C'est un peu la foire...
Les problème les plus graves sont liés à la structure en liste chaînée des partitions logiques, qui est fragile. Quand cette liste chaînée est corrompue, elle peut être interrompue (et les partitions logiques situées après l'interruption ne sont plus visibles) ou rebouclée (et le noyau voit des centaines de partitions, en fait toujours les mêmes qui reviennent en boucle).
Oh joie !
Mais on n'a plus besoin de cela sur de SSD. Right ?
Au contraire, on en a encore plus besoin car les SSD ont des tailles de blocs d'écriture et d'effacement encore plus grandes. C'est pour eux qu'on aligne maintenant les partitions sur des blocs de 1 Mio.
En effet, je me souviens quand j'ai installé mon premier SSD, j'avais lu qu'il fallait bien dimensionner. Quelque chose comme 2048 clusters pour 1 Mio. -- jp willm http://perso.orange.fr/willms/index.html
Le 10/09/2017 à 13:10, Pascal Hambourg a écrit :
C'est le cas quand le fichier image contient un système de fichiers ISO
9660 "pur". Mais de plus en plus les images d'installation ou live sont
dans un format "hybride" qui combine un système de fichiers ISO 9660 et
une table de partition afin d'être directement amorçable aussi bien sur
un disque optique qu'un disque dur ou une clé USB. Avec une image de ce
type, la copie crée une table de partition sur la clé.
Je voyais bien que les isos manjaro sont différentes des *buntus et je
ne pouvais pas utiliser unetbootin pour les iso manjaro par exemple.
Les choses ont peut-être évolué depuis, car unetbootin est dans les
dépôts pacman.
Je ne puis plus voir cette clé à partir de mon gestionnaire de
fichiers, mais elle boot bien.
Le fait que le contenu de la clé ne soit pas visible par le gestionnaire
de fichiers peut venir de sa table de partition pas toujours conforme
aux standard plutôt que de l'absence de table de partition.
C'est un peu la foire...
Les problème les plus graves sont liés à la structure en liste chaînée
des partitions logiques, qui est fragile. Quand cette liste chaînée est
corrompue, elle peut être interrompue (et les partitions logiques
situées après l'interruption ne sont plus visibles) ou rebouclée (et le
noyau voit des centaines de partitions, en fait toujours les mêmes qui
reviennent en boucle).
Oh joie !
Mais on n'a plus besoin de cela sur de SSD. Right ?
Au contraire, on en a encore plus besoin car les SSD ont des tailles de
blocs d'écriture et d'effacement encore plus grandes. C'est pour eux
qu'on aligne maintenant les partitions sur des blocs de 1 Mio.
En effet, je me souviens quand j'ai installé mon premier SSD, j'avais lu
qu'il fallait bien dimensionner. Quelque chose comme 2048 clusters pour
1 Mio.
C'est le cas quand le fichier image contient un système de fichiers ISO 9660 "pur". Mais de plus en plus les images d'installation ou live sont dans un format "hybride" qui combine un système de fichiers ISO 9660 et une table de partition afin d'être directement amorçable aussi bien sur un disque optique qu'un disque dur ou une clé USB. Avec une image de ce type, la copie crée une table de partition sur la clé.
Je voyais bien que les isos manjaro sont différentes des *buntus et je ne pouvais pas utiliser unetbootin pour les iso manjaro par exemple. Les choses ont peut-être évolué depuis, car unetbootin est dans les dépôts pacman.
Je ne puis plus voir cette clé à partir de mon gestionnaire de fichiers, mais elle boot bien.
Le fait que le contenu de la clé ne soit pas visible par le gestionnaire de fichiers peut venir de sa table de partition pas toujours conforme aux standard plutôt que de l'absence de table de partition.
C'est un peu la foire...
Les problème les plus graves sont liés à la structure en liste chaînée des partitions logiques, qui est fragile. Quand cette liste chaînée est corrompue, elle peut être interrompue (et les partitions logiques situées après l'interruption ne sont plus visibles) ou rebouclée (et le noyau voit des centaines de partitions, en fait toujours les mêmes qui reviennent en boucle).
Oh joie !
Mais on n'a plus besoin de cela sur de SSD. Right ?
Au contraire, on en a encore plus besoin car les SSD ont des tailles de blocs d'écriture et d'effacement encore plus grandes. C'est pour eux qu'on aligne maintenant les partitions sur des blocs de 1 Mio.
En effet, je me souviens quand j'ai installé mon premier SSD, j'avais lu qu'il fallait bien dimensionner. Quelque chose comme 2048 clusters pour 1 Mio. -- jp willm http://perso.orange.fr/willms/index.html
jp willm
Le 10/09/2017 à 13:18, Pascal Hambourg a écrit :
Pas sûr que boot-repair suffise. Pour ma part je ne l'utilise pas, c'est comme Gparted : je n'aime pas les trucs trop automatisés, je préfère avoir la maîtrise totale des opérations.
Quand on connais il vaut mieux détailler les opérations "à la main", mais dans mon cas, je passe parfois par des utilitaires.
Pourquoi veux-tu passer l'amorçage en mode EFI ? En dehors du multiboot, ça n'a pas beaucoup d'intérêt, mais des inconvénients certains.
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes tables de partitions en gpt.
Je suis assez casse-cou, mais là, je flippe.
Bah, si les données importantes sont sauvegardées...
Ah oui, j'ai plusieurs copies (synchronisées avec gparted) ! -- jp willm http://perso.orange.fr/willms/index.html
Le 10/09/2017 à 13:18, Pascal Hambourg a écrit :
Pas sûr que boot-repair suffise. Pour ma part je ne l'utilise pas, c'est
comme Gparted : je n'aime pas les trucs trop automatisés, je préfère
avoir la maîtrise totale des opérations.
Quand on connais il vaut mieux détailler les opérations "à la main",
mais dans mon cas, je passe parfois par des utilitaires.
Pourquoi veux-tu passer l'amorçage en mode EFI ? En dehors du multiboot,
ça n'a pas beaucoup d'intérêt, mais des inconvénients certains.
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.
Je suis assez casse-cou, mais là, je flippe.
Bah, si les données importantes sont sauvegardées...
Ah oui, j'ai plusieurs copies (synchronisées avec gparted) !
Pas sûr que boot-repair suffise. Pour ma part je ne l'utilise pas, c'est comme Gparted : je n'aime pas les trucs trop automatisés, je préfère avoir la maîtrise totale des opérations.
Quand on connais il vaut mieux détailler les opérations "à la main", mais dans mon cas, je passe parfois par des utilitaires.
Pourquoi veux-tu passer l'amorçage en mode EFI ? En dehors du multiboot, ça n'a pas beaucoup d'intérêt, mais des inconvénients certains.
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes tables de partitions en gpt.
Je suis assez casse-cou, mais là, je flippe.
Bah, si les données importantes sont sauvegardées...
Ah oui, j'ai plusieurs copies (synchronisées avec gparted) ! -- jp willm http://perso.orange.fr/willms/index.html
jp willm
Le 10/09/2017 à 16:23, Nicolas George a écrit :
jp willm , dans le message <op3h3l$2fqs$, a écrit :
Les UUID des partitions, c'est ce que me retourne blkid.
blkid donne les UUID des partitions et les UUID du contenu, quand les deux existent. Il faut lire soigneusement sa sortie.
Right, il y a aussi PARTUUID="xxx" Décidément... -- jp willm http://perso.orange.fr/willms/index.html
Le 10/09/2017 à 16:23, Nicolas George a écrit :
jp willm , dans le message <op3h3l$2fqs$1@news.gegeweb.eu>, a écrit :
Les UUID des partitions, c'est ce que me retourne blkid.
blkid donne les UUID des partitions et les UUID du contenu, quand les
deux existent. Il faut lire soigneusement sa sortie.
jp willm , dans le message <op3h3l$2fqs$, a écrit :
Les UUID des partitions, c'est ce que me retourne blkid.
blkid donne les UUID des partitions et les UUID du contenu, quand les deux existent. Il faut lire soigneusement sa sortie.
Right, il y a aussi PARTUUID="xxx" Décidément... -- jp willm http://perso.orange.fr/willms/index.html
Francois Lafont
Bonjour à tous, Merci Pascal pour toutes ces explications, personnellement, elles me sont très utiles. On 09/10/2017 11:34 AM, Pascal Hambourg wrote:
S'il porte le logo "AF 512e" (Advanced Format 512B emulation), il a des secteurs physiques de 4096 octets mais des secteurs logiques de 512 octets.
J'aimerais bien avoir une petite explication sur ce point si c'est possible bien sûr. Je ne vois absolument pas comment c'est possible sur un disque d'avoir une taille de secteur logique (on dit un "bloc" je crois ?) strictement plus petite que la taille d'un secteur physique. Je pensais qu'un « secteur logique » était un regroupement de secteurs physiques contigus ? Genre comme sur ce schéma (ou un bloc est constitué de 3 secteurs physique) : https://fr.wikipedia.org/wiki/Secteur_de_disque#/media/File:Disk-structure.svg Et du coup, dans mon esprit on était censé toujours avoir : taille d'un secteur physique =< taille d'un secteur logique Du coup, je me dis que je n'ai peut-être rien compris à cette histoire depuis le début. ;) -- François Lafont
Bonjour à tous,
Merci Pascal pour toutes ces explications, personnellement,
elles me sont très utiles.
On 09/10/2017 11:34 AM, Pascal Hambourg wrote:
S'il porte le logo "AF 512e" (Advanced Format 512B emulation), il a des secteurs physiques de 4096 octets mais des secteurs logiques de 512 octets.
J'aimerais bien avoir une petite explication sur ce point
si c'est possible bien sûr. Je ne vois absolument pas comment
c'est possible sur un disque d'avoir une taille de secteur
logique (on dit un "bloc" je crois ?) strictement plus petite
que la taille d'un secteur physique. Je pensais qu'un « secteur
logique » était un regroupement de secteurs physiques contigus ?
Genre comme sur ce schéma (ou un bloc est constitué de 3
secteurs physique) :
Bonjour à tous, Merci Pascal pour toutes ces explications, personnellement, elles me sont très utiles. On 09/10/2017 11:34 AM, Pascal Hambourg wrote:
S'il porte le logo "AF 512e" (Advanced Format 512B emulation), il a des secteurs physiques de 4096 octets mais des secteurs logiques de 512 octets.
J'aimerais bien avoir une petite explication sur ce point si c'est possible bien sûr. Je ne vois absolument pas comment c'est possible sur un disque d'avoir une taille de secteur logique (on dit un "bloc" je crois ?) strictement plus petite que la taille d'un secteur physique. Je pensais qu'un « secteur logique » était un regroupement de secteurs physiques contigus ? Genre comme sur ce schéma (ou un bloc est constitué de 3 secteurs physique) : https://fr.wikipedia.org/wiki/Secteur_de_disque#/media/File:Disk-structure.svg Et du coup, dans mon esprit on était censé toujours avoir : taille d'un secteur physique =< taille d'un secteur logique Du coup, je me dis que je n'ai peut-être rien compris à cette histoire depuis le début. ;) -- François Lafont
