Discussion :

[Jipété]

Bonjour,
(peut-être pas la meilleure place pour cette discussion, ne pas hésiter à déplacer)

Debian 10.5 64 bits / kernel 4.19.118, quand je crée un initrd.img... avec la commande update-initramfs -v -c -k 5.7.10 -b /testinitram/, ça me génère un fichier .img de 142 Mo comme on peut le voir en bas à gauche de la partie haute de l'image, qui représente l'explorateur de fichiers pcmanfc avec par-dessus et à droite la vision du fichier généré ouvert dans xarchiver, qui ne me montre qu'un seul fichier de 30 ko.


J'ai au milieu en bleu la même vision avec mc (ne pas tenir compte du bandeau vert) et tout en bas dans un terminal c'est un bout de ce qui défile lors de la création du fichier avec l'option -v, et je peux vous dire que j'ai vu passer une sacrée quantité de fichiers (780 lignes de log environ), l'unique fichier dans le le .img n'en faisant pas partie.

Donc 30 ko <> 142 Mo, 1 fichier <> un très grand nombre, une explication à ce micmac ?

[Invité]

Bonjour,

il me semble que xarchiver et mc ne montre pas le même répertoire (/testinitram/ vs. /boot/).

[Jipété]

il me semble que xarchiver et mc ne montrent pas le même répertoire (/testinitram/ vs. /boot/).

Tu as raison, cependant,

J'ai au milieu en bleu la même vision avec mc (ne pas tenir compte du bandeau vert) …

Bon, ok, c'est un vert-bleu,
Et c'est juste que j'ai eu la grosse flemme de refaire une copie d'écran, et je viens de re-vérifier à l'instant en faisant pointer mc sur le bon répertoire, j'ai bien encore le résultat mystérieux de 30 ko…

(faut dire aussi que je suis passablement épuisé par cette histoire, avec laquelle je me bagarre depuis environ 1 mois, et qui n'avance pas. Les gens de debian-fr ont baissé les bras après avoir suggéré un probable problème de microcode du cpu partie gpu pas à jour ou similaire -- faut-il que je me tourne vers AMD ? Déjà que leur site est tout mal fichu et que je n'arrive pas à trouver des infos à jour, je crains le pire…

Quel rapport avec update-initramfs demanderez-vous ? Hé bien c'est parce que je passe mon temps à recompiler des noyaux en modifiant des options ici et là ici ou là, et à force de ne plus avoir les yeux en face des trous, des fois je me fais des nœuds et ça se termine avec des initrd.img foireux…)

[Invité]

Tu as raison, cependant,

J'ai au milieu en bleu la même vision avec mc (ne pas tenir compte du bandeau vert) …

le pire, c'est que je l'ai lu, et puis j'ai oublié.

s'il te plaît, remplace la capture, s'il te plaît. merci, s'il te plaît.
je ne suis pas la seule tête en l'air.

[Jipété]

Je t'avoue franchement et humblement que je n'ai ni le courage ni l'énergie de la refaire, Linux m'épuise, regarde :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Sep 10 13:47:04 debox64 vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.

alors je fais comme on me dit, dmesg | grep -i vboxdrv et ça ne remonte rien…

Et tout est comme ça, maintenant : hier je fais une recherche ggl, et la première chose que remonte cet imbécile de moteur de recherches pertes de temps, c'est une page qui a 20 ans d'âge ! Je vous dis pas la fraîcheur des infos.

Le temps que je perds, si je pouvais facturer, je serais riche à milliards !

[disedorgue]

l'initramfs est une image de système de fichier, et comme tu passe par un update-initramfs, il reprend peut-être la taille d'origine du fs où avant justement, il y avait plein de trucs...

Enfin, c'est de la pure spéculation...

Et pour ton histoire de console, est-ce que tu as essayé une ubuntu au lieu d'une debian, pour voir ?

[Jipété]

l'initramfs est une image de système de fichier, et comme tu passe par un update-initramfs, il reprend peut-être la taille d'origine du fs où avant justement, il y avait plein de trucs...

Enfin, c'est de la pure spéculation...

C'est surtout du pur brouillard car si ça me génère un fichier de 142 Mo avec des sources 5.7.10, le fichier tombe à 34 Mo avec 5.7.0-0.bpo.2-amd64.

Mais le plus rigolo, c'est que sans trop savoir ce que j'ai fait (très certainement un nouveau noyau, peu après avoir posté ici), j'ai gagné un .sav qui est à 142 et un current qui tombe à 30.
Mais les 3 contiennent la même chose, et je voudrais bien savoir où sont tous les modules qui devraient être présents et que je vois dans un .save de 17 Mo fait manuellement (oh !, une simple copie du current) il y a trois semaines...

Et pour ton histoire de console, est-ce que tu as essayé une ubuntu au lieu d'une debian, pour voir ?

Nan mais j'ai essayé toutes les Debian, certaines se comportent aussi mal que celle que j'ai, et d'autres c'est pire : pas de bureau du tout, tout comme une Fedora et la dernière Manjaro.

Mais quand je dis "pas de bureau", c'est vraiment "écran vide" donc un noir lumineux, pas le noir d'un écran éteint ou en veille et d'ailleurs, sa loupiote est toujours bleue, jamais jaune, et je ne vois jamais le message "no signal" ou "going to sleep", donc l'écran fonctionne, c'est juste qu'il ne reçoit rien ou mal ou je ne sais quoi.

D'ailleurs, si je me loggue en aveugle, je vois la loupiote du dur clignoter après le username et après le password, et surtout, en me connectant en ssh depuis l'autre machine, je vois tout avec ps ax par exemple : mes process lancés, et j'ai accès à tout, aux logs ( ah le fameux /proc/fb0: no such device, c'est lui mon problème -- mais le web en est plein).

Aux dernières nouvelles (de l'année dernière, là, mais il faut s'appuyer 5 pages...), il se pourrait qu'il y ait un 'blème entre mon proc AMD 3 qui embarque un proc graphique et Debian, dont les firmwares ne seraient pas bien à jour. J'ai pas tout compris, c'est pas du tout ma tasse de thé.

[Christophe]

Tu peux m'envoyer l'initrd concerné ?
lien wetransfer par exemple

[Christophe]

l'initrd de 30 Mo qui m'a été transmis n'est pas valide. Déjà il n'est pas compressé au format .gz (mais ce qui m'a été transmis est peut-être le fichier d'origine décompressé, et peut-être que ça marche si non compressé), ensuite, il ne contient qu'un fichier kernel/x86/microcode/authenticAMD.bin. Il ne contient pas d'init, de dossiers /bin, /etc ...

Ma version d'xarchiver ne permet pas d'afficher le contenu de l'archive cpio, un initramfs étant une archive cpio compressé. Si j'ouvre mon initrd avec-lui, je verrais un seul fichier : l'archive cpio.

Si tu veux extrair ele contenu de l'archive cpio (à faire dans un dossier vide) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cat nom_archive | cpio -idt

Tu pourras ensuite modifer le contenu et recréer une archive avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

find . | cpio -o >nom_archive

Attention à virer l'archive originale avant
A compresser ensuite avec gzip, et enlever l'extension.gz.

Les initramfs-tools permettent de le faire plus simplement en stockant les fichiers devant être contenant dans l'initrd dans /etc/initramfs-tools. Modifier les fichiers de confs en conséquence et placer les fichiers supplémentaires ou il faut. Te renseigner sur les hooks.

[Jipété]

l'initrd de 30 Mo qui m'a été transmis n'est pas valide. Déjà il n'est pas compressé au format .gz (mais ce qui m'a été transmis est peut-être le fichier d'origine décompressé, et peut-être que ça marche si non compressé), ensuite, il ne contient qu'un fichier kernel/x86/microcode/authenticAMD.bin. Il ne contient pas d'init, de dossiers /bin, /etc ...
[...]

C'est bien ce que j'avais vu, et qui m'a laissé sans voix.

Ceci étant dit, j'ai maintenant un autre problème sur les bras, et pas piqué des vers, bon sang !

J'ai récupéré hier l'iso du live de Debian-Facile, l'ai mis sur une clé uzbe, l'ai booté ça avait l'air sympa, ce matin je décide de faire une install du live vers une autre clé, quand c'est fini je reboote sur cette clé mais ça coince avec un message de "symbole non défini" ou similaire, me souviens plus, je décide de faire un grub-install vers cette clé, au reboot ça foire lamentablement, j'enlève la clé je reboote et là c'est mon disque de boot sda qui couine grave :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
error: symbol 'grub_calloc' not found.
Entering rescue mode...
grub rescue>

et là je suis comme une poule qui aurait trouvé un couteau, avec le curseur qui clignote en attendant un ordre mais lequel ?, il ne connaît même pas help !
Si j'ai bien compris, l'install du live de Debian-Facile m'a cassé le boot du disque principal,

EDIT : ah, j'oubliais : j'ai tenté un live Boot-repair sur clé uzbe, ça boote et au menu deux choix :

• normal et si choisi c'est écran noir et rien d'autre
• failsafe et si choisi c'est kernel panic.

Elle est pas belle la vie en 2020 ?

Je me documente et je reviens…

[Invité]

[disedorgue]

Des fois, le boot foire sur ma becane, je me retrouve avec le prompt grub (pas grub rescue), et dans ce cas, je saisi juste "exit" ( et bien sur je valide avec la touche return ) et il boot normalement...

[Christophe]

ou le grub-install a écrasé la conf du disque.

Pour t'en sortir au niveau du prompt grub, il faut connaitre un peu. Les commandes ressemblent aux commandes de base, tu va avoir par exemple ls, tu peux charger manuellement un noyau et un intrd et démarrer dessus. Si tu y arrives, un update-grub devrait permettre de réparer.

Comment tu fais pour avoir autant de merdes ?

Des fois, le boot foire sur ma becane, je me retrouve avec le prompt grub (pas grub rescue), et dans ce cas, je saisi juste "exit" ( et bien sur je valide avec la touche return ) et il boot normalement...

T'as quoi comme conf ? secureboot on/off ? partoche windows/linux ou juste linux ?

[disedorgue]

T'as quoi comme conf ? secureboot on/off ? partoche windows/linux ou juste linux ?

secure boot + partoche windows sur ssd et linux sur partoche hd
En fait, j'ai laisser l'install initial de windows (que je n'utilise que pour le jeu) qui occupe le ssd, et j'ai installer mon linux sur une partoche du hd.

[Christophe]

Bizarre, je m'en doutais. C'est lui qui doit aider le plantage de grub.
Et ton grub est sur le hdd ou le ssd ?

[disedorgue]

ssd, mais ça arrive rarement, et un simple exit résout le problème.

[Jipété]

Bonjour,

je me retrouve avec le prompt grub (pas grub rescue), et dans ce cas, je saisis juste "exit"

C'est ce que j'ai maintenant, suite à un boot sur une clé puis tout un tas de manips tordues avec un clavier azerty qui ne comprend que le qwerty, je vous raconte pas pour trouver : ou $, bref, j'ai réussi à avancer un peu mais mon prompt grub est le vrai, il n'y a rien d'autre "dessous" (pas comme quand on est au menu du choix du noyau et qu'on peut taper "e" ou "c", je sais plus, pour le prompt), et le help ne connait pas le "| more", résultat limite inutilisable.

ou le grub-install a écrasé la conf du disque.

Oui, c'est surement ça.

Pour t'en sortir au niveau du prompt grub, il faut connaitre un peu.

Et moi je ne connais pas, car ce n'est pas l'endroit où l'on passe son temps -- explorer les commandes de grub, je connais des choses plus marrantes et plus agréables,

Les commandes ressemblent aux commandes de base, tu vas avoir par exemple ls,

Oui, ls j'ai vu, il me donne (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos2) (hd1,msdos1) (hd2) (hd2,msdos2) (hd2,msdos1) mais je ne sais pas quoi faire de plus...

charger manuellement un noyau et un initrd et démarrer dessus

Comment ?

Comment tu fais pour avoir autant de merdes ?

C'est très simple : j'ai acheté une machine avec un AMD Ryzen 3 3200G qui a été designé avec les pieds mais ça, on ne s'en rend compte qu'après, et par-dessus Debian est incapable de le gérer (ou c'est moi qui m'y prend mal, mais impossible de trouver une explication claire et simple -- y en a un qui y est arrivé à coups de backports et de patches du noyau, bref, pendant ce temps la prod n'avance pas) : faites une recherche "amd ryzen 3 black screen" moi j'ai 20 millions de résultats, et je comprends mieux pourquoi la moitié des distros que j'ai testées se terminaient avec un écran noir, les autres me donnant un bureau, ok, mais des consoles 80x25 avec Ctrl-Alt-Fx.
Et en voulant tester une dernière distro puis son install sur une clé suivie d'un reboot qui se termine avec grub rescue >, c'est juste un enchaînement de pas-de-bol.

Mais toutes ces recherches m'auront permis de découvrir un énorme problème depuis cet été avec grub et ses mises à jour de sécurité qui occasionnent un redémarrage qui se termine par grub rescue > et plein de gens qui pleurent sur tous les forums…
Un bon conseil : toutes affaires cessantes, créez-vous une clé Boot-repair (300 M de résultats !) et testez-là, étant entendu qu'elle fonctionne très bien sur ma vieille machine de 10 ans d'âge avec un GenuineIntel famille 6 et pas du tout avec l'AMD tout récent, écran noir -- pas pratique pour restaurer un grub !

[Jipété]

Comment ?

j'en suis là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grub>

J'ai trouvé et suivi ce tuto qui explique tout bien bien, effectivement j'ai retrouvé le bureau, mais à condition de bien faire les choses dans l'ordre, genre

En validant la dernière commande, Ubuntu va alors démarrer. Ensuite, suivez le paragraphe § 7.1.2 pour réparer Grub à partir d'Ubuntu.

Un peu précipité après avoir récupéré le bureau lors d'un premier essai, j'avais zappé la réparation finale,

Ah, un pré-requis mandatory (sinon vous pétez un plomb) :


Pensez à enregistrer cette image à un endroit où vous la retrouverez facilement, c'est trop utile !

Bon, ça c'est réglé, alors

bon week-end !

[Jipété]

Bonjour,

initrd et cpio, le retour

l'initrd de 30 Mo qui m'a été transmis n'est pas valide.

Alors ça c'est quand même bizarre puisque la machine boote avec.

Si tu veux extraire le contenu de l'archive cpio (à faire dans un dossier vide) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cat nom_archive | cpio -idt

Dans un dossier de test créé pour l'occasion, j'y recopie un initrd.img.5.7.10 généré par update-initramfs -c après suppression du précédent et je lance ta commande, qui se contente d'afficher le contenu supposé, je ne peux pas savoir puisque ça n'extrait rien ! :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
# cat initrd.img-5.7.10 | cpio -idt
.
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/AuthenticAMD.bin
62 blocs
# ls -Al
total 19676
-rw-r--r-- 1 root root 20144620 oct.   6 15:26 initrd.img-5.7.10

Mais je trouve ça dans le man de cpio : or (if the -t option is given) list its contents donc je supprime le "t", je relance et je récupère la même chose que toi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# ls -AlR
.:
total 19680
-rw-r--r-- 1 root root 20144620 oct.   6 15:26 initrd.img-5.7.10
drwxr-xr-x 3 root root     4096 oct.   6 15:37 kernel
 
./kernel:
total 4
drwxr-xr-x 3 root root 4096 oct.   6 15:37 x86
 
./kernel/x86:
total 4
drwxr-xr-x 2 root root 4096 oct.   6 15:37 microcode
 
./kernel/x86/microcode:
total 32
-rw-r--r-- 1 root root 30546 oct.   6 15:37 AuthenticAMD.bin

Et pas plus.
Alors que lsinitramfs initrd.img-5.7.10 | wc -l me trouve 900 lignes.

Je comprends mieux pourquoi les newbies s'arrachent les cheveux…

En ce qui me concerne, en regardant les scripts, je me rends compte que lsinitramfs appelle unmkinitramfs et que celui-ci extrait deux dossiers !
early qui contient ce qu'on a vu ci-dessus, et main, qui contient toute l'arborescence bin conf etc init etc.

Voili voilou, c'est une histoire de partie compressée (le main) précédée d'une partie qui ne l'est pas (le kernel), et c'est documenté dans son man :

unmkinitramfs cannot deal with multiple-segmented initramfs images, except where an early (uncompressed) initramfs with system firmware is prepended to the regular compressed initramfs.