Forum

Reprise du message précédent

donné par nic80 pour être sur que Sda1 est bien UEFI

Que donne la commande

Le ls /dev/sd* ne permet que d'identifier le périphérique de la clef USB. Il n'identifie pas du tout la partition EFI.

bash: ls /dev/sd*: Aucun fichier ou dossier de ce type

j'ai trouvé dans la liste la commande mount: dev/sda1 on /boot/EFI type ufat

Il faut donc tenter un fsck depuis un système live afin d'essayer de réparer la partition sda1. Mais vu que le GRUB s'affiche, elle ne devrait pas poser de problème.
Que donne :


Lorsqu'il t'ai demandé un retour d'une commande, il faut nous le fournir complet. On ne pourra pas t'aider avec des retours partiels ou des "oui ça fonctionne".

excuse moi je patauge complètement

- ls / donne:
bin& boot/ dead.letter dev/ etc/ home/ initrd/ lib& lib64& lost+found/ media/ mnt/ opt/ proc/ root/ run/ sbin& srv/ sys/ tmp/ usr /var

- ls /dev donne:
autofs cuse hidraw0 loop1 lp2 port ram13 ram9 snd/ tty13 tty22 tty31 tty40 tty5 tty59 ttys0 uimput vcsa1 video
block/ disk/ hidraw1 loop2 lp3 ppp ram14 random stderr& tty14 tty23 tty32 tty41 tty50 tty6 ttys1 urandom ucsa12 video1
bsg/ dma_heap/ hpet loop3 mapper/ psaux ram15 rfkill stdyn& tty15 tty24 tty33 tty42 tty51 tty60 ttys2 userfaultfd ucsu watchdog
btrfs-control dri/ hugepages/ loop4 media0 ptmx ram2 rtc& stdout& tty16 tty25 tty34 tty43 tty52 tty61 ttys3 userio vcsu1 watchdog0
bus/ drm_dp_aux0 hwrng loop5 mem pts/ ram3 rtc0 tty tty17 tty26 tty35 tty44 tty53 tty62 ttys4 v4l/ vcsu12 zero
char/ fb0 input/ loop6 mqueue/ ram0 ram4 sda tty0 tty18 tty27 tty36 tty45 tty54 tty63 ttys5 v4l-touche0 vfio/
comsole fd& kfd loop7 net/ ram1 ram5 sda1 tty1 tty19 tty28 tty37 tty46 tty55 tty7 ttys6 vcs uga_arbiter
core& full kmsg loop-control null ram10 ram6 sda2 tty10 tty2 tty29 tty38 tty47 tty56 tty8 ttys7 vcs1 vhci
cpu/ fuse log& lp0 nvram ram11 ram7 shm/ tty11 tty20 tty3 tty39 tty48 tty57 tty9 udmabuf vcs12 vhost-net
cpu_dma_latency gpiochip0 loop0 lp1 pktcdvd/ ram12 ram8 snapshot tty12 tty30 tty4 tty49 tty50 ttymu11 uhid vcsa vhost-vsock

devrait donc donner quelque chose puisque je vois un sda et un sda1.
Que donne la sortie complète (prend une photo au lieu de recopier si c'est trop long) :

Maintenant qu'on a identifié les partitions, tu peux insérer une clef USB et regarder de nouveau la sortie de

De nouvelles entrées devraient y être apparues. Probablement sdb et sdb1. Tu peux ensuite suivre la procédure de nic80 pour copier les sorties des commandes sur la clef USB ; tu n'as pas besoin de créer le dossier mnt vu qu'il existe déjà.

Bonjour Yuusha,

Code BASH :
ls /dev/sd*
devrait donc donner quelque chose puisque je vois un sda et un sda1.
/dev/sda /dev/sda1 /dev/sda2

Que donne la sortie complète (prend une photo au lieu de recopier si c'est trop long) :
Code BASH :
mount
lsblk



Maintenant qu'on a identifié les partitions, tu peux insérer une clef USB et regarder de nouveau la sortie de
Code BASH :
ls /dev/sd*
De nouvelles entrées devraient y être apparues. Probablement sdb et sdb1.

/dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1

Tu peux ensuite suivre la procédure de nic80 pour copier les sorties des commandes sur la clef USB ; tu n'as pas besoin de créer le dossier mnt vu qu'il existe déjà.

Je vais suivre la procédure de nic80.
Merci à toi

SUITE
Bonjour,

Faire un "ls /dev/sd*"
sans que la clé soit branchée pour lister les péripheriques présents,
/dev/sda /dev/sda1 /dev/sda2

puis brancher la clé usb et refaire un *ls /dev/sd* . Le(s) periphérique(s) supplementaire(s) seront alors relatif à la clé usb qui aura été branchée.
/dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1

Il sera ensuite possible de la monter pour pouvoir écrire dessus par la commande "mount /dev/sdXy /mnt" où X sera une lettre et y le numéro de partition sur le périphérique sdX.
Ceci présuppose que le répertoire /mnt existe répertoire /mnt existant (sinon il faudra le créer par la commande "mkdir /mnt".
mount /dev/sdb1 /mnt
RETOURNE: bash: mount: :mnt /dev/sdb1 déja monté sur /mnt
rpm -qa --last > /mnt/derniersPaquets.txt

Le fichier derniersPaquets est ok sur la clé

J'aimerais assez faire la manip avec le journal "journalctl --no-hostname --no-pager -b -1 > journalErreur.txt" mais je ne suis pas du tout sur de la syntaxe.

Du temps je vais graver une Live.

Bonjour,

Pour la génération du journal sur la clé, on peut faire:

"journalctl --no-hostname --no-pager -b -1 > /mnt/journalErreur.txt"

Par contre attention le -b -1 indque de prendre le journal du démarrage précédent. Si la machine n'a pas plantée lors du boot précédent du fait du démarrage en recovery à chaque fois, la sortie ne sera pas rellement exploitable puisque la machine démarre " correctement" en mode recovery.

Pour une exploitation et essayer de comprendre ce qu'il se passe, il faut démarrer une fois en mode normal pour faire planter le système puis redémarrer le système en mode recovery. A noter que -b -1 peut être remplacé par -b -2 ou -b -X (ou X est un chiffre représentant un boot précédent (plus le chiffre est grand plus on remonte dans les démarrages).

Si tu as la clef de montée, la syntaxe est :

Bonsoir,
Je suis obligé de mettre le dépannage en standby, probèmes de faux contacts sut l'USB.
Merci pour votre aide et a bientôt.

Bonjour,
A la place de passer par l'USB, si le réseau est monté (grâce à init 3) tu peux installer fpaste, puis:
fpaste <tonfichier.txt>
Tu récupéreras une adresse Internet qui donnera accès au contenu de ton fichier.

Bonsoir tout le monde,
mon pote à pris sa décision, le portable part a la casse, c'est désolant mais j'y peut rien.
En tout cas un grand merci a tous ceux qui sont intervenu, et bonnes fins de vacances.

Bonjour,

J'ai eu ce souci-là sur le même PC LENOVO IDEAPAD 330. J'y ai installer Linux Mint, mise à jour nickel et au bout d'un moment de repos, il me frisait l'écran, je pensais avoir trouver la solution en mettant à jour le noyau, c'était reparti, et en fait non, lors des dernières mises à jour rebelote.

Vu que je devais tester Mageia, je l'ai installer dessus, tout allait bien jusqu'à aujourd'hui après 1 semaine de repos, j'ai ce message d'erreur STONEY not supported in kfd.

Après de nombreuses recherches, je n'ai trouver aucunes solution viable, si ce n'est qu'apparemment, ce problème-là ce produit sur ce modèle principalement.

J'ai donc démarré sur le noyau précédent et il a démarré, solution temporaire puisque le PC, ne m'appartient pas.

Je pense que le disque n'est pas en cause, mais que c'est bien autre chose.

Affaire à suivre...

shaolinlucie :

Bonjour,

J'ai eu ce souci-là sur le même PC LENOVO IDEAPAD 330. J'y ai installer Linux Mint, mise à jour nickel et au bout d'un moment de repos, il me frisait l'écran, je pensais avoir trouver la solution en mettant à jour le noyau, c'était reparti, et en fait non, lors des dernières mises à jour rebelote.

Vu que je devais tester Mageia, je l'ai installer dessus, tout allait bien jusqu'à aujourd'hui après 1 semaine de repos, j'ai ce message d'erreur STONEY not supported in kfd.

Effectivement, je ne trouve pas non plus d'indication de solution. Il semble qu'il y ait un problème entre le kernel et le pilote AMDGPU