[résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

geole · Le 02/04/2023, à 23:21

La commande blkid trouve bien les partitions.
Le boot-info voit bien leur contenu.

A tout hasard, avec le support d'installation, on regarde si elles sont en bon état.

sudo fsck /dev/sdb1

sudo fsck /dev/sdc1

sudo fsck /dev/sdb3

Bybeu · Le 02/04/2023, à 23:24

Quand je boote en rescue les ennuis commencent là

Bybeu · Le 02/04/2023, à 23:41

Sinon en boot normal
ça finit comme ça
ils auraient même pu mettre input device au pluriel : pas de clavier non-plus
Là je reboote pour te donner les fsck...

Bybeu · Le 02/04/2023, à 23:41

[EDIT] pourquoi sudo ? Je suis en console root.

Bybeu · Le 02/04/2023, à 23:42

Ou tu veux que je le fasse depuis la live ? C'est pas pareil ?....
[EDIT] vu : depuis la live

Dernière modification par Bybeu (Le 02/04/2023, à 23:45)

Bybeu · Le 02/04/2023, à 23:55

Heu, en fait c'est sdb1 & 3 (swap et /var) et sdc1 (/home). /srv sur sdb2 est moins critique (pour le boot pas du tout, j'ai que des données là-dedans, films/photos/musique & backups des autres PC)

ubuntu@ubuntu:~$ sudo fsck /dev/sdb1
fsck de util-linux 2.37.2
ubuntu@ubuntu:~$ sudo fsck /dev/sdb3
fsck de util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdb3 : propre, 19686/618464 fichiers, 738554/2491392 blocs
ubuntu@ubuntu:~$ sudo fsck /dev/sdc1
fsck de util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdc1 : propre, 263744/30531584 fichiers, 44070822/122096384 blocs
ubuntu@ubuntu:~$ sudo fsck /dev/sdb1
fsck de util-linux 2.37.2
ubuntu@ubuntu:~$ echo $?
0
ubuntu@ubuntu:~$

Bybeu · Le 03/04/2023, à 00:10

geole a écrit :

La commande blkid trouve bien les partitions.
Le boot-info voit bien leur contenu.
A tout hasard, avec le support d'installation, on regarde si elles sont en bon état.
sudo fsck /dev/sdb1
sudo fsck /dev/sdc1
sudo fsck /dev/sdb3

Y'a un truc que j'aime pas avec la live, c'est que c'est une EFI. Mon PC a tous ses disques en MBR, et le BIOS est sur Legacy+UEFI

Bybeu · Le 03/04/2023, à 00:30

Bon allez, à la plume. Je tombe
Merci pour le coup de main et bonne nuit à tous

geole · Le 03/04/2023, à 07:15

Bonjour.
Dans tes dernières remarques.
On voit que le mode rescue est complêtement à coté de la plaque. Il ne sait pas acceder aux autres partitions. Donc à oublier.

On voit que le mode normal fonctionne bien pour le montage des quatre partitions.
Mais que le service FMT-SUPPORT se scratch.

Mon conseil. Boote en mode recovery normal
et malgré les difficultés de présentation de l'écran, ( Après quelques appuis sur la touche entrée, cela devrait se stabiliser ) choisis de demander le montage du réseau.
choisis d'être root
et tente ces commandes.

apt update
apt upgrade

Si tu n'y arrives absolument pas, fait un chroot. https://doc.ubuntu-fr.org/chroot
Attention il faudra prévoir le montage des trois autres partitions avant de commencer les contrôles..

Note sur le service qui ne part pas https://packages.debian.org/fr/sid/binfmt-support

Dernière modification par geole (Le 03/04/2023, à 07:30)

Bybeu · Le 03/04/2023, à 23:05

'Soir les Ub's
Des news : pas moyen d'obtenir un boot avec /var montée.
Je réussis à booter en mode normal (càd pas recovery ni rescue) en remplaçant dans la ligne linux de grub radeon.dpm=0 par $vt_handoff 3
Login avec mon compte perso, mais pas de HOME : HOME=/
Alors sudo su -
J'ai remis le grub de l'upgrade que j'avais précédemment remplacé par mon backup puis update-grub qui n'a marché qu'après un mkdir -p /var/lib/os-prober/mount (vide, ça a suffit).
Par contre pas moyen de refaire derrière un update-initramfs -u, il manque la vraie /var qui contient lib/initramfs-tools (j'ai vérifié en la montant mount /dev/sdb3 /media/root/var créé ad-hod - tout y est bien)
J'ai compilé un résumé du log de boot qui montre que c'est systemd qui semble dans les choux : c'est lui qui plante le montage des partitions :
3 erreurs ~normales~ au début avec une MoBo chinoise

...
13:34:38 nux kernel: [Firmware bug]: AMD-Vi: IOAPIC[0] not in IVRS table
13:34:38 nux kernel: [Firmware bug]: AMD-Vi: No southbridge IOAPIC found
13:34:38 nux kernel: AMD-Vi: Disabling interrupt remapping
...

et puis systemd en action : les blèmes commencent avec systemd-udevd.service

...
13:34:38 nux kernel: sda: sda1
...
13:34:38 nux kernel: sdb: sdb1 sdb2 sdb3
...
13:34:38 nux kernel: sdc: sdc1
...
13:34:38 nux kernel: ip_tables...
13:34:38 nux systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LICRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 +IDN +PCRE2 default-hierarchy=hybrid)
13:34:38 nux systemd[1]: Detected architecture x86-64
13:34:38 nux systemd[1]: Set hostname to <nux>
13:34:38 nux systemd[1]: /lib/systemd/system/systemd-udevd.service:26: Executable path is not absolute: udevadm control --reload --timeout 0
13:34:38 nux systemd[1]: /lib/systemd/system/systemd-udev-trigger.service:22: Executable path is not absolute: udevadm trigger --type=subsystems --action=add
13:34:38 nux systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
13:34:38 nux systemd[1]: /lib/systemd/system/fstrim.service:18: Unknown system call group, ignoring: @system-service
13:34:38 nux systemd[1]: /lib/systemd/system/systemd-hwdb-update.service:25: Executable path is not absolute: systemd-hwdb update
13:34:38 nux systemd[1]: /lib/systemd/system/uuidd.service:21: Executable path is not absolute: Unknown system call group, ignoring: @system-service
13:34:38 nux systemd[1]: systemd-hwdb-update.service: Cannot add dependency job, ignoring: Unit systemd-hwdb-update.service is not loaded properly: Exec format error
13:34:38 nux kernel: random: systemd: uninitilized urandom read (16 bytes read)
...
13:34:38 nux kernel: EXT4-FS (sda1): remounted. Opts: errors=remount-ro
...
13:34:38 nux systemd-journald[300]: Journal started
13:34:38 nux systemd-journald[300]: Runtime journal (/run/log/journal/c8a.....) is 8.0M max 159.9M, 144.9M free.
...
13:34:38 nux systemd[1]: Started Set the console keyboard layout.
13:34:38 nux systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
13:34:38 nux systemd[1]: Reached target Local Encrypted Volumes.
13:34:38 nux systemd[1]: Reached target Local File Systems (Pre).
13:36:08 nux systemd[1]: dev-disk-by\x2duuid-ffac7b81\x2db405\x2d480b\x2d8681\x2d107e9ef9870a.device: Job dev-disk-by\x2duuid-ffac7b81\x2db405\x2d480b\x2d8681\x2d107e9ef9870a.device/start timed out.
13:36:08 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-ffac7b81\x2db405\x2d480b\x2d8681\x2d107e9ef9870a.device.
13:36:08 nux systemd[1]: Dependency fail for /var.
...
13:36:08 nux systemd[1]: Starting Created Volatile Files and Directories...
13:36:08 nux systemd[1]: Started Tell Plymouth To Write Out Runtime Data.

Et ainsi de suite avec avec /home, /srv & Swap. La vérification des UUID des logs par rapport à /etc/fstab et lsblk et ls /dev/disk/by-uuid n'était pas de trop mais ne révèle pas d'incohérence.

Bybeu · Le 16/04/2023, à 09:37

Bonjour tous
Je vous livre la solution que m'a apporté un gars du support ubuntu sur IRC
Tout d'abord, je ne suis pas sûr que l'erreur provenait de là, mais j'avais ignoré un défaut de config grave signalé dans la conf de postfix ou mail-tools : il y avait l'IP du DNS de mon FAI comme adresse de serveur mail. Le gars me l'a fait remplacer par <hostname.local> (nux.local). À la fin, sudo apt update et sudo apt upgrade, => téléchargement de 3 ou 4Go de mises à jours, et hop, c'était réparé. En suivant, upgrade vers 22.04 OK.
Voilà, avec des commentaires en fin de lignes de ce que j'ai pigé. Boot en Live USB :

   1  lsblk -fe7
    2  mount /dev/sdc1 /mnt        # vu la ligne 4 ci-dessous, il s'agit du / d'origine
    3  ls /mnt
    4  cat /mnt/etc/os-release        # 20.04
    5  umount /mnt
    6  tune2fs -L linux /dev/sdc1    # Ajout d'une étiquette (-L(abel) linux pour pas batailler avec les UUID) 
    7  lsblk -fe7
    8  mount /dev/sda2 /mnt         # idem ligne 2 pour /srv (voir lignes 10 et 11)
    9  ls /mnt
   10  ls /mnt/iso
   11  ls /mnt/media
   12  umount /mnt
   13  tune2fs -L media /dev/sda2    # idem ligne 6 
   14  lsblk -f7
   15  lsblk -fe7
   16  mount /dev/sda3 /mnt   #idem ligne 2 pour /var (voir ligne 20)
   17  ls /mnt
   18  ls /var
   19  umount /mnt
   20  tune2fs -L var /dev/sda3     # idem ligne 6   
   21  lsblk -fe7
   22  mount /dev/sdb1 /mnt    #idem ligne 2 pour /home (voir ligne 25)
   23  ls /mnt
   24  umount /mnt
   25  tune2fs -L home /dev/sdb1     # idem ligne 6   
   26  lsblk -fe7
   27  mount LABEL=linux /mnt
   28  #mount LABEL=var /mnt/var
   29  cat /mnt/etc/fstab
   30  lsblk -fe7
   31  tune2fs -L srv /dev/sda2
   32  mount LABEL=srv /mnt/srv
   33  #mount LABEL=var /mnt/var
   34  lsblk -fe7
   35  mount LABEL=var /mnt/var
   36  mount LABEL=home /mnt/home
   37  cd /mnt
   38  for d in proc sys dev dev/pts run; do mount --bind /$d $d; done
   39  chroot .
   40  history
   41  ls home
   42  cd home/moi
   43  ls
   44  history > history.txt

iznobe · Le 16/04/2023, à 10:11

Bonjour , avec la liste des 44 commandes que tu donnes , on voit qu ' il a procédé a un chroot , qu ' il est aller voir dans ton repertoire perso pour y lister les fichiers , qu ' il a regardé les commandes que tu as passé , et c' est tout ...
les 38 1eres commandes c ' est de l ' identification de partition ( LABEL ) afin de proceder au chroot .

39  chroot .
   40  history
   41  ls home
   42  cd home/moi
   43  ls

Malheureusement on ne sait pas ce qu ' il a reellement corrigé du coup , il doit manquer la fin ( avant sudo apt update et sudo apt upgrade ) et donc le meilleur et certainement la solution .
vu qu ' il recupere l ' historique de tes commandes , on peut supposer qu ' il a du trouver quelquechose dedans qui a probablement cassé le systeme de MAJ et l' a corrigé , mais aucune certitude .

Dernière modification par iznobe (Le 16/04/2023, à 10:17)

Bybeu · Le 16/04/2023, à 11:00

Ce qui a permis la reprise apt update... c'est que /var était montée ET en ligne grâce au chroot à mon avis.
Peut-être que les logs permettraient plutôt de savoir pourquoi ça a planté. Il me semble me souvenir qu'au moment de l'échec du apt dist-upgrade j'ai vu un truc style : "Remise du système en l'état initial"

Merci pour votre présence et votre implication

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 02/04/2023, à 23:21

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#27 Le 02/04/2023, à 23:24

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#28 Le 02/04/2023, à 23:41

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#29 Le 02/04/2023, à 23:41

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#30 Le 02/04/2023, à 23:42

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#31 Le 02/04/2023, à 23:55

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#32 Le 03/04/2023, à 00:10

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#33 Le 03/04/2023, à 00:30

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#34 Le 03/04/2023, à 07:15

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#35 Le 03/04/2023, à 23:05

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#36 Le 16/04/2023, à 09:37

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#37 Le 16/04/2023, à 10:11

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

#38 Le 16/04/2023, à 11:00

Re : [résolu] Mise à jour difficile (18.04 vers 20.04 cassée)

Pied de page des forums