Mon idée c'est de déplacer /usr : réduire la partion /home de 50 Go -
creer une partition que j'affecterai plus tard à /usr -déplacer les
fichiers de /usr à la nouvelle partition - modifier /etc/fstab en fonction
de la nouvelle affectation de la nouvelle partition. Je me retrouverai
avec 18 Go de libre sur la partition /
Quelqu'un a une meilleure idée ?
--
Je ne crois que les histoires dont les témoins se feraient égorger.
-+- Blaise Pascal (1623-1662), Pensées - IX.593 -+-
--
La nature veut qu'on jouisse de la vie le plus possible et qu'on meure
sans y penser. Le christianisme a retourné cela.
-+- Charles Sainte Beuve -+-
Le Sun, 01 Apr 2018 12:06:26 +0200, Pascal Hambourg a écrit :
Si le contenu de /var est transféré dans un nouveau système de fichiers avec un UUID différent, il faudra mettre à jour l'UUID dans /etc/fstab.
Question bête (et méchante) comment je fais pour avoir l'uuid ? Bon j'ai trouvé un moyen, mais il y en a peut-être un autre)
Avec blkid, ou en regardant dans /dev/disk/by-uuid. On peut aussi définir soi-même l'UUID lors de la création du système de fichiers.
plan d'attaque : 1. J'installe un système live sur une clé usb 2. (Je boute dessus) Je réduis /home et je crée une partition (gparted) 3. Je copie les fichiers de /var dans la nouvelle partition (il me semble que gparted offre la possibilité de cloner une partition
Oui. Dans ce cas la partition clone aura le même UUID que la partition originale, il n'y aura donc pas besoin de modifier fstab. Inconvénient : à moins que gparted utilise un algorithme "intelligent" qui ne copie que les blocs utilisés, à l'instar de partclone, ça copie aussi les blocs non utilisés donc ça peut être plus long qu'une copie des fichiers en fonction du taux d'occupation de la partition.
4. Je mets à jour fstab
Ou bien tu modifies l'UUID de la partition (avec tune2fs si ext4).
5. Je supprime l'ancienne partition /var
Optionnellement, tu fais pareil avec le swap pour 3 Go de plus. Dans ce cas je recommande de remettre le même UUID sur la nouvelle partition, soit par clonage, soit lors de son initialisation avec mkswap (gparted propose peut-être aussi l'option, je le connais peu), soit après avec swaplabel au lieu de modifier fstab car l'UUID du swap peut se retrouver dans d'autres fichiers de configuration pour l'hibernation (/etc/initramfs-tools/conf.d/resume et l'initramfs qu'il faut ensuite reconstruire pour ne pas se prendre une erreur et une attente au redémarrage).
6. J'agrandis / 7. C'est bon, jusqu'à la prochaine indigestion (NB /var avait débordé auparavant à cause des packages)
Il faut penser à nettoyer le cache de téléchargement de paquets régulièrement, au moins avec apt-get autoclean. Si tu as besoin de plus d'espace dans /var, tu peux en profiter pour l'agrandir aussi par la même occasion.
J'ai rien oublié ?
Je ne vois rien.
quelle distribution live : j'ai une clé de 4 Go et l'autre 8 Go
Désolé, je n'y connais rien en distribution live, je n'en utilise pas.
Le 01/04/2018 à 16:14, Jo Engo a écrit :
Le Sun, 01 Apr 2018 12:06:26 +0200, Pascal Hambourg a écrit :
Si le contenu de /var est transféré dans un nouveau système de fichiers
avec un UUID différent, il faudra mettre à jour l'UUID dans /etc/fstab.
Question bête (et méchante) comment je fais pour avoir l'uuid ? Bon j'ai
trouvé un moyen, mais il y en a peut-être un autre)
Avec blkid, ou en regardant dans /dev/disk/by-uuid. On peut aussi
définir soi-même l'UUID lors de la création du système de fichiers.
plan d'attaque :
1. J'installe un système live sur une clé usb
2. (Je boute dessus) Je réduis /home et je crée une partition (gparted)
3. Je copie les fichiers de /var dans la nouvelle partition (il me semble
que gparted offre la possibilité de cloner une partition
Oui. Dans ce cas la partition clone aura le même UUID que la partition
originale, il n'y aura donc pas besoin de modifier fstab. Inconvénient :
à moins que gparted utilise un algorithme "intelligent" qui ne copie que
les blocs utilisés, à l'instar de partclone, ça copie aussi les blocs
non utilisés donc ça peut être plus long qu'une copie des fichiers en
fonction du taux d'occupation de la partition.
4. Je mets à jour fstab
Ou bien tu modifies l'UUID de la partition (avec tune2fs si ext4).
5. Je supprime l'ancienne partition /var
Optionnellement, tu fais pareil avec le swap pour 3 Go de plus.
Dans ce cas je recommande de remettre le même UUID sur la nouvelle
partition, soit par clonage, soit lors de son initialisation avec mkswap
(gparted propose peut-être aussi l'option, je le connais peu), soit
après avec swaplabel au lieu de modifier fstab car l'UUID du swap peut
se retrouver dans d'autres fichiers de configuration pour l'hibernation
(/etc/initramfs-tools/conf.d/resume et l'initramfs qu'il faut ensuite
reconstruire pour ne pas se prendre une erreur et une attente au
redémarrage).
6. J'agrandis /
7. C'est bon, jusqu'à la prochaine indigestion (NB /var avait débordé
auparavant à cause des packages)
Il faut penser à nettoyer le cache de téléchargement de paquets
régulièrement, au moins avec apt-get autoclean. Si tu as besoin de plus
d'espace dans /var, tu peux en profiter pour l'agrandir aussi par la
même occasion.
J'ai rien oublié ?
Je ne vois rien.
quelle distribution live : j'ai une clé de 4 Go et l'autre 8 Go
Désolé, je n'y connais rien en distribution live, je n'en utilise pas.
Le Sun, 01 Apr 2018 12:06:26 +0200, Pascal Hambourg a écrit :
Si le contenu de /var est transféré dans un nouveau système de fichiers avec un UUID différent, il faudra mettre à jour l'UUID dans /etc/fstab.
Question bête (et méchante) comment je fais pour avoir l'uuid ? Bon j'ai trouvé un moyen, mais il y en a peut-être un autre)
Avec blkid, ou en regardant dans /dev/disk/by-uuid. On peut aussi définir soi-même l'UUID lors de la création du système de fichiers.
plan d'attaque : 1. J'installe un système live sur une clé usb 2. (Je boute dessus) Je réduis /home et je crée une partition (gparted) 3. Je copie les fichiers de /var dans la nouvelle partition (il me semble que gparted offre la possibilité de cloner une partition
Oui. Dans ce cas la partition clone aura le même UUID que la partition originale, il n'y aura donc pas besoin de modifier fstab. Inconvénient : à moins que gparted utilise un algorithme "intelligent" qui ne copie que les blocs utilisés, à l'instar de partclone, ça copie aussi les blocs non utilisés donc ça peut être plus long qu'une copie des fichiers en fonction du taux d'occupation de la partition.
4. Je mets à jour fstab
Ou bien tu modifies l'UUID de la partition (avec tune2fs si ext4).
5. Je supprime l'ancienne partition /var
Optionnellement, tu fais pareil avec le swap pour 3 Go de plus. Dans ce cas je recommande de remettre le même UUID sur la nouvelle partition, soit par clonage, soit lors de son initialisation avec mkswap (gparted propose peut-être aussi l'option, je le connais peu), soit après avec swaplabel au lieu de modifier fstab car l'UUID du swap peut se retrouver dans d'autres fichiers de configuration pour l'hibernation (/etc/initramfs-tools/conf.d/resume et l'initramfs qu'il faut ensuite reconstruire pour ne pas se prendre une erreur et une attente au redémarrage).
6. J'agrandis / 7. C'est bon, jusqu'à la prochaine indigestion (NB /var avait débordé auparavant à cause des packages)
Il faut penser à nettoyer le cache de téléchargement de paquets régulièrement, au moins avec apt-get autoclean. Si tu as besoin de plus d'espace dans /var, tu peux en profiter pour l'agrandir aussi par la même occasion.
J'ai rien oublié ?
Je ne vois rien.
quelle distribution live : j'ai une clé de 4 Go et l'autre 8 Go
Désolé, je n'y connais rien en distribution live, je n'en utilise pas.
Jo Engo
Le Sun, 01 Apr 2018 16:15:17 +0200, Pascal Hambourg a écrit :
"Lourde" parce que cette opération consiste à recopier tout son contenu (lecture d'un bloc, déplacement de la tête, écriture, et on recommence avec le bloc suivant). Vu la taille de la partition, je pense qu'il y en a au strict minimum pour 2h30 en fonction de la taille de bloc utilisée pour la copie.
/dev/sda9 420G 15G 384G 4% /home ce serait tuer un moineau avec un bazooka. Il doit y avoir plus simple à faire. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. -+- Karl Popper -+-
Le Sun, 01 Apr 2018 16:15:17 +0200, Pascal Hambourg a écrit :
"Lourde"
parce que cette opération consiste à recopier tout son contenu (lecture
d'un bloc, déplacement de la tête, écriture, et on recommence avec le
bloc suivant). Vu la taille de la partition, je pense qu'il y en a au
strict minimum pour 2h30 en fonction de la taille de bloc utilisée pour
la copie.
/dev/sda9 420G 15G 384G 4% /home ce serait tuer un
moineau avec un bazooka. Il doit y avoir plus simple à faire.
--
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
-+- Karl Popper -+-
Le Sun, 01 Apr 2018 16:15:17 +0200, Pascal Hambourg a écrit :
"Lourde" parce que cette opération consiste à recopier tout son contenu (lecture d'un bloc, déplacement de la tête, écriture, et on recommence avec le bloc suivant). Vu la taille de la partition, je pense qu'il y en a au strict minimum pour 2h30 en fonction de la taille de bloc utilisée pour la copie.
/dev/sda9 420G 15G 384G 4% /home ce serait tuer un moineau avec un bazooka. Il doit y avoir plus simple à faire. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. -+- Karl Popper -+-
Pascal Hambourg
Le 01/04/2018 à 16:34, Jo Engo a écrit :
Le Sun, 01 Apr 2018 16:15:17 +0200, Pascal Hambourg a écrit :
"Lourde" parce que cette opération consiste à recopier tout son contenu (lecture d'un bloc, déplacement de la tête, écriture, et on recommence avec le bloc suivant). Vu la taille de la partition, je pense qu'il y en a au strict minimum pour 2h30 en fonction de la taille de bloc utilisée pour la copie.
/dev/sda9 420G 15G 384G 4% /home ce serait tuer un moineau avec un bazooka. Il doit y avoir plus simple à faire.
Mais c'est simple, en fait il n'y a pas plus simple pour l'utilisateur. C'est seulement long (et risqué en cas d'interruption car pas de retour en arrière possible). Allez, une idée pour gagner du temps : réduire très fortement la partition /home à quasiment sa taille minimum avant de la déplacer. Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au maximum mais seulement de l'espace à libérer pour la racine, laisser de l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Le 01/04/2018 à 16:34, Jo Engo a écrit :
Le Sun, 01 Apr 2018 16:15:17 +0200, Pascal Hambourg a écrit :
"Lourde"
parce que cette opération consiste à recopier tout son contenu (lecture
d'un bloc, déplacement de la tête, écriture, et on recommence avec le
bloc suivant). Vu la taille de la partition, je pense qu'il y en a au
strict minimum pour 2h30 en fonction de la taille de bloc utilisée pour
la copie.
/dev/sda9 420G 15G 384G 4% /home ce serait tuer un
moineau avec un bazooka. Il doit y avoir plus simple à faire.
Mais c'est simple, en fait il n'y a pas plus simple pour l'utilisateur.
C'est seulement long (et risqué en cas d'interruption car pas de retour
en arrière possible).
Allez, une idée pour gagner du temps : réduire très fortement la
partition /home à quasiment sa taille minimum avant de la déplacer.
Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au
maximum mais seulement de l'espace à libérer pour la racine, laisser de
l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Le Sun, 01 Apr 2018 16:15:17 +0200, Pascal Hambourg a écrit :
"Lourde" parce que cette opération consiste à recopier tout son contenu (lecture d'un bloc, déplacement de la tête, écriture, et on recommence avec le bloc suivant). Vu la taille de la partition, je pense qu'il y en a au strict minimum pour 2h30 en fonction de la taille de bloc utilisée pour la copie.
/dev/sda9 420G 15G 384G 4% /home ce serait tuer un moineau avec un bazooka. Il doit y avoir plus simple à faire.
Mais c'est simple, en fait il n'y a pas plus simple pour l'utilisateur. C'est seulement long (et risqué en cas d'interruption car pas de retour en arrière possible). Allez, une idée pour gagner du temps : réduire très fortement la partition /home à quasiment sa taille minimum avant de la déplacer. Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au maximum mais seulement de l'espace à libérer pour la racine, laisser de l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Jo Engo
Le Sun, 01 Apr 2018 16:44:33 +0200, Pascal Hambourg a écrit :
Allez, une idée pour gagner du temps : réduire très fortement la partition /home à quasiment sa taille minimum avant de la déplacer. Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au maximum mais seulement de l'espace à libérer pour la racine, laisser de l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Pourquoi ne pas simplement copier les fichiers avec rsync par exemple ?
Le Sun, 01 Apr 2018 16:44:33 +0200, Pascal Hambourg a écrit :
Allez, une idée pour gagner du temps : réduire très fortement la
partition /home à quasiment sa taille minimum avant de la déplacer.
Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au
maximum mais seulement de l'espace à libérer pour la racine, laisser de
l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Pourquoi ne pas simplement copier les fichiers avec rsync par exemple ?
Le Sun, 01 Apr 2018 16:44:33 +0200, Pascal Hambourg a écrit :
Allez, une idée pour gagner du temps : réduire très fortement la partition /home à quasiment sa taille minimum avant de la déplacer. Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au maximum mais seulement de l'espace à libérer pour la racine, laisser de l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Pourquoi ne pas simplement copier les fichiers avec rsync par exemple ?
Jo Engo
Le Sun, 01 Apr 2018 16:33:06 +0200, Pascal Hambourg a écrit :
l'initramfs qu'il faut ensuite reconstruire
Comment fait-on ça ? je l'ai vu se reconstruire lors de la mise à jour d'un paquet mais je ne sais pas comment faire ça manuellement.
Le Sun, 01 Apr 2018 16:33:06 +0200, Pascal Hambourg a écrit :
l'initramfs qu'il faut ensuite reconstruire
Comment fait-on ça ? je l'ai vu se reconstruire lors de la mise à jour
d'un paquet mais je ne sais pas comment faire ça manuellement.
Le Sun, 01 Apr 2018 16:33:06 +0200, Pascal Hambourg a écrit :
tu fais pareil avec le swap pour 3 Go de plus.
Là il y a un gag : le live va vouloir utiliser le swap. Si je lui dis unswap, il va comprendre ?
Pascal Hambourg
Le 01/04/2018 à 18:00, Jo Engo a écrit :
Le Sun, 01 Apr 2018 16:44:33 +0200, Pascal Hambourg a écrit :
Allez, une idée pour gagner du temps : réduire très fortement la partition /home à quasiment sa taille minimum avant de la déplacer. Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au maximum mais seulement de l'espace à libérer pour la racine, laisser de l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Pourquoi ne pas simplement copier les fichiers avec rsync par exemple ?
Si tu veux, mais là aussi il faut d'abord réduire drastiquement la partition /home actuelle pour pouvoir créer la nouvelle /partition home. En fait dans les deux cas j'aime bien cette idée car contrairement à la simple réduction de /home + déplacement de /var ou /usr : - elle évite de repousser /var ou /usr à la fin du disque, loin de tout et plus lente ; - elle permet de choisir la quantité d'espace disque à allouer à la partition racine.
Le 01/04/2018 à 18:00, Jo Engo a écrit :
Le Sun, 01 Apr 2018 16:44:33 +0200, Pascal Hambourg a écrit :
Allez, une idée pour gagner du temps : réduire très fortement la
partition /home à quasiment sa taille minimum avant de la déplacer.
Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au
maximum mais seulement de l'espace à libérer pour la racine, laisser de
l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Pourquoi ne pas simplement copier les fichiers avec rsync par exemple ?
Si tu veux, mais là aussi il faut d'abord réduire drastiquement la
partition /home actuelle pour pouvoir créer la nouvelle /partition home.
En fait dans les deux cas j'aime bien cette idée car contrairement à la
simple réduction de /home + déplacement de /var ou /usr :
- elle évite de repousser /var ou /usr à la fin du disque, loin de tout
et plus lente ;
- elle permet de choisir la quantité d'espace disque à allouer à la
partition racine.
Le Sun, 01 Apr 2018 16:44:33 +0200, Pascal Hambourg a écrit :
Allez, une idée pour gagner du temps : réduire très fortement la partition /home à quasiment sa taille minimum avant de la déplacer. Autre avantage : il n'y aura pas de chevauchement. Ne pas la déplacer au maximum mais seulement de l'espace à libérer pour la racine, laisser de l'espace libre après pour l'agrandir à nouveau à sa taille souhaitée.
Pourquoi ne pas simplement copier les fichiers avec rsync par exemple ?
Si tu veux, mais là aussi il faut d'abord réduire drastiquement la partition /home actuelle pour pouvoir créer la nouvelle /partition home. En fait dans les deux cas j'aime bien cette idée car contrairement à la simple réduction de /home + déplacement de /var ou /usr : - elle évite de repousser /var ou /usr à la fin du disque, loin de tout et plus lente ; - elle permet de choisir la quantité d'espace disque à allouer à la partition racine.
Pascal Hambourg
Le 01/04/2018 à 18:04, Jo Engo a écrit :
Le Sun, 01 Apr 2018 16:33:06 +0200, Pascal Hambourg a écrit :
l'initramfs qu'il faut ensuite reconstruire
Comment fait-on ça ? je l'ai vu se reconstruire lors de la mise à jour d'un paquet mais je ne sais pas comment faire ça manuellement.
update-initramfs -u
Le 01/04/2018 à 18:04, Jo Engo a écrit :
Le Sun, 01 Apr 2018 16:33:06 +0200, Pascal Hambourg a écrit :
l'initramfs qu'il faut ensuite reconstruire
Comment fait-on ça ? je l'ai vu se reconstruire lors de la mise à jour
d'un paquet mais je ne sais pas comment faire ça manuellement.
