debuguer un pb de boot sur HDD ?

[piper]

Hello,
Voilà le soucis :
J'en ai ma claque des cartes SD qui flanches.
J'ai 4 Pi en fonction, 3 exploitent des disques SSD : pas de soucis pour eux
J'en ai un toujours sur carte SD, il se trouve qu'il est connecté à 4 disques mécaniques de grosses capacités, bien remplis
Evidement c'est ça carte qui a lâché Grrr

Donc j'ai commencé par la changer et réinstaller dessus tout mon bazard système (emby, samba, vsftpd , reconstruire les bases de données de emby .... le temps de scanner les 12To de données des disques , d'interroger imdb , il a fallut 30h).

Bref, ras le bol

Donc je me suis dit : l'un de ces gros disques mécanique à un peu de place (400Go), je vais lui mettre les partoches de la carte SD
Donc retailler la partition des données et les déplacées vers la droite pour avoir un trou : 32h de traitement
Dans l'espace disponible en début de disque obtenu, y mettre une copie des partoches de boot et root de la carte SD : 10 minutes
Modifier les fichiets sur le disque dur du cmd du boot et fstab de rootfs pour préciser qui est /boot et / : 30 secondes
Demander au Pi de booter de préférence sur USB : 30 secondes

Mais rien à faire : il boot sur la carte SD et si elle n'est pas là, il ne boote pas du tout
Précision importante : c'est un Pi headless (pas d'écran, dans une armoire informatique), accessible via le réseau local en ssh

Impossible de savoir ce qui ne va pas : boot.log n'est d'aucune utilité (pas de boot donc pas de boot.log), dmesg non plus : disponible si le boot a fonctionné !

Il y a une trace qui dit ce qui se passe avant de trouver le secteur de boot ?
Sans avoir à brancher un écran ce serait mieux !

A moins que ..... les Pi ne sachent pas du tout démarrer sur un disque mécanique sans un mettre un délais d'accès (pas trouver où ça se gère , même google ne sait pas)

[domi]

Bonjour,

J'ai fait cela sur un RPI 3, je laisse la carte SD juste pour qu'elle indique où booter.
Ma partition principal du DD est /dev/sda1

dans le fichier "cmdline.txt" j'ai changé le root :

Code : Tout sélectionner

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 cgroup_enable=memory elevator=deadline rootwait

Mon FSTAB n'est pas changé, en dehors d'avoir commenté la ligne "/dev/mmcblk0p2" (fstab à modifier sur le DD qui va booter).

Code : Tout sélectionner

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
# /dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
/dev/sda1       /               ext4    defaults,noatime  0       1
/dev/sda2       /home           ext4    defaults        0       2
/dev/sda3       /media/hdd      ext4    defaults        0       2

tmpfs           /tmp            tmpfs   nosuid,nodev         0       0
tmpfs           /var/tmp        tmpfs   nosuid,nodev         0       0

En dehors du cmdline.txt, je n'ai rien changé d'autre sur la SD, le RPI boot sur la carte, et va chercher le système sur le DD. Le système sur la SD ne sert plus à rien. Seule la partition boot de la SD est utilisé au démarrage.

Pour un essai, j'ai débranché le DD USB, le RPI ne boot pas. Je boot donc bien sur le DD lorsqu'il est branché.
ça doit faire 3 ans que le RPI tourne comme ça, et depuis plus de problème.

[jelopo]

Bonjour,

Je suis d'accord avec l'approche de @domi. Lorsque le système est démarré, il n'y a pas d'écritures dans /boot qui est sur la carte SD donc la durée de vie de celle ci n'est pas impactée.

A+

[piper]

OK, vous bootez sur une carte SD et le dossier boot contient l'information disant que le système est sur le HDD
Cette solution (que j'ai déjà utilisé par le passé) ne répond pas au problème : je veux me passer complètement de la carte SD.

En fait, j'ai trouvé et compris qu'il n'y a aucune solution.

Le Pi scanne les 4 ports USB à la recherche de support bootable puis passe au lecteur de carte et recommence sa boucle.
Il s'arrête et démarre le 1er support qu'il trouve.
A chaque étape, sa tentative s'arrête s'il n'a pas trouvé au bout d'un certain temps (timeout) plutôt cours sur chaque port. Mais multiplié par 5 (4 USB + SDCARD) ça semble long lorsqu'il ne trouve rien.

Sauf que ce time out est parfait pour une carte SD, une clé USB, un disque SSD mais insuffisant pour un disque dur mécanique.

[dyox]

Bonjour Piper,

Tu n'as pas précisé le modèle de Pi mais si c'est celui de ta signature, je pars sur un Pi4. As-tu mis à jour le bootloader, on ne sait jamais ?
La partie /boot est bien en FAT32 ?

As-tu essayé usb-storage.quirks ?

Tu as priorisé le boot sur usb, ok. Et tu as 4 DD de 3T. As-tu fais ton bilan de puissance ? Tes dd consomment combien et ton alim est bonne ?
Pour info mes Seagate 4T 2.5" USB3 en charge c'est du 0.6A.
Pour éviter un éventuel appel de courant qui déstabilise l'ensemble des ports usb, je testerai bien avec seulement le dd de l'OS et en laissant la priorité du boot sur la carte sd, même vide.

Je te laisse lire toutes les options et celle-ci parait être intéressante :
https://www.raspberrypi.com/documentati ... R_OFF_TIME

A moins que ..... les Pi ne sachent pas du tout démarrer sur un disque mécanique sans un mettre un délais d'accès (pas trouver où ça se gère , même google ne sait pas)

Ben si, le fichier timeout mais pas pour le Pi4 mais il reste l'option :
If the device fails to respond after this maximum timeout, it is possible to increase the timeout to five seconds using program_usb_boot_timeout=1 in config.txt.
https://www.raspberrypi.com/documentati ... boot-modes

Si tu as laissé "console=ttyAMA0,115200" dans le cmdline, tu as accès la lecture du boot avec un convertisseur usb-TTL mais il te faut un laptop.
ou https://www.raspberrypi.com/documentati ... #BOOT_UART
C'est dommage que tu ne veuilles sortir le Pi de l'armoire, avec un écran tu aurais su toute suite.

Comme dirait notre lolo, RaspiOS est une hérésie sur les cartes sd mais il existe DietPi qui bien mieux appropriée.

Bons essais et tiens nous au courant, bonne journée !!

[piper]

Oui, c'est un Pi4-8Go
Bien sûr le boot loader est à jour, sans quoi, je n'aurai pas pu paramétrer le boot sur port USB en 1er et pas pu voir à l'écran ce qui ce passe (passage d'un port usb à un autre, puis recherche carte SD et recherche à nouveau du 1er port USB).
Oui, 1ère partition : FAT32, montée en /boot , drapeaux : boot/lba, c'est la copie conforme de la partition de boot d'une carte SD faite avec gparted
Oui 2ième ext4, point de montage / c'est la copie conforme de la partition de root d'une carte SD faite avec gparted

Côté puissance c'est simple :
Les disques sont alimentés par une alimentation recyclée de PC de 300W (connexions aux prises molex qui servaient à connecter des disques dur 3,5 pouces en IDE (pour ceux qui se souviennent.... p... je dois être trop vieux)
Ces 300W alimentent les disques durs et la Box (ça devrait suffire, ou alors.... c'est grave)

J'ai re-copié ces partitions sur une clé USB pour voir (même méthode : avec gparted)
Et vou savez quoi ? Ca boot !
Et bien sûr j'ai accès à mes disques dans un explorateur de fichiers.

J'ai commandé un SSD. Ce que je vais faire c'est copier à l'exact les partitions de ce HDD vers le SSD quand je l'aurai reçu
Si ça démarre c'est que un Pi n'est pas fait pour booter sur un disque mécanique que mon disque mécanique WD 2 To n'est pas compatible (genre spécificité du temps de latence au démarrage)

En fait normalement, les 4 ports USB sont occupés par 4 disques mécaniques. Donc ça va finir avec un hub USB alimenté

[Artemus24]

Salut à tous.

Il arrive que certains disque USB ne sont pas compatibles au démarrage sur la Raspberry Pi.

A part cela, as tu configuré le boot USB ? Mettre dans config.txt "program_usb_boot_mode=1".
Puis vérifier par "vcgencmd otp_dump | grep 17" que tu obtiens bien "17:3020000a".

Autre point à vérifier : dans cmdline.txt, pour "root=", je mets le "PARTUUID" qui doit être le même dans FSTAB.

Cordialement.
Artemus24.
@+