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 -+-
Jo Engo , dans le message <pan$1710$22c5355e$d0bd14c5$, a écrit :
À cause de liens durs ?
Non, à cause de composants indispensables dans /usr. Les liens durs, c'est anecdotique.
Pascal Hambourg
Le 01/04/2018 à 10:55, Nicolas George a écrit :
Jo Engo a écrit :
Le Sat, 31 Mar 2018 19:31:13 +0200, François Patte a écrit :
Séparer /usr de / entraine des problèmes pour certaines distributions (fedora par exemple).
À cause de liens durs ?
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils sont limités à un même système de fichiers. Si un lien dur est visible, sa cible l'est aussi. Tu veux parler de liens symboliques ?
Non, à cause de composants indispensables dans /usr.
Il me semblait que ce problème avait été résolu en montant /usr dans l'initramfs (ce que fait Debian depuis la version 8) avant de passer la main à l'init du système. Il me semblait aussi que c'était d'ailleurs un prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui est en cours dans Debian. [1] "/usr merge" qui déplace le contenu de /bin, /lib* et /sbin dans leurs homologues dans /usr et les remplace par des liens symboliques. À ne pas confondre avec l'inclusion de /usr dans le système de fichiers racine. PS : Nicolas, tu pourrais laisser un minimum de contexte pour qu'on comprenne la question sans relire le message précédent.
Le 01/04/2018 à 10:55, Nicolas George a écrit :
Jo Engo a écrit :
Le Sat, 31 Mar 2018 19:31:13 +0200, François Patte a écrit :
Séparer /usr de / entraine des problèmes pour certaines distributions
(fedora par exemple).
À cause de liens durs ?
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils
sont limités à un même système de fichiers. Si un lien dur est visible,
sa cible l'est aussi. Tu veux parler de liens symboliques ?
Non, à cause de composants indispensables dans /usr.
Il me semblait que ce problème avait été résolu en montant /usr dans
l'initramfs (ce que fait Debian depuis la version 8) avant de passer la
main à l'init du système. Il me semblait aussi que c'était d'ailleurs un
prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui
est en cours dans Debian.
[1] "/usr merge" qui déplace le contenu de /bin, /lib* et /sbin dans
leurs homologues dans /usr et les remplace par des liens symboliques. À
ne pas confondre avec l'inclusion de /usr dans le système de fichiers
racine.
PS : Nicolas, tu pourrais laisser un minimum de contexte pour qu'on
comprenne la question sans relire le message précédent.
Le Sat, 31 Mar 2018 19:31:13 +0200, François Patte a écrit :
Séparer /usr de / entraine des problèmes pour certaines distributions (fedora par exemple).
À cause de liens durs ?
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils sont limités à un même système de fichiers. Si un lien dur est visible, sa cible l'est aussi. Tu veux parler de liens symboliques ?
Non, à cause de composants indispensables dans /usr.
Il me semblait que ce problème avait été résolu en montant /usr dans l'initramfs (ce que fait Debian depuis la version 8) avant de passer la main à l'init du système. Il me semblait aussi que c'était d'ailleurs un prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui est en cours dans Debian. [1] "/usr merge" qui déplace le contenu de /bin, /lib* et /sbin dans leurs homologues dans /usr et les remplace par des liens symboliques. À ne pas confondre avec l'inclusion de /usr dans le système de fichiers racine. PS : Nicolas, tu pourrais laisser un minimum de contexte pour qu'on comprenne la question sans relire le message précédent.
Pascal Hambourg
Le 01/04/2018 à 11:30, Pascal Hambourg a écrit :
Le 01/04/2018 à 10:55, Nicolas George a écrit :
Jo Engo a écrit :
Le Sat, 31 Mar 2018 19:31:13 +0200, François Patte a écrit :
Séparer /usr de / entraine des problèmes pour certaines distributions (fedora par exemple).
À cause de liens durs ?
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils sont limités à un même système de fichiers. Si un lien dur est visible, sa cible l'est aussi. Tu veux parler de liens symboliques ?
Je crois que je viens de comprendre. Tu veux parler d'un paquet qui installerait par exemple un fichier dans /bin et créerait un lien dur vers celui-ci dans /usr/bin (ou vice versa), ce qui échouerait si /usr est séparé de la racine. Etant donné que la séparation de /usr est une longue tradition dont il serait imprudent de ne pas tenir compte, je pense que ce serait une mauvaise idée de faire cela, et que les paquets qui veulent rendre un même programme présent à la fois dans / et /usr (avant la fusion de /usr) le font plutôt avec un lien symbolique.
Le 01/04/2018 à 11:30, Pascal Hambourg a écrit :
Le 01/04/2018 à 10:55, Nicolas George a écrit :
Jo Engo a écrit :
Le Sat, 31 Mar 2018 19:31:13 +0200, François Patte a écrit :
Séparer /usr de / entraine des problèmes pour certaines distributions
(fedora par exemple).
À cause de liens durs ?
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils
sont limités à un même système de fichiers. Si un lien dur est visible,
sa cible l'est aussi. Tu veux parler de liens symboliques ?
Je crois que je viens de comprendre. Tu veux parler d'un paquet qui
installerait par exemple un fichier dans /bin et créerait un lien dur
vers celui-ci dans /usr/bin (ou vice versa), ce qui échouerait si /usr
est séparé de la racine. Etant donné que la séparation de /usr est une
longue tradition dont il serait imprudent de ne pas tenir compte, je
pense que ce serait une mauvaise idée de faire cela, et que les paquets
qui veulent rendre un même programme présent à la fois dans / et /usr
(avant la fusion de /usr) le font plutôt avec un lien symbolique.
Le Sat, 31 Mar 2018 19:31:13 +0200, François Patte a écrit :
Séparer /usr de / entraine des problèmes pour certaines distributions (fedora par exemple).
À cause de liens durs ?
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils sont limités à un même système de fichiers. Si un lien dur est visible, sa cible l'est aussi. Tu veux parler de liens symboliques ?
Je crois que je viens de comprendre. Tu veux parler d'un paquet qui installerait par exemple un fichier dans /bin et créerait un lien dur vers celui-ci dans /usr/bin (ou vice versa), ce qui échouerait si /usr est séparé de la racine. Etant donné que la séparation de /usr est une longue tradition dont il serait imprudent de ne pas tenir compte, je pense que ce serait une mauvaise idée de faire cela, et que les paquets qui veulent rendre un même programme présent à la fois dans / et /usr (avant la fusion de /usr) le font plutôt avec un lien symbolique.
Pascal Hambourg
Le 01/04/2018 à 10:33, Jo Engo a écrit :
Le Sun, 01 Apr 2018 01:54:15 +0200, Pascal Hambourg a écrit :
Ça dépend de l'espace supplémentaire dont tu as besoin. Apparemment la partition /var est à la suite de la partition /, donc tu pourrais la déplacer derrière la partition /home (après avoir réduit cette dernière de 10 Go) et agrandir / avec l'espace libéré.
Pas con. Comment être sûr que c'est possible ? Avec fdisk ? Une fois la manip faite quue dois-je modifier ? fstab ? Faire un appel noyau ?
A mon avis fdisk n'est pas l'outil approprié, il n'a même pas de fonctionnalité pour redimensionner une partition. Supprimer une partition et la recréer avec le même secteur de début est casse-gueule. Il vaut mieux utiliser parted ou gparted. Leurs modifications sont prises en compte immédiatement et inconditionnellement par le noyau, contrairement à fdisk dont les modifications ne peuvent être prises en compte si ne serait-ce qu'une seule partition du disque est en cours d'utilisation (contournement : exécuter partprobe ensuite). CAVEAT : - Parted ne redimensionne pas le système de fichiers contenu dans la partition donc dans le cas d'une réduction il faut le faire avant avec le programme idoine (et après dans le cas d'un agrandissement). Gparted fait les deux en même temps. - A de rares exceptions près comme btrfs, la réduction d'un système de fichiers n'est possible que s'il est démonté. Elle peut être impossible avec certains systèmes de fichiers comme xfs (rappel : par défaut openSUSE utilise xfs pour /home, pensez-y avant d'allouer 90% de l'espace disque à /home). Heureusement /home n'est pas le système de fichiers le plus difficile à démonter, il suffit normalement qu'aucun utilisateur normal ne soit connecté. En revanche l'agrandissement à chaud d'un système de fichiers monté (comme /) est souvent possible. - Déplacer une partition n'est possible que si elle n'est pas en cours d'utilisation. Or /var est quasiment toujours utilisé pour les logs ou autres, sauf peut-être en démarrant en mode single. On n'est pas forcément obligé de déplacer la partition, on peut copier le contenu de /var (avec cp, rsync...) dans le système de fichiers d'une nouvelle partition. Cloner une partition en cours d'utilisation (avec dd ou équivalent) va produire un résultat "sale" comme lorsqu'on arrête le système brutalement sans avoir démonté les systèmes de fichiers proprement. Pour toutes ces raisons, la réalisation de ces opérations depuis un autre système (système live par exemple) où aucune des partitions à modifier n'est utilisée peut être plus confortable que depuis le système installé. 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.
Le 01/04/2018 à 10:33, Jo Engo a écrit :
Le Sun, 01 Apr 2018 01:54:15 +0200, Pascal Hambourg a écrit :
Ça dépend de l'espace supplémentaire dont tu as besoin.
Apparemment la partition /var est à la suite de la partition /, donc tu
pourrais la déplacer derrière la partition /home (après avoir réduit
cette dernière de 10 Go) et agrandir / avec l'espace libéré.
Pas con. Comment être sûr que c'est possible ? Avec fdisk ? Une fois la
manip faite quue dois-je modifier ? fstab ? Faire un appel noyau ?
A mon avis fdisk n'est pas l'outil approprié, il n'a même pas de
fonctionnalité pour redimensionner une partition. Supprimer une
partition et la recréer avec le même secteur de début est casse-gueule.
Il vaut mieux utiliser parted ou gparted. Leurs modifications sont
prises en compte immédiatement et inconditionnellement par le noyau,
contrairement à fdisk dont les modifications ne peuvent être prises en
compte si ne serait-ce qu'une seule partition du disque est en cours
d'utilisation (contournement : exécuter partprobe ensuite).
CAVEAT :
- Parted ne redimensionne pas le système de fichiers contenu dans la
partition donc dans le cas d'une réduction il faut le faire avant avec
le programme idoine (et après dans le cas d'un agrandissement). Gparted
fait les deux en même temps.
- A de rares exceptions près comme btrfs, la réduction d'un système de
fichiers n'est possible que s'il est démonté. Elle peut être impossible
avec certains systèmes de fichiers comme xfs (rappel : par défaut
openSUSE utilise xfs pour /home, pensez-y avant d'allouer 90% de
l'espace disque à /home). Heureusement /home n'est pas le système de
fichiers le plus difficile à démonter, il suffit normalement qu'aucun
utilisateur normal ne soit connecté. En revanche l'agrandissement à
chaud d'un système de fichiers monté (comme /) est souvent possible.
- Déplacer une partition n'est possible que si elle n'est pas en cours
d'utilisation. Or /var est quasiment toujours utilisé pour les logs ou
autres, sauf peut-être en démarrant en mode single. On n'est pas
forcément obligé de déplacer la partition, on peut copier le contenu de
/var (avec cp, rsync...) dans le système de fichiers d'une nouvelle
partition. Cloner une partition en cours d'utilisation (avec dd ou
équivalent) va produire un résultat "sale" comme lorsqu'on arrête le
système brutalement sans avoir démonté les systèmes de fichiers proprement.
Pour toutes ces raisons, la réalisation de ces opérations depuis un
autre système (système live par exemple) où aucune des partitions à
modifier n'est utilisée peut être plus confortable que depuis le système
installé.
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.
Le Sun, 01 Apr 2018 01:54:15 +0200, Pascal Hambourg a écrit :
Ça dépend de l'espace supplémentaire dont tu as besoin. Apparemment la partition /var est à la suite de la partition /, donc tu pourrais la déplacer derrière la partition /home (après avoir réduit cette dernière de 10 Go) et agrandir / avec l'espace libéré.
Pas con. Comment être sûr que c'est possible ? Avec fdisk ? Une fois la manip faite quue dois-je modifier ? fstab ? Faire un appel noyau ?
A mon avis fdisk n'est pas l'outil approprié, il n'a même pas de fonctionnalité pour redimensionner une partition. Supprimer une partition et la recréer avec le même secteur de début est casse-gueule. Il vaut mieux utiliser parted ou gparted. Leurs modifications sont prises en compte immédiatement et inconditionnellement par le noyau, contrairement à fdisk dont les modifications ne peuvent être prises en compte si ne serait-ce qu'une seule partition du disque est en cours d'utilisation (contournement : exécuter partprobe ensuite). CAVEAT : - Parted ne redimensionne pas le système de fichiers contenu dans la partition donc dans le cas d'une réduction il faut le faire avant avec le programme idoine (et après dans le cas d'un agrandissement). Gparted fait les deux en même temps. - A de rares exceptions près comme btrfs, la réduction d'un système de fichiers n'est possible que s'il est démonté. Elle peut être impossible avec certains systèmes de fichiers comme xfs (rappel : par défaut openSUSE utilise xfs pour /home, pensez-y avant d'allouer 90% de l'espace disque à /home). Heureusement /home n'est pas le système de fichiers le plus difficile à démonter, il suffit normalement qu'aucun utilisateur normal ne soit connecté. En revanche l'agrandissement à chaud d'un système de fichiers monté (comme /) est souvent possible. - Déplacer une partition n'est possible que si elle n'est pas en cours d'utilisation. Or /var est quasiment toujours utilisé pour les logs ou autres, sauf peut-être en démarrant en mode single. On n'est pas forcément obligé de déplacer la partition, on peut copier le contenu de /var (avec cp, rsync...) dans le système de fichiers d'une nouvelle partition. Cloner une partition en cours d'utilisation (avec dd ou équivalent) va produire un résultat "sale" comme lorsqu'on arrête le système brutalement sans avoir démonté les systèmes de fichiers proprement. Pour toutes ces raisons, la réalisation de ces opérations depuis un autre système (système live par exemple) où aucune des partitions à modifier n'est utilisée peut être plus confortable que depuis le système installé. 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.
Jo Engo
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils sont limités à un même système de fichiers.
Justement ça aurait expliqué pourquoi /usr et / soient dans le même système de fichier
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils
sont limités à un même système de fichiers.
Justement ça aurait expliqué pourquoi /usr et / soient dans le même
système de fichier
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Je ne vois pas en quoi des liens durs peuvent poser problèmes puisqu'ils sont limités à un même système de fichiers.
Justement ça aurait expliqué pourquoi /usr et / soient dans le même système de fichier
Jo Engo
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Il me semblait que ce problème avait été résolu en montant /usr dans l'initramfs (ce que fait Debian depuis la version 8) avant de passer la main à l'init du système. Il me semblait aussi que c'était d'ailleurs un prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui est en cours dans Debian.
Soyons bref : je fonce ou j'évite ? parce que c'est pas clair là (quoique l'idée de déplacer /var (si elle (la partoche) est bien après / ne me déplait pas)
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Il me semblait que ce problème avait été résolu en montant /usr dans
l'initramfs (ce que fait Debian depuis la version 8) avant de passer la
main à l'init du système. Il me semblait aussi que c'était d'ailleurs un
prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui
est en cours dans Debian.
Soyons bref : je fonce ou j'évite ? parce que c'est pas clair là (quoique
l'idée de déplacer /var (si elle (la partoche) est bien après / ne me
déplait pas)
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Il me semblait que ce problème avait été résolu en montant /usr dans l'initramfs (ce que fait Debian depuis la version 8) avant de passer la main à l'init du système. Il me semblait aussi que c'était d'ailleurs un prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui est en cours dans Debian.
Soyons bref : je fonce ou j'évite ? parce que c'est pas clair là (quoique l'idée de déplacer /var (si elle (la partoche) est bien après / ne me déplait pas)
Pascal Hambourg
Le 01/04/2018 à 12:56, Jo Engo a écrit :
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Il me semblait que ce problème avait été résolu en montant /usr dans l'initramfs (ce que fait Debian depuis la version 8) avant de passer la main à l'init du système. Il me semblait aussi que c'était d'ailleurs un prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui est en cours dans Debian.
Soyons bref : je fonce ou j'évite ? parce que c'est pas clair là (quoique l'idée de déplacer /var (si elle (la partoche) est bien après / ne me déplait pas)
C'est quelle distribution ? Si c'est Debian 8/Jessie ou plus récent, /usr peut être monté par l'initramfs. Mais je ne garantis pas la bonne prise en charge d'un "bind mount" de répertoire, pas testé. Tu peux vérifier l'ordre physique des partitions avec fdisk, parted ou n'importe quel autre partitionneur.
Le 01/04/2018 à 12:56, Jo Engo a écrit :
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Il me semblait que ce problème avait été résolu en montant /usr dans
l'initramfs (ce que fait Debian depuis la version 8) avant de passer la
main à l'init du système. Il me semblait aussi que c'était d'ailleurs un
prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui
est en cours dans Debian.
Soyons bref : je fonce ou j'évite ? parce que c'est pas clair là (quoique
l'idée de déplacer /var (si elle (la partoche) est bien après / ne me
déplait pas)
C'est quelle distribution ? Si c'est Debian 8/Jessie ou plus récent,
/usr peut être monté par l'initramfs. Mais je ne garantis pas la bonne
prise en charge d'un "bind mount" de répertoire, pas testé.
Tu peux vérifier l'ordre physique des partitions avec fdisk, parted ou
n'importe quel autre partitionneur.
Le Sun, 01 Apr 2018 11:30:27 +0200, Pascal Hambourg a écrit :
Il me semblait que ce problème avait été résolu en montant /usr dans l'initramfs (ce que fait Debian depuis la version 8) avant de passer la main à l'init du système. Il me semblait aussi que c'était d'ailleurs un prérequis à la "fusion de /usr" [1] dont Fedora a été précurseur et qui est en cours dans Debian.
Soyons bref : je fonce ou j'évite ? parce que c'est pas clair là (quoique l'idée de déplacer /var (si elle (la partoche) est bien après / ne me déplait pas)
C'est quelle distribution ? Si c'est Debian 8/Jessie ou plus récent, /usr peut être monté par l'initramfs. Mais je ne garantis pas la bonne prise en charge d'un "bind mount" de répertoire, pas testé. Tu peux vérifier l'ordre physique des partitions avec fdisk, parted ou n'importe quel autre partitionneur.
Jo Engo
Le Sun, 01 Apr 2018 13:48:58 +0200, Pascal Hambourg a écrit :
Tu peux vérifier l'ordre physique des partitions avec fdisk, parted ou n'importe quel autre partitionneur.
Sortie de fdisk /dev/sda (p) (j'ajoute l'affectation) ------------------------------------------------------------------------>8 Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sda1 * 2048 2050047 2048000 1000M b W95 FAT32 (freedos) /dev/sda2 2052094 976771071 974718978 464,8G 5 Étendue /dev/sda5 2052096 50878463 48826368 23,3G 83 Linux (/) /dev/sda6 50880512 70410239 19529728 9,3G 83 Linux (/var) /dev/sda7 70412288 77619199 7206912 3,4G 82 partition d'échange Linux g/ Solaris (swap) /dev/sda8 77621248 81524735 3903488 1,9G 83 Linux (/opt) /dev/sda9 81526784 976771071 895244288 426,9G 83 Linux (/home) La partition 2 ne commence pas sur une frontière de cylindre physique. (en rouge) 8<------------------------------------------------------------------------ On peut en faire des choses :) je mets en option : - déplacer /var (réduire /home, créer une partition, déplacer les fichiers, affecter la partition à /var) puis agrandir / L'autre option est de réduire /home créer une partition, déplacer les fichiers de /usr/ affecter la partition à /usr, le désavantage est que ça va me libérer 23Go que je ne saurais pas comment affecter Y a-t-il une troisième voie ? -- Il faudrait essayer d'être heureux, ne serait-ce que pour montrer l'exemple. -+- Jacques Prévert -+-
Le Sun, 01 Apr 2018 13:48:58 +0200, Pascal Hambourg a écrit :
Tu peux vérifier l'ordre physique des partitions avec fdisk, parted ou
n'importe quel autre partitionneur.
Sortie de fdisk /dev/sda (p)
(j'ajoute l'affectation)
------------------------------------------------------------------------>8
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2048 2050047 2048000 1000M b W95 FAT32
(freedos)
/dev/sda2 2052094 976771071 974718978 464,8G 5 Étendue
/dev/sda5 2052096 50878463 48826368 23,3G 83 Linux (/)
/dev/sda6 50880512 70410239 19529728 9,3G 83 Linux (/var)
/dev/sda7 70412288 77619199 7206912 3,4G 82 partition
d'échange Linux g/ Solaris (swap)
/dev/sda8 77621248 81524735 3903488 1,9G 83 Linux (/opt)
/dev/sda9 81526784 976771071 895244288 426,9G 83 Linux (/home)
La partition 2 ne commence pas sur une frontière de cylindre physique.
(en rouge)
8<------------------------------------------------------------------------
On peut en faire des choses :) je mets en option :
- déplacer /var (réduire /home, créer une partition, déplacer les
fichiers, affecter la partition à /var) puis agrandir /
L'autre option est de réduire /home créer une partition, déplacer les
fichiers de /usr/ affecter la partition à /usr, le désavantage est que ça
va me libérer 23Go que je ne saurais pas comment affecter
Y a-t-il une troisième voie ?
--
Il faudrait essayer d'être heureux, ne serait-ce que pour montrer
l'exemple.
-+- Jacques Prévert -+-
Le Sun, 01 Apr 2018 13:48:58 +0200, Pascal Hambourg a écrit :
Tu peux vérifier l'ordre physique des partitions avec fdisk, parted ou n'importe quel autre partitionneur.
Sortie de fdisk /dev/sda (p) (j'ajoute l'affectation) ------------------------------------------------------------------------>8 Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sda1 * 2048 2050047 2048000 1000M b W95 FAT32 (freedos) /dev/sda2 2052094 976771071 974718978 464,8G 5 Étendue /dev/sda5 2052096 50878463 48826368 23,3G 83 Linux (/) /dev/sda6 50880512 70410239 19529728 9,3G 83 Linux (/var) /dev/sda7 70412288 77619199 7206912 3,4G 82 partition d'échange Linux g/ Solaris (swap) /dev/sda8 77621248 81524735 3903488 1,9G 83 Linux (/opt) /dev/sda9 81526784 976771071 895244288 426,9G 83 Linux (/home) La partition 2 ne commence pas sur une frontière de cylindre physique. (en rouge) 8<------------------------------------------------------------------------ On peut en faire des choses :) je mets en option : - déplacer /var (réduire /home, créer une partition, déplacer les fichiers, affecter la partition à /var) puis agrandir / L'autre option est de réduire /home créer une partition, déplacer les fichiers de /usr/ affecter la partition à /usr, le désavantage est que ça va me libérer 23Go que je ne saurais pas comment affecter Y a-t-il une troisième voie ? -- Il faudrait essayer d'être heureux, ne serait-ce que pour montrer l'exemple. -+- Jacques Prévert -+-
Jo Engo
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) 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 (ou j'ai rêvé ?)) 4. Je mets à jour fstab 5. Je supprime l'ancienne partition /var 6. J'agrandis / 7. C'est bon, jusqu'à la prochaine indigestion (NB /var avait débordé auparavant à cause des packages) J'ai rien oublié ? quelle distribution live : j'ai une clé de 4 Go et l'autre 8 Go -- L'Homme nait bon. Ça commence à se dégrader entre six et sept mois. -+- Georges Perros -+-
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)
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 (ou j'ai rêvé ?))
4. Je mets à jour fstab
5. Je supprime l'ancienne partition /var
6. J'agrandis /
7. C'est bon, jusqu'à la prochaine indigestion (NB /var avait débordé
auparavant à cause des packages)
J'ai rien oublié ?
quelle distribution live : j'ai une clé de 4 Go et l'autre 8 Go
--
L'Homme nait bon. Ça commence à se dégrader entre six et sept mois.
-+- Georges Perros -+-
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) 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 (ou j'ai rêvé ?)) 4. Je mets à jour fstab 5. Je supprime l'ancienne partition /var 6. J'agrandis / 7. C'est bon, jusqu'à la prochaine indigestion (NB /var avait débordé auparavant à cause des packages) J'ai rien oublié ? quelle distribution live : j'ai une clé de 4 Go et l'autre 8 Go -- L'Homme nait bon. Ça commence à se dégrader entre six et sept mois. -+- Georges Perros -+-
Pascal Hambourg
Le 01/04/2018 à 15:18, Jo Engo a écrit :
Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sda1 * 2048 2050047 2048000 1000M b W95 FAT32 (freedos) /dev/sda2 2052094 976771071 974718978 464,8G 5 Étendue /dev/sda5 2052096 50878463 48826368 23,3G 83 Linux (/) /dev/sda6 50880512 70410239 19529728 9,3G 83 Linux (/var) /dev/sda7 70412288 77619199 7206912 3,4G 82 partition d'échange Linux g/ Solaris (swap) /dev/sda8 77621248 81524735 3903488 1,9G 83 Linux (/opt) /dev/sda9 81526784 976771071 895244288 426,9G 83 Linux (/home)
Donc la partition /var est bien à la suite de la partition /.
La partition 2 ne commence pas sur une frontière de cylindre physique. (en rouge) 8<------------------------------------------------------------------------ On peut en faire des choses :) je mets en option : - déplacer /var (réduire /home, créer une partition, déplacer les fichiers, affecter la partition à /var) puis agrandir /
Et si ce n'est pas suffisant, tu peux faire de même avec la partition de swap qui est à la suite de la partition /var pour quelques Go de plus. L'éloignement du swap de / va dégrader les temps d'accès, mais ce sera déjà le cas pour /var.
L'autre option est de réduire /home créer une partition, déplacer les fichiers de /usr/ affecter la partition à /usr, le désavantage est que ça va me libérer 23Go que je ne saurais pas comment affecter Y a-t-il une troisième voie ?
La méthode lourde : avec gparted, réduire et déplacer la partition /home vers la fin du disque afin de libérer de l'espace avant elle. "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. Au moindre pépin interrompant l'opération, on perd tout le contenu de la partition puisque les emplacements source et destination se chevauchent en grande partie. Ensuite on peut déplacer les partitions entre / et /home du côté de /home pour libérer l'espace côté /, ce qui permet de l'agrandir.
Le 01/04/2018 à 15:18, Jo Engo a écrit :
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2048 2050047 2048000 1000M b W95 FAT32
(freedos)
/dev/sda2 2052094 976771071 974718978 464,8G 5 Étendue
/dev/sda5 2052096 50878463 48826368 23,3G 83 Linux (/)
/dev/sda6 50880512 70410239 19529728 9,3G 83 Linux (/var)
/dev/sda7 70412288 77619199 7206912 3,4G 82 partition
d'échange Linux g/ Solaris (swap)
/dev/sda8 77621248 81524735 3903488 1,9G 83 Linux (/opt)
/dev/sda9 81526784 976771071 895244288 426,9G 83 Linux (/home)
Donc la partition /var est bien à la suite de la partition /.
La partition 2 ne commence pas sur une frontière de cylindre physique.
(en rouge)
8<------------------------------------------------------------------------
On peut en faire des choses :) je mets en option :
- déplacer /var (réduire /home, créer une partition, déplacer les
fichiers, affecter la partition à /var) puis agrandir /
Et si ce n'est pas suffisant, tu peux faire de même avec la partition de
swap qui est à la suite de la partition /var pour quelques Go de plus.
L'éloignement du swap de / va dégrader les temps d'accès, mais ce sera
déjà le cas pour /var.
L'autre option est de réduire /home créer une partition, déplacer les
fichiers de /usr/ affecter la partition à /usr, le désavantage est que ça
va me libérer 23Go que je ne saurais pas comment affecter
Y a-t-il une troisième voie ?
La méthode lourde : avec gparted, réduire et déplacer la partition /home
vers la fin du disque afin de libérer de l'espace avant elle. "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. Au moindre pépin interrompant l'opération, on perd tout le
contenu de la partition puisque les emplacements source et destination
se chevauchent en grande partie.
Ensuite on peut déplacer les partitions entre / et /home du côté de
/home pour libérer l'espace côté /, ce qui permet de l'agrandir.
Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sda1 * 2048 2050047 2048000 1000M b W95 FAT32 (freedos) /dev/sda2 2052094 976771071 974718978 464,8G 5 Étendue /dev/sda5 2052096 50878463 48826368 23,3G 83 Linux (/) /dev/sda6 50880512 70410239 19529728 9,3G 83 Linux (/var) /dev/sda7 70412288 77619199 7206912 3,4G 82 partition d'échange Linux g/ Solaris (swap) /dev/sda8 77621248 81524735 3903488 1,9G 83 Linux (/opt) /dev/sda9 81526784 976771071 895244288 426,9G 83 Linux (/home)
Donc la partition /var est bien à la suite de la partition /.
La partition 2 ne commence pas sur une frontière de cylindre physique. (en rouge) 8<------------------------------------------------------------------------ On peut en faire des choses :) je mets en option : - déplacer /var (réduire /home, créer une partition, déplacer les fichiers, affecter la partition à /var) puis agrandir /
Et si ce n'est pas suffisant, tu peux faire de même avec la partition de swap qui est à la suite de la partition /var pour quelques Go de plus. L'éloignement du swap de / va dégrader les temps d'accès, mais ce sera déjà le cas pour /var.
L'autre option est de réduire /home créer une partition, déplacer les fichiers de /usr/ affecter la partition à /usr, le désavantage est que ça va me libérer 23Go que je ne saurais pas comment affecter Y a-t-il une troisième voie ?
La méthode lourde : avec gparted, réduire et déplacer la partition /home vers la fin du disque afin de libérer de l'espace avant elle. "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. Au moindre pépin interrompant l'opération, on perd tout le contenu de la partition puisque les emplacements source et destination se chevauchent en grande partie. Ensuite on peut déplacer les partitions entre / et /home du côté de /home pour libérer l'espace côté /, ce qui permet de l'agrandir.
