Taille partitions

Support Debian
#1

Bonjour,

root@alpha30:~# df -k                                                                                                                          
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
udev                 3044756       0    3044756   0% /dev
tmpfs                 611220   24632     586588   5% /run
/dev/sdb1            8518920 6867828    1195312  86% /
tmpfs                3056084       0    3056084   0% /dev/shm
tmpfs                   5120       4       5116   1% /run/lock
tmpfs                3056084       0    3056084   0% /sys/fs/cgroup
/dev/sdb7             368615    2142     342921   1% /tmp
/dev/sdb5            2817056 2420120     234120  92% /var
/dev/sdb8          937003976  610856  888773024   1% /home
tmpfs                 611216      16     611200   1% /run/user/118
tmpfs                 611216      32     611184   1% /run/user/1000
root@alpha30:~#

je voudrais changer la taille des partitions suivantes:
-minorer /home
-augmenter / ainsi que /var

vous conseillez quelle mèthodologie à part réinstaller Debian 3.16
et
faire un apt-get dist-upgrade pour venir en 4.9.0… je suis en testing
à vous lire
JB

#2

Bonjour,

Peut-on avoir aussi le retour de fdisk -l /dev/sd? ?

#3

Pas la peine, c’est couru d’avance. Selon toute évidence l’installation a été effectuée avec le partitionnement assisté qui a créé une partition principale pour / et une partition étendue contenant des partitions logiques pour /var, le swap, /tmp et /home. Avec des tailles inadaptées comme souvent, d’où le besoin de redimensionner.

L’espace qui serait libéré par la réduction de /dev/sdb8 (/home) serait donc situé à la fin du disque et ne pourrait servir à agrandir / et /var sauf si ceux-ci ont un système de fichiers btrfs (contradictoire avec le partitionnement assisté qui utilise ext4 donc improbable).

Pour redimensionner les partitions, il faut les déplacer donc passer par un autre système qui ne monte aucune de ces partitions, comme un système live.

Note : L’utilisation de LVM lors du partitionnement aurait grandement simplifié le redimensionnement. A méditer lors d’une prochaine installation. Je pense que dès qu’on sépare l’arborescence en plusieurs systèmes de fichiers, on devrait systématiquement définir les tailles manuellement et utiliser LVM.

#4

Ah, ben oui, tellement l’habitude de mettre du LVM à toutes les sauces que je n’ai pas fait attention.
En fait, c’est possible en réinstallant, copiant toutes les données.

#5

Bonjour

De plus, il ne pourra pas agrandir la partition racine (/dev/sdb1) tant qu’il n’aura pas réduit la taille de la partition étendue (/dev/sdb2) dans laquelle sont inscrites les partitions secondaires /dev/sdb5 /dev/sdb7 /dev/sdb8

(sans parler de l’existence possible des partitions secondaires /dev/sdb4 et /dev/sdb6 dont une est peut-être du type swap)

Il lui faudrait donc, depuis un système live, utiliser GParted (qui me semble plus simple à utiliser)
pour :

  • Réduire l’espace occupé par les partitions /dev/sdb7 et /dev/sdb8
  • Augmenter la taille de la partition /dev/sdb5 ( /var)
  • Déplacer ces partitions contenues dans /dev/sdb2 au début de la partition étendue
  • Réduire la taille de la partition étendue /dev/sdb2
  • Déplacer la partition étendue /dev/sdb2 vers la fin du disque
  • Augmenter la taille de la partition /dev/sdb1

Je plussoie à fond (même quand on utilise pas LVM)

#6

Comment arrive tu a définir la position des partions sur le disque depuis sont df -k ?

Cordialement

#7

Selon toute probabilité, la position des partitions correspond à leur numérotation.

[quote=“MicP, post:5, topic:72573”]
Il lui faudrait donc, depuis un système live, utiliser GParted (qui me semble plus simple à utiliser)pour : - Réduire l’espace occupé par les partitions /dev/sdb7 et /dev/sdb8- Augmenter la taille de la partition /dev/sdb5 ( /var)- Déplacer ces partitions contenues dans /dev/sdb2 au début de la partition étendue- Réduire la taille de la partition étendue /dev/sdb2- Déplacer la partition étendue /dev/sdb2 vers la fin du disque[/quote]
Je ne suis pas sûr que le déplacement de la partition étendue va déplacer les partitions logiques.
D’après ma petite expérience de Gparted, il faut plutôt réduire ou déplacer les partitions logiques vers la “droite” (fin du disque) puis déplacer la position de début de la partition étendue.

#8

J’ajoute que par expérience que ce type d’opération à même une chance de compromettre les donnée, une sauvegarde est indispensable.

Le mieux à faire si il n’est pas du tout envisageable de réinstaller serait sans doute d’utiliser un second disque et de refaire sur celui-ci un partitionnement correcte et d’y transférer les données par la suite, ce qui permettra de pouvoir par la même repartir sur un plan de partitionnement bénéficiant d’un montage avec LVM.
Il suffira du coup de prévoir une bascule sur le nouveau disque afin de pouvoir retirer l’ancien disque.

Mais ma main à coupée que la réinstallation serait le plus pratique ^^

#9

Excusez moi du retard,
comme boite à outil j’ai:
-Knoppix
-Ubuntu

  • autres Linux
    je peux utiliser un disque usb2 sata

pour la sauvegade des partitions:
-dd
-tar
-cpio
merci de participer
JB

#10

Tout à fait d’accord.

Désolé d’avoir posté sans prendre le temps de vérifier.
Je suis un peu fatigué ces jour-ci, mais ce n’est pas une excuse :
Il me faudra apprendre à être plus vigilant, surtout quand je suis dans cet état.

Je plussoie aussi la méthode (beaucoup plus sûre) proposé par clochette

Et je vais me reposer un peu pour pouvoir poster dans de meilleurs conditions.
(j’étais chez mon médecin cet après midi)

#11

Si tu as la possibilité de connecter directement sur un port SATA de ta machine le disque qui va recevoir la copie,
tu gagnera beaucoup beaucoup de temps,
car entre l’usb 2.0 et le port SATA, les vitesses de transferts sont extrêmement plus rapide par le port SATA

Par contre, ne redémarre pas la machine juste après avoir fait les copies sans avoir déconnecté le disque qui a reçut la copie des partitions.

Car le système de démarrage risque de ne plus très bien savoir sur quel disque se trouve la “bonne” partition à utiliser pour le système, vu qu’il y en aura une copie sur l’autre disque.

#12

Au moins une sauvegarde des données importantes (documents, fichiers de configuration, bases de données…). En effet l’interruption du processus de déplacement des données d’une partition pour une raison quelconque (plantage, fausse manip’, coupure d’alimentation…) aurait des conséquences catastrophiques rendant très difficile la récupération des données, surtout lorsque l’ancienne et la nouvelle position se chevauchent.

dd (ou ses alternatives plus “intelligentes” comme clonezilla, partclone ou partimage qui permettent de ne sauvegarder que les blocs occupés) ne convient pas pour la sauvegarde d’une partition dont la taille va être réduite car il est impossible de restaurer les données dans un espace plus petit.

Pour l’exécution de Gparted, n’importe quel système qui le contient devrait faire l’affaire.

#13

merci pour l’info
je suis en train de démonter un portable avec un ssd de 250GB
avant de faire des bétises je vais refaire les étapes en mettant tout sous /
A+
JB

#14

Ce risque n’existe que si on a fait un clonage d’un disque sur l’autre.

#15

En ce qui concerne les systèmes de fichiers mountés par /etc/fstab, j’ai eu rencontré des problèmes qui ce sont avérés êtres dû au fait qu’il y avait deux systèmes de fichiers dont l’UUID étaient le même

#16

Bien sûr, mais seul le clonage d’un disque ou d’une partition peut aboutir à ce résultat. Toutes les méthodes de sauvegarde n’impliquent pas le clonage des partitions. Par exemple la création d’un fichier image ou d’une archive.

#17

[quote=“PascalHambourg, post:16, topic:72573”]
Bien sûr, mais seul le clonage d’un disque ou d’une partition peut aboutir à ce résultat. …
[/quote]Tout-à fait d’accord : j’avais oublié de spécifier qu’il s’agissait d’une copie par clonage d’une partition formatée, et non du contenu du système de fichiers de cette partition.

=======
Ayant constaté qu’avec le clonage, je rencontrais ce problème de confusion dû à la présence de deux systèmes de fichiers ayant le même UUID, j’ai repris mes vielles habitudes qui consistaient plutôt à créer avec dd un fichier copie de la partition (juste après avoir réduit, avec GParted, la taille de la partition à copier).

#18

j’ai recupéré mon ssd 240GB qui était sur un portable de 2007 et remis l’ancien disque sur celui-ci (portable)
en fouillant j’ai trouvé une clé usb de 32GB
pour l’instant je vais installer depuis la clé
à moi de trouver le bon Jessie 4.9.0 sans passer par la 3.16
JB

#19

Ça a vraiment un intérêt, sur une installation destinée à un usage a priori standard, de mettre /var, /tmp… sur des partitions dédiées ?
Personnellement, j’ai toujours tout laissé dans / et je ne m’en suis jamais plus mal porté.

En outre, depuis que j’ai toujours plusieurs linux installés, je conserve même /home dans /.

En revanche, j’ai une partition de données (pas les configurations, qui restent dans les /home respectifs) qui contient Documents, Images, Musique, etc., communs à tous les linux. Tout ça est transparent grâce à quelques bind dans /etc/fstab

#20

Bonjour,
j’ai des petits ennuis avec l’installeur de:
-rw-r–r-- 1 jb1 jb1 260046848 févr. 4 19:06 debian-8.7.1-amd64-netinst.iso
il fait “beaucoup de manips” avant de poser la question du clavier,
conséquense qwerty
pas de nom de machine,
abandon install au grub
A+
JB