Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

Goudinette · Le 04/05/2025, à 22:02

Bonjour,
j'auto-héberge à des fins personnelles quelques services (cloud, mails, xmpp...).
Le serveur est constitué d'un Raspberry Pi 5 sous Ubuntu Server 24.04 et deux clés USB montées en Raid1 pour les données et j'y accède par SSH depuis un ordi portable.
Tout allait bien jusqu'à aujourd'hui et une mise à jour du noyau Linux.
Au reboot du serveur, j'ai trouvé le temps anormalement long.
J'ai donc branché le Raspberry sur mon téléviseur et j'ai constaté qu'il ne reconnaissait pas les deux clés USB et finissait par démarrer en mode dégradé en me demandant de taper sur "Entrée" ou "Ctrl D".
J'ai branché un clavier sur un port USB disponible mais impossible de taper quoi que ce soit.
En testant un autre OS sur une carte micro SD différente, le clavier fonctionne. J'en déduis qu'il ne s'agit pas d'un problème matériel mais logiciel.

Je ne trouve rien de probant dans les logs.
Log de Apt (pour voir les mises à jour effectuées) :

Start-Date: 2025-05-04  17:25:13
Commandline: apt upgrade
Requested-By: ubuntu (1000)
Install: linux-modules-6.8.0-1024-raspi:arm64 (6.8.0-1024.28, automatic), linux-image-6.8.0-1024-raspi:arm64 (6.8.0-1024.28, automatic), linux-tools-6.8.0-1024-raspi:arm64 (6.8.0-1024.28, automatic), linux-raspi-headers-6.8.0-1024:arm64 (6.8.0-1024.28, automatic), linux-headers-6.8.0-1024-raspi:arm64 (6.8.0-1024.28, automatic), linux-raspi-tools-6.8.0-1024:arm64 (6.8.0-1024.28, automatic)
Upgrade: linux-tools-common:arm64 (6.8.0-58.60, 6.8.0-59.61), libfwupd2:arm64 (1.9.28-0ubuntu1~24.04.1, 1.9.29-0ubuntu1~24.04.1ubuntu1), apparmor:arm64 (4.0.1really4.0.1-0ubuntu0.24.04.3, 4.0.1really4.0.1-0ubuntu0.24.04.4), libapparmor1:arm64 (4.0.1really4.0.1-0ubuntu0.24.04.3, 4.0.1really4.0.1-0ubuntu0.24.04.4), ubuntu-pro-client-l10n:arm64 (34~24.04, 35.1ubuntu0~24.04), cloud-init:arm64 (24.4.1-0ubuntu0~24.04.2, 24.4.1-0ubuntu0~24.04.3), distro-info-data:arm64 (0.60ubuntu0.2, 0.60ubuntu0.3), libsdl2-2.0-0:arm64 (2.30.0+dfsg-1build3, 2.30.0+dfsg-1ubuntu3.1), linux-headers-raspi:arm64 (6.8.0-1020.24, 6.8.0-1024.28), linux-raspi:arm64 (6.8.0-1020.24, 6.8.0-1024.28), linux-image-raspi:arm64 (6.8.0-1020.24, 6.8.0-1024.28), fwupd:arm64 (1.9.28-0ubuntu1~24.04.1, 1.9.29-0ubuntu1~24.04.1ubuntu1), linux-libc-dev:arm64 (6.8.0-58.60, 6.8.0-59.61), ubuntu-pro-client:arm64 (34~24.04, 35.1ubuntu0~24.04)
End-Date: 2025-05-04  17:28:34

Le log système s'arrête à la désactivation de tous les services lors du reboot.
Donc me voilà un peu désemparé.
Si quelqu'un a une idée du problème, je lui en serai reconnaissant !

geole · Le 04/05/2025, à 22:35

Bonsoir.
Il faudrait probablement regarder le problème du boot.

journalctl --no-pager -b -p warning

Cependant, le serveur devrait pouvoir rebooter avec le noyau précédant.

Dernière modification par geole (Le 04/05/2025, à 22:38)

Goudinette · Le 05/05/2025, à 09:14

Bonjour,
Merci pour la réponse.
Le problème, c'est que je ne peux pas utiliser le clavier.
Je peux éventuellement lire les logs sur la carte micro SD en l'insérant dans un autre ordi mais comme je l'ai dit, je n'ai rien trouvé pour m'orienter sur une piste (ou alors j'ai mal cherché, ce qui est tout aussi plausible !).
Je ne sais pas non plus comment booter sur le noyau précédent. Il ne semble pas y avoir de grub et j'hésite à modifier les fichiers dans le répertoire de boot.

xubu1957 · Le 05/05/2025, à 09:32

Bonjour,

Le 29/05/2017, moko138 a écrit :

Démarrer sur un noyau précédent
- redémarre en tapotant les touches Majuscules ou Echap
- à l'apparition du menu de grub, descends avec la flèche bas, sur la ligne :
Linux previous versions
ou
Advanced options for Ubuntu
- valide
- choisis un noyau autre que le plus récent.
- valide et laisse le pc poursuivre son démarrage.

Le 03/12/2022, nany a écrit :

Quand on a réussi à afficher le menu de GRUB, il faut alors aller sur la deuxième ligne (Advanced options for Ubuntu ou Options avancées pour Ubuntu en français) puis valider pour faire apparaître un sous-menu où il est alors possible de choisir une autre version de noyau.

Doc recovery_mode

Goudinette · Le 05/05/2025, à 10:26

Bonjour,
ça ne fonctionne pas. Enfin si, mais pas comme attendu : l'appui sur MAJ ou Echap ouvre une page Raspberry qui veut me faire installer un OS par le réseau, ce dont je n'ai pas envie.
Je pense que le boot du Raspberry est particulier.

Sinon j'ai remarqué un message d'erreur pendant le boot :

[ TIME ] Timed out waiting for device dev-md0.device - /dev/md0.
[DEPEND] Dependency failed for systemd fsck@dev-md0.service - File System Check on /dev/md0.
[DEPEND] Dependency failed for media-data.mount - /media/data.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.

/dev/md0 sont mes deux clés USB en Raid1 normalement montées sur /media/data. L'erreur semble confirmer qu'à un moment donné les ports USB ne sont plus reconnus.

geole · Le 05/05/2025, à 10:38

Goudinette a écrit :

Je peux éventuellement lire les logs sur la carte micro SD en l'insérant dans un autre ordinateur.
Il ne semble pas y avoir de grub..

Bonjour.
Il faut trouver une piste de l'incident. Elle est très certainement dans les fichiers de log.

Il y a toujours un grub. Mais, en standard, il fait tout pour passer inaperçu. Il n'est pas toujours facile de le rendre visible.

Remarques
1) Tu peux toujours accéder au contenu de tes clés USB depuis un autre ordinateur. Il te suffit d'installer l'application mdadm
2) Je ne pense pas que cela soit une bonne idée d'utiliser deux clés USB en raids. C'est quand même assez fragile.
3) Il se pourrait que la trace montre qu'une des clés ne peut plus se monter. Il faudrait alors monter le raid en mode dégradé. Cela ne se fait pas automatiquement sauf si on utilise ZFS au lieu de MDADM.

Dernière modification par geole (Le 05/05/2025, à 10:39)

iznobe · Le 05/05/2025, à 10:44

Bonjour , je vois pas pourquoi tu en deduis que les ports USB ne sont plus reconnus .
Par contre ce qui est sur , c ' est que , lors du demarrage , il ne peut pas acceder au raid /dev/md0 . qu ' il semble endommagé , et que le systeme demande de faire un fsck dessus .
Tu noteras que des " clés USB " pour installer un OS ( comme des carte SD / micro SD ) dessus , c' est quelquechose de tres peu " solide " a cause du nombre d' ecriture tres limitées avant de causer la mort de celles-ci . Il vaut mieux utiliser un disque dur .

tu pourrais modifier le fichier /etc/fstab sur un autre ordi , pour y enlever le raid du demarrage ( commenter la ligne ) et tenter de redemarrer sans , histoire de voir si cela debloque le demarrage en attendant .

Dernière modification par iznobe (Le 05/05/2025, à 10:48)

geole · Le 05/05/2025, à 10:46

J'avais commencé à rediger ma réponse sans avoir lu cela qui confirme que le raids a un problème.

Goudinette a écrit :

[ TIME ] Timed out waiting for device dev-md0.device - /dev/md0.
[DEPEND] Dependency failed for systemd fsck@dev-md0.service - File System Check on /dev/md0.
[DEPEND] Dependency failed for media-data.mount - /media/data.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.

Sais-tu refabriquer ces clés à partir de données sauvegardées ou faut-il partir à la réparation du raid?

Dernière modification par geole (Le 05/05/2025, à 10:53)

Goudinette · Le 05/05/2025, à 11:40

Même si c'est une possibilité, ce serait quand même une drôle de coïncidence que le raid ait un problème juste au moment du reboot après la mise à jour du noyau.
Ce qui me fait penser plutôt à un problème avec les ports USB, c'est que c'est pareil avec le clavier : il fonctionne au démarrage mais plus quand le système me demande de taper sur Entrée pour la maintenance ou sur CTRL-D pour continuer.

iznobe · Le 05/05/2025, à 11:43

Ok , admettons .
Dans ce cas, il me semble que le meilleur moyen pour commencer à resoudre ton probléme , est alors de demarrer sur l' ancien noyau comme deja proposé , histoire de verifier ce que ca dis sur les ports USB .

Pour cela , il faut mettre la carte SD dans ton ordi et aller modifier le fichier /etc/default/grub .

il y a plusieurs modifications a apporter , mais je n' ai pas mon ordi sous la main ...
Mais heureusement , il y a la doc ubuntu : https://doc.ubuntu-fr.org/tutoriel/grub … er_le_menu

DOC UBUNTU a écrit :

cas 3
Affiché directement avec un décompte de 10s.
Pour Ubuntu 16.04:
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10 # ne pas laisser à zéro si vous voulez avoir le temps de sélectionner éventuellement un autre système.

je pense pas que ca ait beaucoup changer depuis la 16.04 meme si ca date .

Dernière modification par iznobe (Le 05/05/2025, à 11:47)

Goudinette · Le 05/05/2025, à 12:40

Il me semblait avoir lu que Grub n'était pas supporté par le Raspberry Pi. Je n'ai d'ailleurs pas de fichier /etc/default/grub.

Pour en revenir aux ports USB, j'ai inséré dans le Raspberry Pi une autre carte micro-SD avec Ubuntu Server installé dessus mais "nu" et j'ai pu y accéder par SSH.
Si je fais un blkid, je vois ça :

/dev/sdb1: UUID="2759d346-40a7-773b-fdd8-8d7a45930f0a" UUID_SUB="862b880f-a238-5fe6-c7f1-36b22782335b" LABEL="mon.hostname:0" TYPE="linux_raid_member" PARTUUID="1a0694b0-9460-7042-b628-33d250b13f34"
/dev/sda1: UUID="2759d346-40a7-773b-fdd8-8d7a45930f0a" UUID_SUB="12253f3d-8f44-74f8-4b2c-3c7697e80a4b" LABEL="mon.hostname:0" TYPE="linux_raid_member" PARTUUID="186942d5-44c1-cb4e-855b-9d0fa249ec63"

Le noyau linux utilisé par cette carte est la version 6.8.0-1018-raspi alors que celui qui pose problème depuis la mise à jour est la version 6.8.0-1024-raspi.

geole · Le 05/05/2025, à 13:01

Goudinette a écrit :

Même si c'est une possibilité, ce serait quand même une drôle de coïncidence que le raid ait un problème juste au moment du reboot après la mise à jour du noyau..

Il y a une chose que tu ne sembles pas savoir.
Lorsque le raid a un problème, il alerte d'une façon particulière.
Le cas le plus classique est d'installer une application dialoguant avec la messagerie pour recevoir cette alerte et de la traiter correctement.
Cette action n'est pas souvent faite.
Pendant tout ce temps, le raid fonctionne en dégradé puisque tout est en double exemplaire.

Puis arrive la fausse manipulation. On arrête l'ordinateur et le raid ne met plus en route car, en standard, il exige que tout soit en bon état pour mettre en route automatiquement.
On peut donc ramasser cet incident plusieurs mois après l'incident initial pour un serveur qui boote rarement.

Cependant, il existe des commandes manuelles pour forcer son démarrage en mode dégradé.

Je t'ai demandé si son contenu était sauvegardé ou s'il fallait aller le récupérer.

Dernière modification par geole (Le 05/05/2025, à 13:05)

geole · Le 05/05/2025, à 13:17

Goudinette a écrit :

Si je fais un blkid, je vois ça :

/dev/sdb1: UUID="2759d346-40a7-773b-fdd8-8d7a45930f0a" UUID_SUB="862b880f-a238-5fe6-c7f1-36b22782335b" LABEL="mon.hostname:0" TYPE="linux_raid_member" PARTUUID="1a0694b0-9460-7042-b628-33d250b13f34"
/dev/sda1: UUID="2759d346-40a7-773b-fdd8-8d7a45930f0a" UUID_SUB="12253f3d-8f44-74f8-4b2c-3c7697e80a4b" LABEL="mon.hostname:0" TYPE="linux_raid_member" PARTUUID="186942d5-44c1-cb4e-855b-9d0fa249ec63"

.

Pour en connaître un peu plus, publie

cat /proc/mdstat

et en fonction du N° récupéré

 sudo mdadm -D /dev/md0
 sudo mdadm -D /dev/md127

sudo mdadm --examine /dev/sda1 /dev/sdb1

Dernière modification par geole (Le 05/05/2025, à 13:27)

Goudinette · Le 05/05/2025, à 14:18

Le contenu du raid est sauvegardé toutes les nuits sur un vieux NAS Synology.

cat /proc/mdstat

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md127 : active raid1 sda1[0] sdb1[1]
      244324288 blocks super 1.2 [2/2] [UU]
      bitmap: 0/2 pages [0KB], 65536KB chunk

sudo mdadm -D /dev/md127

/dev/md127:
           Version : 1.2
     Creation Time : Thu Feb 15 17:22:42 2024
        Raid Level : raid1
        Array Size : 244324288 (233.01 GiB 250.19 GB)
     Used Dev Size : 244324288 (233.01 GiB 250.19 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon May  5 12:55:55 2025
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : mon.hostname:0
              UUID : 2759d346:40a7773b:fdd88d7a:45930f0a
            Events : 3028

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

sudo mdadm --examine /dev/sda1 /dev/sdb1

/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 2759d346:40a7773b:fdd88d7a:45930f0a
           Name : mon.hostname:0
  Creation Time : Thu Feb 15 17:22:42 2024
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 488648671 sectors (233.01 GiB 250.19 GB)
     Array Size : 244324288 KiB (233.01 GiB 250.19 GB)
  Used Dev Size : 488648576 sectors (233.01 GiB 250.19 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=95 sectors
          State : clean
    Device UUID : 12253f3d:8f4474f8:4b2c3c76:97e80a4b

Internal Bitmap : 8 sectors from superblock
    Update Time : Mon May  5 12:55:55 2025
  Bad Block Log : 512 entries available at offset 16 sectors
       Checksum : 7d8ccf0d - correct
         Events : 3028


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 2759d346:40a7773b:fdd88d7a:45930f0a
           Name : mon.hostname:0
  Creation Time : Thu Feb 15 17:22:42 2024
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 488648671 sectors (233.01 GiB 250.19 GB)
     Array Size : 244324288 KiB (233.01 GiB 250.19 GB)
  Used Dev Size : 488648576 sectors (233.01 GiB 250.19 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=95 sectors
          State : clean
    Device UUID : 862b880f:a2385fe6:c7f136b2:2782335b

Internal Bitmap : 8 sectors from superblock
    Update Time : Mon May  5 12:55:55 2025
  Bad Block Log : 512 entries available at offset 16 sectors
       Checksum : 89e428a1 - correct
         Events : 3028


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

En appliquant ces commandes, je me pose une question : le raid s'appelle ici md127 alors qu'au boot, il cherche (et ne trouve pas) un md0. Est-ce que le problème ne pourrait pas venir de là ?

geole · Le 05/05/2025, à 14:26

Ton NAS est en bon état. Tant mieux (Events : 3028 pour les deux partitions )
Je pense que tu as vu la cause. La mise à niveau logiciel a changé son N°. Il ne te reste plus qu'à rectifier le fstab.
Cependant, ce n'est pas obligatoire qu'il s'appelle md127 dans le PI.

Par acquit de conscience, tente un montage

sudo fsck -yv /dev/md127
sudo mount -v /dev/md127 /mnt
ls -l /mnt
sudo umount -v /dev/md127

Dernière modification par geole (Le 05/05/2025, à 17:51)

Goudinette · Le 05/05/2025, à 16:56

Bon, ç'aurait été trop simple.
Si je monte manuellement le raid avec

sudo mount -v /dev/md127 /media/data

je peux voir le contenu du raid grâce à

ls -l /media/data

En revanche, si j'ajoute dans /etc/fstab la ligne

/dev/md127 	/media/data	ext4	defaults 	0	1

je retrouve exactement le même problème qu'au début, c'est à dire un blocage en cours de boot en "emergency mode" et l'impossibilité de répondre au prompt avec le clavier. :-/

iznobe · Le 05/05/2025, à 17:25

as tu fais le fsck sur le raid comme demandé auparavant ?

Goudinette · Le 05/05/2025, à 18:27

Oui. Voici :

~$ sudo fsck -yv /dev/md127
[sudo] password for goudinette: 
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/md127: clean, 497356/15278080 files, 16216294/61081072 blocks

geole · Le 05/05/2025, à 18:43

Pour éviter le plantage, mets une option
/dev/md127 /media/data ext4 defaults,nofail 0 1

Peux-tu rappeler où actuellement le raids est monté
et peux-tu y faire cette commande

journalctl --no-pager  --since  yesterday -g  "dev/md"

Goudinette · Le 05/05/2025, à 19:15

Le raid est monté sur /media/data. Apparemment, l'ajout de nofail dans /etc/fstab a fonctionné.
Voilà le retour de la commande :

~$ journalctl --no-pager  --since  yesterday -g  "dev/md"
-- Boot eda714baa4be4d5fa69fee385737c9b6 --
May 05 12:33:51 raspi4 root[26132]: mdcheck start checking /dev/md127
May 05 12:33:51 raspi4 mdadm[26143]: mdadm: NewArray event detected on md device /dev/md127
May 05 12:33:51 raspi4 mdadm[26143]: mdadm: RebuildStarted event detected on md device /dev/md127
May 05 12:38:51 raspi4 mdadm[26143]: mdadm: Rebuild21 event detected on md device /dev/md127
May 05 12:43:51 raspi4 mdadm[26143]: mdadm: Rebuild43 event detected on md device /dev/md127
May 05 12:47:51 raspi4 mdadm[26143]: mdadm: Rebuild62 event detected on md device /dev/md127
May 05 12:51:52 raspi4 mdadm[26143]: mdadm: Rebuild80 event detected on md device /dev/md127
May 05 12:56:52 raspi4 mdadm[26143]: mdadm: RebuildFinished event detected on md device /dev/md127
May 05 12:57:51 raspi4 root[27267]: mdcheck finished checking /dev/md127
May 05 14:05:12 raspi4 sudo[27382]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/sbin/mdadm -D /dev/md127
May 05 14:07:27 raspi4 sudo[27390]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/sbin/mdadm -D /dev/md0
May 05 14:23:14 raspi4 mdadm[26143]: mdadm: DeviceDisappeared event detected on md device /dev/md127
-- Boot 86da89c7d0db4115a0143ba026fdf534 --
May 05 14:23:19 raspi4 (udev-worker)[419]: md127: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md127' failed with exit code 1.
May 05 14:23:19 raspi4 mdadm[805]: mdadm: NewArray event detected on md device /dev/md127
May 05 14:46:34 raspi4 mdadm[805]: mdadm: DeviceDisappeared event detected on md device /dev/md127
-- Boot 89440fd414eb4cca8f2dd1f80d0059b3 --
May 05 14:47:01 raspi4 systemd[1]: Expecting device dev-md0.device - /dev/md0...
May 05 14:47:03 raspi4 (udev-worker)[435]: md127: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md127' failed with exit code 1.
May 05 14:47:03 raspi4 mdadm[582]: mdadm: NewArray event detected on md device /dev/md127
-- Boot 0c448964e3204e5494fcd65c4269af72 --
May 05 14:50:04 raspi4 systemd[1]: Expecting device dev-md127.device - /dev/md127...
May 05 14:50:05 raspi4 (udev-worker)[438]: md0: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md0' failed with exit code 1.
May 05 14:50:05 raspi4 mdadm[519]: mdadm: NewArray event detected on md device /dev/md0
-- Boot 63267724b5da4032955808896a10b8c3 --
May 05 14:54:30 raspi4 (udev-worker)[406]: md127: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md127' failed with exit code 1.
May 05 14:54:30 raspi4 mdadm[759]: mdadm: NewArray event detected on md device /dev/md127
-- Boot bb8e76711d404930ac6b0671c8ceae70 --
May 05 14:54:31 raspi4 (udev-worker)[416]: md127: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md127' failed with exit code 1.
May 05 14:54:31 raspi4 mdadm[598]: mdadm: NewArray event detected on md device /dev/md127
May 05 15:22:58 raspi4 sudo[1289]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/sbin/fsck -yv /dev/md0
May 05 15:23:35 raspi4 sudo[1294]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/bin/mount -v /dev/md0 /mnt
May 05 15:23:35 raspi4 kernel: /dev/md0: Can't lookup blockdev
May 05 15:24:20 raspi4 sudo[1298]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/bin/umount -v /dev/md127
May 05 15:24:36 raspi4 sudo[1304]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/sbin/fsck -yv /dev/md127
May 05 15:24:53 raspi4 sudo[1318]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/bin/mount -v /dev/md127 /mnt
May 05 15:30:52 raspi4 mdadm[598]: mdadm: DeviceDisappeared event detected on md device /dev/md127
-- Boot 5d328cd3bd3f4eff916240702af1cecd --
May 05 14:54:34 raspi4 (udev-worker)[413]: md127: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md127' failed with exit code 1.
May 05 14:54:34 raspi4 mdadm[605]: mdadm: NewArray event detected on md device /dev/md127
May 05 16:28:46 raspi4 sudo[1752]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/bin/nano /dev/md127
May 05 16:31:41 raspi4 sudo[1981]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/bin/umount -v /dev/md127
May 05 16:32:14 raspi4 sudo[1990]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/bin/mount -v /dev/md127 /media/data
-- Boot 6edc5ae5f11a4d648994274c46823b4d --
May 05 16:38:31 raspi4 systemd[1]: Expecting device dev-md127.device - /dev/md127...
May 05 16:38:32 raspi4 (udev-worker)[439]: md0: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md0' failed with exit code 1.
May 05 16:38:32 raspi4 mdadm[498]: mdadm: NewArray event detected on md device /dev/md0
May 05 16:40:01 raspi4 systemd[1]: Timed out waiting for device dev-md127.device - /dev/md127.
May 05 16:40:01 raspi4 systemd[1]: Dependency failed for systemd-fsck@dev-md127.service - File System Check on /dev/md127.
-- Boot 4d5f4bbd86344e2a9f8c754e96559462 --
May 05 17:07:56 raspi4 (udev-worker)[410]: md127: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md127' failed with exit code 1.
May 05 17:07:56 raspi4 mdadm[610]: mdadm: NewArray event detected on md device /dev/md127
May 05 18:25:13 raspi4 sudo[1246]:   goudinette : TTY=pts/0 ; PWD=/home/goudinette ; USER=root ; COMMAND=/usr/sbin/fsck -yv /dev/md127
-- Boot 61b2f93f284247349e9161d46a058e53 --
May 05 18:51:26 raspi4 systemd[1]: Expecting device dev-md127.device - /dev/md127...
May 05 18:51:27 raspi4 (udev-worker)[403]: md127: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/md127' failed with exit code 1.
May 05 18:51:27 raspi4 systemd[1]: Found device dev-md127.device - /dev/md127.
May 05 18:51:27 raspi4 mdadm[605]: mdadm: NewArray event detected on md device /dev/md127
May 05 18:51:27 raspi4 systemd[1]: Starting systemd-fsck@dev-md127.service - File System Check on /dev/md127...
May 05 18:51:28 raspi4 systemd-fsck[630]: /dev/md127: clean, 497356/15278080 files, 16216294/61081072 blocks
May 05 18:51:29 raspi4 systemd[1]: Finished systemd-fsck@dev-md127.service - File System Check on /dev/md127.

Par contre, pour arriver à ce résultat, je boote sur un autre Ubuntu Server car je n'arrive pas à reprendre la main sur celui qui est à l'origine du problème.

geole · Le 05/05/2025, à 19:28

Donc c'est normal qu'o, ne voie ce qui s'est passé hier

Pour aujourd'hui on voit un premier fsck qui dure 30 minutes environ

-- Boot eda714baa4be4d5fa69fee385737c9b6 --
May 05 12:33:51 raspi4 root[26132]: mdcheck start checking /dev/md127
May 05 12:33:51 raspi4 mdadm[26143]: mdadm: NewArray event detected on md device /dev/md127
May 05 12:33:51 raspi4 mdadm[26143]: mdadm: RebuildStarted event detected on md device /dev/md127
May 05 12:38:51 raspi4 mdadm[26143]: mdadm: Rebuild21 event detected on md device /dev/md127
May 05 12:43:51 raspi4 mdadm[26143]: mdadm: Rebuild43 event detected on md device /dev/md127
May 05 12:47:51 raspi4 mdadm[26143]: mdadm: Rebuild62 event detected on md device /dev/md127
May 05 12:51:52 raspi4 mdadm[26143]: mdadm: Rebuild80 event detected on md device /dev/md127
May 05 12:56:52 raspi4 mdadm[26143]: mdadm: RebuildFinished event detected on md device /dev/md127
May 05 12:57:51 raspi4 root[27267]: mdcheck finished checking /dev/md127

Au final, cela va bien plus vite maintenant

May 05 18:51:27 raspi4 systemd[1]: Found device dev-md127.device - /dev/md127.
May 05 18:51:27 raspi4 mdadm[605]: mdadm: NewArray event detected on md device /dev/md127
May 05 18:51:27 raspi4 systemd[1]: Starting systemd-fsck@dev-md127.service - File System Check on /dev/md127...
May 05 18:51:28 raspi4 systemd-fsck[630]: /dev/md127: clean, 497356/15278080 files, 16216294/61081072 blocks
May 05 18:51:29 raspi4 systemd[1]: Finished systemd-fsck@dev-md127.service - File System Check on /dev/md127.

Donc il y a eu un incident hier... Un faux contact dans un branchement USB?????

Goudinette · Le 05/05/2025, à 20:06

L'incident s'est produit hier à 17h28 au reboot après une mise à jour du noyau mais il n'y a eu aucune manipulation matérielle.
J'ai aussi ajouté nofail dans le fichier fstab de la carte incriminée et le boot ne se bloque plus au montage du raid et va jusqu'au prompt de login. En revanche, je ne peux toujours pas utiliser le clavier et un message apparaît après quelques secondes (que je ne voyais pas quand ça bloquait) :

brcm-pcie 1000120000.pcie: Unable to find MSI PCI address

geole · Le 06/05/2025, à 17:39

Bonjour
Cela veut probablement dire que le nvme n'est pas détecté.

iznobe · Le 06/05/2025, à 19:18

ca ressembe pas mal à ca non : https://forums.raspberrypi.com/viewtopic.php?t=387259 ? sauf que c' est le noyau seulement qui a été monté .

on ne sait pas si le pi est équipé d' un NVME ou pas , par defaut , c' est une carte micro-sd qui fait office de disque dur .

Dernière modification par iznobe (Le 06/05/2025, à 19:19)

Goudinette · Hier à 09:26

Bonjour,
effectivement, ça a l'air d'être un problème entre le Raspberry Pi 5 et les derniers noyaux, si j'ai bien compris.
Je n'ai pas de NVME et c'est bien la micro-SD qui sert de disque dur.
Bizarrement, je ne peux toujours pas accéder au serveur installé sur la carte problématique, que ce soit par SSH ou en direct par clavier USB alors que ça fonctionne avec une autre carte (même version d'Ubuntu Server et même noyau) malgré les mêmes messages d'erreurs.
La carte problématique n'a pas l'air endommagée et j'y accède sans problème en l'insérant dans mon ordi.
Je n'aurai pas beaucoup de temps dans les jours qui viennent mais je continue les recherches.
Merci à vous pour votre aide, je viendrai dire si j'ai trouvé une solution.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 04/05/2025, à 22:02

Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#2 Le 04/05/2025, à 22:35

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#3 Le 05/05/2025, à 09:14

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#4 Le 05/05/2025, à 09:32

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#5 Le 05/05/2025, à 10:26

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#6 Le 05/05/2025, à 10:38

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#7 Le 05/05/2025, à 10:44

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#8 Le 05/05/2025, à 10:46

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#9 Le 05/05/2025, à 11:40

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#10 Le 05/05/2025, à 11:43

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#11 Le 05/05/2025, à 12:40

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#12 Le 05/05/2025, à 13:01

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#13 Le 05/05/2025, à 13:17

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#14 Le 05/05/2025, à 14:18

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#15 Le 05/05/2025, à 14:26

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#16 Le 05/05/2025, à 16:56

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#17 Le 05/05/2025, à 17:25

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#18 Le 05/05/2025, à 18:27

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#19 Le 05/05/2025, à 18:43

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#20 Le 05/05/2025, à 19:15

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#21 Le 05/05/2025, à 19:28

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#22 Le 05/05/2025, à 20:06

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#23 Le 06/05/2025, à 17:39

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#24 Le 06/05/2025, à 19:18

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

#25 Hier à 09:26

Re : Ports USB inactifs sur Raspberry Pi 5 et Ubuntu Server en mode dégradé

Pied de page des forums