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

Bybeu · Le 31/03/2023, à 21:28

Bonjour tous
Je me suis enfin décidé après des années à mettre à jour mon bon vieux "serveur" 16.04 vers la 22.04.
Le première étape vers 18.04 c'est bien passée quasiment les doigts dans le nez à part quelques bricoles (/tmp en tmpfs désactivé dans fstab et reboot, /var trop petite, reboot/resize en live de 5 à 10Go (il en manquait ~1) et reboot, et puis quelques fichiers de conf dans /etc sauvegardés à la volée par copie en fichier-de-conf.16.04 pour remplacement par la version du responsable du paquet (surtout sshd, minidlna.conf et default/grub). Juste vers la fin une erreur non bloquante de postfix à cause de mailutils (exit code 75 ~ "Veuillez signaler un bug"). Reboot (non proposé, bizarre, mais bon je l'ai fait quand-même) et hop, boot OK en 18.04, et login as usual (pas wayland).

Passage en 20.04 :
Là ça secoue. Le pb postfixt/mailutils recommence et cette fois empêche la mise à jour. Je mets les 2 à jour avec synaptic. Un reboot, login, lancement du gestionnaire de mises à jour... c'est long... pendant ce temps je teste firefox et thunderbird, RàS. Retour au gestionnaire de mise à jour : il me propose une liste longue comme le bras (ou un trombone) Mise à jour partielle ou Suivant par défaut. Je choisis suivant. Ça bosse, ça bosse, je reviens un heure après, bloqué sur mon issue.net que je garde comme d'habitude. Je reviens un moment plus tard, c'est terminé, mais encore pas de reboot demandé.
Je reboote, mais il me renvoie à l'écran de login. Je me logue et je demande le reboot. Là ça y va... et je vois passer un message fugitif en rouge concernant /var
Au redémarrage il y a plein de tempos de 1mn30 pour des Start jobs pour des xxxxxx.device et ça se finit par un petit message en mode graphique sur l'écran qui indique un problème de détection de video et d'input device que je dois ~ "corriger moi-même", mais ni la souris ni le clavier ne fonctionnent, donc pas de Ctrl+Alt+Fx possibles => reset, et choix du mode Recovery sur l'écran de grub (qui marche très bien lui :-) ).
Là je tombe sur le menu semi-graphique en mode texte prévu, mais inutilisable : tout pourri pas des messages qui arrivent par dessus (style "Taper Ctrl et D ou Entrée pour continuer") et le clavier qui ne fonctionne pas pour sélectionner une option dans le menu... je peux fournir des photos de l'écran ou autre chose.

Merci pour vos conseils

Dernière modification par Bybeu (Le 16/04/2023, à 09:12)

Vobul · Le 31/03/2023, à 22:21

Tu as deux solutions. Soit tu tentes de corriger tous les bugs liés à une upgrade de plusieurs versions majeures. Soit tu fais une réinstallation propre.

J'opterai pour la deuxième solution.

iznobe · Le 31/03/2023, à 22:36

Bonsoir .
Avant de faire des Mises A niveaux successives , il faut deja s' assurer que le materiel est compatible , que le materiel reponds aux exigences recommandées requises pour la version finale , qu ' il y aura suffisament d' espace disque pour supporte ces multiples a niveaux :
telechargements de paquets , decompression , installation multiples , on prend le temps de sauvegarder ses fichiers persos , et surtout , on vient demander sur le forum , avant que ca soit la panique a bord ...

bref ca ne s ' improvise pas comme ca .
on ne sait meme pas si ton processeur est compatible 64 bit par exemple , si tu as au moins 2 Gigas de RAM ...

Bybeu · Le 31/03/2023, à 22:48

Bonsoir Iznobe
Je n'ai pas voulu spammer ce nouveau fil avec des détails pas forcément utiles. J'ai déjà upgradé des 16/18.04 vers la 22.04 sur des PC vraiment bien plus vieux que celui-ci. Lui il est sur une MoBo MSI FM2/FM2+ avec un APU A8-5600K, 16Go de RAM PC3-1600 et 3 SSD crucial : un M4 de 64Go avec 20Go pour / en mode MBR et le reste non partitionné, un MX500 de 500Go pour /home et un autre MX500 avec 4Go de swap, ~1,9To pour /srv et 10Go pour /var
D'autre part la live 22.04 fonctionne sans problème apparent.

Dernière modification par Bybeu (Le 01/04/2023, à 11:58)

iznobe · Le 31/03/2023, à 23:10

Dans ce cas , il doit etre compatible .

montre

df -Th

si tu peux .
Sinon j ' espere que tu as tout bien sauvegarder e que tu pourras tout remettre en place proprement apres une reinstall , si besoin .

EDIT : vu :

Au redémarrage il y a plein de tempos de 1mn30 pour des Start jobs pour des xxxxxx.device et ça se finit par un petit message en mode graphique sur l'écran qui indique un problème de détection de video et d'input device que je dois ~ "corriger moi-même", mais ni la souris ni le clavier ne fonctionnent, donc pas de Ctrl+Alt+Fx possibles => reset, et choix du mode Recovery sur l'écran de grub (qui marche très bien lui :-) ).
Là je tombe sur le menu semi-graphique en mode texte prévu, mais inutilisable : tout pourri pas des messages qui arrivent par dessus (style "Taper Ctrl et D ou Entrée pour continuer") et le clavier qui ne fonctionne pas pour sélectionner une option dans le menu... je peux fournir des photos de l'écran ou autre chose.

si le clavier ne fonctionne nulle part , jen e vois pas trop comment faire pour depanner .
un chroot ou bien , un mode recovery , mais vu l' etat de l' OS ...

Donc +1 pour une reinstall @Vobul .

Dernière modification par iznobe (Le 31/03/2023, à 23:15)

Bybeu · Le 01/04/2023, à 09:59

Bonjour les gars
J'ai réussi à avoir une console root à partir du menu Recovery quand il était tout pourri, avec la touche Echap. Clavier en français, les man fonctionnent
J'ai fait des photos si besoin, il n'est pas mort , je recopie :

root@nux:~# cd /
root@nux:/# df -Th
Sys. de fichiers Type      Taille Utilisé Dispo Uti% Monté sur
udev             devtempfs   7,5G       0  7,5G   0% /dev
tmpfs            tmpfs       1,5G    8,7M  1,5G   1% /run
/dev/sda1        ext4         20G     11G  8,5G  55% /
tmpfs            tmpfs       7,5G       0  7,5G   0% /dev/shm
tmpfs            tmpfs       5,0M       0  5,0M   0% /run/lock
tmpfs            tmpfs       7,5G       0  7,5G   0% /sys/fs/cgroup
tmpfs            tmpfs       100K       0  100K   0% /run/cgmanager/fs
root@nux:/#

Et j'ai le reste si vous avez besoin* (fstab, lsblk avec les UUID)
Et un diff entre le nouveau /etc/default/grub et mon backup ?

* disons que j'aimerais bien que vous ayez besoin

Dernière modification par Bybeu (Le 01/04/2023, à 11:30)

Bybeu · Le 01/04/2023, à 13:11

Et si je remettais mon backup du fichier de conf grub en place et update-grub derrière ? C'est risqué ?

Dernière modification par Bybeu (Le 01/04/2023, à 13:12)

Bybeu · Le 01/04/2023, à 18:01

Ça change rien, sauf qu'avec update-grub j'ai eu 6 erreurs
mkdir : impossible de créer le répertoire "/var/lib/os-prober/mount": Aucun fichier ou dossier de ce type
Normal /var n'est pas dispo, (ni /home ni swap)
J'ai essayé en remplaçant les UUID dans fstab, c'est pareil sauf que pendant le boot au lieu de timeout sur des uuid j'ai des time out sur des dev-sdbX /sdcX

iznobe · Le 02/04/2023, à 00:04

Ton systeme est completement en vrac .

Vu que tu as un acces en recovery , c ' est le moment d' en profiter , si tu nes l' as pas fai avant , pour sauvegarder tes documents persos et serveur .

Ensuite une bonne reinstalle toute fraiche et c ' est reparti pour 10 ans pépère

Bybeu · Le 02/04/2023, à 08:03

Bonjour Iznobe
Je n'arrive pas à m'y résoudre, il y a tellement de boulot de conf là-dedans que ça me démoralise complètement de m'imaginer m'y remettre. Et puis je trouve que c'est plus instructif et excitant de dépanner que faire comme sur Windows, réinstaller.
En attendant, j'arrive parfois à rebooter en mode recovery et (le plus dur et mystérieux) obtenir une console root qui fonctionne très bien, au lieu d'avoir un clavier (changé, d'un USB à un PS/2 mais sans effet) sur lequel il faut parfois taper 2 fois ou plus sur les touches pour avoir un retour à l'écran et là alors même les commandes de base ne fonctionnent pas () et l'historique des commandes affiche des tronçons des commandes que je viens de tenter ???

Alors voilà où j'en suis : après avoir réussi à avoir une console root 100% OK j'ai réussi à remonter manuellement mes partitions /var (et /home pour me faire un petit plaisir avec quelque chose qui marche) avec des mount /var et mount /home, facile, référencés dans fstab. Maintenant, mon challenge suivant est de réactiver dans le fstab les lignes avec les UUID et voir si je réussis à refaire, après reboot et remontage manuel, les update-grub et update-initramfs -u que j'ai réussi (echo $? => 0) avec les montages en /dev/sdX.
Étape suivante, monter à la mano une clé USB pour copier des bouts de logs pour poster sur des forums.

...
[DEPEND] Dependency failed for Daily rotation of log files
[DEPEND] Dependency failed for Process errorXreporting is enabled (file watch).
         Starting Tell Plymouth To Write Out Runtime Data...
[  OK  ] Started Emergency Shell.
[  OK  ] Started Tell Plymouth To Write Out Runtime Data.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Appuyer sur Entrée pour la maintenance
(ou appuyez sur Ctrl et D pour continuer) :

Je crois que c'est à partir de là, après avoir fait Ctrl+D plusieurs fois et que ça tourne en boucle sur l'écran ... :

...
(ou appuyez sur Ctrl et D pour continuer) : (<- ben allez, Ctrl+D encore, ça fera jamais que 4 ou 5 fois)
Reloading system manager configuration
Starting default target
You are in emergency mode....

... qu'on peut enfin taper Entrée pour avoir une console root qui marche... Ben non, Entrée à ce moment, ça relance le "Menu de récupération (état du système de fichiers : lecture seule) inutilisable GRRRRR Ctrl+C, Redémarrage normal => écran noir => Ctrl+Alt+Suppr. Je tente sur noyau 4.4.0-127-generic (recovery mode) au lieu du 4.15.0-208-generic pour voir...

iznobe · Le 02/04/2023, à 08:09

Salut , pour commencer , 4 versions d ' ecart tu te doutes bien que la plupart des logiciels ont evolués , et ne gerent plus les choses de la meme maniere . les reglages que tu possedais donc en 16.04 ont tres peu de chances d' etre compatible en 22.04 .
Tu gagneras du temps a tout reinstaller proprement , il y a tres tres peu de chances que meme si tu arrives a demarrer normalement , tout refonctionne normalement ensuite ... ni que tu puisses faire les MAN suivantes ...

-------------------------------------------

Sinon , avec :

lsblk -fe7

tu peux recuperer les bons UUID de tes partitions .
avec

sudo mount -av

, tu verras les points de montages posant probleme , et , editer ensuite ton fstab de façon a corriger au moins les soucis là .

avec

sudo dpkg --configure -a

tu pourras tenter de finaliser l' installation de paquets ayant echoué precedemment si il y en a , et que tu disposes de l' acces au net .

-------------------------------------------

pour les retours que tu donnes , on ne sait pas d ' ou cela provient , tu as tapé une commande pour les obtenir ? laquelle ? tu ne la montres pas .
c ' est ce que montre le recovery mode ?

il t ' indique une commande qui permettrade visualisez ce qui pose soucis :

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs

Dernière modification par iznobe (Le 02/04/2023, à 08:21)

Bybeu · Le 02/04/2023, à 08:38

Salut Iznobe, bon dimanche. Toujours fidèle au poste ?
Les retours que je donne ne sont après aucune commande, c'est juste une recopie de la fin de l'affichage du démarrage.
Got it !!!! : Console de recovery pourrie
En ajoutant rescue à la ligne linux ça zappe le menu et on tombe directement en console root propre, y'a plus de race entre process, non mais ça puait vraiment le mauvais pâté ranci ça !
Je m'en vais remettre mon fstab au carré et je vais regarder tes conseils. Mais déjà, je peux te dire que j'avais déjà regardé journalctl -xb et que les erreurs de montage y étaient bien confirmées. Le problème c'était de pouvoir les analyser ou poster ici ... sans recopier à la mano (fastidieux)...dommage que le forum ne permettre pas de poster des photos, y'a des fois où ça serait bien pratique, avec une charte de bonne conduite, rien que pour les pb de boot ( ) Bon, là ça avance
@+

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

iznobe · Le 02/04/2023, à 09:19

c ' est deja le cas , on n ' est pas si fermé que ca

Quand on ne peut pas faire de copier coller , on a la possibilité de mettre des photos .
Il faut cependant les heberger soit meme sur un site comme imgbb ou zupimages puis transmettre le lien ( ou miniature ) .

Cependant comme @Vobul et moi , t ' avons deja conseillé , tu gagneras finalement du temps a tout reinstaller au propre .

il ya de toute façons apres moultes modifications ou pas , un moment , ou tu seras forcé d ' y venir . tout le temps que tu auras passé a tenter de reparer sera perdu . sachant qu en plus il reste 2 MAN a effectuer ...c ' est peine perdue de s ' obstiner a vouloir reparer .

Dernière modification par iznobe (Le 02/04/2023, à 09:21)

xubu1957 · Le 02/04/2023, à 09:21

Bonjour,

Voir > [Tuto] Poster une image

Bybeu · Le 02/04/2023, à 10:58

root@nux:~# man mount
...
Note  that it is a bad practice to use mount -a for fstab check-
ing. The recommended solution is findmnt --verify.
...

root@nux:~# lsblk -fe7|more    <- jolie celle-là +1
NAME   FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
|_sda1 ext4         09ecdff0-44fe-437e-8063-deabc6feb00e    8,5G
root@nux:~#

root@nux:~# findmnt --verify
Success, no errors or warnings detected
root@nux:~# findmnt -x --verbose|more
/
   [ ] la cible existe
   [ ] Options VFS : noatime
   [ ] Options FS : errors=remount-ro
   [ ] UUID=09ecdff0-44fe-437e-8063-deabc6feb00e traduit en /dev/sda1
   [ ] la source /dev/sda1 existe
   [ ] FS de type ext4
/home
   [ ] la cible existe
   [ ] UUID=e80baa09-5e4b-4c29-9d0b-bc265f8384f4 traduit en /dev/sdc1
   [ ] la source /dev/sdc1 existe
   [ ] FS de type ext4
/srv
   [ ] la cible existe
   [ ] UUID=7323407c-7d0b-4acd-8299-c8f3787111ff traduit en /dev/sdb2
   [ ] la source /dev/sdb2 existe
   [ ] FS de type ext4
/var
   [ ] la cible existe
   [ ] UUID=ffac7b81-b405-480b-8681-107e9ef9870a traduit en /dev/sdb3
   [ ] la source /dev/sdb3 existe
   [ ] FS de type ext4
none
   [ ] UUID=66392631-7c4f-4773-8614-4c5ea0913890 traduit en /dev/sdb1
   [ ] la source /dev/sdb1 existe
   [ ] FS de type swap
Success, no errors or warnings detected
root@nux:~#

Bon j'ai perdu u gros bout de mon post à cause du timeout de connexion au forum
Là ça gaze, alors j'abrège mes manips. J'ai mes partitions montées, plus la clé usb où j'ai trouvé des logs d'hier vers 16h. Curieux disais-je, j'ai rien demandé à partir de la clé. Bon mais grâce à tout ça je peux faire du copier/coller

Bybeu · Le 02/04/2023, à 16:49

Vraiment difficile. J'ai réussi à mettre le réseau en console root avec /etc/network/interfaces et /etc/resolv.conf puis systemctl restart networking.
Mais

root@nux:~# dpkg --configure -a
dpkg: erreur: impossible d'accéder au répertoire administratif de dpkg: aucun fichier ou dossier de ce type
root@nux:~#

Je soupçonne que ma partition /var (/dev/sdb3) ne soit pas montée. En fait je ne peux pas démonter /var pour remonter ma vraie /var. Et bingo, il n'y a dans la /var de la console root que des fichiers récents. Si je monte ma /dev/sdb3 dans /media/root/var j'y retrouve plein de fichiers anciens...

xubu1957 · Le 02/04/2023, à 16:55

Avec :

dpkg: erreur: impossible d'accéder au répertoire administratif de dpkg: aucun fichier ou dossier de ce type

Je trouve une réponse d'inbox, avec ce lien.

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

Merci Xubu
J'avais vu ce lien. Je viens encore de réessayer mais

root@nux:~# mount -o remount,rw /dev/sdb3 /var
mount: /var: point de montage non monté ou mauvaise option

Alors qu'avec / ça marche. J'ai aussi essayé avec l'option -l (lazzy), pareil. En fait /var est buzy. / aussi mais comme c'est le montage d'origine au boot ça passe quand-même je pense.
Je vais devenir expert en mount si ça continue, dire que depuis 15 ans que je suis sur Linux cette commande me faisait un peu flipper
Et umount /var m'envoie une erreur "/var non monté" (même retour echo $? 32)... et oui ça ressemble à un répertoire volatile, j'ai cru voir passer un truc comme ça dans les logs (mais sans détail sur les répertoires en question - pareil mes modif sur le réseau sont à moitié persistantes : interfaces est gardée, mais pas resolv.conf (en fait c'est un lien qui pointe vers /run/resolconf/resolv.conf recréé à chaque boot comme /run)).
Je viens de vérifier : mes modifs dans /etc/fstab survivent bien au reboot... j'ai eu une goutte de sueur qui a perlé au front.

En fait tout ça c'est des particularités de la console root je pense. J'ai envie de booter sur clé live et de copier tout dev/sdb3/* dans /sda1/var. J'en profiterai pour retailler / à tout le disque. Ces histoires de partitions dédiées, c'est pénible, peut-être has-been. Le seul intérêt que j'y ai trouvé y'a pas longtemps c'est en cas de récup de données avec photorec : s'il y avait eu un disque physique pour les données (ou les $HOME) ça m'aurait évité de récupérer 350000 fichiers inutiles

L'idéal me semble-t-il serait que je trouve la raison de ces problèmes de dépendances non satisfaites pour les montages au boot.
Je vérifie que /dev/sda1/var est bien vide et je reviens... (il faut bien monter les devices block dans des répertoires vides n'est-ce pas ?)
@+

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

geole · Le 02/04/2023, à 18:55

Bonjour.
Rapidement.
On monte les partitions sur des répertoires.
Si ces répertoires ne sont pas vide, le contenu est masqué et ne redeviendra accessible qu'au démontage de la partition.
Tu devrais définir le montage de tes trois partitions ( home var srv ) dans le fichier fstab et non en faire un montage ultérieur.

Pour une visualisation plus simple des anomalies, au lieu de frapper

journalctl -xb

qui est conseillée, frappe plutôt

journalctl --no-pager -b -p err

qui est souvent suffisante pour détecter les erreurs.
Tu photographies et tu postes la photo dans un site et tu donnes le lien
Tu donnes aussi le contenu de /etc/fstab car il est certainement dans un drole d'état

Dernière modification par geole (Le 02/04/2023, à 18:58)

Bybeu · Le 02/04/2023, à 21:34

Bonsoir geole

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdh1 during installation
UUID=09ecdff0-44fe-437e-8063-deabc6feb00e /               ext4    noatime,errors=remount-ro 0       1

# /home was on /dev/sdf1 during installation
#/dev/sdc1 /home           ext4    defaults        0       2
UUID=e80baa09-5e4b-4c29-9d0b-bc265f8384f4 /home           ext4    defaults        0       2

# /srv was on /dev/sdg2 during installation
#/dev/sdb2 /srv            ext4    defaults        0       2
UUID=7323407c-7d0b-4acd-8299-c8f3787111ff /srv            ext4    defaults        0       2

# /tmp was on /dev/sdg3 during installation
#UUID=7b9d93fc-6898-4085-8117-7f1c76fd8a28 /tmp            ext4    defaults        0       2
#tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=2G           0       0

# /var was on /dev/sdg4 during installation
#/dev/sdb3 /var            ext4    defaults        0       2
UUID=ffac7b81-b405-480b-8681-107e9ef9870a /var            ext4    defaults        0       2

# swap was on /dev/sdg1 during installation
#/dev/sdb1 none            swap    sw              0       0
UUID=66392631-7c4f-4773-8614-4c5ea0913890 none            swap    sw              0       0

Pour la suite comme ça dépassait de l'écran j'ai fait une redirection vers une clé USB et j'ai collé ci-dessous

-- Logs begin at Sun 2023-04-02 22:11:15 CEST, end at Sun 2023-04-02 22:16:07 CEST. --
avril 02 22:11:15 nux kernel: [Firmware Bug]: AMD-Vi: IOAPIC[0] not in IVRS table
avril 02 22:11:15 nux kernel: [Firmware Bug]: AMD-Vi: No southbridge IOAPIC found
avril 02 22:11:15 nux kernel: AMD-Vi: Disabling interrupt remapping
avril 02 22:11:15 nux systemd[1]: /lib/systemd/system/systemd-udevd.service:26: Executable path is not absolute: udevadm control --reload --timeout 0
avril 02 22:11:15 nux systemd[1]: /lib/systemd/system/systemd-udev-trigger.service:22: Executable path is not absolute: udevadm trigger --type=subsystems --action=add
avril 02 22:11:15 nux systemd[1]: /lib/systemd/system/grub-common.service:10: Executable path is not absolute: grub-editenv /boot/grub/grubenv unset recordfail
avril 02 22:11:15 nux systemd[1]: /lib/systemd/system/systemd-hwdb-update.service:25: Executable path is not absolute: systemd-hwdb update
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-66392631\x2d7c4f\x2d4773\x2d8614\x2d4c5ea0913890.device.
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-e80baa09\x2d5e4b\x2d4c29\x2d9d0b\x2dbc265f8384f4.device.
avril 02 22:12:45 nux systemd[1]: sysinit.target: Job grub-initrd-fallback.service/start deleted to break ordering cycle starting with sysinit.target/start
avril 02 22:12:45 nux systemd[1]: sysinit.target: Unable to break cycle starting with sysinit.target/start
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-ffac7b81\x2db405\x2d480b\x2d8681\x2d107e9ef9870a.device.
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-7323407c\x2d7d0b\x2d4acd\x2d8299\x2dc8f3787111ff.device.
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-66392631\x2d7c4f\x2d4773\x2d8614\x2d4c5ea0913890.device.
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-e80baa09\x2d5e4b\x2d4c29\x2d9d0b\x2dbc265f8384f4.device.
avril 02 22:14:15 nux systemd[1]: grub-initrd-fallback.service: Job sysinit.target/start deleted to break ordering cycle starting with grub-initrd-fallback.service/start
avril 02 22:14:15 nux systemd[1]: sysinit.target: Unable to break cycle starting with sysinit.target/start
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-ffac7b81\x2db405\x2d480b\x2d8681\x2d107e9ef9870a.device.
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-7323407c\x2d7d0b\x2d4acd\x2d8299\x2dc8f3787111ff.device.

Je regarde le lien plus haut pour voir comment poster les photos.

PS : je suis obligé de booter en recovery mode et en remplaçant recovery par rescue dans grub (voir lien "got it" plus haut)

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

geole · Le 02/04/2023, à 22:25

Bybeu a écrit :

# /etc/fstab: static file system information.
UUID=e80baa09-5e4b-4c29-9d0b-bc265f8384f4 /home           ext4    defaults        0       2
UUID=7323407c-7d0b-4acd-8299-c8f3787111ff /srv            ext4    defaults        0       2
UUID=ffac7b81-b405-480b-8681-107e9ef9870a /var            ext4    defaults        0       2
UUID=66392631-7c4f-4773-8614-4c5ea0913890 none            swap    sw              0       0

Pour la suite comme ça dépassait de l'écran j'ai fait une redirection vers une clé USB et j'ai collé ci

-- Logs begin at Sun 2023-04-02 22:11:15 CEST, end at Sun 2023-04-02 22:16:07 CEST. --
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-66392631\x2d7c4f\x2d4773\x2d8614\x2d4c5ea0913890.device.
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-e80baa09\x2d5e4b\x2d4c29\x2d9d0b\x2dbc265f8384f4.device.
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-ffac7b81\x2db405\x2d480b\x2d8681\x2d107e9ef9870a.device.
avril 02 22:12:45 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-7323407c\x2d7d0b\x2d4acd\x2d8299\x2dc8f3787111ff.device.
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-66392631\x2d7c4f\x2d4773\x2d8614\x2d4c5ea0913890.device.
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-e80baa09\x2d5e4b\x2d4c29\x2d9d0b\x2dbc265f8384f4.device.
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-ffac7b81\x2db405\x2d480b\x2d8681\x2d107e9ef9870a.device.
avril 02 22:14:15 nux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-7323407c\x2d7d0b\x2d4acd\x2d8299\x2dc8f3787111ff.device.

Cela fait 4 partitions qui refusent d'être montées automatiquement.
Auraient-ellles changé d'uuid? Les disques seraient-ils en mauvais état? voir débranchés.
si tu disposes d'un support d'installation quelconque, fais un boot-info. https://doc.ubuntu-fr.org/tutoriel/boot-info
Sinon reboote et au plantage, fais cette commande.

blkid

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

Bybeu · Le 02/04/2023, à 22:35

image1
image2

geole · Le 02/04/2023, à 22:52

boot-info avec ton support d'installation 22.04

Bybeu · Le 02/04/2023, à 22:53

blkid
/dev/sda1: UUID="09ecdff0-44fe-437e-8063-deabc6feb00e" TYPE="ext4" PARTUUID="000470aa-01"
/dev/sdb1: UUID="66392631-7c4f-4773-8614-4c5ea0913890" TYPE="swap" PARTUUID="0002e7a0-01"
/dev/sdb2: UUID="7323407c-7d0b-4acd-8299-c8f3787111ff" TYPE="ext4" PARTUUID="0002e7a0-02"
/dev/sdb3: UUID="ffac7b81-b405-480b-8681-107e9ef9870a" TYPE="ext4" PARTUUID="0002e7a0-03"
/dev/sdc1: UUID="e80baa09-5e4b-4c29-9d0b-bc265f8384f4" TYPE="ext4" PARTUUID="00049bc6-01"
/dev/sdd1: UUID="2023-02-23-04-13-44-00" LABEL="Ubuntu 22.04.2 LTS amd64" TYPE="iso9660" PARTLABEL="ISO9660" PARTUUID="a0891d7e-b930-4513-94d8-f629dbd637b2"
/dev/sdd2: SEC_TYPE="msdos" LABEL_FATBOOT="ESP" LABEL="ESP" UUID="F7DB-4D56" TYPE="vfat" PARTLABEL="Appended2" PARTUUID="a0891d7e-b930-4513-94db-f629dbd637b2"
/dev/sdd4: LABEL="writable" UUID="ecd7ee80-c4f4-11ed-a3b2-f754ab66d4f7" TYPE="ext4" PARTUUID="8edcaf39-9068-614b-af17-3a34ccb3b5c4"
/dev/sdd3: PARTLABEL="Gap1" PARTUUID="a0891d7e-b930-4513-94da-f629dbd637b2"

Les 4 partitions ne sont pas sur /dev/sda
/ est sur sda1

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

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

Rapport de boot

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 31/03/2023, à 21:28

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

#2 Le 31/03/2023, à 22:21

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

#3 Le 31/03/2023, à 22:36

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

#4 Le 31/03/2023, à 22:48

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

#5 Le 31/03/2023, à 23:10

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

#6 Le 01/04/2023, à 09:59

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

#7 Le 01/04/2023, à 13:11

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

#8 Le 01/04/2023, à 18:01

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

#9 Le 02/04/2023, à 00:04

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

#10 Le 02/04/2023, à 08:03

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

#11 Le 02/04/2023, à 08:09

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

#12 Le 02/04/2023, à 08:38

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

#13 Le 02/04/2023, à 09:19

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

#14 Le 02/04/2023, à 09:21

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

#15 Le 02/04/2023, à 10:58

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

#16 Le 02/04/2023, à 16:49

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

#17 Le 02/04/2023, à 16:55

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

#18 Le 02/04/2023, à 17:55

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

#19 Le 02/04/2023, à 18:55

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

#20 Le 02/04/2023, à 21:34

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

#21 Le 02/04/2023, à 22:25

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

#22 Le 02/04/2023, à 22:35

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

#23 Le 02/04/2023, à 22:52

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

#24 Le 02/04/2023, à 22:53

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

#25 Le 02/04/2023, à 23:04

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

Pied de page des forums