Erreur lors de la mise à niveau vers Trisquel 10
- Inicie sesión ou rexístrese para enviar comentarios
Bonjour,
Je rencontre un problème lors de la mise à niveau de Trisquel 9 vers Trisquel 10.
J'ai d'abord essayé d'effectuer le mise à niveau avec la commande sudo do-release-upgrade -d (comme je l'avais fait pour la mise à niveau vers Trisquel 9.Le mise à niveau s'est arrêtée avec un message indiquant qu'un paquet avec un PPA était installé.
J'ai donc décoché la ligne du seul dépoôt PPA présent dans Synaptic. Ensuite, j'ai relancé la mise à niveau avec la même commande. J'ai alors eu un message m'indiquant que le mise à niveau était impossible du fait que j'ai installé une version de développement (avec l'option -d de do-release-upgrade, très probablement).
J'ai ensuite tenté d'utiliser la commande do-release-upgrade sans option. J'ai à nouveau obtenu le message ci-dessous, mai cette fois sans plus de précision.
Impossible d'évaluer la mise à niveau
Un problème insoluble est survenu lors du calcul de la mise à niveau.
Je me dis qu'il faudrait que je fasse en sorte que mon installation de Trisquel ne soit plus reconnue comme de développement pour effectuer la mise à niveau. Mais comment le faire ? Si ce n'est pas une bonne piste, que faire d'autre ?
La solution quelque peu brutale est d’exécuter dans un terminal :
$ sudo sed -i s/etiona/nabia/ /etc/apt/sources.list && sudo apt update && sudo apt full-upgrade
Ces derniers jours, j’ai mis à jour trois systèmes ainsi.
Merci Magic Banana pour cette suggestion.
J'ai essayé la commande. Mais sans succès pour le moment, comme on peut le voir ci-dessous.
$ sudo sed -i s/etiona/nabia/ /etc/apt/sources.list && sudo apt update && sudo apt full-upgrade
Atteint :1 http://archive.trisquel.info/trisquel nabia InRelease
Atteint :2 http://archive.trisquel.info/trisquel nabia-security InRelease
Atteint :3 http://archive.trisquel.info/trisquel nabia-updates InRelease
Atteint :4 http://archive.trisquel.info/trisquel nabia-backports InRelease
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
1594 paquets peuvent être mis à jour. Exécutez « apt list --upgradable » pour les voir.
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Erreur !
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites :
libgirepository-1.0-1 : Casse: python-gi (< 3.34.0-4~) mais 3.26.1-2ubuntu1 devra être installé
E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état.
Après une petite recherche, j'ai constaté que les paquets libgirepository-1.0.1 et python-gi sont malheureusement visiblement importants pour le système. La version de python-gi de Nabia est la 3.36.0-1 qui ne semble pas devoir être installée et cela crée donc le problème, on dirait. Reste à savoir pourquoi…
En faisant une recherche sur Internet, je suis tombé sur un rapport de bogue du paquet ubuntu-release-upgrader (cf. https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1875523). Le bogue ressemble fortement au problème que je rencontre. Vu ce qui y est indiqué, j'ai désinstallé python-gi (et ses quelques dépendances qui ne me sont a priori pas utiles). La commande do-release-upgrade donne la même erreur que précédemment. En relançant la commande indiquée par Magic Banana, l'erreur que j'avais avec a disparu. :)
Par contre, j'ai un message d'erreur m'indiquant que je n'ai pas assez d'espace disponible sur /var/cache/apt/archives/. Mais c'est une autre histoire…
J'ai fair de la place pour pouvoir procéder à la mise à niveau.
J'ai ensuite été embêté avec une erreur avec l'installation de grub2-common avec les messages ci-dessous.
dpkg: erreur de traitement de l'archive /tmp/apt-dpkg-install-hjtHT7/03-grub2-common-2.04-1ubuntu26.13+10.0trisquel6_amd64.deb (--unpack) :
tentative de remplacement de « /etc/kernel/postinst.d/zz-update-grub », qui appartient aussi au paquet grub-efi-amd64_2.04-1ubuntu44.1.2+9.0trisquel5
dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé (pipe))
(…)
Des erreurs ont été rencontrées pendant l'exécution :
/tmp/apt-dpkg-install-hjtHT7/03-grub2-common-2.04-1ubuntu26.13+10.0trisquel6_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
J'ai saisi les commandes de la réponse de la page https://askubuntu.com/questions/1348102/cant-upgrade-because-of-grub-efi-amd64-d%C3%A9pend-grub-efi-amd64-bin-2-04-1u (en adaptant les noms des paquets vu que des versions plus récentes ont été téléchargées).
L'installation a pu continuer jusqu'à ce que je tombe à nouveau sur des problèmes :
Removing obsolete conffile /etc/bash_completion.d/grub ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Failed to restart grub-common.service: Unit grub-common.service is not loaded properly: Exec format error.
See system logs and 'systemctl status grub-common.service' for details.
invoke-rc.d: initscript grub-common, action "restart" failed.
● grub-common.service - Record successful boot for GRUB
Loaded: error (Reason: Exec format error)
Active: inactive (dead)
août 09 08:17:05 julien-Latitude-E7440 grub-common[1519]: ...done.
août 09 08:17:05 julien-Latitude-E7440 systemd[1]: Started LSB: Record successful boot for GRUB.
août 09 19:34:18 julien-Latitude-E7440 systemd[1]: Stopping LSB: Record successful boot for GRUB...
août 09 19:34:18 julien-Latitude-E7440 systemd[1]: Stopped LSB: Record successful boot for GRUB.
août 09 19:34:20 julien-Latitude-E7440 systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
août 09 21:34:37 julien-Latitude-E7440 systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
août 09 21:34:38 julien-Latitude-E7440 systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
août 09 21:34:38 julien-Latitude-E7440 systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
août 09 21:34:38 julien-Latitude-E7440 systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
août 09 21:34:39 julien-Latitude-E7440 systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
dpkg: erreur de traitement du paquet grub-common (--configure) :
installed grub-common package post-installation script subprocess returned error exit status 1
(…)
Paramétrage de libpurple0 (1:2.13.0-2.2ubuntu4+10.0trisquel1) ...
dpkg: des problèmes de dépendances empêchent la configuration de grub-efi-amd64-bin :
grub-efi-amd64-bin dépend de grub-common (>= 2.02~beta2-9) ; cependant :
Le paquet grub-common n'est pas encore configuré.
dpkg: erreur de traitement du paquet grub-efi-amd64-bin (--configure) :
problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de grub-efi-amd64 :
grub-efi-amd64 dépend de grub-efi-amd64-bin (= 2.04-1ubuntu44.2+10.0trisquel4) ; cependant :
Le paquet grub-efi-amd64-bin n'est pas encore configuré.
dpkg: erreur de traitement du paquet grub-efi-amd64 (--configure) :
problèmes de dépendances - laissé non configuré
Paramétrage de python3 (3.8.2-0ubuntu2) ...
Aucun rapport « apport » n'a été créé car le message d'erreur indique une erreur consécutive à un échec précédent.
Aucun rapport « apport » n'a été créé car le message d'erreur indique une erreur consécutive à un échec précédent.
running python rtupdate hooks for python3.8...
/usr/lib/ubiquity/plugins/ubi-partman.py:997: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if max_size_mb is not 0:
running python post-rtupdate hooks for python3.8...
(…)
Paramétrage de python3-icu (2.4.2-0ubuntu3) ...
dpkg: des problèmes de dépendances empêchent la configuration de grub2-common :
grub2-common dépend de grub-common (= 2.04-1ubuntu26.13+10.0trisquel6) ; cependant :
Le paquet grub-common n'est pas encore configuré.
dpkg: erreur de traitement du paquet grub2-common (--configure) :
problèmes de dépendances - laissé non configuré
Aucun rapport « apport » écrit car MaxReports a déjà été atteint
(…)
Traitement des actions différées (« triggers ») pour ureadahead (0.100.0-21) ...
Des erreurs ont été rencontrées pendant l'exécution :
grub-common
grub-efi-amd64-bin
grub-efi-amd64
grub2-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
J'ai ensuite relancé la commande ci-dessous visiblement avec succès.
sudo apt install -f
Puis j'ai relancé la commande suivante.
sudo apt full-upgrade
La mise à niveau s'est terminée (avec un problème d'espace disque disponible au milieu).
Par contre, en redémarrant, j'ai eu droit à ce qui suit.
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
/sbin/init: symbol lookup error: /lib/systemd/libsystemd-sahred-245.so: undefined symbol; seccomp_api_get
Grâce au rapport de bogue que j'ai trouvé (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876486), j'ai pu corriger le problème en déplaçant les fichiers ci-dessous depuis une session live.
/lib/x86_64-linux-gnu/libseccomp.so.2.3.1
/lib/x86_64-linux-gnu/libseccomp.so.2
J'ai ensuite démarré Trisquel sans problème. :)
Bonjour à tous,
Bon, si je vous écris ici, c'est que j'ai encore raté quelque chose :-(
(je ne sais pas si c'est bien de reprendre dans un sujet existant ou s'il créer un nouveau sujet, donc j'ai mis ici)
Je voulais faire le mettre à jour de la version 9 à la version 10 de Trisquel. Comme vous le savez peut-être j'ai toujours des soucis d'espace disponible. J'ai pourtant libérer ~6 Go mais la mise à jour est toujours refusée.
Puisque le
# apt-get full-upgrade
était refusé par manque de place, j'ai simplement fait
# apt-get upgrade
en pensant faire des
# apt-get autoremove
# apt-get autoclean
# apt-get clean
lorsqu'il n'y aurait plus de place. Sauf que cela n'a pas fonctionné :-(
J'ai donc pris le risque de faire un reboot en ayant conscience que le système pouvait ne pas redémarrer, mais je pensais pouvoir relancer Trisquel en mode texte et dans le pire des cas, reprendre a partir d'un Live USB.
Après le reboot le système se lance presque normalement, mais après avoir passé avec succès le crypt_setup avec mon mot de passe, le clavier et la souris (et le pad) ne fonctionne plus. je ne peux donc pas entrer le mot de passe de ma session, ni basculer en mode texte [Ctrl+Alt+F1] :-(
Du coup, je suis sur le système Live USB. Mais là je n'arrive pas à faire le "chroot" pour terminer les mises à jour.
Pouvez-vous m'aider ? J'ai juste besoin de passé mon terminal sur le système embarqué pour poursuivre et terminer les mises à jour.
Je reprend ici la méthode trouvée à l'adresse : https://debian-facile.org/doc:systeme:chroot
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 2,6G 1 loop /rofs
sda 8:0 1 28,9G 0 disk
├─sda1 8:1 1 2,7G 0 part /cdrom
├─sda2 8:2 1 1M 0 part
└─sda3 8:3 1 26,2G 0 part /var/log
sdb 8:16 0 698,7G 0 disk
├─sdb1 8:17 0 731M 0 part
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 697,9G 0 part
└─luks-e72baf04-8452-48db-82ce-5b4a9a9c1031 253:0 0 697,9G 0 crypt
├─trisquel--vg-root 253:1 0 18,6G 0 lvm
├─trisquel--vg-swap_1 253:2 0 2,9G 0 lvm
└─trisquel--vg-home 253:3 0 676,4G 0 lvm
sr0 11:0 1 1024M 0 rom # lsblk --fs
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs 0 100% /rofs
sda iso9660 trisquel 10.0.1 amd64 2022-05-26-01-10-16-00
├─sda1 iso9660 trisquel 10.0.1 amd64 2022-05-26-01-10-16-00 0 100% /cdrom
├─sda2 vfat EFI 0CF4-5769
└─sda3 ext4 writable 1b74e0b4-d224-4b38-85cd-dbee9aa48ebc 24,3G 0% /var/log
sdb
├─sdb1 ext4 3b6b74cb-3fed-4610-ac47-7aec3fe5493d
├─sdb2
└─sdb5 crypto_LUKS e72baf04-8452-48db-82ce-5b4a9a9c1031
└─luks-e72baf04-8452-48db-82ce-5b4a9a9c1031
LVM2_member Hac7og-ju3V-vusi-zuIa-HNa8-csNZ-GXGoso
├─trisquel--vg-root ext4 f3c2e36b-bf5d-4ed3-861a-7e1f9e21d20b
├─trisquel--vg-swap_1 swap 95bb48f6-2e3a-4e6f-8140-019d78ac1f23
└─trisquel--vg-home xfs 5719fec2-0ecd-4769-a534-c354b297a91b
sr0
Donc, si j'ai tout compris, c'est /dev/sdb1 qu'il faut monter.
# mkdir /mnt/plouf
# mount /dev/sdb1 /mnt/plouf
# mount /dev/sdb5 /mnt/plouf/home/
mount: /mnt/plouf/home: type de système de fichiers « crypto_LUKS » inconnu.
Je passe à la suite parce que je ne croix pas que le home soit nécessaire.
# mount --bind /dev/ /mnt/plouf/dev
# mount --bind /sys/ /mnt/plouf/sys
# mount -t proc /proc /mnt/plouf/proc
# chroot /mnt/plouf /bin/bash
chroot: failed to run command ‘/bin/bash’: No such file or directory
Grrrrrrr
Bref, là je suis dans les choux
donc je fait un petit
# umount -R /mnt/plouf
pour mettre les compteurs à zéro et recommencer une procédure avec votre aide.
Merci d'avance.
I am a translator!
Sur /mnt/plouf, il faut monter ton système de fichier root qui est /dev/vg-trisquel/root, pas /dev/sdb1 qui est très probablement le système de fichier qui contient /boot.
Cela devrait faire les montages corrects:
# mount /dev/vg-trisquel/root /mnt/plouf
# mount /dev/sdb1 /mnt/plouf/boot
# mount /dev/vg-trisquel/home /mnt/plouf/home
Tu ne peux pas monter /dev/sdb5 avec mount car c'est un volume physique de chiffrement. Une fois que tu as déverrouillé avec cryptsetup, tu vois les volumes logiques et ils aparaissent dans /dev/nom-du-groupe-de-volumes/nom-du-volume.
Ca peux arriver que tu voies "luks-..." dans lsblk, ce qui montre que le déverouillage par cryptsetup a bien marché, mais qu'ils n'apparaissent pas, dans ce cas, faire
# modprobe dm_mod
# vgscan
# vgchange -ay
et ils devraient apparaître.
J'espère que tu réussiras à faire ta mise à jour.
Si besoin, les détails complets sur LVM sont à https://wiki.parabola.nu/LVM. Le wiki parabola sur les fonctions essentielles est excellent, comme l'installation est totalement manuelle, tout est documenté.
EDIT: correction de sda en sdb.
Merci Avron ;-)
Mais à la première commande ca ne fonctionne pas. J'ai essayé plusieurs variantes. Où peut-on trouver le nom correcte ?
# mount /dev/vg-trisquel/root /mnt/plouf
mount: /mnt/plouf: le périphérique spécial /dev/vg-trisquel/root n'existe pas.
# mount /dev/vgtrisquel/root /mnt/plouf
mount: /mnt/plouf: le périphérique spécial /dev/vgtrisquel/root n'existe pas.
# mount /dev/trisquel/root /mnt/plouf
mount: /mnt/plouf: le périphérique spécial /dev/trisquel/root n'existe pas.
# mount /dev/trisquel--vg/root /mnt/plouf
mount: /mnt/plouf: le périphérique spécial /dev/trisquel--vg/root n'existe pas.
I am a translator!
Est-ce que lsblk montre "luks-..."?
Si oui, regarde ce qu'il y a dans /dev/mapper avec vg-trisquel et root ou home, je ne sais plus très bien comment les noms sont donnés exactement.
EDIT: J'ai inversé trisquel et vg, essaie avec /dev/trisquel-vg/root et /dev/trisquel-vg/home
Ok, c'était bien ça, le "vg" est après "trisquel" :
# mount /dev/trisquel-vg/root /mnt/plouf
# mount /dev/sdb1 /mnt/plouf/boot
# mount /dev/trisquel-vg/home /mnt/plouf/home
# chroot /mnt/plouf /bin/bash
J'ai aussi ajouter le :
# mount -a
indiqué ici : https://debian-facile.org/doc:systeme:chroot
Ca a fonctionné !!!
Maintenant, j'ai toujours le même problème qu'avant, problème de place :
# apt-get autoremove
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1506 non mis à jour.
# apt-get autoclean
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
# apt-get clean
# apt-get upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été conservés :
[GROSSE-LISTE]
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1505 non mis à jour.
# apt-get full-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
[GROSSE-LISTE]
Veuillez utiliser « apt autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
[GROSSE-LISTE]
Les NOUVEAUX paquets suivants seront installés :
[GROSSE-LISTE]
1456 mis à jour, 499 nouvellement installés, 190 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 2 516 Mo dans les archives.
Après cette opération, 2 658 Mo d'espace disque supplémentaires seront utilisés.
E: Pas assez d'espace disponible sur /var/cache/apt/archives/
Puisqu'il est demandé je refais :
# apt autoremove
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1505 non mis à jour.
Donc je suis coincé :-(
Comment je peux faire ?
I am a translator!
Pour ton "df -h", cela montre peut-être un problème, je n'ai pas trop la possibilité de vérifier ça.
Le plus simple à mon avis: sauvegarder /home, écraser tout avec une nouvelle installation de trisquel 10 à partir de l'iso, recopier home et installer les paquets que tu avais installé en plus de l'installation par défaut.
Je sais qu'il y a une façon de voir les paquets installés pour réinstaller les mêmes, j'ai déjà vu ça sur le forum trisquel mais je ne sais plus ou.
Je vois deux autres possibilités mais c'est plus compliqué:
Possibilité 1:
- copier /home sur un disque externe
- démonter home et réduire le volume home ("lvresize -L -10G trisquel-vg/home" pour le réduire de 10G, attention cela détruit le contenu de home, c'est pourquoi il faut le sauvegarder avant)
- créer un système de fichier xfs sur le volume réduit (mkfs.xfs /dev/trisquel-vg/home)
- mettre à jour /etc/fstab si besoin (seulement si le volume home est référencé avec un UUID, car l'UUID du nouveau système de fichier est différent)
- démonter root et agrandir le volume root ("lvresize -r -L +10G trisquel-vg/root" pour agrandir de 10G, "-r" permet de redimensionner le système de fichier root avec (marche avec ext4 mais pas avec xfs)
- monter root
- monter home et y remettre les données sauvegardées
- recommencer ta manip de mise à jour
Possibilité 2:
Installer trisquel 10 à partir de l'iso, sans écraser /home. Le principe est décrit à https://blog.wohli.org/2016/10/05/Installing-Ubuntu-16-10-on-existing-LUKS-encrypted-LVM/ mais il faut adapter. Je l'ai fait récemment et ça a marché mais je ferais sûrement de petites erreurs si je ré-essayais.
Ah, oui, j'ai oublié :
# df -h
df: impossible de lire la table des systèmes de fichiers montés: Aucun fichier ou dossier de ce type
Bon, malgré les soucis j'ai pu avancé un peu puisque lorsque je fais
# apt-get full-upgrade
il me répond avec des gosses listes de paquets
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
[GROSSE-LISTE]
Veuillez utiliser « apt autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
[GROSSE-LISTE]
Les NOUVEAUX paquets suivants seront installés :
[GROSSE-LISTE]
avant de me mettre le message d'erreur pour manque de place.
Du coup, j'ai pu faire manuellement quelques installation de type
# apt-get -f install [PAQUET] [PAQUET] [PAQUET] [PAQUET] [PAQUET] [PAQUET] [PAQUET]
en copiant 1 ligne de la liste des nouveaux paquets à installer
Ça a fonctionné jusqu'à une nouvelle erreur qui me bloque tout
# apt-get install -f
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Correction des dépendances... Fait
Les paquets supplémentaires suivants seront installés :
cryptsetup
Les paquets suivants seront mis à jour :
cryptsetup
1 mis à jour, 0 nouvellement installés, 0 à enlever et 1211 non mis à jour.
2 partiellement installés ou enlevés.
Il est nécessaire de prendre 159 ko dans les archives.
Après cette opération, 3 072 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
Réception de :1 https://archive.trisquel.info/trisquel nabia-security/main amd64 cryptsetup amd64 2:2.2.2-3ubuntu2.4 [159 kB]
159 ko réceptionnés en 1s (113 ko/s)
Préconfiguration des paquets...
E: Impossible d'écrire le journal (Est-ce que /dev/pts est monté ?) - posix_openpt (2: Aucun fichier ou dossier de ce type)
(Lecture de la base de données... 488715 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../cryptsetup_2%3a2.2.2-3ubuntu2.4_amd64.deb ...
Dépaquetage de cryptsetup (2:2.2.2-3ubuntu2.4) sur (2:2.0.2-1ubuntu1.2) ...
dpkg: erreur de traitement de l'archive /var/cache/apt/archives/cryptsetup_2%3a2.2.2-3ubuntu2.4_amd64.deb (--unpack) :
tentative de remplacement de « /usr/sbin/luksformat », qui appartient aussi au paquet cryptsetup-bin 2:2.0.2-1ubuntu1.2
dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé (pipe))
Des erreurs ont été rencontrées pendant l'exécution :
/var/cache/apt/archives/cryptsetup_2%3a2.2.2-3ubuntu2.4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Il me faut surmonter le problème avec le paquet cryptsetup !
# apt-get upgrade cryptsetup
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Vous pouvez lancer « apt --fix-broken install » pour corriger ces problèmes.
Les paquets suivants contiennent des dépendances non satisfaites :
cryptsetup-initramfs : Dépend: cryptsetup (>= 2:2.2.2-3ubuntu2.4)
Casse: cryptsetup (< 2:2.0.3-1)
cryptsetup-run : Dépend: cryptsetup (>= 2:2.1.0-6)
E: Dépendances non satisfaites. Essayez « apt --fix-broken install » sans paquet
(ou indiquez une solution).
notez que j'ai fait ce qui est demandé "apt --fix-broken install" et même "dpkg --configure -a" mais c'est toujours la même erreur qui est donné.
Une idée ?
E: Impossible d’écrire le journal (Est-ce que /dev/pts est monté ?)
Probablement pas. Juste avant chroot, tu veux exécuter la commande suivante (où /mnt/plouf/ est là où tu as monté la partition racine) :
$ for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt/plouf/$i; done
message d'erreur pour manque de place.
Il te faut résoudre ce problème de place. Vu l’état douteux dans lequel se trouve ton système, je pense, comme Avron, que le plus raisonnable serait de partir sur une nouvelle installation depuis l’ISO de Trisquel 10. Choisis le type d’installation « Autre chose » pour pouvoir définir une partition racine suffisamment grande : estime ce dont tu penses avoir besoin au maximum… et multiplie par au moins 2 pour être tranquille ! Avant tout cela, sauvegarde les données des utilisateurs.
I am a translator!
Peux-tu dire à nouveau (je pense que c'était toi qui avait expliqué) comment faire pour récupérer la liste des paquets installés et les réinstaller tous?
Est-ce qu'il y a des docs sur cela sur le site trisquel, et sur la réinstallation en gardant home? C'est des questions souvent posées. Si ce n'est pas le cas, je veux bien essayer de faire ça.
Il y a six ans, j’ai écrit cela an anglais : https://trisquel.info/en/wiki/cloning-system-or-how-make-copy-installed-packages-one-computer-another
Apparemment, je n’ai jamais pris le temps de traduire ce manuel en français. Si tu veux le faire, tu es le bienvenu ! Je viens d’actualiser la version anglaise :
- pour ne plus faire référence à gksu, qui n’existe plus;
- pour donner Back In Time, maintenant par défaut dans Trisquel, plutôt que Déjà-Dup, qui était à l’époque par défaut dans Trisquel, comme exemple d’outil de sauvegarde de données;
- pour parler de « différentes architectures », plutôt que de « 32 bits et 64 bits », les deux architectures que Trisquel supportait à l’époque;
- pour de menues améliorations de forme.
Bon voilà, j'ai pu terminer la mise à jour vers T10 !!!
J'ai refait le chroot depuis le "live USB" selon la remarque de Magic Banana comme suit :
$ sudo -i
# mount /dev/trisquel-vg/root /mnt/plouf
# mount /dev/sdb1 /mnt/plouf/boot
# mount /dev/trisquel-vg/home /mnt/plouf/home
# for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt/plouf/$i; done
# chroot /mnt/plouf /bin/bash
# mount -a
De cette manière, la commande "df -h" fonctionnait normalement ;-)
(je l'ai juste fait pour tester)
Du coup, j'ai pu faire des
# du -hd1 /var /tmp | sort -hr
avec différents dossiers pour trouver des choses à supprimer pour faire encore plus de place.
Du coup j'ai pu relancer les mises à jour avec les commandes suivantes
# apt-get dist-upgrade -f
# apt-get upgrade -f
# apt-get full-upgrade -f
# apt-get install -f
# apt-get update
J'ai entrecoupé toute ces commandes par
# apt-get autoremove
# apt-get autoclean
# apt-get clean
Je sais que vous m'aviez dit que "clean" et "autoclean" sont similaire, mais j'ai vu, par des recherches qu'il y a de petite différence, du coup je fais les 2 parce que finalement ça ne mange pas de pains comme on dit ;-)
Bref, tout a pu se terminer normalement sauf un détail :
Au lancement du système, je tombe sur le "BusyBox" avec l'invite de commande "initramfs".
La dernière fois que j'ai eu se problème, j'avais pu le résoudre avec la solution donné ici : https://www.shellhacks.com/busybox-initramfs-ubuntu-boot-problem-fix/
Mais, là, la commande
(initramfs) fsck /dev/mapper/trisquel--vg-root -y
m'a donné comme résultat que le dossier n'existait pas (je ne me rappel pas exactement de la formule en anglais)
Du coup j'ai relancer mon système en utilisant le noyau Linux précédant (une version 4.xx) dans le GRUB. Je vais encore essayer de trouver une solution pour démarrer normallement mon système sur le noyau Linux version 5.xx de Trisquel 10. Si vous avez une aidée à me proposé je suis preneur.
Il y a peut être un autre soucis avec des "applet" du tableau de bord, mais je verrai ça dans un second temps. Peut-être que le problème se résolvera tout seul avec la version 5 de Linux.
Je vous redis...
Je sais que vous m'aviez dit que "clean" et "autoclean" sont similaire, mais j'ai vu, par des recherches qu'il y a de petite différence, du coup je fais les 2 parce que finalement ça ne mange pas de pains comme on dit ;-)
Ça ne mange pas pain. Néanmoins, si tu exécutes apt clean, exécuter juste avant/après apt autoclean ne sert strictement à rien. apt clean supprime tous les paquets (les .deb, pas ce qu’ils permettent d’installer); apt autoclean un sous-ensemble : ceux qui ne seront presque certainement plus jamais utiles.
De la même façon, apt full-upgrade fait tout ce que fait upgrade ou dist-uprade et plus : cette commande a le droit de supprimer des paquets.
apt update télécharge les informations sur les paquets : elle doit être exécutée *avant* une commande d'upgrade.
Ah, super Magic Banana !
Ce sont des informations très intéressante. Je vais garder ça sous le coude.
Du côté de mon système, J'ai toujours le problème de BusyBox. Je vais encore faire des recherches et des essais. Je ferai probablement un sujet spécifique sur le forum ;-)
- Inicie sesión ou rexístrese para enviar comentarios