root devenu trop petit pour migration vers 22.04 LTS

geole · Le 24/06/2022, à 20:10

On ne savait pas que tu avais un NAS pour déjà y mettre tes données

Il devrait être possible de regrouper les deux partitions
J'ai une petite idée sans le support d'installation en créant un autre utilisateur. J'expliquerais demain.

Pour avoir une idée de ce qui reste

sudo du -haxd2 /home 2>/dev/null | sort -hr | head -50

Bonne soirée.

Dernière modification par geole (Le 24/06/2022, à 22:10)

Qid · Le 24/06/2022, à 21:33

geole a écrit :

On ne savait pas que tu avais un NAS pour déjà y mettre tes données
Il devrait être possible de regrouper les deux partitions

Effectivement ma commande avait mis au jour ce nas qui à mon sens ne justifie pas un home séparé puisqu'en théorie les données ne sont donc pas stockées dans le home mais soit dans l'autre disque dur soit dans le nas... Quant-à Steam et en fait n'importe quelle application c'est très facile de le déplacer en lui faisant croire qu'il est toujours au même endroit : c'est le principe des liens symboliques et perso c'est entre autre comme ça que j'ai déplacé mon profil thunderbird sur ma partition data que ce soit pour la version que j'ai en snap ou en deb : elles pointent toutes deux au même endroit...

Laadna · Le 25/06/2022, à 01:12

benoit@kubuntu:~$ sudo du -haxd2 /home 2>/dev/null | sort -hr | head -50
143G    /home/benoit
143G    /home
93G     /home/benoit/.steam
15G     /home/benoit/GOG Games
11G     /home/benoit/Images
8,4G    /home/benoit/Documents
6,6G    /home/benoit/.local
3,5G    /home/benoit/.cache
3,0G    /home/benoit/.wine
1,8G    /home/benoit/snap
1,2G    /home/benoit/.mozilla
796M    /home/benoit/.config
607M    /home/benoit/.install
204M    /home/benoit/.PlayOnLinux
30M     /home/benoit/.xsession-errors
8,5M    /home/benoit/.mbwarband
7,3M    /home/benoit/.ts3client
1,6M    /home/benoit/.thunderbird
116K    /home/benoit/libpng12-0_1.2.54-1ubuntu1_amd64.deb
76K     /home/benoit/.pki
64K     /home/benoit/Bureau
60K     /home/benoit/.audacity-data
36K     /home/benoit/virtual-drives
32K     /home/benoit/Steam
28K     /home/benoit/.kde
28K     /home/benoit/.bash_history
20K     /home/benoit/.sane
16K     /home/lost+found
16K     /home/benoit/.face
12K     /home/benoit/.psensor
12K     /home/benoit/.multiwinia
12K     /home/benoit/.lios
12K     /home/benoit/.capy
12K     /home/benoit/.acetoneiso
8,0K    /home/benoit/.putty
8,0K    /home/benoit/.hplip
8,0K    /home/benoit/.gnupg
8,0K    /home/benoit/.gnome
4,0K    /home/benoit/.Xauthority
4,0K    /home/benoit/.wget-hsts
4,0K    /home/benoit/.smbcredentials
4,0K    /home/benoit/.screenlayout
4,0K    /home/benoit/.pulse-cookie
4,0K    /home/benoit/Public
4,0K    /home/benoit/.profile
4,0K    /home/benoit/.mtab.fuseiso
4,0K    /home/benoit/Modèles
4,0K    /home/benoit/.gtkrc-2.0
4,0K    /home/benoit/.gphoto
4,0K    /home/benoit/Downloads

Mon nas est un disque réseau très lent en accès et en écriture, pour faire de longues copies ou de nombreux accès (typiquement, naviguer dans des albums photos) c'est vraiment pas pratique. C'est pour ça que je garde les documents et les images sur sda. J'ai un disque dur usb pour ce genre de sauvegarde, la copie y est beaucoup plus rapide.

Coeur Noir · Le 25/06/2022, à 04:01

Bah il reste un peu de ménage à faire par là :

11G     /home/benoit/Images
8,4G    /home/benoit/Documents
6,6G    /home/benoit/.local
3,5G    /home/benoit/.cache
1,8G    /home/benoit/snap
1,2G    /home/benoit/.mozilla

⋅ 1.2Go pour .mozilla ça me paraît étonnamment gros → tu cumules des ( anciens ) profils Firefox ?
⋅ snap, tu pourras sans doute gagner un peu d'espace temporairement via :

LANG=C snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do sudo snap remove "$snapname" --revision="$revision"; done

ça virera leurs versions n-1. Cet espace sera donc réoccupé à la prochaine mise à jour d'un snap.
⋅ cache, c'est des éléments stockés pour « accélérer » le fonctionnement de divers logiciels ( vignettes d'images, caches des navigateurs web et autres appli's… ) le vider complètement ne serait pas « dangereux » mais là aussi, c'est temporaire, les logiciels y remettront des données peu à peu.
⋅ local, et surtout ../share, là faut être plus sélectif, car ça peut contenir des config's et des paramètres opportuns pour ton utilisateur ( icones, thèmes, arrières-plans… ) Note : si tu as tendance à « personnaliser » ton système, les packs d'icônes et de thèmes ça peut représenter des Go - alors qu'on en utilise qu'un seul à la fois, à priori.
⋅ Documents et Images, y'a forcément là-dedans des choses que tu peux stocker ailleurs, voire supprimer. C'est quasiment 20Go à récupérer là.

⋅ 30Mo pour .xsession-errors ça m'étonne un peu aussi, mais là je ne saurais quoi conseiller.

Une fois quelques gigas libérés dans cette partition qui contient ton $HOME, c'est des gigas qui pourraient être réattribués à la partition qui contient / la racine de ton système.
Agir sur le partitionnement d'un système et ses supports est toujours une opération à risques : au préalable, une sauvegarde fiable des données que tu juges importantes est une prudence minimale incontournable.

___________________

ncdu c'est vachement bien → https://forum.ubuntu-fr.org/viewtopic.php?id=1761411 → et ça permet de faire une partie de ce ménage.

ncdu -x /

ne « scrutera » ( en lecture seule ) que les dossiers sur la même partition que / ( autrement dit ne comptabilisera pas des montages dans /media, /mnt ou ailleurs. )
alors qu'un

sudo ncdu -x /

est à manier avec la plus grande précaution : là tu peux aussi effacer des éléments côté système, puisque lancé en tant que l'utilisateur root : ncdu demande confirmation avant d'effacer MAIS c'est une suppression définitive qui ne passe par aucune corbeille, attention.

ncdu ~

si on veut scruter le répertoire personnel $HOME ( = le dossier à ton nom dans le dossier système /home ). Puisque lancé par toi, chez toi dans ton répertoire perso à toi, là tu peux aussi effacer, tu n'es pas qu'en lecture. C'est la touche « D » comme delete pour supprimer un élément.
Les liens symboliques sont indiqués par un @ et ne sont pas « comptabilisés ».
Si présence de montages dans ton $HOME préférer alors

ncdu -x ~

qui du coup ne comptabilisera pas non plus ce qui est stocké sur une autre partition que le $HOME scruté.

Exemple :

ncdu 1.15.1 ~ Use the arrow keys to navigate, press ? for help                                                                  
--- /home/django ---------------------------------------------------------------------------------------------------------------
    2,9 GiB [##########] /.cache		# Inévitable pourtant installation récente, à peine 3 semaines.                                        
  358,9 MiB [#         ] /.local
  287,0 MiB [          ] /.mozilla		# Pourtant il y a 3 profils Firefox actifs.
  149,3 MiB [          ] /.thunderbird
   95,2 MiB [          ] /.config
  732,0 KiB [          ] /snap			# Je n'ai aucun snap installé. Même pas Firefox.
   76,0 KiB [          ] /.pki
   36,0 KiB [          ] /.tor-browser
   24,0 KiB [          ] /.var
   16,0 KiB [          ]  .bash_history
   12,0 KiB [          ] /.waterfox
   12,0 KiB [          ] /.gnupg
e   4,0 KiB [          ] /.themes			#   Note les e en début de ligne :
e   4,0 KiB [          ] /.ssh				#   signifient que ces dossiers sont
e   4,0 KiB [          ] /.gphoto			#   vides ( empty ).
    4,0 KiB [          ]  .bashrc
    4,0 KiB [          ]  .profile
    4,0 KiB [          ]  .bash_aliases
    4,0 KiB [          ]  .bash_logout
    4,0 KiB [          ]  .lesshst
    4,0 KiB [          ]  .hidden
@   0,0   B [          ]  Musique		#   Note les @ en début de ligne :
@   0,0   B [          ]  Téléchargements	#
@   0,0   B [          ]  Documents		#   Les « dossiers usuels » de mon utilisateur django…
@   0,0   B [          ]  Modèles		#
@   0,0   B [          ]  Vidéos		#   …sont des liens symboliques qui ciblent une autre partition.
@   0,0   B [          ]  Images		#
@   0,0   B [          ]  Bureau		#   Ce $HOME est à la racine du système, dans /home, pas sur une autre partition.
    0,0   B [          ]  .sudo_as_admin_successful
 Total disk usage:   3,8 GiB  Apparent size:   3,6 GiB  Items: 62815

Dernière modification par Coeur Noir (Le 25/06/2022, à 04:34)

Coeur Noir · Le 25/06/2022, à 04:25

↑ Là je n'ai évoqué que ton répertoire personnel, dans le but de récupérer de la place et rétrécir ta partition pour des $HOME séparés et réattribuer cet espace à la partition racine.

Côté système ce qui prend de la place c'est principalement : l'installation de logiciels, qui impactent traditionnellement les dossiers /usr/{lib,bin} et plus récemment /var/lib.
Si tu as installés des logiciels dont tu te ne sers plus ou pas, désinstalle-les ( via logiciels, synaptic ou commande sudo apt purge logiciel ) et ça allègera ↑ ces dossiers.
L'autre piste côté système, c'est les « journaux », les « logs » dont on peut limiter la taille, forcer la purge, la « rotation ».
Chez moi, install' récente donc, c'est déjà 1Go et 49 éléments de données dans /var/log/journal.

Dernière modification par Coeur Noir (Le 25/06/2022, à 04:38)

Qid · Le 25/06/2022, à 09:30

Laadna a écrit :

Mon nas est un disque réseau très lent en accès et en écriture, pour faire de longues copies ou de nombreux accès

Tsss... Entre le second disque interne en qui tu n'as pas confiance et le nas qui est trop lent ça commence à faire beaucoup de support de stockage qui ne servent à rien... N'empêche qu'en attendant il va bien falloir que tu acceptes de faire du ménage pour que tu ais de nouveau suffisamment d'espace sur ton système pour que celui-ci soit utilisable dans de bonnes conditions

Laadna · Le 25/06/2022, à 10:06

Coeur Noir a écrit :

...

Dans .mozilla, le coupable c'est ~/.mozilla/firefox/7ixtdyk6.default-release/storage/default/ : quasiment 1 go de dossiers portant des intitulés de sites web visités, avec dedans un dossier vide ls et un fichier .metadata-v2 avec une seule ligne de texte (l'url du site avec un formatage qui fait penser à du utf-8). J'imagine que ça peut jarter ?
Par exemple le premier dossier intitulé http+++192.168.1.1, le fichier dedans indique juste (je ne peux pas copier ici cette ligne de texte, j'imagine à cause des caractères). Et tous les autres sont pareils.

Je ne vois pas d'autre profil stocké.

Dans .local, le plus gros dossier de loin c'est ~/.local/share/mediaindex/ qui contient des milliers de fichiers d'1 ou 2 mo :

Ensuite j'ai ~/.local/share/lutris/runners/wine/ :

Lutris est une interface graphique pour faire tourner des jeux 3d via wine.

Images et Documents ça peut temporairement dégager, le temps de la manipulation. Je vais de toutes façons les sauvegarder ailleurs, comme tu l'indiques, par sécurité.

Dernière modification par Laadna (Le 25/06/2022, à 10:08)

geole · Le 25/06/2022, à 10:43

Bonjour
Je te rappelle ma proposition de regrouper les deux partitions.
J'avais noté initialement
143G /home/benoit
On a maintenant identifié les 4 plus gros répertoires

143G    /home
93G     /home/benoit/.steam
15G     /home/benoit/GOG Games
11G     /home/benoit/Images
8,4G    /home/benoit/Documents

L'idéal serait que tu disposes d'un support d'installation idéalement en version 22.04
Ce qui te permettrait de savoir si cette version est compatible avec ton ordinateur et de le faire depuis ce support.

Cependant tu peux le faire avec la partition actuelle.
Voici la façon de réaliser.
1) Installer gparted si ce n'est pas déjà fait
2) Dupliquer la ligne décrivant le home
3) Dans une des duplications ajouter le caractère # en début de ligne afin de la commenter
4) Dans l'autre duplication, remplacer le mot home par le mot data afin d'avoir un autre point de montage
5) Rebooter
6) Un home tout neuf sera recréé ( action testée en 20.04) . il sera alloué au premier utilisateur trouvé dans /etc/password.
7) Ne pas s'inquiéter du message d'erreur disant que le fichier .dbus est absent.
8) Constater que le clavier est anglais et que la commande setxkbmap le laisse en anglais.
9) Lancer gparted et rétrécir au maxima par la gauche la partition /data (à démonter)
10) Agrandir au maxima la partition /
11) Remonter la partition /data
12) Commencer à "déplacer" par la commande mv répertoires et fichiers de la partition /data dans le répertoire /home

On ne pourra pas transférer le gros répertoire d'un seul coup, Il faudra alors le découper
Peux-tu dire comment est constitué ce répertoire
sudo du -haxd2 /home/benoit/.steam 2>/dev/null | sort -hr | head -50

En fait, la partition home fait 195 go. On dispose donc d'un espace libre de 195-143= 52 go.
Ajoutons les 2 go de la racine, on obtient seulement un espace maxima de manoeuvre de 54 go.

Est-tu certain que ton vieux disque ou un disque externe ne peut pas héberger temporairement le répertoire steam le temps de la manipulation?

Dernière modification par geole (Le 25/06/2022, à 10:56)

Coeur Noir · Le 25/06/2022, à 21:24

Laadna a écrit :

Images et Documents ça peut temporairement dégager, le temps de la manipulation. Je vais de toutes façons les sauvegarder ailleurs, comme tu l'indiques, par sécurité.

Oui c'est bien l'idée : « retirer » temporairement ( ou définitivement ) ce qui peut l'être afin d'avoir la marge de manœuvre suffisante pour ré-organiser les partitions, voire mettre à niveau le système, voire en installer un nouveau à côté de l'ancien - tu réimporteras, ou partageras, ce qui te plaît ensuite ( depuis des sauvegardes, ou depuis tes partitions « internes » ).

Dans .mozilla, le coupable c'est ~/.mozilla/firefox/7ixtdyk6.default-release/storage/default/ : quasiment 1 go de dossiers portant des intitulés de sites web visités

Ton profil Firefox à toi c'est ~/.mozilla/firefox/7ixtdyk6.default-release et là-dedans sont stockées dans ../storage/default/ toutes les données associés aux sites que tu visites ( cookies, stockage DOM et local… )
explications en Anglais par là. Pour alléger cette partie, c'est en réglant plus finement les « Cookies et données de sites »
dans « Menu / Paramètres » de Firefox, section « Vie privée et sécurité » = about:preferences#privacy dans la barre d'adresse.
Tu peux y [ Effacer les données | Gérer les données | Gérer les exceptions ].

Pour repérer le « profil » en cours d'utilisation dans ton Firefox → Menu / Aide → Plus d'information de dépannage.

Dernière modification par Coeur Noir (Le 25/06/2022, à 21:28)

Coeur Noir · Le 25/06/2022, à 23:01

@Geole : peux-tu préciser le but de la manœuvre que tu proposes au #33 - sans la recette technique, juste l'objectif opérationnel ?
J'ai la nette impression que tu te compliques la tâche ( et que telle qu'elle, ta description est bien trop évasive pour aider qui que ce soit. )

Pour l'instant, l'objectif à atteindre c'est de libérer de la place sur :
⋅ la partition qui contient le ou les $HOME - il y a au moins celui de benoit ( sda3 ),
⋅ la partition qui contient la racine / du système ( sda2 ).
en supprimant ou déplaçant - temporairement ou définitivement - ce qui peut l'être.

Ensuite l'idée c'est de redimensionner les partitions :
⋅ réduire la partition qui contient le ou les $HOME ( sda3 ) autant que possible ( gardons lui quelques Go libres quand même ),
⋅ pour agrandir d'autant la partition voisine qui contient la racine système ( sda2 ), d'un nombre de Go suffisants pour permettre mises à jour puis mise à niveau, éventuellement.

Sans rien faire d'autre, on peut obtenir :
⋅ une sda2 qui passerait de 27,94Go à ±52Go, et au moins 27Go d'espace libre ;
⋅ une sda3 qui elle passerait de 195,13Go à ±170Go, et au moins 10Go d'espace libre.
…espaces libres évalués d'après le message #1, c'est à dire sans prendre en compte les « nettoyages » et déplacements temporaires de données moins utiles qui auraient eu lieu entre temps.

52 Go pour une racine système ( qui ne contient pas les $HOME puisqu'ils sont sur une autre partition ) ça doit suffire pour de la mise à jour / mise à niveau.
170Go pour la partition qui contient les $HOME ( partition montée dans le dossier /home de la racine ) c'est pas fou, mais c'est déjà un peu de stockage - sachant que Laadna ne laissait dans son $HOME que Documents et Images, que ses autres dossiers usuels sont à priori sur l'autre disque dans la partition sdb1 ( montée dans le dossier système /media/deux ) ainsi que sur un NAS externe…

Je pense qu'il faut déjà parvenir à ce résultat ( avoir agrandi sda2 et réduit sda3 ).

Ensuite, plus tard Laadna pourra se questionner sur l'organisation de ses données et partitions :
⋅ est-ce qu'une partition unique sur le disque sda contenant toute la racine ( avec le ou les $HOME contenus dans le dossier /home directement ) ne serait pas suffisante ?
⋅ est-ce que le NAS ne devrait pas lui aussi être monté dès le démarrage système ( dans /media/NAS par ex. ) ?
⋅ dans le $HOME benoit est-ce que des liens symboliques en lieu et place de certains dossiers usuels ( liens qui cibleraient les dossiers utiles dans le NAS et sdb1 ) ne seraient pas suffisants ?
⋅ ou encore, faudrait-il considérer les partitions [ sda3 + sdb1 ] comme un seul emplacement virtuel qui contiendrait essentiellement les documents et médias visibles des utilisateurs ( emplacement virtuel alors monté par ex. dans /media/DATA ) tandis que le ou les $HOME resteraient sagement dans le dossier /home à la partition racine du système et ne contiendraient plus essentiellement que des fichiers et dossiers cachés de paramétrages et configurations ( entre autres lutris, steam, gog… ) ?

Des façons de faire, y'en a des tas, le tout c'est que Laadna choisisse celle qui lui convient, celle qu'il maîtrisera à ± long terme, et s'y tienne.
Changer de « méthode » sur une installation qui a du vécu nécessitera forcément de déplacer et sauvegarder beaucoup de données ( entre autre les $HOME ) afin de réorganiser un partitionnement adéquat à la nouvelle organisation.
Ce qui n'est pas vraiment la question de départ.

________________________________

Et j'ai pas vraiment fini, la suite au prochain épisode, car ce qui est proposé au #33 me chiffonne à plus d'un titre.

Dernière modification par Coeur Noir (Le 26/06/2022, à 00:12)

Qid · Le 25/06/2022, à 23:29

Je crois bien que geole était pour une partition unique et non plus un home séparé mais je n'ai pas relu la totalité des interventions depuis mon dernier passage donc j'ai peut-être raté quelque chose...

Coeur Noir · Le 26/06/2022, à 00:38

HS pour Geole et Qid

Bah oui moi aussi j'ai peut-être raté quelque chose, mais même s'il s'agit d'une partition unique, la procédure au #33 ne le permettra pas, faute de place, faute d'une chronologie adaptée des opérations.

geole a écrit :

2) Dans le fichier /etc/fstab dupliquer la ligne utilisant le home le dossier /home comme point de montage
3) Dans une des duplications ajouter le caractère # en début de ligne afin de la commenter ( annule le montage d'une partition dans /home = libère le dossier /home qui n'est plus un point de montage mais redevient un dossier « ordinaire », à ce moment là, vide )
4) Dans l'autre duplication, remplacer le chemin /home par le chemin /media/DATA afin d'avoir un autre point de montage dont il faut préalablement créer le dossier ( qui servira dorénavant comme point de montage pour la partition précédemment montée dans /home )

soit fin du 4) la création du dossier /media/DATA via

sudo mkdir /media/DATA          # pas besoin de changer ses droits et permissions, il contiendra le ou les anciens $HOME qui ont déjà des droits et permissions adéquats.

Ensuite en 5) il ne faut surtout pas rebooter mais lancer une relecture du fstab via

sudo mount -a

afin que les nouveaux montages s'effectuent. Les vérifier, par ex. via :

lsblk -fe7 -o +size

ou en listant le contenu des points de montage

ls -la /home		# qui devrait être vide ( à moins que par le passé il ait déjà servi à accueillir des $HOME directement… )
ls -la /media/DATA	# qui devrait montrer le ou les $HOME *anciennement* montés dans /home

Si c'est bien le cas, on ne reboote toujours pas, pas encore, car…

6) Un home tout neuf sera recréé ( action testée en 20.04) . il sera alloué au premier utilisateur trouvé dans /etc/password.

Des $HOME tout neufs seront recréés ( = un dossier au nom de chaque $USER dans le dossier /home ). Ils seront alloués à chaque utilisateur d'uid ≥ 1000 et ≤ 9999 trouvés dans /etc/passwd. La vérification de certains éléments des $HOME n'a lieu que lorsqu'un utilisateur lance sa session ( qu'elle soit graphique ou en console → XDG ) MAIS si le système a vu des utilisateurs enregistrés dans /etc/passwd il a besoin que les dossiers $HOME correspondants existent assez tôt dans le démarrage pour quelques « bricoles » : dbus, xsession, le clavier, la langue…
Donc pour éviter les problèmes 7 et 8, avant de rebooter, il faut d'ores et déjà créer le $HOME de l'utilisateur dans le dossier /home :

sudo mkdir /home/$USER			# crée un dossier au nom de l'utilisateur de la session courante
sudo chown $USER:$USER /home/$USER	# attribue à ce dossier les propriétaires ( utilisateur et groupe ) de l'utilisateur de la session courante

On vérifie par un

ls -la /home    # qui doit montrer un dossier benoit appartenant à benoit:benoit avec droits rwxr-xr-x ( ou rwxr-x--- selon version d'Ubuntu. )

Si benoit doit créer d'autres $HOME pour d'autres utilisateurs il ne devra plus utiliser la variable $USER
mais directement les noms des utilisateurs concernés dans les chemins des dossiers /home/<tel_utilisateur>,
et leurs uid associés dans la commande chown ( 1001:1001 ou 1002:1002 ou… au lieu de $USER:$USER )
Arrivé là, a-y-est, on peut ( enfin ! ) redémarrer le pc.

Que se passera-t-il ?
⋅ benoit lance sa session. Elle est toute neuve, toute fraîche, paramétrages par défaut comme sortie d'usine.
⋅ dans son répertoire personnel $HOME = /home/$USER = /home/benoit, il y a les dossiers usuels ( Bureau, Documents, Images, etc ) vides.
⋅ $HOME = benoit est un dossier dans le dossier /home. Tout cela se trouve donc à la racine de la partition système sda2.
⋅ en naviguant via l'explorateur de fichiers dans DATA ( autres emplacements → ordinateur → media → DATA ) l'utilisateur benoit trouve là aussi un dossier benoit ( qui lui appartient ) situé, lui, dans la partition sda3, dorénavant montée dans /media/DATA. Avant toutes ces manipulations, elle était montée dans /home. C'est « l'ancien » $HOME de benoit.

Ici on n'a absolument pas changé la taille des partitions.
sda2 fait toujours dans les 27 Go et sda3 dans les 195 Go.
On a juste changé l'emplacement de montage de la partition sda3 ( c'était /home avant, maintenant c'est /media/DATA ).

Donc là, il ne faut surtout pas s'amuser maintenant à importer beaucoup de données dans ce [ $HOME = le dossier /home/benoit à la racine du système ], y'a pas la place !

Là il faut absolument ( avec un outil de partitionnement ) :
⋅ réduire sda3, en lui gardant un peu d'espace libre quand même, puis la déplacer vers la droite
ET
⋅ étendre sda2 vers la droite, pour couvrir l'espace libéré par la réduction de sda3
ET
⋅ tout ça après avoir fait les ménages / nettoyages / déplacements de données déjà évoqués.
Car l'idée de base c'est un manque de place dans la racine au cas où Laadna voudrait mettre à niveau son système.

Enfin, sda3 contient ( toujours ) l'ancien $HOME benoit qui héberge une partie de ses documents et médias visibles mais aussi des éléments cachés de configuration et paramétrages.
Pendant que les dossiers usuels de benoit dans son $HOME à la racine sda2 du système sont toujours vides.

Là c'est quoi la stratégie ? On « se sert » de sda3 tel quel comme d'une partition de données personnelles visibles séparée de la racine ? Ou on se dit qu'on va tout remettre dans le $HOME à la racine de sda2, beaucoup trop petit pour l'instant ?
Dans le premier cas on ne touche plus au partitionnement ( qu'on vient de redimensionner ) mais il y a des données ( cachées ) à déplacer, d'autres ( visibles ) à « lier symboliquement ».
Dans le second cas, il faut sauvegarder ailleurs toutes les données contenues dans sda3, puis supprimer sda3, puis étendre sda2 sur tout l'espace libéré pour que cette partition couvre tout le disque, puis réimporter aux bons endroits du $HOME les données sauvegardées ( visibles comme cachées ).

Les 2 méthodes sont complètement envisageables mais chacune avec des « actions » différentes, un temps à y consacrer différent, des avantages et inconvénients différents, etc.

Si le but c'était d'obtenir au final une partition sda2 pour le système entier, y'a pas besoin de ce chemin tortueux avec création d'un nouveau $HOME ou de montage dans data !
1⋅ on sauvegarde ailleurs les données de sda3 ( le $HOME de benoit )
2⋅ on annule ou enlève du fstab le montage de sda3 dans /home,
3⋅ on démonte sda3, ou sudo mount -a ( on vérifie qu'on a bien ce qu'on croit : un dossier /home vide )
4⋅ suppression de sda3, agrandissement de sda2 sur tout le reste du disque,
5⋅ coller dans /home le $HOME de benoit précédemment sauvegardé,
6⋅ redémarrer et constater la magie.

…mouais, ce que j'ai peut-être raté, c'est que certaines opérations d'agrandissement des partitions ne seraient pas faisables depuis le système en cours de fonctionnement ?
Il me semble que cela ne pose plus problème quand il s'agit seulement d'agrandir la partition racine - sans doute plus délicat s'il s'agit de la déplacer complètement ( bornes début et fin, ici on ne touche qu'à la borne de fin. ).

Fin du HS

Dernière modification par Coeur Noir (Le 26/06/2022, à 01:48)

geole · Le 26/06/2022, à 10:28

Bonjour
Les principes
Initialement, comme tout le monde, je pense, j'ai proposé de booter avec un support d'installation pour rétrécir la partition contenant le répertoire /home par son début de 10 Go et d'allouer ces 10 GO à la partition racine .
Cette solution résout le problème de manque de place disque actuel.

Cependant, puisqu'il y a deux partitions, il arrivera un moment où l'une n'aura plus de place et l'autre encore de la place, Donc ce n'est pas le pérou, D'autant plus qu'avec une partition home séparée, un jour, il y aura un problème de démarrage de boot suite à un mauvais arrêt.
D'où l'idée nouvelle de regrouper les deux partitions. Comme cela lorsqu'il n'y aura plus de place, Il n'y aura plus de place nulle part!
Habituellement, la réalisation se fait avec un support d'installation.
Habituellement, on sauve les données ou un maxima de données ailleurs afin de permettre une réalisation simple.

Comme il semble que cette solution ne puisse pas pas être mise en oeuvre, j'ai proposé la solution suivante décrite rapidement ci-après
1) Créer un home tout neuf afin de pouvoir lancer le rétrécissement maxima de l'ex-home
car dans l'état actuel, gparted ne sait pas rétrécir une partition en cours d'utilisation.....
2) Rétrécir au maxima l'ex-home,
De mémoire, cette partition fait 180 Go avec 140 go d'utilisés, Donc au grand maxima 40 go sont libérables et ré-injectables dans la racine.
On peut alors y transférer 40 Go. Donc cette action serait à faire 4 fois. Comme les partitions sont stockées dans un SSD, cela sera moins lent qu'avec un disque dur

J'ai noté l'idée de commencer par les répertoires commençant par un point (à l'exception du répertoire .steam) afin d'avoir le plus rapidement un logiciel pleinement opérationnel.

J'ai aussi demandé le contenu de ce gros répertoire .tseam afin de s'assurer qu'il n'y a pas un fichier dont la taille serait supérieure à 40 Go car il faudrait alors découper ce fichier en morceaux....

J'ai présenté tout cela afin de faire comprendre que ce n'était pas simple et qu'il était certainement préférable de déplacer temporairement ailleurs le répertoire .steam qui est le problème.

Je pense que cette fois-ci c'est clair.

Dernière modification par geole (Le 26/06/2022, à 10:31)

Laadna · Le 26/06/2022, à 17:10

Coeur Noir a écrit :

[...]
Ensuite, plus tard Laadna pourra se questionner sur l'organisation de ses données et partitions :
⋅ est-ce qu'une partition unique sur le disque sda contenant toute la racine ( avec le ou les $HOME contenus dans le dossier /home directement ) ne serait pas suffisante ?
⋅ est-ce que le NAS ne devrait pas lui aussi être monté dès le démarrage système ( dans /media/NAS par ex. ) ?
⋅ dans le $HOME benoit est-ce que des liens symboliques en lieu et place de certains dossiers usuels ( liens qui cibleraient les dossiers utiles dans le NAS et sdb1 ) ne seraient pas suffisants ?
⋅ ou encore, faudrait-il considérer les partitions [ sda3 + sdb1 ] comme un seul emplacement virtuel qui contiendrait essentiellement les documents et médias visibles des utilisateurs ( emplacement virtuel alors monté par ex. dans /media/DATA ) tandis que le ou les $HOME resteraient sagement dans le dossier /home à la partition racine du système et ne contiendraient plus essentiellement que des fichiers et dossiers cachés de paramétrages et configurations ( entre autres lutris, steam, gog… ) ?

Je peux déjà apporter des éléments de réponse, des fois que s'occuper de cela en même temps que la migration soit possible/souhaitable. Comme dit plus haut, ce n'est pas un problème urgent : je préfère prendre le temps de voir et réfléchir à l'opération la plus sûre et la plus simple sur le long terme.

Je sépare root et home depuis des années, car cela me permet de réinstaller un système sans avoir besoin de reparamétrer-sauvvegarder-importer outre mesure, et de ne rien perdre en documents et paramétrages si le root perd les pédales. Il m'a été dit ici que ce n'est désormais plus nécessaire car le home n'est pas écrasé en cas de réinstallation du système. Si c'est confirmé (mais ça me semble contre-intuitif, je veux bien des détails) je n'ai effectivement plus aucune nécessité à séparer les deux et cela me semble la solution la plus simple sur le long terme (devoir allouer de l'espace à une partition sans savoir comment évolue le besoin en espace libre est un exercice compliqué).

Le NAS est déjà monté dès le démarrage, via une entrée dans /etc/fstab :

//192.168.1.20/Volume_1 /media/nas      cifs    _netdev,user,vers=1.0,credentials=/home/benoit/.smbcredentials  0       0

J'ai créé des liens symboliques entre des dossiers du NAS et le home (musique, vidéo) pour que l'accès à ces dossiers soit transparent.

Pour déplacer d'autres dossiers de sda (typiquement, ceux qui contiennent des jeux : .steam et GOG Games en particulier), j'ignore comment ils vont réagir avec cette surcouche de bricolage. Steam est un environnement délicat, la plupart des jeux qui tournent via wine ou lutris aussi. C'est déjà suffisamment compliqué de trouver une aide efficace quand je rencontre un soucis de portage, j'aimerais m'épargner une couche supplémentaire de trucs à expliquer/contourner/traiter. D'autant qu'en l'état je n'ai pas vraiment de problème, et assez d'espace pour que cette façon de procéder continue de fonctionner (même si c'est vrai qu'avec l'inflation des espaces disques demandé par certains jeux, je ne suis pas à l'abri d'un jeu steam qui va déborder de l'espace disque restant...).
Pour donner une idée de pourquoi je préfère éviter de toucher à ça : les jeux GOG supportent normalement très bien d'être installés ailleurs que dans le répertoire par défaut. Sauf qu'une fois, j'ai un jeu qui a refusé de fonctionner en étant installé dans .install... Et qui une fois dans son dossier par défaut s'est comporté normalement. Ça fait partie des myriades de trucs qui ne devraient pas poser de problème mais qui en posent quand même, et comme quand je vais chez le médecin, la moitié des personnes confrontées au problème préfèrent le nier plutôt que d'admettre que c'est incompréhensible mais bel et bien là. Donc c'est la solution pas très élégante mais très efficace pour que ce problème ne surgisse jamais.
Dans sdb j'ai aussi des jeux installés (ceux qui sont moins pénibles, encapsulés dans leur propre instance de wine par exemple). En fait c'était mon idée de départ, de mettre tous les jeux sur sdb : réserver sda pour le système et les données importantes à accès régulier (documents), que je ne veux pas avoir à sauvegarder toutes les semaines et pour qui l'accès via le NAS est un peu pénible. Sauf que les facéties de portage et l'intransigeance de steam (qui ne s'installe que dans ~/.steam) m'ont finalement conduit à en saupoudrer un peu partout (sda étant un SSD, je ne pouvais pas non plus tout y mettre).

Ceci dit je viens d'aller faire un tour sur ldlc et il semble que mes références de prix de disques durs datent un peu, je viens de voir des disques de 2 To à un prix correct (pour mon budget). Et il se trouve que j'ai même la prise sata/alim pour brancher cet éventuel troisième disque sans devoir en débrancher un autre. Il me semble que ça simplifierait tout : à la fois les manipulations que vous envisagez pour que je puisse migrer, et l'inflation future du root qui pourrait donc s'étaler de tout son long dans sda sans emmerder qui que ce soit (sauf steam, mais j'ai quand même pas mal de marge je pense avant que ça ne devienne conflictuel entre les deux). Comme sdb commence à accuser son âge (il doit avoir bien quinze ans et je ne l'ai pas beaucoup reposé), ce n'est de toutes façons qu'une question de temps avant qu'il me lâche.

Dernière modification par Laadna (Le 26/06/2022, à 17:12)

geole · Le 26/06/2022, à 17:27

Avec ces précisions de l'arrivée d'un troisième disque et la contrainte de ./team, tu pourrais envisager de mettre toute la partition /home dans ce troisième disque par un simple copier/copier avec gparted en live-USB (à créer lorsque la version 22.04.1 sera disponible) après y avoir créé une table de partition GPT.
Comme la version 22.04 ne sera certainement disponible qu'en Aout, tu as encore quelques semaines.

ou alors tu regroupes quand même le home afin d'avoir de la performance d'accès si c'est nécessaire en ne laissant que les snap et .steam car .thunderbird peut être déporté.

Dernière modification par geole (Le 26/06/2022, à 17:34)

Coeur Noir · Le 26/06/2022, à 18:10

[edit : ça arrive un peu tard dans la discussion, du coup]

Ok ! L'idée c'est bien d'obtenir au final une partition sda2 pour le système entier qui couvre tout le ssd.

Geole a écrit :

Donc cette action serait à faire 4 fois.

On peut justement éviter cette répétition s'il est possible de sauvegarder ailleurs toutes les données de sda3.

Pour arriver plus vite au même résultat ( soit une partition sda2 qui couvre tout le ssd, et le $HOME de benoit inclus dans le dossier /home de cette partition sda2 ) :

1⋅ depuis le système installé en cours d'utilisation { et, important, en n'y faisant rien d'autres que ces opérations }
1⋅a) sauvegarder ailleurs ( par ex. un DD externe en EXT4 ) les données de sda3, vérifier que cette sauvegarde est exploitable, fiable.

sudo   cp   -rav   /home/*   /media/benoit/uuid_ou_label_du_dd_externe_en_ext4

1⋅b) démonter sda3 et supprimer sda3 ( par ex. via gparted )
1⋅c) enlever de fstab le montage de sda3 dans /home { important }
1⋅d) vérifier l'état du dossier /home à ce moment-là : il doit être vide
1⋅e) créer dans /home un $HOME pour benoit

sudo mkdir /home/benoit
sudo chown benoit:benoit /home/benoit

1⋅f) éteindre le pc.

2⋅ depuis une session live-usb, en mode essayer sans installer.
2⋅a) installer gparted
2⋅b) y agrandir sd×2 autant que possible vers la droite { sd×2 ou tout autre nom qu'aura pris ce disque, attention ! On parle de la partition qui contient la racine du système installé sur le ssd, qui fait dans les 28Go } soit tout le reste du disque ce qui donnerait une partition mesurant dans les 223Go.
2⋅c) monter sd×2 depuis l'explorateur de fichiers, qui devrait alors apparaître dans /media/ubuntu/uuid_ou_label_partitions_sd×2
2⋅d) connecter le DD externe de la sauvegarde qui devrait alors monter dans /media/ubuntu/uuid_ou_label_DD_externe
2⋅e) rapatrier les données de benoit sauvegardées sur le DD externe vers son $HOME sur sd×2 :

cd /media/ubuntu
sudo   cp   -rav   uuid_ou_label_DD_externe/benoit/*   uuid_ou_label_partitions_sd×2/home/benoit

…prendra des minutes, patience ( l'option v dans la commande cp rend visible, verbeux, le déroulé de la copie. )
2⋅f ) quand c'est fini, quitter la session live-usb et redémarrer le pc normalement.

Si tout s'est bien passé, on a :
⋅ un système qui démarre,
⋅ une session benoit avec toutes ses affaires,
⋅ une partition sda2 qui contient toute la racine système et qui s'étend sur tout le ssd.

Sauf que… pas sûr que c'est le souhait de Laadna :

Laadna a écrit :

Nota. Il n'y avait pas de raison d'avoir une partition hébergeant le répertoire home si c'est pour la stocker sur le même disque.
Fut un temps, j'avais régulièrement des problèmes qui nécessitaient de réinstaller la distribution. Séparer /home et / rendait l'opération bien moins pénible (restauration des configuration de logiciels, sauvegarde auto des documents, etc).

Je ne défends pas spécialement la technique de la « partition séparée pour les $HOME » mais dans ces contextes précis elle semblait plutôt judicieuse :
⋅ réinstaller la même version et variante de système dans la partition racine, sans aucun impact sur les $HOME
OU
⋅ mettre à niveau le système installé dans cette racine ( passer de 20.04 à 22.04 sans réinstaller, tout en conservant les données et paramètres des utilisateurs. )

____________________________

Un peu hors-sujet : cette technique de la « partition séparée pour les $HOME » a ses limites :
1⋅ la plupart du temps les « couacs » ne se situent pas dans le système mais dans les éléments cachés des $HOME. Donc ré-employer ces éléments cachés potentiellement boiteux dans un système « neuf » ne réparera rien.
2⋅ Dans le même ordre d'idées, si on réinstalle ( from scratch, sans passer par une mise à niveau ) une autre version du même système, les éléments cachés des $HOME ne seront plus forcément adaptés ( puisqu'ils dépendent du système et versions logicielles de l'installation initiale. )
3⋅ c'est donc encore « plus vrai » lorsqu'il s'agit d'installer un système très différent ( version, distribution, environnement de bureau… ) les éléments cachés des $HOME initiaux ne seront plus du tout adaptés au nouveau système.

Quand on est dans ce genre de contextes ( multi-boot, beaucoup d'utilisateurs, des données utilisateurs partagées entre plusieurs machines… on est d'accord c'est des cas moins ordinaires mais pas rares ) il vaut mieux alors
« isoler » seulement les données visibles de ces utilisateurs ( leurs documents et médias divers qui eux sont neutres et ré-employables à peu près n'importe où )
et laisser les $HOME à la racine de leurs systèmes respectifs, les données visibles font alors l'objet de liens symboliques vers leur(s) cible(s) hors partition système.

Dernière modification par Coeur Noir (Le 26/06/2022, à 18:21)

Coeur Noir · Le 26/06/2022, à 18:40

Laadna a écrit :

Il m'a été dit ici que ce n'est désormais plus nécessaire car le home n'est pas écrasé en cas de réinstallation du système. Si c'est confirmé (mais ça me semble contre-intuitif, je veux bien des détails)

À vérifier - illustrations ou doc's bienvenus - les installateurs des versions les plus récentes d'×buntu proposent quelque part un choix « réparer » qui va ré-écrire la partie système sans toucher à /home.

je n'ai effectivement plus aucune nécessité à séparer les deux et cela me semble la solution la plus simple sur le long terme (devoir allouer de l'espace à une partition sans savoir comment évolue le besoin en espace libre est un exercice compliqué).

Ça peut être ça ! Tout le ssd pour ton système qui contient « classiquement » les $HOME dans /home et puisque tu pratiques déjà les liens symboliques, au besoin c'est tous les dossiers usuels visibles qui deviennent des liens symboliques vers d'autre(s) partitions(s) pour ne laisser dans les $HOME sur le ssd que les éléments cachés ( qui chez toi prennent de la place : les données des jeux, .steam, .wine et autres « encapsulations » ).
Ça se trouve ça te laisse la place de remettre tous tes jeux sur le sdd ( potentiel gain de performances ? )

__________________________

au cas où… c'est hors-sujet mais puisque c'est un élément qui a motivé la question initiale :

Concernant ~/.steam que tu voulais déplacer, ça a pourtant l'air faisable :
https://www.reddit.com/r/linux_gaming/c … r_in_home/ ⋅ https://steamcommunity.com/app/221410/d … 457410420/ ⋅ https://askubuntu.com/questions/226884/ … 654#257654 ( plus ancien ).
⋅ la destination doit porter les droits et permissions adéquats ( je suppose que Steam installe en tant que root en demandant le mot de passe ? ) soit un dossier appartenant à root:root en rwxr-xr-x
⋅ de toute façon cette manip' ( créer une nouvelle bibliothèque ) est à faire depuis l'appli' Steam ( qui je suppose crée le dossier avec les droits adéquats. )
⋅ la méthode lien symbolique ne fonctionne pas avec tous les contenus Steam donc autant l'éviter : certains crient au bug, je suppose que des composants de Steam utilisent des liens matériels - et non symboliques - qui ne référencent qu'à l'intérieur d'un même système de fichiers ( c'est un choix technique, pas un bug. )

Oui je suppose beaucoup car pas utilisateur de Steam… mais plutôt bien rôdé aux questions de droits, permissions, montages.

Dernière modification par Coeur Noir (Le 26/06/2022, à 20:14)

Laadna · Le 26/06/2022, à 18:51

geole a écrit :

Avec ces précisions de l'arrivée d'un troisième disque et la contrainte de ./team, tu pourrais envisager de mettre toute la partition /home dans ce troisième disque par un simple copier/copier avec gparted en live-USB (à créer lorsque la version 22.04.1 sera disponible) après y avoir créé une table de partition GPT.
Comme la version 22.04 ne sera certainement disponible qu'en Aout, tu as encore quelques semaines.
ou alors tu regroupes quand même le home afin d'avoir de la performance d'accès si c'est nécessaire en ne laissant que les snap et .steam car .thunderbird peut être déporté.

Je peux me passer du gain de performance offert par un SSD sur un jeu, je trouve par contre un peu dommage d'avoir un disque/partition de 200 go qui n'héberge que le root.

En fait cette discussion me fait hésiter entre réintégrer /home sur la partition système et utiliser des liens symboliques depuis le nouveau disque dur pour tout ce qui prend de la place et qui supporte bien d'être déplacé, et déplacer /home entièrement sur un second disque dur.

Dans le premier cas, j'aurai forcément un jour des jeux volumineux à déplacer/installer sur le gros disque (celui qui n'existe pas encore), en espérant qu'ils se comportent normalement. L'opération de regroupement root/home sera assez minutieuse.
Dans le second cas, j'ai un disque/partition unique pour héberger le root beaucoup trop grand (même les snap vont se retrouver sur /home, si j'ai bien suivi). Et une opération très simple en définitive (déplacer /home depuis sda3 vers sdc1 via un livecd, et basta).

J'ai quand même l'impression que si je supporte de voir un ssd aux trois quarts vide, la solution 2 parait plus durable et pratique (autant à l'usage qu'à la mise en place). Au moins je suis certain que ce problème d'espace libre ne se posera plus, ni sur le root ni sur home.

Coeur Noir a écrit :

Ça peut être ça ! Tout le ssd pour ton système qui contient « classiquement » les $HOME dans /home et puisque tu pratiques déjà les liens symboliques, au besoin c'est tous les dossiers usuels visibles qui deviennent des liens symboliques vers d'autre(s) partitions(s) pour ne laisser dans les $HOME sur le ssd que les éléments cachés ( qui chez toi prennent de la place : les données des jeux, .steam, .wine et autres « encapsulations » ).
Ça se trouve ça te laisse la place de remettre tous tes jeux sur le sdd ( potentiel gain de performances ? )

Si je fais le calcul, ces dossiers qui seraient déplaçables et accessibles via liens symboliques représentent à la louche 35 Go. Plus les 51 actuellement libres (sda2 et sda3 confondus), cela représente donc 86 Go de libres (sur un total de 223, donc 137 déjà occupés). Est-ce que ce n'est pas un peu juste pour imaginer me retrouver d'ici quelques années à devoir batailler entre les snap, les fichiers temporaires/log et autres trucs qui se remplissent régulièrement, et les jeux steam (+ ceux indéplaçables pour de mystérieuses raisons) ? Vous aviez l'air d'accord pour dire que la 22.04 et les snap allaient prendre pas mal de place supplémentaire.

Dernière modification par Laadna (Le 26/06/2022, à 19:00)

geole · Le 26/06/2022, à 19:15

Tu as bien résumé. Mais je pense que dans 10 ans, la version 22.04 tiendra encore dans un SSD de 250 GO y compris avec les snap .
cependant, en mettant tout le Home sur le disque dur, le Ssd ne sera pas vide, tu peux y créer un répertoire de premier niveau tel que /divers et y stocker quelques trucs ...

Dernière modification par geole (Le 26/06/2022, à 19:34)

Coeur Noir · Le 26/06/2022, à 20:24

Je pense que la digression est permise dorénavant
⋅ snap ou flatpak : j'allais dire oublie-les. Non pas vraiment : ils ne prennent de la place que si tu installes des logiciels dans ce format. T'es donc pas obligé.
⋅ 22.04 : par défaut la variante officielle ( ±gnome ) vient avec 2 logiciels installés en snap, le snap-store ( Logiciels ) et Firefox. Et il y en a un troisième assez classique qui n'est disponible que dans ce format ( mais pas installé par défaut ) le navigateur web Chromium.
⋅ Rien n'interdit de désinstaller ces 2 snap, pour réinstaller les mêmes logiciels dans des formats plus classiques ( gnome-software depuis les dépôts, ou l'archive autonome de Firefox depuis le site officiel Mozilla. )
⋅ Tu es sous Kubuntu apparemment, ça sera plutôt Discover, et pas gnome-software.
⋅ les fichiers temporaires/log et autres trucs qui se remplissent régulièrement → les logs, ça se limite. Le reste, ça se nettoie, y'a des utilitaires graphiques pour ça - bleachbit, stacer et d'autres - ou des commandes qui vont bien qui peuvent s'automatiser. Mais tu as le temps avant que ça devienne une urgence ( si on part du principe que ta racine système occupe dorénavant le ssd entier ).

Le résumé au #43 m'a perdu

Quel est le problème avec le ssd qui contiendrait toute la racine système, les $HOME inclus :
⋅ tu prends soin de stocker tes documents et médias ailleurs que sur cette partition système via liens symboliques vers NAS et autre(s) disque(s),
⋅ tu parviens à créer une ou des autres bibliothèques Steam ( re-voir #42 )
⋅ tu as alors : ton OS + tes logiciels « utilitaires » + ( une part de ) tes logiciels « ludiques » + les config's et paramétrages utilisateur(s) en accord avec cette version d'OS → tout ça sur le disque le plus rapide à ta disposition.

Je ne comprends pas le problème puisque ça ↑ là ça ressemble à une situation de base idéale qu'on peut résumer à :
⋅ peu ou pas de documents et médias utilisateurs dans le(s) $HOME,
⋅ seulement ~essentiellement~ des éléments techniques dans ce ssd,
⋅ et un système qui restera accessible et fonctionnel à ton utilisateur même si les ressources « externes » viennent à flancher ( NAS, disques 2 et 3… qui ne contiennent rien de « technique » vital au système. )

Manquer de place ? T'as peut-être le temps de voir venir quand même… et surtout ça semble possible d'installer les contenus Steam ailleurs ( je ne garantis rien à ce sujet mais puisque tu es un consommateur Steam, il faut absolument que tu parviennes à « créer / gérer » ces bibliothèques. )

__________________________________

Utiliser les bons termes : le dossier système /home n'est pas le répertoire personnel $HOME et Home n'a pas de signification « informatique ».
Le dossier /home ne bouge jamais et fait toujours partie de la racine système. C'est les $HOME qu'on déplace ( par ex. ici le dossier benoit qui se trouvait au départ dans sda3 et qui finira dans sda2. )
Dans un cas /home servait de point de montage aux données d'une autre partition, dans l'autre cas /home abritera directement les données, dans les 2 cas le dossier /home se trouve toujours sur sda2.

Dernière modification par Coeur Noir (Le 26/06/2022, à 22:37)

Laadna · Le 26/06/2022, à 20:57

Coeur Noir a écrit :

...
⋅ tu parviens à créer une ou des autres bibliothèques Steam ( re-voir #42 )
...

J'avais raté ton édition (intervenue après mon dernier message). C'est une fonctionnalité de Steam que j'ignorais. Ça semble donc résoudre le dernier de mes problèmes. Merci pour avoir trouvé cette info.

Coeur Noir a écrit :

Je ne comprends pas le problème puisque ça ↑ là ça ressemble à une situation de base idéale qu'on peut résumer à :
⋅ peu ou pas de documents et médias utilisateurs dans le(s) $HOME,
⋅ seulement ~essentiellement~ des éléments techniques dans ce ssd,
⋅ et un système qui restera accessible et fonctionnel à ton utilisateur même si les ressources « externes » viennent à flancher ( NAS, disques 2 et 3… qui ne contiennent rien de « technique » vital au système. )

En effet, c'est l'idéal.

Du coup, vu que vous sembliez en désaccord sur les étapes, la chronologie et la précision dans les descriptions, quel est le message de référence que je dois suivre pour fusionner /home dans le root actuel (après avoir déplacé sur le nouveau disque tout ce qui sera par la suite accessible via des symlinks, plus mes jeux déplaçables) ?

Dernière modification par Laadna (Le 26/06/2022, à 21:06)

Coeur Noir · Le 26/06/2022, à 21:28

C'est des manip's que je fais assez souvent MAIS dans mon contexte les risques sont faibles ( sauvegardes, systèmes et données utilisateurs dupliquées sur diverses machines, parfois onduleurs… ) donc au pire j'ai pas peur de faire une connerie et revenir en arrière, quitte à réinstaller. Cela pour dire : ça se trouve, par l'inertie de l'habitude, je ne vois plus là-dedans un « risque » évident !
J'invite Geole - et quiconque voudra bien - à étudier le #41 pour assurer qu'il n'y manque rien et corriger si besoin.

Ça implique de pouvoir sauvegarder ailleurs ( DD externe par ex. ) tout le contenu de ta partition sda3 - puisqu'on va la supprimer.

Déjà à y re-réfléchir, une fois la sauvegarde faite, il sera plus prudent d'agir uniquement depuis une session live-usb.
Le risque, en agissant en partie depuis le système installé, c'est que si un événement quelconque t'oblige à relancer ta session ou redémarrer le pc après l'étape 1⋅b et avant la 1⋅e bah y'a plus de $HOME, ta session aura une drôle d'allure ou un clavier qwerty… ce qui resterait complètement « réparable » depuis une live-session après coup, donc rien de « fatal » mais ça peut dérouter.

geole · Le 27/06/2022, à 09:14

Coeur Noir a écrit :

1⋅ depuis le système installé en cours d'utilisation { et, important, en n'y faisant rien d'autres que ces opérations }
1⋅a) sauvegarder ailleurs ( par ex. un DD externe en EXT4 ) les données de sda3, vérifier que cette sauvegarde est exploitable, fiable.
sudo   cp   -rav   /home/*   /media/benoit/uuid_ou_label_du_dd_externe_en_ext4
1⋅b) démonter sda3 et supprimer sda3 ( par ex. via gparted )

Bonjour.
Je serais surpris que le démontage du home en cours d'utilisation soit possible.
Je ne pense pas que cela soit une très bonne idée de sauver un /home en cours d'utilisation.
Comme la suite doit se faire en live-USB, autant tout faire en live_usb.

Coeur Noir · Le 27/06/2022, à 12:05

Je serais surpris que le démontage du home en cours d'utilisation soit possible
Oui c'est surprenant mais ça « fonctionne ».
La config' de la session est en mémoire tant que tu ne la quittes pas et, bien sûr, dès lors que tu as démonté la partition qui contient les $HOME, faut surtout pas chercher à accéder à des documents et médias, ils ne sont plus là…
D'où le : « et, important, en n'y faisant rien d'autres que ces opérations ».

Mais oui, autant tout faire depuis la live-session - faut adapter les premiers chemins du coup, puisque dans la live-session, le système installé montera dans /media/ubuntu/uuid_ou_label_partition

Coeur Noir · Le 27/06/2022, à 12:15

on peut certainement se passer du support d'installation puisque ubuntu sait agrandir sa propre partition
Ah.
Tu avais l'air de douter de cette capacité, un peu plus tôt, au #38.

Ça reste plus prudent d'agir sur des partitions « démontées » à priori. Même s'il me semble que certaines opérations ( pas toutes ) sont faisables sur des partitions en cours d'utilisation.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 24/06/2022, à 20:10

Re : root devenu trop petit pour migration vers 22.04 LTS

#27 Le 24/06/2022, à 21:33

Re : root devenu trop petit pour migration vers 22.04 LTS

#28 Le 25/06/2022, à 01:12

Re : root devenu trop petit pour migration vers 22.04 LTS

#29 Le 25/06/2022, à 04:01

Re : root devenu trop petit pour migration vers 22.04 LTS

#30 Le 25/06/2022, à 04:25

Re : root devenu trop petit pour migration vers 22.04 LTS

#31 Le 25/06/2022, à 09:30

Re : root devenu trop petit pour migration vers 22.04 LTS

#32 Le 25/06/2022, à 10:06

Re : root devenu trop petit pour migration vers 22.04 LTS

#33 Le 25/06/2022, à 10:43

Re : root devenu trop petit pour migration vers 22.04 LTS

#34 Le 25/06/2022, à 21:24

Re : root devenu trop petit pour migration vers 22.04 LTS

#35 Le 25/06/2022, à 23:01

Re : root devenu trop petit pour migration vers 22.04 LTS

#36 Le 25/06/2022, à 23:29

Re : root devenu trop petit pour migration vers 22.04 LTS

#37 Le 26/06/2022, à 00:38

Re : root devenu trop petit pour migration vers 22.04 LTS

#38 Le 26/06/2022, à 10:28

Re : root devenu trop petit pour migration vers 22.04 LTS

#39 Le 26/06/2022, à 17:10

Re : root devenu trop petit pour migration vers 22.04 LTS

#40 Le 26/06/2022, à 17:27

Re : root devenu trop petit pour migration vers 22.04 LTS

#41 Le 26/06/2022, à 18:10

Re : root devenu trop petit pour migration vers 22.04 LTS

#42 Le 26/06/2022, à 18:40

Re : root devenu trop petit pour migration vers 22.04 LTS

#43 Le 26/06/2022, à 18:51

Re : root devenu trop petit pour migration vers 22.04 LTS

#44 Le 26/06/2022, à 19:15

Re : root devenu trop petit pour migration vers 22.04 LTS

#45 Le 26/06/2022, à 20:24

Re : root devenu trop petit pour migration vers 22.04 LTS

#46 Le 26/06/2022, à 20:57

Re : root devenu trop petit pour migration vers 22.04 LTS

#47 Le 26/06/2022, à 21:28

Re : root devenu trop petit pour migration vers 22.04 LTS

#48 Le 27/06/2022, à 09:14

Re : root devenu trop petit pour migration vers 22.04 LTS

#49 Le 27/06/2022, à 12:05

Re : root devenu trop petit pour migration vers 22.04 LTS

#50 Le 27/06/2022, à 12:15

Re : root devenu trop petit pour migration vers 22.04 LTS

Pied de page des forums