Ubuntu-fr

geole

Re : root devenu trop petit pour migration vers 22.04 LTS

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

Bonjour.
Cependant, il reste permis d'en douter.

a@p:~$ df -htext4
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda6           32G     13G   18G  41% /
/dev/sda18          58G    109M   55G   1% /home
a@p:~$ 
a@p:~$ sudo umount /dev/sda18
[sudo] Mot de passe de a : 
umount: /home: la cible est active.
a@p:~$ 
a@p:~$ sudo umount -f /dev/sda18
umount: /home: la cible est active.
a@p:~$
a@p:~$ sudo umount /home
umount: /home: la cible est active.
a@p:~$ 
a@p:~$ sudo fuser -kimuv /home
                     UTIL.       PID ACCÈS  COMMANDE
/home:               root     kernel mount (root)/home
                     a          1430 F...m (a)pulseaudio
                     a          1432 F.c.m (a)tracker-miner-f
                     a          1439 ..c.. (a)gdm-wayland-ses
                     a          1445 ..c.. (a)dbus-daemon
                     a          1450 ..c.. (a)gnome-session-b
                     a          1463 ..c.. (a)gvfsd
                     a          1484 ..c.. (a)gvfsd-fuse
                     a          1507 ..c.. (a)gvfs-udisks2-vo
                     a          1529 ..c.. (a)gnome-session-c
                     a          1542 ..c.. (a)gvfs-afc-volume
                     a          1553 ..c.. (a)gvfs-mtp-volume
                     a          1558 ..c.. (a)dconf-service
                     a          1562 ..c.. (a)gvfs-gphoto2-vo
                     a          1566 ..c.m (a)gnome-session-b
                     a          1572 ..c.. (a)gvfs-goa-volume
                     a          1576 ..c.m (a)goa-daemon
                     a          1588 F.c.m (a)gnome-shell
                     a          1589 ..c.m (a)at-spi-bus-laun
                     a          1595 ..c.. (a)dbus-daemon
                     a          1602 ..c.. (a)goa-identity-se
                     a          1678 ..c.m (a)Xwayland
                     a          1699 ..c.. (a)xdg-permission-
                     a          1701 ..c.m (a)gnome-shell-cal
                     a          1710 ..c.m (a)evolution-sourc
                     a          1720 f.c.m (a)evolution-calen
                     a          1732 ..c.. (a)gjs
                     a          1734 ..c.. (a)at-spi2-registr
                     a          1739 ..c.m (a)gsd-a11y-settin
                     a          1740 ..c.m (a)gsd-color
                     a          1741 ..c.m (a)gsd-datetime
                     a          1742 ..c.m (a)gsd-housekeepin
                     a          1743 ..c.m (a)gsd-keyboard
                     a          1745 ..c.m (a)gsd-media-keys
                     a          1747 ..c.m (a)gsd-power
                     a          1748 ..c.. (a)gsd-print-notif
                     a          1750 ..c.. (a)gsd-rfkill
                     a          1752 ..c.. (a)gsd-screensaver
                     a          1753 ..c.m (a)gsd-sharing
                     a          1754 ..c.m (a)gsd-smartcard
                     a          1755 ..c.m (a)gsd-sound
                     a          1756 ..c.m (a)gsd-usb-protect
                     a          1761 ..c.m (a)gsd-wacom
                     a          1762 ..c.m (a)gsd-wwan
                     a          1768 ..c.. (a)gsd-disk-utilit
                     a          1779 ..c.m (a)evolution-alarm
                     a          1874 ..c.. (a)gsd-printer
                     a          1926 F.c.m (a)evolution-addre
                     a          1927 F.c.m (a)gvfsd-metadata
                     a          1930 ..c.. (a)gvfsd-trash
                     a          1946 ..c.m (a)snap-store
                     a          1970 ..c.. (a)xdg-document-po
                     a          2077 ..c.. (a)ibus-daemon
                     a          2084 ..c.. (a)ibus-memconf
                     a          2085 ..c.m (a)ibus-extension-
                     a          2087 ..c.m (a)ibus-x11
                     a          2096 ..c.. (a)ibus-portal
                     a          2101 ..c.m (a)gsd-xsettings
                     a          2102 ..c.. (a)ibus-engine-sim
                     colord     2130 ....m (colord)colord
                     a          2302 ..c.m (a)xdg-desktop-por
                     a          2306 ..c.m (a)xdg-desktop-por
                     a          2361 ....m (a)gnome-terminal-
                     a          2366 ..c.. (a)bash
                     a          2911 ..c.m (a)update-notifier
                     a          2966 ..c.m (a)deja-dup-monito
                     root       2975 ..c.. (root)sudo
Tuer le processus 1430 ? (y/N) 

a@p:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS"
a@p:~$ 

Bien entendu, on peut tuer les process. La session meure et une nouvelle est lancée.    On en reste au même point.

---

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Coeur Noir

Re : root devenu trop petit pour migration vers 22.04 LTS

Aaarrrff… moralité : tout faire depuis une live-session.

Sauf éventuellement les sauvegardes qui peuvent se lancer depuis le système installé, en cours.
Ou depuis une live-session, qu'importe.

J'y mettrais pas ma main à couper - ni quoi que ce soit d'autre d'ailleurs :
- est-ce que ça peut dépendre du type de session ( wayland / xorg ) ?
- …dépendre de l'environnement de bureau ?
- …de la version d'×buntu ?
- …du fait de lancer une session graphique ou d'agir depuis une console sans avoir lancé de session graphique au préalable ?

Car je vois bien dans « mes notes » que j'étais parvenu à démonter des partitions utilisant « /home » comme point de montage.
Ces notes datent ( 14.04~18.04 ) et ne concernent jamais Gnome. Et n'évoquent pas non plus session live ou session installée, graphique ou console, ni avec quel utilisateur j'aurais accompli ce miracle…
Et comme aujourd'hui aucun des systèmes que j'ai à portée de clavier n'utilisent /home comme point de montage, je n'ai pas tout de suite les conditions de test adéquat.

moralité ( bis ) : mieux prendre mes notes.

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

Coeur Noir

Re : root devenu trop petit pour migration vers 22.04 LTS

Donc ajustement de la méthode. Avec plus de « prudence ».

Se munir d'une clé usb contenant un système démarrable en live et d'un DD externe de taille suffisante pour la sauvegarde, hébergeant un système de fichiers EXT× ( ou tout autre format gérant les droits et permissions Linux, ça exclut à minima NTFS, FAT, ExFAT. )

0. planter le décor
0⋅a) lancer le pc sur le système live en mode « essayer sans installer »
0⋅b) quand la session graphique est lancée, connecter le DD externe, ce qui déclenche son montage automatique.
0.c ) aller chercher dans l'explorateur de fichiers la partition de ±195Go qui contient le(s) $HOME du système installé « en dur » ( il y a au moins celui de benoit ) - ça aura pour effet de monter cette partition.
0.d) repérer les disques, partitions en présence et points de montages utilisés en lançant depuis un terminal :

lsblk -fe7 -o +size,model          # bien agrandir la fenêtre du terminal avant de lancer cette commande, sa réponse est un tableau assez large.
                                   # commande terriblement utile et pratique, à garder sous le coude ;-)

ici tu dois reconnaître :
⋅ au moins trois supports : la clé usb d'où provient ce système live en cours, ton HDD, ton SSD,
⋅ des points de montage pour les partitions montées, au moins 2 : un pour la partition de ±195Go, qui devrait être /media/ubuntu/label_ou_uuid_grosse_partition ( celle qu'on voit nommée sda3 au #1 )
et un pour le DD externe, sous la même forme /media/ubuntu/label_ou_uuid_périphérique_DD_externe
⋅ puisqu'on est dans un système différent de celui installé, les noms de blocs périphérique ont pu changer : ce qui s'appelait sda s'appelle peut-être sdc ici - d'où l'importance de se repérer ( avec les capacités, les modèles, les labels… ) et d'où le fait que je les évoquerai sd×N, × que tu déduiras et que je ne peux deviner, N est un ordinal qui ne change pas.

1⋅ sauvegarde
1⋅a) procéder à la sauvegarde du contenu de la partition sd×3 de ±195Go via :

cd /media/ubuntu          # place le terminal à cet emplacement, ça raccourcit un peu les commandes…
sudo   cp   -rav   label_ou_uuid_grosse_partition/*   label_ou_uuid_périphérique_DD_externe/

Prendra un certain voire un temps certain ( utilise de préférence de l'usb3, les ports bleus. )
1⋅b) quand c'est fini, sans message d'erreur espérons, navigue jusqu'à ce DD externe et vérifie que tu y retrouves bien tous tes petits : au moins un dossier benoit dans lequel se trouvent des éléments cachés ( .cache, .config, .local, etc ) et visibles ( Documents, Images, Gog Games, Bureau, etc )
1⋅c) démonte proprement la partition puis déconnecte ce disque. C.à.d pas en arrachant le câble sauvagement, mais via clic droit dans l'explorateur de fichiers, démonter, puis après la notification, déconnecter. Cela pour limiter tout risque de confusion plus tard, à l'étape 3.

2⋅ préventif, au cas où la procédure serait interrompue avant terme
2⋅a) monter la partition sd×2 de ±28Go qui contient la racine du système installé en dur.
2⋅b) à nouveau, repérage des disques et partitions en présence ( lsblk… ) Tu dois reconnaître la partition et son point de montage du genre /media/ubuntu/label_ou_uuid_petite_partition
2⋅c) créer dans le dossier /home de ce système un $HOME pour benoit :

cd /media/ubuntu/label_ou_uuid_petite_partition          # place le terminal dans la racine du système installé, puisqu'on va rester là un moment.
sudo mkdir /home/benoit

si benoit est le premier et seul utilisateur humain existant sur le système en dur

sudo chown 1000:1000 /home/benoit          # approprie ce dossier à l'utilisateur et au groupe d'uid:gid 1000, soit benoit dans le système installé en dur.

Si doute sur la question du nombre d'utilisateurs humains et de leur uid ( identifiant numérique intrinsèque au système de fichiers ) :

grep -E :[0-9]{4}: /etc/passwd

et y repérer à quel uid correspond le nom benoit.
Si plusieurs utilisateurs, créer un $HOME pour chaque, à son nom, en lui attribuant son uid correspondante.
2⋅d) garder une copie du fstab actuel ( celui du système installé « en dur » ) :

sudo   cp   /etc/fstab   /etc/fstab_sauv

2⋅e) démonter cette petite partition sd×2 de ±28Go.

3⋅ entrons dans le vif du sujet : modifier le partitionnement du disque qui contient le système installé.
3⋅a) installer gparted dans la session live, s'il ne l'est pas déjà :

sudo apt install gparted

et le lancer.
3⋅b) reconnaître le disque adéquat ( a ou b ou… ) le sélectionner pour y supprimer la grosse partition sd×3 de ±195Go.
3⋅c) étendre la petite partition de 28Go ( celle qui héberge le système installé ) vers la droite de sorte à couvrir tout l'espace libéré par la suppression précédente.
3⋅d) après que gparted ait fini, le quitter, monte cette partition ( via explorateur de fichiers ) et lance à nouveau un repérage ( lsblk… encore ),
tu dois trouver une plus grande partition sd×2 de ±224Go, là où avant tu en voyais 2 ( sd×2 et sd×3 ) : ta racine système dispose dorénavant de toute cette partition. Laisse la « montée » et repère son point de montage ( colonne mountpoints dans lsblk ) du genre /media/ubuntu/label_ou_uuid_plus_grande_partition, on va bientôt lui donner à manger…
3⋅e) comme la partition sd×3 n'existe plus, on peut enlever son montage du fstab du système installé :

cd /media/ubuntu/label_ou_uuid_plus_grande_partition          # pour se placer à la racine du système installé
sudoedit /etc/fstab					      # pour ouvrir dans un terminal un éditeur de texte en mode « administrateur »
kate /etc/fstab						      # quoi que sous Kubuntu, kate sait faire ça proprement je crois, au choix.

pour y commenter ou supprimer la ligne qui faisait référence à sda3.

4⋅ réimporter dans le $HOME de benoit sur le système en dur, les données sauvegardées sur le DD externe
4⋅a) brancher le DD externe de tout à l'heure, il doit monter dans /media/ubuntu/label_ou_uuid_périphérique_DD_externe
4⋅b) puisque la plus grande partition de ±224Go est restée montée, on peut lancer la copie.

cd /media/ubuntu
sudo   cp   -rav   label_ou_uuid_périphérique_DD_externe/benoit/*   label_ou_uuid_plus_grande_partition/home/benoit/
          # ici, bien que les dossiers « benoit » de part et d'autre appartiennent bien à benoit,
          # sudo et options -ra obligatoires car on est dans une session live, ça n'est pas l'utilisateur benoit qui agit.
          # L'option -v est facultative mais donne une idée de ce qui se passe, et informera en cas de pépin.
          # [ ctrl ] + [ c ] s'il fallait interrompre la copie en cours. On n'sait jamais.

4⋅c) quand la copie est finie, démonter proprement la partition du DD externe, et débrancher le disque. Conserver cette sauvegarde.
4⋅d) vérifier ce qui se trouve maintenant dans /media/ubuntu/label_ou_uuid_plus_grande_partition/home/benoit/
4⋅e) et ma foi si tout paraît reconnaissable, il est temps de quitter cette session live, en demandant le redémarrage du pc qui dira quand retirer la clé usb. Que pourrait-il mal se passer ?

____________________________

⋅ l'étape 2⋅ est préventive dans le sens où elle permettra au système de démarrer une session fonctionnelle pour benoit si un accident pas complètement fatal survenait ensuite. Elle n'est cependant pas facultative.

⋅ pour l'étape 4⋅ je suis parti du principe qu'il n'y a qu'un seul utilisateur humain, benoit.
Si plusieurs $HOME ont été sauvegardés à la racine du disque externe ( et rien d'autre à cet emplacement ), la commande de « réimport » deviendrait :

sudo   cp   -rav   label_ou_uuid_périphérique_DD_externe/*   label_ou_uuid_plus_grande_partition/home/

L'option -a de cp conserve tous les attributs des éléments copiés : droits, permissions, propriétaires, dates de création, etc.

⋅ une potentielle étape 5 ⋅ une fois le système installé « en dur » démarré, ce pourrait être opportun d'y lancer

sudo partprobe
sudo update-grub

la première informe le système des changements de partitions, la seconde mettra à jour grub, qui gère le démarrage du système. Pertinent ? Utile ? Fera pas de mal…

⋅ Il m'aura fallu plus de 2 heures pour rédiger tout ça. Il te faudra bien moins de temps pour « faire » tout ça - moderato le temps nécessaire aux transferts de données entre ton pc et le DD externe.

Dernière modification par Coeur Noir (Le 29/06/2022, à 02:57)

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

Laadna

Re : root devenu trop petit pour migration vers 22.04 LTS

Merci pour tout ça. J'ai commencé la copie, et j'anticipe un problème : le disque externe se remplit bien et la console confirme la copie, cependant tout est copié dans un dossier qui m'est inaccessible (verrouillé). Est-ce que c'est du au recours à sudo dans la commande de copie ? Est-ce que quand je copierai de nouveau le contenu de ce dossier dans le nouveau $HOME (à l'étape 4) je ne vais pas me retrouver avec des données correctement copiées mais inaccessibles ?

Dernière modification par Laadna (Le 30/06/2022, à 09:01)

geole

Re : root devenu trop petit pour migration vers 22.04 LTS

Bonjour.
La commande a été lancée avec sudo comme rien n'existait, il a créé le répertoire sous son nom qui est root.
Pour le racheter

sudo chown -Rc TonNom:TonNom   Le pointDeMontageDeLaPartitionExterne

Soit donc quelque chose comme cela

sudo chown -Rc benoit:benoit /media/benoit/benoit-dd

Tu as du oublier de faire ce qui était demandé.

si benoit est le premier et seul utilisateur humain existant sur le système en dur

sudo chown 1000:1000 /home/benoit          # approprie ce dossier à l'utilisateur et au groupe d'uid:gid 1000, soit benoit dans le système installé en dur.

ou alors tu n'es pas le numéro 1000. Pour le vérifier.

id

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

---

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Laadna

Re : root devenu trop petit pour migration vers 22.04 LTS

[...]

Tu as du oublier de faire ce qui était demandé.

J'en étais encore au 1b, mais impossible de vérifier si les dossiers copiés sont bien accessibles avec leur contenu...

chown rend la plupart des dossiers accessibles, mais pas tous (avec 1000:1000, via le live-cd j'imagine que l'utilisateur et le groupe benoit:benoit n'existent pas) :

kubuntu@kubuntu:/media/kubuntu$ id
uid=999(kubuntu) gid=999(kubuntu) groups=999(kubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),132(lxd),133(sambashare)

Certains dossiers restent inaccessibles, je crois que c'est une question de droits et permissions plus que d'utilisateurs et de groupes : les dossiers verrouillés appartiennent bien à l'utilisateur/groupe 1000:1000 mais l'onglet "droits d'accès" de Dolphin précise que groupe et autre n'ont "aucun accès", contrairement aux dossiers accessibles ou ils ont un accès en lecture.

geole

Re : root devenu trop petit pour migration vers 22.04 LTS

essaie la commande standard

sudo chown -Rc $USER:$USER /media/benoit/benoit-dd

sinon, pour rendre accessible à tout le monde en lecture

sudo chmod -R 744  /media/benoit/benoit-dd

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

---

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Laadna

Re : root devenu trop petit pour migration vers 22.04 LTS

Avec cette commande, je n'ai plus accès au dossier copié :

Impossible d'entrer dans le dossier /media/kubuntu/benoit-dd/benoit.

geole

Re : root devenu trop petit pour migration vers 22.04 LTS

alors en écriture si encore possible

sudo chmod -R 777  /media/benoit/benoit-dd

---

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Coeur Noir

Re : root devenu trop petit pour migration vers 22.04 LTS

Geole !
Jamais de chmod -R 777 !

La commande a été lancée avec sudo comme rien n'existait, il a créé le répertoire sous son nom qui est root.
Pour le racheter

sudo chown -Rc TonNom:TonNom   Le pointDeMontageDeLaPartitionExterne

Là c'est du grand n'importe quoi !!!
La commande c'est sudo cp -rav qui conserve tous les attributs des éléments originaux.
Et ça ne sert presque jamais à rien de changer les droits sur un point de montage.

Ce qui compte c'est que le dossier benoit appartienne à benoit au final dans le système installé en dur, soit l'utilisateur d'uid 1000.

Ici en agissant depuis la live-session, l'utilisateur courant de cette live session, nommé kubuntu et d'uid 999, n'a pas d'accès aux affaires de 1000, c'est normal - et c'est donc un détail que j'avais oublié dans la procédure.

Pour voir le contenu du dossier benoit sur le DD externe depuis la session live, il faut passer par le mode administrateur de Dolphin, s'il en a un
ou par une commande

sudo ls -la /chemin/vers/DD_Externe/benoit

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

Laadna

Re : root devenu trop petit pour migration vers 22.04 LTS

Je n'ai pas appliqué les droits 777 sur le dossier. J'ai préféré rebooter sur la session installée, pour vérifier que la copie était bien là et accessible (j'avais oublié ls).

Pour une raison que j'ignore, à l'étape 2c je n'ai pas eu de message d'erreur mais le dossier /home est resté vide. J'ai contourné ce problème à l'étape 4b en copiant le dossier de plus haut niveau dans le dossier de plus haut niveau (pour que la copie se fasse à partir du dossier benoit vers le dossier /home au lieu du contenu de benoit dans le contenu de /home/benoit). Si ça fait cafouiller les droits j'essayerai de nouveau de chown 1000:1000.

La copie du fstab n'a pas fonctionné non plus, là aussi sans message d'erreur... Mais j'ai vérifié avant d'agrandir la partition, et je l'ai sauvegardé par un autre biais.

Pour le moment ça recopie depuis le disque externe vers /home.

Ha et je n'ai pas pensé à le préciser, mais en effet je n'ai pas d'autre utilisateur (et donc un seul dossier présent dans /home).

Pour le moment ça semble aller à peu près comme prévu.

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

geole

Re : root devenu trop petit pour migration vers 22.04 LTS

A l'issue de la recopie, la partition du disque interne doit avoir le répertoire "/home/benoit" visible et contenant tes données

---

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Laadna

Re : root devenu trop petit pour migration vers 22.04 LTS

Tout semble parfaitement fonctionner. Un grand merci ;-)

Coeur Noir

Re : root devenu trop petit pour migration vers 22.04 LTS

Tout semble parfaitement fonctionner.
Ça c'est une bonne nouvelle

Bon va falloir que je fasse divers essais depuis des live-session d'une 22.04 car les autres « freins » que tu as rencontrés m'intriguent un peu.
Que l'utilisateur 999/Kubuntu propre à la live-session n'ait pas pu tout faire, ça ok.
Que des commandes en sudo restent sans effet, c'est curieux.

Juste pour rassurer tout le monde, depuis le système installé, à nouveau :

lsblk -fe7 -o +size

et

ls -la /home        # -lna montrerait les uid/gid plutôt que les noms

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

Laadna

Re : root devenu trop petit pour migration vers 22.04 LTS

benoit@kubuntu:~$ lsblk -fe7 -o +size
NAME   FSTYPE LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT     SIZE
sda                                                                                  223,6G
├─sda1 vfat         B5CC-1239                             502,9M     2% /boot/efi      512M
└─sda2 ext4         2e3fdca3-ede2-42b7-a340-8287da32a0d0  161,3G    21% /            223,1G
sdb                                                                                  232,9G
└─sdb1 ext4         817b511f-80e5-4647-9679-1a9a72451739   90,4G    55% /media/deux  232,9G
sdc                                                                                  931,5G
└─sdc1 ext4         6a7683ba-0d00-4687-abd8-65e75a7f4458  678,4G    21% /media/trois 931,5G
sr0                                                                                   1024M
benoit@kubuntu:~$ ls -la /home
total 16
drwxr-xr-x  4 root   root   4096 juin  30 15:30 .
drwxr-xr-x 20 root   root   4096 janv. 16  2021 ..
drwxr--r-- 33 benoit benoit 4096 juil.  1 15:18 benoit
drwx------  2 benoit benoit 4096 janv. 16  2021 lost+found
benoit@kubuntu:~$ 

Que des commandes en sudo restent sans effet, c'est curieux.

J'ai pensé avoir pu me gourer d'UUID, mais si elle était invalide ou qu'elle pointait vers une partition sans fstab, il y aurait eu un message d'erreur je pense.

Dernière modification par Laadna (Le 01/07/2022, à 14:24)

geole

Re : root devenu trop petit pour migration vers 22.04 LTS

Bonjour.
Je crois comprendre que tu n'as pas rapatrié .steam
Fonctionne-t-il depuis sa partition actuelle?

---

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Laadna

Re : root devenu trop petit pour migration vers 22.04 LTS

En fait je l'ai recopié .steam dans /home/benoit, puis j'ai déménagé via l'outil intégré de steam tout ce qui pouvait l'être (c'est-à-dire les jeux sans dépendances) vers sdc1. Et ils fonctionnent tous correctement, certains ont demandé de réinstaller proton mais c'est de toutes façons régulier quand c'est la version expérimentale de proton qui permet de faire tourner le jeu.