Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux erreur bloquante au boot sur un rapspberry pi2

erreur bloquante au boot sur un rapspberry pi2

30 réponses
Avatar
yamo'
Salut,

Désolé si je ne suis pas clair mais, j'ai un problème qui dépasse mes
compétences ; c'est comme ça qu'on apprend...

Sur un raspberry pi2, j'ai une erreur udev qui m'empêche de monter la
racine. Erreur que j'ai suite à mise à jour systemd sur testing (je sais
j'aurais mieux fait de rester en stable).

Comment peut-t'on essayer de réparer?

La console de secours ne fonctionne pas ; j'ai : Root account is locked ...

Le démarrage sur l'ancien système noob ne propose pas de démarrer dessus
et ça ne me propose que des ré-installations ce qui ne m'arrange guère.

J'ai gardé l'ancien fichier de démarrage mais j'aimerais éviter de
bidouiller sans comprendre ce que je fais.

Le démarrage désiré est sur un disque usb2 qui fonctionne (j'ai fait des
checkdisc sur le système d'où j'écris...) :
<https://www.circuidipity.com/pi-usb-storage/>

Auriez-vous des pistes ou de saines lectures à me conseiller pour
comprendre comment réparer?



Merci d'avance,

--
Stéphane
http://pasdenom.info serveur usenet en rade
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Doug713705
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83b595$0$20343$) :
fgrep root /media/yamo/racine/etc/shadow
root:*:16482:0:99999:7:::
Et il a été modifié hier matin (sûrement à initiative du système ; je
n'ai pas touché aux comptes).
ls -al --full-time /media/yamo/racine/etc/shadow
-rw-r----- 1 root shadow 1806 2018-08-26 09:32:58.739999998 +0200
/media/yamo/racine/etc/shadow
Je vais lire les docs...

J'ai enlevé le * en deuxième position.
Je peux maintenant accéder à la console...

Logique puisque dorénavant le compte root n'a plus de mot de passe mais
conserve son autorisation d'accès.
Il faudra donc bien penser à remettre tout ça dans l'ordre ;-)
--
En ce temps-là, nos fleurs vendaient leur viande aux chiens
Et nous habitions tous de sordides tripots
Avec des aiguillages pour nos petits matins,
Quand le beau macadam nous traitait de salauds.
-- H.F. Thiéfaine, Exil Sur planète fantôme
Avatar
Doug713705
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83ad46$0$26730$) :
Comme info complémentaire le fichier /ect/fstab :
proc /proc proc defaults 0 0
/dev/mmcblk0p5 /boot vfat defaults 0 2
/dev/sda1 / ext4 relatime,errors=remount-ro 0 1
#/dev/mmcblk-1p6 / ext4 defaults,noatime 0 1
/dev/mapper/sda2_crypt none swap sw 0 0
#/dev/mapper/sda3_crypt /media/sda3_crypt ext4 defaults,noatime 0 1
#/media/sda3_crypt/spool /var/spool none bind
/dev/mapper/VgData-LvVarSpool /var/spool ext4 rw 0 0
/dev/mapper/VgData-LvDataHome /home ext4 rw 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode77 0 0
###### A tester :
#/dev/mapper/VgData-LvDataBackup /backup ext4 rw 0 0
/dev/mapper/VgData-LvSwap2 none swap sw 0 0
La première ligne avec /proc m'étonne beaucoup ...

Aucune inquiétude de ce coté.
proc est un pseudo système de fichiers qui permet d'atteindre certaines
informations noyau.
Ce n'est pas un périphérique et n'a donc pas d'entrée dans /dev.
Un peu de lecture:
https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html
--
Mais l'ombre des plaisirs s'enfuit
Toujours plus loin vers l'inconnu.
-- H.F. Thiéfaine, La môme kaléïdoscope
Avatar
yamo'
Doug713705 a écrit le 27/08/2018 à 10:33 :
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83b595$0$20343$) :
fgrep root /media/yamo/racine/etc/shadow
root:*:16482:0:99999:7:::
Et il a été modifié hier matin (sûrement à initiative du système ; je
n'ai pas touché aux comptes).
ls -al --full-time /media/yamo/racine/etc/shadow
-rw-r----- 1 root shadow 1806 2018-08-26 09:32:58.739999998 +0200
/media/yamo/racine/etc/shadow
Je vais lire les docs...

J'ai enlevé le * en deuxième position.
Je peux maintenant accéder à la console...

Logique puisque dorénavant le compte root n'a plus de mot de passe mais
conserve son autorisation d'accès.
Il faudra donc bien penser à remettre tout ça dans l'ordre ;-)

Oui, après c'est uniquement accessible en console non?
Quand je fais un ls /dev/mapper je n'ai que control forcément ça n'aide
pas à monter le système...
J'ai tenté d'afficher les Volumes Groupes avec vgs
J'ai pleins de fois :
WARNING: Device /ram0 not initialized un udev database even after
1000000 microseconds
de ram0 à ram15 avec aussi les devices connus de la carte sd
Et à la fin étrangement il me donne la bonne utilisation de VgData...
lvs me donne les bonnes réponses!
Va falloir que j'écrive à la main les règles udev pour remettre à la
bonne place les /ramX <-> /dev/mappper/machinchose?
Comme je peux monter le système de fichier sur un autre ordi y a
peut-être moyen de demander à udev d'écrire un fichier de conf pour son
confrère udev du raspberry?
--
Stéphane
http://pasdenom.info
Avatar
Doug713705
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83b9e0$0$15493$) :
Doug713705 a écrit le 27/08/2018 à 10:33 :
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83b595$0$20343$) :
fgrep root /media/yamo/racine/etc/shadow
root:*:16482:0:99999:7:::
Et il a été modifié hier matin (sûrement à initiative du système ; je
n'ai pas touché aux comptes).
ls -al --full-time /media/yamo/racine/etc/shadow
-rw-r----- 1 root shadow 1806 2018-08-26 09:32:58.739999998 +0200
/media/yamo/racine/etc/shadow
Je vais lire les docs...

J'ai enlevé le * en deuxième position.
Je peux maintenant accéder à la console...

Logique puisque dorénavant le compte root n'a plus de mot de passe mais
conserve son autorisation d'accès.
Il faudra donc bien penser à remettre tout ça dans l'ordre ;-)

Oui, après c'est uniquement accessible en console non?
Quand je fais un ls /dev/mapper je n'ai que control forcément ça n'aide
pas à monter le système...
J'ai tenté d'afficher les Volumes Groupes avec vgs
J'ai pleins de fois :
WARNING: Device /ram0 not initialized un udev database even after
1000000 microseconds
de ram0 à ram15 avec aussi les devices connus de la carte sd
Et à la fin étrangement il me donne la bonne utilisation de VgData...
lvs me donne les bonnes réponses!
Va falloir que j'écrive à la main les règles udev pour remettre à la
bonne place les /ramX <-> /dev/mappper/machinchose?

Ça semble peu probable.
Comme je peux monter le système de fichier sur un autre ordi y a
peut-être moyen de demander à udev d'écrire un fichier de conf pour son
confrère udev du raspberry?

Ça, par contre, ressemble à la pire solution jamais envisagée :)
Ce que tu peux faire:
- Rescanner le PV, VG et LV de manière à faire revenir les dev.
L'option --mknodes te permettra de recréer les dev nodes manquants (c'est
souvent ça qui pose problème lorsque 'on joue avec LVM) mais la commande
ci-dessous devrait se charger de tout:
# vgchange -ay
Je dis ça de mémoire et sans connaître ta machine.
Ceci dit, cette commande devrait être inoffensive, elle ne fait que
raffraîchir les VG.
--
En ce temps-là, nos fleurs vendaient leur viande aux chiens
Et nous habitions tous de sordides tripots
Avec des aiguillages pour nos petits matins,
Quand le beau macadam nous traitait de salauds.
-- H.F. Thiéfaine, Exil Sur planète fantôme
Avatar
yamo'
Doug713705 a écrit le 27/08/2018 à 11:07 :
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83b9e0$0$15493$) :
Doug713705 a écrit le 27/08/2018 à 10:33 :
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83b595$0$20343$) :
fgrep root /media/yamo/racine/etc/shadow
root:*:16482:0:99999:7:::
Et il a été modifié hier matin (sûrement à initiative du système ; je
n'ai pas touché aux comptes).
ls -al --full-time /media/yamo/racine/etc/shadow
-rw-r----- 1 root shadow 1806 2018-08-26 09:32:58.739999998 +0200
/media/yamo/racine/etc/shadow
Je vais lire les docs...

J'ai enlevé le * en deuxième position.
Je peux maintenant accéder à la console...

Logique puisque dorénavant le compte root n'a plus de mot de passe mais
conserve son autorisation d'accès.
Il faudra donc bien penser à remettre tout ça dans l'ordre ;-)

Oui, après c'est uniquement accessible en console non?
Quand je fais un ls /dev/mapper je n'ai que control forcément ça n'aide
pas à monter le système...
J'ai tenté d'afficher les Volumes Groupes avec vgs
J'ai pleins de fois :
WARNING: Device /ram0 not initialized un udev database even after
1000000 microseconds
de ram0 à ram15 avec aussi les devices connus de la carte sd
Et à la fin étrangement il me donne la bonne utilisation de VgData...
lvs me donne les bonnes réponses!
Va falloir que j'écrive à la main les règles udev pour remettre à la
bonne place les /ramX <-> /dev/mappper/machinchose?

Ça semble peu probable.
Comme je peux monter le système de fichier sur un autre ordi y a
peut-être moyen de demander à udev d'écrire un fichier de conf pour son
confrère udev du raspberry?

Ça, par contre, ressemble à la pire solution jamais envisagée :)
Ce que tu peux faire:
- Rescanner le PV, VG et LV de manière à faire revenir les dev.
L'option --mknodes te permettra de recréer les dev nodes manquants (c'est
souvent ça qui pose problème lorsque 'on joue avec LVM) mais la commande
ci-dessous devrait se charger de tout:
# vgchange -ay
Je dis ça de mémoire et sans connaître ta machine.
Ceci dit, cette commande devrait être inoffensive, elle ne fait que
raffraîchir les VG.

Ça a fonctionné (le mount -a a fonctionné)
Mais quand j'active le daemon ssh je perds la main...
Le mode normal est accessible en telinit 3 (pas sûr du 3)?
--
Stéphane
http://pasdenom.info
Avatar
Doug713705
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83c1bb$0$5500$) :
# vgchange -ay
Je dis ça de mémoire et sans connaître ta machine.
Ceci dit, cette commande devrait être inoffensive, elle ne fait que
raffraîchir les VG.

Ça a fonctionné (le mount -a a fonctionné)
Mais quand j'active le daemon ssh je perds la main...

Ce n'est probablement pas lié mais un autre problème, vraissemblableement
lié au problème réseau notifié par systemd (Failed to start Raise network
interfaces).
Sans interface réseau, tu auras du mal à faire écouter un démon sur un
port ;-)
Maintenant que les disques sont réapparus, tu peux tenter de relancer
les services qui ont échoué au boot:
# systemctl networking restart
Pour vérifier la liste des interfaces réseaux configurées:
# ip a
Le mode normal est accessible en telinit 3 (pas sûr du 3)?

Le run level 3 correspond au mode multiuser.
En gros c'est le mode "normal" avant le démarrage d'X.
Lorsque tu es sur un shell de secours le système est probablement en
run level 1 (maintenance, mono utilisateur).
Pour connaître le runlevel dans lequel tu te trouves:
# runlevel
--
L'idiot du village fait la queue
Et tend sa carte d'adhérent
Pour prendre place dans le grand feu
-- H.F. Thiéfaine, Aligator 427
Avatar
yamo'
Doug713705 a écrit le 27/08/2018 à 11:34 :
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83c1bb$0$5500$) :
# vgchange -ay
Je dis ça de mémoire et sans connaître ta machine.
Ceci dit, cette commande devrait être inoffensive, elle ne fait que
raffraîchir les VG.

Ça a fonctionné (le mount -a a fonctionné)
Mais quand j'active le daemon ssh je perds la main...

Ce n'est probablement pas lié mais un autre problème, vraissemblableement
lié au problème réseau notifié par systemd (Failed to start Raise network
interfaces).
Sans interface réseau, tu auras du mal à faire écouter un démon sur un
port ;-)
Maintenant que les disques sont réapparus, tu peux tenter de relancer
les services qui ont échoué au boot:
# systemctl networking restart

J'ai du réseaux j'ai démarré inn2 mais il ne me réponds pas... Tu le
vois peut-être dans tes logs (je n'en ai pas à cause d'un gros soucis
rsyslog).
Pour vérifier la liste des interfaces réseaux configurées:
# ip a
Le mode normal est accessible en telinit 3 (pas sûr du 3)?

Le run level 3 correspond au mode multiuser.
En gros c'est le mode "normal" avant le démarrage d'X.
Lorsque tu es sur un shell de secours le système est probablement en
run level 1 (maintenance, mono utilisateur).

Oui, je pense aussi.
Pour connaître le runlevel dans lequel tu te trouves:
# runlevel

J'aime bien la réponse "unknown" !!
Pas moyen de mettre à jour l'heure même en utilisant cette technique :
<https://askubuntu.com/questions/254826/how-to-force-a-clock-update-using-ntp>
--
Stéphane
http://pasdenom.info
Avatar
yamo'
yamo' a écrit le 27/08/2018 à 11:41 :
J'ai du réseaux j'ai démarré inn2 mais il ne me réponds pas...

Yes il vient de me répondre :
Erreur avec les groupes (NNTP) : loadav [innwatch:load] 1657 gt 1500
--
Stéphane
http://pasdenom.info
Avatar
Doug713705
Le 2018-08-27, yamo' nous expliquait dans
fr.comp.os.linux.configuration
(<5b83c73c$0$15189$) :
Maintenant que les disques sont réapparus, tu peux tenter de relancer
les services qui ont échoué au boot:
# systemctl networking restart

J'ai du réseaux j'ai démarré inn2 mais il ne me réponds pas... Tu le
vois peut-être dans tes logs (je n'en ai pas à cause d'un gros soucis
rsyslog).
Pour vérifier la liste des interfaces réseaux configurées:
# ip a
Le mode normal est accessible en telinit 3 (pas sûr du 3)?

Le run level 3 correspond au mode multiuser.
En gros c'est le mode "normal" avant le démarrage d'X.

Lorsque tu es sur un shell de secours le système est probablement en
run level 1 (maintenance, mono utilisateur).

Oui, je pense aussi.
Pour connaître le runlevel dans lequel tu te trouves:
# runlevel

J'aime bien la réponse "unknown" !!

:)
Pas moyen de mettre à jour l'heure même en utilisant cette technique :
<https://askubuntu.com/questions/254826/how-to-force-a-clock-update-using-ntp>

Il faut probablement arreter le service ntpd en premier lieu:
# systemctl stop ntp
Mettre la machine à l'heure à partir du pool de ntp.org
# ntpdate pool.ntp.org
Ensuite redémarrer le service ntp.
Au point où tu en es je suppose que tu peux redémarrer la machine.
Si le problème initial était la disparition des VG, elle devrait
maintenant repartir comme avant.
Si elle bloque toujours il faudra bien lire les journaux de systemd pour
comprendre l'origine du problème.
--
Tes militants parcourent les foires
Tournant leur orgue à rédemption,
Mais, coincés dans cette vieille histoire,
A quoi nous servent tant d'illusions ?
-- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Avatar
yamo'
Copie et fu2 fr.comp.usenet.serveurs
yamo' a écrit le 27/08/2018 à 11:43 :
yamo' a écrit le 27/08/2018 à 11:41 :
J'ai du réseaux j'ai démarré inn2 mais il ne me réponds pas...

Yes il vient de me répondre :
Erreur avec les groupes (NNTP) : loadav [innwatch:load] 1657 gt 1500

Bon maintenant même si ce n'est pas vraiment résolu ; rester en init 1
n'est pas une solution.
Là j'aurai besoin de débloquer la vérification de la date (mon serveur
est encore en week-end).
Peux t'on provisoirement désactiver ce contrôle de date?
Là il faut poster des messages de Samedi ou Dimanche matin pour que ça
passe...
--
Stéphane
http://pasdenom.info
1 2 3