Supprimer windows

Le
Comte de Niouzes
Bonjour les gens !

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 !

Claude

^_^
Vos réponses Page 4 / 5
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #26444124
Francois Lafont , dans le message
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 ?)

Non, cette histoire de « bloc », c'est pour la gestion de l'espace par
certains systèmes de fichiers.
strictement plus petite
que la taille d'un secteur physique. Je pensais qu'un « secteur
logique » était un regroupement de secteurs physiques contigus ?

Les secteurs physiques, c'est ce qui est présent réellement à la surface
du disque, avec les informations de synchronisation et de correction.
Les secteurs logiques, c'est ce à quoi donne accès le contrôleur disque
en réponse aux commandes ATA.
Si les secteurs logiques sont plus petits que les secteurs physiques,
une opération de lecture lira les secteurs physiques qui contiennent les
secteurs logiques demandés (donc plus que demandé) et renverra le
contenu voulu.
Plus grave, une opération d'écriture peut modifier des secteurs
physiques partiellement. Le contrôleur devra alors lire les secteurs
physiques modifiés en mémoire tampon, insérer le nouveau contenu et
ensuite écrire sur le disque : beaucoup plus lent.
Francois Lafont
Le #26444130
On 09/10/2017 06:00 PM, Nicolas George wrote:
Non, cette histoire de « bloc », c'est pour la gestion de l'espace par
certains systèmes de fichiers.

Ah ok merci pour la rectification.
Les secteurs physiques, c'est ce qui est présent réellement à la surface
du disque, avec les informations de synchronisation et de correction.
Les secteurs logiques, c'est ce à quoi donne accès le contrôleur disque
en réponse aux commandes ATA.

Ok donc le secteur logique est une propriété qui concerne le
contrôleur disque qui relie la carte mère au disque lui-même.
Donc, si je comprends bien, plusieurs disques (éventuellement
avec des caractéristiques différentes) auront tous la même
taille de secteur logique s'ils sont connectés au même
contrôleur disque. Et donc cette notion de secteur logique
ne dépend ni de l'OS ni de l'éventuel file system que l'on
peut placer sur le disque (ou ses partitions). J'ai bon ?
Si les secteurs logiques sont plus petits que les secteurs physiques,
une opération de lecture lira les secteurs physiques qui contiennent les
secteurs logiques demandés (donc plus que demandé) et renverra le
contenu voulu.
Plus grave, une opération d'écriture peut modifier des secteurs
physiques partiellement. Le contrôleur devra alors lire les secteurs
physiques modifiés en mémoire tampon, insérer le nouveau contenu et
ensuite écrire sur le disque : beaucoup plus lent.

Ok donc dans le cas de l'écriture, le contrôleur effectue en
quelques sortes l'opération d'abord en mémoire tampon (j'imagine
qu'on peut voir ça comme une sorte de mémoire RAM du contrôleur
disque ?) avant de tout balancer sur le disque.
Puis-je considérer la commande suivante comme un bon moyen de
connaître la taille d'un secteur physique et logique pour un
disque donnée (c'est la commande fdisk d'un Debian Stretch) ?
~$ sudo fdisk -l /dev/sdc | grep Sector
Sector size (logical/physical): 512 bytes / 512 bytes
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?
--
François Lafont
Nicolas George
Le #26444137
Francois Lafont , dans le message
Ok donc le secteur logique est une propriété qui concerne le
contrôleur disque qui relie la carte mère au disque lui-même.

Je parlais du contrôleur présent dans le disque lui-même.
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?

Comme d'habitude avec l'industrie.
Pascal Hambourg
Le #26444138
Le 10/09/2017 à 16:35, jp willm a écrit :
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.

Il ne faut pas exagérer le risque avec les partitions logiques. J'ai
noirci le tableau à dessein, mais si on ne modifie pas les partitions
tous les quatre matins il n'y a pas de risque. Dans mon cas, je passe
mon temps à créer, supprimer ou redimensionner des partitions sur un
disque qui en contient déjà une vingtaine, donc la plus grande
robustesse de GPT et la stabilité de la numérotation des partitions est
appréciable.
Convertir un disque du format DOS/MBR vers GPT en préservant les
partitions existantes n'est pas difficile avec gdisk à condition qu'il y
ait assez d'espace non alloué au début et à la fin du disque (une
trentaine de secteurs) pour loger les deux tables de partition
principale et de secours.
Par contre, il faut généralement réinstaller le chargeur d'amorçage dans
le MBR. Pour GRUB, il est aussi préférable de créer une petite partition
de type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par la
table de partition principale GPT. Pas besoin de beaucoup : 60 ko
suffisent, et la conversion en GPT laisse des "trous" avant la première
partition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.
Pascal Hambourg
Le #26444139
Le 10/09/2017 à 21:38, Francois Lafont a écrit :
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?

Il y a une justification au format avancé 512e :
- l'avantage d'utiliser des secteurs logiques de 512 octets est la
compatibilité avec tous les systèmes existants et anciens, ce qui n'est
pas le cas des secteurs de 4096 octets ;
- l'avantage d'utiliser des secteurs physiques de 4096 octets est
l'accroissement de la capacité de stockage utile puisqu'il y a moins
d'informations de synchronisation et de détection/correction d'erreur à
insérer entre les secteurs. C'est pourquoi beaucoup de disques de grande
capacité utilisent ce format.
L'inconvénient, c'est la contre-performance en cas d'écriture d'un
secteur physique incomplet. On contourne cet inconvénient en alignant
les unités d'allocation ("blocs") des systèmes de fichiers sur les
secteurs physiques, afin que l'écriture se fasse toujours sur des
secteurs physiques entiers.
Sergio
Le #26444147
Le 10/09/2017 à 21:38, Francois Lafont a écrit :
Puis-je considérer la commande suivante comme un bon moyen de
connaître la taille d'un secteur physique et logique pour un
disque donnée (c'est la commande fdisk d'un Debian Stretch) ?
~$ sudo fdisk -l /dev/sdc | grep Sector
Sector size (logical/physical): 512 bytes / 512 bytes

Non, se méfier du grep... Si t'as une version différente de fdisk[*], par exemple. Chez moi (LinuxMint 19) ça donne :
$ sudo fdisk -l /dev/sdc | grep Sector
255 heads, 63 sectors/track, 243201 cylinders
$
Parce que la sortie complète de fdisk donne :
[...]
Disk /dev/sda: 2000 GB, 2000396321280 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
[...]
[*]Surtout que ce genre de manip, on la fait souvent depuis un LiveCD/USB de dépannage, qui n'est pas toujours sa distribution favorite.
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
jp willm
Le #26444173
Le 10/09/2017 à 23:27, Pascal Hambourg a écrit :
Le 10/09/2017 à 16:35, jp willm a écrit :
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.

Il ne faut pas exagérer le risque avec les partitions logiques. J'ai
noirci le tableau à dessein, mais si on ne modifie pas les partitions
tous les quatre matins il n'y a pas de risque.

Ouf, je n'y touche pas à mes partoches.
Dans mon cas, je passe
mon temps à créer, supprimer ou redimensionner des partitions sur un
disque qui en contient déjà une vingtaine, donc la plus grande
robustesse de GPT et la stabilité de la numérotation des partitions est
appréciable.

Ah, ok, je vois un peu la gymnatique.
Mais bon, je crois que je vais quand même opter pour les tables de
partition GPT dès que l'occasion se présente.
Convertir un disque du format DOS/MBR vers GPT en préservant les
partitions existantes n'est pas difficile avec gdisk à condition qu'il y
ait assez d'espace non alloué au début et à la fin du disque (une
trentaine de secteurs) pour loger les deux tables de partition
principale et de secours.

Ah oui, il en faut aussi à la fin car le il y a une redondance.
Par contre, il faut généralement réinstaller le chargeur d'amorçage dans
le MBR.

Oui, j'ai un peu lu à ce sujet.
Pour GRUB, il est aussi préférable de créer une petite partition
de type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par la
table de partition principale GPT.

J'ai cru comprendre qu'il n'est pas besoin de la formater.

Pas besoin de beaucoup : 60 ko
suffisent,

Certains disent 1 Mo mais je serai radin :o)
et la conversion en GPT laisse des "trous" avant la première
partition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.

Reste à voir si cet espace est important, et si on peut le récupérer...
Encore merci !
--
jp willm
http://perso.orange.fr/willms/index.html
Pascal Hambourg
Le #26444195
Le 11/09/2017 à 07:39, Sergio a écrit :
Non, se méfier du grep... Si t'as une version différente de fdisk[*],
[...]
Disk /dev/sda: 2000 GB, 2000396321280 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
[...]

Ça doit être gnu-fdisk, une variante de fdisk basée sur libparted qui
gérait le format GPT à l'époque où le fdisk d'util-linux ne le faisait
pas encore.
Pascal Hambourg
Le #26444203
Le 11/09/2017 à 17:56, jp willm a écrit :
Le 10/09/2017 à 23:27, Pascal Hambourg a écrit :
 Pour GRUB, il est aussi préférable de créer une petite partition
de type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par
la table de partition principale GPT.

J'ai cru comprendre qu'il n'est pas besoin de la formater.

En effet. Elle ne va pas servir à stocker des fichiers.
 Pas besoin de beaucoup : 60 ko
suffisent,

Certains disent 1 Mo mais je serai radin :o)

1 Mio est l'alignement par défaut, donc certains partitionneurs
renâclent à créer une partition plus petite qui sera forcément non
alignée. Mais s'il y a bien une partition pour laquelle on se fiche de
l'alignement, c'est la partition BIOS boot. Elle n'est écrite que lors
de l'installation du chargeur d'amorçage qui l'utilise, donc pas souvent
dans le cas de GRUB.
A l'origine, GRUB 2 était conçu pour que sa core image tienne dans
l'espace de 62 secteurs, soit 31 Kio, situé entre le MBR et le début de
la premièr partition du temps de l'alignement sur les cylindres.
Dans certains cas cela peut dépasser, par exemple lorsque /boot/grub est
dans btrfs sur LVM, ce qui nécessite l'inclusion de pilotes volumineux.
Mais on est encore loin des 60 ko.
 et la conversion en GPT laisse des "trous" avant la première
partition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.

Reste à voir si cet espace est important, et si on peut le récupérer...

Comme je l'ai écrit, cela dépend le l'alignement des partition appliqué
lors du partitionnement initial. Avec un alignement sur des cylindres,
cela peut être juste. Il suffit de regarder les positions de début et de
fin des partitions avec fdisk.
Mais si tu veux parler de récupérer ces espaces libres pour agrandir les
partitions ou en créer d'autres (que la partition BIOS boot), tu risques
d'être déçu car cela ne représente au mieux que quelques méga-octets.
jp willm
Le #26444277
Le 11/09/2017 à 21:49, Pascal Hambourg a écrit :
1 Mio est l'alignement par défaut, donc certains partitionneurs
renâclent à créer une partition plus petite qui sera forcément non
alignée. Mais s'il y a bien une partition pour laquelle on se fiche de
l'alignement, c'est la partition BIOS boot. Elle n'est écrite que lors
de l'installation du chargeur d'amorçage qui l'utilise, donc pas souvent
dans le cas de GRUB.

Oui bon, si Gparted râle, je m'inclinerai :o)
A l'origine, GRUB 2 était conçu pour que sa core image tienne dans
l'espace de 62 secteurs, soit 31 Kio, situé entre le MBR et le début de
la premièr partition du temps de l'alignement sur les cylindres.

Je me souviens bien de cela, car tu me l'avais expliqué ici 8-)
Dans certains cas cela peut dépasser, par exemple lorsque /boot/grub est
dans btrfs sur LVM, ce qui nécessite l'inclusion de pilotes volumineux.
Mais on est encore loin des 60 ko.

Je ne suis donc pas concerné, mais c'est toujours bien de le savoir.
Reste à voir si cet espace est important, et si on peut le récupérer...

Comme je l'ai écrit, cela dépend le l'alignement des partition appliqué
lors du partitionnement initial. Avec un alignement sur des cylindres,
cela peut être juste. Il suffit de regarder les positions de début et de
fin des partitions avec fdisk.


[ ~]$ sudo fdisk -l
Disque /dev/sda : 119,2 GiB, 128035676160 octets, 250069680 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x00030a71
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2046 250068991 250066946 119,2G 5 Étendue
/dev/sda5 2048 46875094 46873047 22,4G 83 Linux
/dev/sda6 140625920 148436991 7811072 3,7G 82 partition
d'échang
/dev/sda7 148439040 250068991 101629952 48,5G 83 Linux
/dev/sda8 46876672 93749247 46872576 22,4G 83 Linux
/dev/sda9 93751296 140623871 46872576 22,4G 83 Linux
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
Par contre je ne suis pas foutu de vérifier :o/
Mais si tu veux parler de récupérer ces espaces libres pour agrandir les
partitions ou en créer d'autres (que la partition BIOS boot), tu risques
d'être déçu car cela ne représente au mieux que quelques méga-octets.

Bon, c'est rassurant d'un côté, mais les performances ne risquent-elles
pas de pâtir d'un mauvais alignement des partitions ?
--
jp willm
http://perso.orange.fr/willms/index.html
Publicité
Poster une réponse
Anonyme