SYSTEME: distupgrade manque de place, quelle stratégie ?

Support Debian
#1

Bonjour,
J’utilise wheezy sur un poste de travail et je ne peux pas me permettre le moindre problème car je suis en pleine rédaction de mon mémoire.
Le système est installé sur une partition de 9 Go sur lequel il n’y a que 738 Mo de libre (rootfs).
Mes données sont sur une partition de 760 Go dont seuls 93 Go sont utilisés (sda11).

Je sais à peu près comment faire un peu de place sur la racine, mais je suis coincé avec des applications KDE qui ne peuvent pas se désinstaller sans perdre le cœur du bureau. Et pourtant je n’en ai absolument pas besoin, c’était juste pour essayer.

Est-ce que je n’aurais pas intérêt à créer une nouvelle partition sur sda11 pour y installer jessie. Est ce que je pourrais alors lui commander d’utiliser sda11 comme /home.
J’ai vraiment besoin de cette mise à niveau pour avoir une version plus récente de biber pour LaTeX.

Merci de votre réponse.

Linux Hermes 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1~bpo70+1 (2015-04-27) x86_64 GNU/Linux

#2

La trilogie de nettoyage

sudo apt-get clean
sudo apt-get autoclean
sudo apt-get autoremove

#3

Je pense que le plus simple est de faire une sauvegarde de ton mémoire dans un coin, de faire un [mono]dd if=/dev/partionrootfs of=/media/disquebackup/rootfs.iso[/mono] pour être sûr de ne rien perdre. Ensuite, tu boot sur un live gparted, tu réduis /home et agrandis /, tu vérifies que le fstab est toujours valide (ça va changer les UUID) et tu redémarres le PC.
En théorie tu ne perdras pas de données, et au pire tu as un backup.

#4

Pardon mais est-ce bien raisonnable ?
Si la rédaction a déjà commencé, changer tout le système juste pour changer un programme me paraît aventureux surtout dans ces circonstances.
Désolé par avance pour l’inutilité éventuelle de mon intervention.

#5

[quote=“jcsm33”]Si la rédaction a déjà commencé, changer tout le système juste pour changer un programme me paraît aventureux surtout dans ces circonstances.
Désolé par avance pour l’inutilité éventuelle de mon intervention.[/quote]

Ton intervention n’est pas inutile, elle est même parfaitement légitime. Cependant, LaTeX est du genre gros, ça ne m’étonnerait pas qu’il faille dans les 2 Go de libre pour faire la mise à jour.

#6

Installe un jessie en chroot sur un disque et utilise le tex jessie comme ça (cf chroot transparent) rustique mais efficace.

#7

Pourquoi .iso ? Le système de fichiers racine n’est pas de l’ISO 9660.

Réduire la partition /home ne suffira pas, car l’espace libéré sera à la fin de cell-ci, pas à la fin de la partition racine.

Ma petite rengaine : avec LVM, le problème aurait été facilement résolu et à chaud, sans devoir lancer un autre système. A méditer pour la prochaine installation. Le système de fichiers btrfs est prometteur aussi car il permet de concaténer des partitions.

Comme jcsm33, je ne suis pas convaincu que la mise à niveau du système à un moment critique soit bien raisonnable. En dehors de cela, que contient la racine ? /var, /home, /usr sont-ils séparés ? Sinon, une façon de gagner de la place serait de les déplacer dans une autre partition.

#8

Pourquoi .iso ? Le système de fichiers racine n’est pas de l’ISO 9660.
[/quote]
Parce que ça permet de le différentier d’un fichier binaire ou autre truc sans extention.

[quote=“PascalHambourg”]

Réduire la partition /home ne suffira pas, car l’espace libéré sera à la fin de cell-ci, pas à la fin de la partition racine.

Ma petite rengaine : avec LVM, le problème aurait été facilement résolu et à chaud, sans devoir lancer un autre système. A méditer pour la prochaine installation. Le système de fichiers btrfs est prometteur aussi car il permet de concaténer des partitions.

Comme jcsm33, je ne suis pas convaincu que la mise à niveau du système à un moment critique soit bien raisonnable. En dehors de cela, que contient la racine ? /var, /home, /usr sont-ils séparés ? Sinon, une façon de gagner de la place serait de les déplacer dans une autre partition.[/quote]
On ne peut pas la réduire depuis le début ? J’ai aussi l’habitude de LVM :stuck_out_tongue:
Dans ce cas, pourquoi pas diminuer /home et puis créer deux partions de 20 Go à la fin pour y mettre /var et /usr ?

#9

Il y a d’autres extensions plus appropriées que .iso dans ce cas. J’aime bien .bin ou .img. Un nom de fichier bien explicite comme image_de_sda11 peut également être suffisant.

Les outils de redimensionnement de système de fichiers (resize2fs…) agrandissent ou réduisent à partir de la fin. Réduire à partir du début, cela revient à réduire le système de fichier et la partition (à partir de la fin) puis déplacer la partition entière. Il se peut que les outils “conviviaux” comme gparted le fassent implicitement.

C’est une possibilité parmi d’autres. /usr est souvent ce qui occupe le plus d’espace dans un système typique (en dehors de /home), mais un /usr séparé peut poser des problèmes dans certains cas particuliers s’il n’est pas monté très tôt lors du démarrage (en même temps que la racine), ce qui semble être le cas dans Debian depuis Jessie.

#10

Le /usr séparé ne pose pas de problème quand on a un initramfs : https://www.gentoo.org/support/news-items/2013-09-27-initramfs-required.html
Et ce serait quand même dommage de ne pas pouvoir de /usr séparé sous jessie…

#11

[quote=“grandtoubab”]La trilogie de nettoyage

sudo apt-get clean
sudo apt-get autoclean
sudo apt-get autoremove[/quote]
Pour les deux premières commandes : OK
Pour la troisième, précautions et test préliminaire avec ‘-s’. Cette commande a une fâcheuse tendance à vouloir supprimer des paquets qui n’ont pas lieu de l’être et ce, spécialement dans KDE.

#12

Quand on a un initramfs qui monte /usr. Vérification faite dans le changelog du paquet initramfs-tools, c’est le cas depuis Jessie (sous la pression de systemd, qui n’a pourtant rien à voir).

#13

Quand on a un initramfs qui monte /usr. Vérification faite dans le changelog du paquet initramfs-tools, c’est le cas depuis Jessie (sous la pression de systemd, qui n’a pourtant rien à voir).[/quote]
Je dirais bien que le problème est qu’on ne sait plus très bien ce qui n’a rien à voir avec systemd: systemd s’occupe du montage des partitions au début et du coup change la gestion usuelle.

As tu une opinion sur la logique de systemd et le débat (si c’est un débat) en cours?

#14

Je ne connais pas encore assez systemd et sa logique pour avoir une opinion.

Par contre le montage d’/usr dès l’initramfs va enfin me permettre de tester la fusion de /bin, /sbin et /lib avec leurs homonymes dans /usr sur une partition séparée de la racine.
Objectif : avoir le maximum de choses qui ne bougent pas sur une partition /usr qui peut être montée en lecture seule la plupart du temps (sauf lors d’apt-get, automatisable), et le minimum sur une partition racine nécessairement en lecture-écriture qui peut être sauvegardée rapidement.

#15

[quote=“PascalHambourg”]Je ne connais pas encore assez systemd et sa logique pour avoir une opinion.

Par contre le montage d’/usr dès l’initramfs va enfin me permettre de tester la fusion de /bin, /sbin et /lib avec leurs homonymes dans /usr sur une partition séparée de la racine.
Objectif : avoir le maximum de choses qui ne bougent pas sur une partition /usr qui peut être montée en lecture seule la plupart du temps (sauf lors d’apt-get, automatisable), et le minimum sur une partition racine nécessairement en lecture-écriture qui peut être sauvegardée rapidement.[/quote]
Ça serait intéressant, en effet.
Tu nous tiendras au courant de tes expériences et de la possibilité de modifier cette distribution des rôles a posteriori.

#16

[quote=“PascalHambourg”]Je ne connais pas encore assez systemd et sa logique pour avoir une opinion.

Par contre le montage d’/usr dès l’initramfs va enfin me permettre de tester la fusion de /bin, /sbin et /lib avec leurs homonymes dans /usr sur une partition séparée de la racine.[/quote]

Comment se passe la vérification de la partition /usr au démarrage si besoin? Comme pour la racine, un montage préliminaire en lecture seule puis un remontage dans un deuxième temps?

#17

Merci pour vos réponses même si j’ai du mal à tout comprendre.
Pour ce qui est de autoremove, j’ai déjà eu de mauvaises surprises.
La solution en chroot est peut être la plus sûre, mais est-ce que vous pourriez m’orienter vers une bonne explication (en français si possible) ?
De même pour placer /usr sur une partition à créer en prenant un bout de sda11, je n’ai pas compris si c’était risqué ou non.
Voici la sortie de df -h je ne sais pas si ça peut faire avancer le shmilblik :

Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 9,1G 7,9G 738M 92% /
udev 10M 0 10M 0% /dev
tmpfs 381M 1,1M 380M 1% /run
/dev/disk/by-uuid/cf4f4ec0-631f-4082-b2e3-39e94e9fc951 9,1G 7,9G 738M 92% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 2,3G 88K 2,3G 1% /run/shm
/dev/sda11 762G 93G 631G 13% /home

Merci pour vos retours.

#18

Réduire le /home pour mettre un /usr à côté n’est pas risqué avec gparted, il pense à tout pour toi.

#19

popcon-largest-unused, préconisé au Chapitre 4. Mises à niveau depuis Debian 7 (Wheezy), m’a permis de faire un gros ménage.
Voici maintenant la place disponible sur la racine :
Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 9,1G 5,7G 2,9G 67% /
Pensez vous que ce soit suffisant pour une mise à niveau ?

Connaîtriez vous une bonne documentation pour restaurer à partir d’une image comme me l’a indiqué SwordArMor

Merci

#20

Tu auras plus de précisions en lisant la doc de Arch Linux : wiki.archlinux.org/index.php/Di … disk_image