Il y a quelques temps, j'avais posté ici un article demandant quels risques
il y avait a tenter de redimensionner avec Gparted des partitions, dont
l'une contient des fichiers relatifs à grub.
Vous m'aviez convaincus qu'il n'y avait pas de danger.
Je confirme : j'ai procédé à l'opération et elle fût un succès.
Pour ceux que la procédure intéresse (de mémoire car je n'ai pas pris de
notes) :
Ordinateur : Dell LatitudeE6230 installé nativement avec Ubuntu
Ubuntu actuel : 16.04 LTS
sda1 : recovery partition dell
sda2 : partition d'installeur ubuntu
sda3 : /, trop petit
sda4 : étendue
sda5 : swap
sda6 : /home, trop grand
Téléchargement de l'installateur à jour d'ubuntu
Installation de cet installateur sur une clef 4GO avec "Créateur de disque
de démarrage"
Boot sur cette clef USB
Lancement de gparted (qui râle sur une clef usb mal partitionnée :-))
Préparation de la modification des tailles
- diminuer sda6 de 10GO
- rajouter 10G devant sda6
- rajouter 10G devant sda5
- diminuer sda4 de 10G
- rajouter 10G devant sda4
- rallonger sda3 de 10G
Exécuter les modifications
Patienter en croisant les doigts (très important)
Rebooter après avoir retiré la clef.
Tout a l'air OK : grub n'a pas été affecté.
J'ai juste un doute sur les rajouts de 10G devant sdax. Il me semble l'avoir
fait et constaté que gparted recalculait tout les déplacements et la
nouvelle table de partition en conséquence.
L'interface graphique montre le résultat attendu.
Merci à tout ceux d'entre vous qui m'ont recommandé l'opération.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry Houx
Le 20/03/2017 à 09:50, Dominique MICOLLET a écrit :
Bonjour, Il y a quelques temps, j'avais posté ici un article demandant quels risques il y avait a tenter de redimensionner avec Gparted des partitions, dont l'une contient des fichiers relatifs à grub. Vous m'aviez convaincus qu'il n'y avait pas de danger. Je confirme : j'ai procédé à l'opération et elle fût un succès. Pour ceux que la procédure intéresse (de mémoire car je n'ai pas pris de notes) : Ordinateur : Dell LatitudeE6230 installé nativement avec Ubuntu Ubuntu actuel : 16.04 LTS sda1 : recovery partition dell sda2 : partition d'installeur ubuntu sda3 : /, trop petit sda4 : étendue sda5 : swap sda6 : /home, trop grand Téléchargement de l'installateur à jour d'ubuntu Installation de cet installateur sur une clef 4GO avec "Créateur de disque de démarrage" Boot sur cette clef USB Lancement de gparted (qui râle sur une clef usb mal partitionnée :-)) Préparation de la modification des tailles - diminuer sda6 de 10GO - rajouter 10G devant sda6 - rajouter 10G devant sda5 - diminuer sda4 de 10G - rajouter 10G devant sda4 - rallonger sda3 de 10G Exécuter les modifications Patienter en croisant les doigts (très important) Rebooter après avoir retiré la clef. Tout a l'air OK : grub n'a pas été affecté. J'ai juste un doute sur les rajouts de 10G devant sdax. Il me semble l'avoir fait et constaté que gparted recalculait tout les déplacements et la nouvelle table de partition en conséquence. L'interface graphique montre le résultat attendu. Merci à tout ceux d'entre vous qui m'ont recommandé l'opération. Cordialement Dominique
Sinon, lvm est une bonne solution, linux le gère bien.
Le 20/03/2017 à 09:50, Dominique MICOLLET a écrit :
Bonjour,
Il y a quelques temps, j'avais posté ici un article demandant quels risques
il y avait a tenter de redimensionner avec Gparted des partitions, dont
l'une contient des fichiers relatifs à grub.
Vous m'aviez convaincus qu'il n'y avait pas de danger.
Je confirme : j'ai procédé à l'opération et elle fût un succès.
Pour ceux que la procédure intéresse (de mémoire car je n'ai pas pris de
notes) :
Ordinateur : Dell LatitudeE6230 installé nativement avec Ubuntu
Ubuntu actuel : 16.04 LTS
sda1 : recovery partition dell
sda2 : partition d'installeur ubuntu
sda3 : /, trop petit
sda4 : étendue
sda5 : swap
sda6 : /home, trop grand
Téléchargement de l'installateur à jour d'ubuntu
Installation de cet installateur sur une clef 4GO avec "Créateur de disque
de démarrage"
Boot sur cette clef USB
Lancement de gparted (qui râle sur une clef usb mal partitionnée :-))
Préparation de la modification des tailles
- diminuer sda6 de 10GO
- rajouter 10G devant sda6
- rajouter 10G devant sda5
- diminuer sda4 de 10G
- rajouter 10G devant sda4
- rallonger sda3 de 10G
Exécuter les modifications
Patienter en croisant les doigts (très important)
Rebooter après avoir retiré la clef.
Tout a l'air OK : grub n'a pas été affecté.
J'ai juste un doute sur les rajouts de 10G devant sdax. Il me semble l'avoir
fait et constaté que gparted recalculait tout les déplacements et la
nouvelle table de partition en conséquence.
L'interface graphique montre le résultat attendu.
Merci à tout ceux d'entre vous qui m'ont recommandé l'opération.
Cordialement
Dominique
Sinon, lvm est une bonne solution, linux le gère bien.
Le 20/03/2017 à 09:50, Dominique MICOLLET a écrit :
Bonjour, Il y a quelques temps, j'avais posté ici un article demandant quels risques il y avait a tenter de redimensionner avec Gparted des partitions, dont l'une contient des fichiers relatifs à grub. Vous m'aviez convaincus qu'il n'y avait pas de danger. Je confirme : j'ai procédé à l'opération et elle fût un succès. Pour ceux que la procédure intéresse (de mémoire car je n'ai pas pris de notes) : Ordinateur : Dell LatitudeE6230 installé nativement avec Ubuntu Ubuntu actuel : 16.04 LTS sda1 : recovery partition dell sda2 : partition d'installeur ubuntu sda3 : /, trop petit sda4 : étendue sda5 : swap sda6 : /home, trop grand Téléchargement de l'installateur à jour d'ubuntu Installation de cet installateur sur une clef 4GO avec "Créateur de disque de démarrage" Boot sur cette clef USB Lancement de gparted (qui râle sur une clef usb mal partitionnée :-)) Préparation de la modification des tailles - diminuer sda6 de 10GO - rajouter 10G devant sda6 - rajouter 10G devant sda5 - diminuer sda4 de 10G - rajouter 10G devant sda4 - rallonger sda3 de 10G Exécuter les modifications Patienter en croisant les doigts (très important) Rebooter après avoir retiré la clef. Tout a l'air OK : grub n'a pas été affecté. J'ai juste un doute sur les rajouts de 10G devant sdax. Il me semble l'avoir fait et constaté que gparted recalculait tout les déplacements et la nouvelle table de partition en conséquence. L'interface graphique montre le résultat attendu. Merci à tout ceux d'entre vous qui m'ont recommandé l'opération. Cordialement Dominique
Sinon, lvm est une bonne solution, linux le gère bien.
Dominique MICOLLET
Bonjour, Thierry Houx wrote:
Sinon, lvm est une bonne solution, linux le gère bien.
J'ai eu une machine avec cette solution. Le problème a été que je n'ai pas compris comment on changeait la taille des partitions sans les vider. J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu. Me suis-je trompé ? Cordialement Dominique
Bonjour,
Thierry Houx wrote:
Sinon, lvm est une bonne solution, linux le gère bien.
J'ai eu une machine avec cette solution.
Le problème a été que je n'ai pas compris comment on changeait la taille des
partitions sans les vider.
J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter
les volumes logiques pour changer la taille, puis restaurer le contenu.
Sinon, lvm est une bonne solution, linux le gère bien.
J'ai eu une machine avec cette solution. Le problème a été que je n'ai pas compris comment on changeait la taille des partitions sans les vider. J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu. Me suis-je trompé ? Cordialement Dominique
Fran=c3=a7ois Patte
Le 20/03/2017 15:51, Dominique MICOLLET a écrit :
Bonjour, Thierry Houx wrote:
Sinon, lvm est une bonne solution, linux le gère bien.
J'ai eu une machine avec cette solution. Le problème a été que je n'ai pas compris comment on changeait la taille des partitions sans les vider. J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu. Me suis-je trompé ?
Oui!
Cordialement
Itou -- François Patte Université Paris Descartes
Le 20/03/2017 15:51, Dominique MICOLLET a écrit :
Bonjour,
Thierry Houx wrote:
Sinon, lvm est une bonne solution, linux le gère bien.
J'ai eu une machine avec cette solution.
Le problème a été que je n'ai pas compris comment on changeait la taille des
partitions sans les vider.
J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter
les volumes logiques pour changer la taille, puis restaurer le contenu.
Sinon, lvm est une bonne solution, linux le gère bien.
J'ai eu une machine avec cette solution. Le problème a été que je n'ai pas compris comment on changeait la taille des partitions sans les vider. J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu. Me suis-je trompé ?
Oui!
Cordialement
Itou -- François Patte Université Paris Descartes
Nicolas George
Dominique MICOLLET , dans le message <58cfec55$0$24774$, a écrit :
Le problème a été que je n'ai pas compris comment on changeait la taille des partitions sans les vider. J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu. Me suis-je trompé ?
Ça aiderait de réfléchir à ce que son des partitions, ce que sont des filesystems et comment les deux interagissent entre eux. Une partition, c'est une partie contigüe d'un périphérique de bloc, de taille fixe, pas facilement modifiable, sur laquelle un logiciel peut lire et écrire à volonté à n'importe quelle position. Un volume logique LVM, c'est à peu près pareil, sauf que ce n'est pas forcément contigu en vrai, ni même sur le même périphérique, mais ça apparaît bien contigu pour les logiciels qui s'en servent. Un filesystem, c'est une structure de données et le logiciel pour la manipuler, en général implémenté dans le noyau, qui permet d'organiser l'espace contigu d'un périphérique de bloc (donc d'une partition, d'un volume logique ou d'un vrai périphérique comme une disquette) pour y définir des fichiers, avec leurs noms, qui puissent grossir ou rapetisser facilement, être déplacés, etc. En général, il filesystem va essayer d'utiliser toute la place disponible sur son périphérique. Mais il est possible de le configurer pour éviter certaines zones, par exemple des secteurs défectueux, ou bien une zone qui va être amenée à disparaître prochainement. Ça peut se configurer au début ou a posteriori, à condition que les outils existent. Redimensionner une partition, ça revient juste à changer, à l'endroit idoine, l'indication de la position où elle se termine. Les données du début restent les mêmes, les données de la fin deviennent inaccessibles si on rapetisse, ou bien on se retrouve avec des données aléatoires à la fin, ce qui traînant là sur le disque auparavant, si on agrandit. On peut aussi déplacer une partition, mais c'est beaucoup plus coûteux parce qu'il faut tout copier ; et si le départ et l'arrivée se chevauchent, il faut copier dans le bon ordre et ne pas interrompre en route. Redimensionner un volume logique LVM, c'est un peu plus complexe en interne mais plus facile pour l'opérateur, et plus efficace. Exercice : décrire, dans l'ordre, les opérations nécessaires pour agrandir une partition et le filesystem qu'elle contient ; même question pour rapetisser.
Dominique MICOLLET , dans le message
<58cfec55$0$24774$426a74cc@news.free.fr>, a écrit :
Le problème a été que je n'ai pas compris comment on changeait la taille des
partitions sans les vider.
J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter
les volumes logiques pour changer la taille, puis restaurer le contenu.
Me suis-je trompé ?
Ça aiderait de réfléchir à ce que son des partitions, ce que sont des
filesystems et comment les deux interagissent entre eux.
Une partition, c'est une partie contigüe d'un périphérique de bloc, de
taille fixe, pas facilement modifiable, sur laquelle un logiciel peut
lire et écrire à volonté à n'importe quelle position. Un volume logique
LVM, c'est à peu près pareil, sauf que ce n'est pas forcément contigu en
vrai, ni même sur le même périphérique, mais ça apparaît bien contigu
pour les logiciels qui s'en servent.
Un filesystem, c'est une structure de données et le logiciel pour la
manipuler, en général implémenté dans le noyau, qui permet d'organiser
l'espace contigu d'un périphérique de bloc (donc d'une partition, d'un
volume logique ou d'un vrai périphérique comme une disquette) pour y
définir des fichiers, avec leurs noms, qui puissent grossir ou
rapetisser facilement, être déplacés, etc.
En général, il filesystem va essayer d'utiliser toute la place
disponible sur son périphérique. Mais il est possible de le configurer
pour éviter certaines zones, par exemple des secteurs défectueux, ou
bien une zone qui va être amenée à disparaître prochainement. Ça peut se
configurer au début ou a posteriori, à condition que les outils
existent.
Redimensionner une partition, ça revient juste à changer, à l'endroit
idoine, l'indication de la position où elle se termine. Les données du
début restent les mêmes, les données de la fin deviennent inaccessibles
si on rapetisse, ou bien on se retrouve avec des données aléatoires à la
fin, ce qui traînant là sur le disque auparavant, si on agrandit. On
peut aussi déplacer une partition, mais c'est beaucoup plus coûteux
parce qu'il faut tout copier ; et si le départ et l'arrivée se
chevauchent, il faut copier dans le bon ordre et ne pas interrompre en
route. Redimensionner un volume logique LVM, c'est un peu plus complexe
en interne mais plus facile pour l'opérateur, et plus efficace.
Exercice : décrire, dans l'ordre, les opérations nécessaires pour
agrandir une partition et le filesystem qu'elle contient ; même question
pour rapetisser.
Dominique MICOLLET , dans le message <58cfec55$0$24774$, a écrit :
Le problème a été que je n'ai pas compris comment on changeait la taille des partitions sans les vider. J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu. Me suis-je trompé ?
Ça aiderait de réfléchir à ce que son des partitions, ce que sont des filesystems et comment les deux interagissent entre eux. Une partition, c'est une partie contigüe d'un périphérique de bloc, de taille fixe, pas facilement modifiable, sur laquelle un logiciel peut lire et écrire à volonté à n'importe quelle position. Un volume logique LVM, c'est à peu près pareil, sauf que ce n'est pas forcément contigu en vrai, ni même sur le même périphérique, mais ça apparaît bien contigu pour les logiciels qui s'en servent. Un filesystem, c'est une structure de données et le logiciel pour la manipuler, en général implémenté dans le noyau, qui permet d'organiser l'espace contigu d'un périphérique de bloc (donc d'une partition, d'un volume logique ou d'un vrai périphérique comme une disquette) pour y définir des fichiers, avec leurs noms, qui puissent grossir ou rapetisser facilement, être déplacés, etc. En général, il filesystem va essayer d'utiliser toute la place disponible sur son périphérique. Mais il est possible de le configurer pour éviter certaines zones, par exemple des secteurs défectueux, ou bien une zone qui va être amenée à disparaître prochainement. Ça peut se configurer au début ou a posteriori, à condition que les outils existent. Redimensionner une partition, ça revient juste à changer, à l'endroit idoine, l'indication de la position où elle se termine. Les données du début restent les mêmes, les données de la fin deviennent inaccessibles si on rapetisse, ou bien on se retrouve avec des données aléatoires à la fin, ce qui traînant là sur le disque auparavant, si on agrandit. On peut aussi déplacer une partition, mais c'est beaucoup plus coûteux parce qu'il faut tout copier ; et si le départ et l'arrivée se chevauchent, il faut copier dans le bon ordre et ne pas interrompre en route. Redimensionner un volume logique LVM, c'est un peu plus complexe en interne mais plus facile pour l'opérateur, et plus efficace. Exercice : décrire, dans l'ordre, les opérations nécessaires pour agrandir une partition et le filesystem qu'elle contient ; même question pour rapetisser.
Christophe PEREZ
Le 20/03/2017 15:51, Dominique MICOLLET a écrit :
J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu.
Quand je pense que c'est le même qui voulait me donner des leçons de compréhension de Linux...
Le 20/03/2017 15:51, Dominique MICOLLET a écrit :
J'ai eu l'impression qu'il fallait faire des sauvegardes à part,
réaffecter les volumes logiques pour changer la taille, puis restaurer
le contenu.
Quand je pense que c'est le même qui voulait me donner des leçons de
compréhension de Linux...
J'ai eu l'impression qu'il fallait faire des sauvegardes à part, réaffecter les volumes logiques pour changer la taille, puis restaurer le contenu.
Quand je pense que c'est le même qui voulait me donner des leçons de compréhension de Linux...
Dominique MICOLLET
Bonjour, Nicolas George wrote:
Exercice : décrire, dans l'ordre, les opérations nécessaires pour agrandir une partition et le filesystem qu'elle contient ; même question pour rapetisser.
Vous m'apprenez qu'il existe une commande de redimensionnement de système de fichier :-). Cordialement Dominique.
Bonjour,
Nicolas George wrote:
Exercice : décrire, dans l'ordre, les opérations nécessaires pour
agrandir une partition et le filesystem qu'elle contient ; même question
pour rapetisser.
Vous m'apprenez qu'il existe une commande de redimensionnement de système de
fichier :-).
Exercice : décrire, dans l'ordre, les opérations nécessaires pour agrandir une partition et le filesystem qu'elle contient ; même question pour rapetisser.
Vous m'apprenez qu'il existe une commande de redimensionnement de système de fichier :-). Cordialement Dominique.
Dominique MICOLLET
Bonjour, Christophe PEREZ wrote:
Quand je pense que c'est le même qui voulait me donner des leçons de compréhension de Linux...
Tout le monde ne connaît pas, comme vous, toutes les arcanes de linux. Ma connaissance se limite à ce que j'ai pu expérimenter, et je n'ai que très rarement eu à redimensionner des partitions ou des systèmes de fichiers. Et quand cela est arrivé, je me suis généralement contenté de contourner le problème jusqu'à la prochaine installation de version majeure du système. Je n'ai pas les mêmes contraintes que vous, donc pas la même expérience. Le but de ce forum est d'échanger ces expériences, pas de concourir pour le trophée du meilleur administrateur, que je vous accorde bien volontiers. Discordialement Dominique
Bonjour,
Christophe PEREZ wrote:
Quand je pense que c'est le même qui voulait me donner des leçons de
compréhension de Linux...
Tout le monde ne connaît pas, comme vous, toutes les arcanes de linux.
Ma connaissance se limite à ce que j'ai pu expérimenter, et je n'ai que très
rarement eu à redimensionner des partitions ou des systèmes de fichiers.
Et quand cela est arrivé, je me suis généralement contenté de contourner le
problème jusqu'à la prochaine installation de version majeure du système.
Je n'ai pas les mêmes contraintes que vous, donc pas la même expérience.
Le but de ce forum est d'échanger ces expériences, pas de concourir pour le
trophée du meilleur administrateur, que je vous accorde bien volontiers.
Quand je pense que c'est le même qui voulait me donner des leçons de compréhension de Linux...
Tout le monde ne connaît pas, comme vous, toutes les arcanes de linux. Ma connaissance se limite à ce que j'ai pu expérimenter, et je n'ai que très rarement eu à redimensionner des partitions ou des systèmes de fichiers. Et quand cela est arrivé, je me suis généralement contenté de contourner le problème jusqu'à la prochaine installation de version majeure du système. Je n'ai pas les mêmes contraintes que vous, donc pas la même expérience. Le but de ce forum est d'échanger ces expériences, pas de concourir pour le trophée du meilleur administrateur, que je vous accorde bien volontiers. Discordialement Dominique
