[Résolu] Grub abimé...

pierrotlalune · 17/11/2019 18:22:48

Pour l'instant, le pilote "nvidia" ne se compile pas, ni avec:

# dnf install xorg-x11-drv-nvidia-390xx akmod-nvidia-390xx
# reboot

ni avec:

# akmods --force

Le pilote n'étant pas fonctionnel, je l'ai désinstallé avec:

# dnf remove *nvidia*

Je pense que se dysfonctionnent pourrait être associer au "grub" encore "désorganisé":

# ls -l /boot/loader/entries
total 16
-rw-r--r--. 1 root root 329 17 nov.  16:50 f78e00f22e9d47c3814a60a9dffa8afb-0-rescue.conf
-rw-r--r--. 1 root root 356 17 nov.  16:50 f78e00f22e9d47c3814a60a9dffa8afb-5.3.11-300.fc31.x86_64.conf
-rw-r--r--. 1 root root 352 17 nov.  16:50 f78e00f22e9d47c3814a60a9dffa8afb-5.3.8-300.fc31.x86_64.conf
-rw-r--r--. 1 root root 352 17 nov.  16:50 f78e00f22e9d47c3814a60a9dffa8afb-5.3.9-300.fc31.x86_64.conf
-rw-r--r--. 1 root root 379 17 nov.  16:50 fb0c7db0921149639d5f00295eb34d23-0-rescue.conf
-rw-r--r--. 1 root root 352 17 nov.  16:50 fb0c7db0921149639d5f00295eb34d23-5.2.18-200.fc30.x86_64.conf
-rw-r--r--. 1 root root 348 17 nov.  16:50 fb0c7db0921149639d5f00295eb34d23-5.3.5-200.fc30.x86_64.conf
-rw-r--r--. 1 root root 348 17 nov.  16:50 fb0c7db0921149639d5f00295eb34d23-5.3.6-200.fc30.x86_64.conf
#

J'ai bien les bons "kernel-devel" et "kernel-headers":

$ rpm -qa | grep kernel-devel
kernel-devel-5.3.11-300.fc31.x86_64
kernel-devel-5.3.9-300.fc31.x86_64
kernel-devel-5.3.8-300.fc31.x86_64
[alexandre@tales ~]$ rpm -qa | grep kernel-headers
kernel-headers-5.3.11-300.fc31.x86_64
[alexandre@tales ~]$ uname -r
5.3.11-300.fc31.x86_64
[alexandre@tales ~]$

A suivre...
pll

nouvo09 · 17/11/2019 23:47:38

Je pense que se dysfonctionnent pourrait être associer au "grub" encore "désorganisé":

Tu as réactivé BLSCFG ???

pierrotlalune · 18/11/2019 00:03:19

nouvo09 a écrit :

Tu as réactivé BLSCFG ???

Bonsoir nouvo09;
Et non !!!

$ cat /etc/default/grub
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="0"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"
$

a+
pll

nouvo09 · 18/11/2019 00:40:40

nouvo09 a écrit :
Tu as réactivé BLSCFG ???
Bonsoir nouvo09;
Et non !!!

D'où viennent tous ces fichiers datés de 17 nov. 16:50 dans ce dossier /boot/loader/entries ? Qu'estc e que tu as fait à cette heure là ?

Si BLSCFG n'est pas activé, ils ne servent à rien.

pierrotlalune · 18/11/2019 00:56:14

nouvo09 a écrit :

D'où viennent tous ces fichiers datés de 17 nov. 16:50 dans ce dossier /boot/loader/entries ? Qu'estc e que tu as fait à cette heure là ?
Si BLSCFG n'est pas activé, ils ne servent à rien.

Cela correspond à la tentative d'installation du pilote nvidia.

nouvo09 · 18/11/2019 09:09:27

Étonnant, mais soit.

pierrotlalune · 19/11/2019 17:21:20

J'ai voulu démarrer en "niveau 3", pour tenter de compiler le pilote Nvidia. J'ai donc édité le menu du "grub":

Je ne vois pas de ligne "linux" pour mettre le"3". Les paramètres sont ils corrects ?
Merci.
pll

nouvo09 · 19/11/2019 18:28:05

Ben tu prends ta fleche en bas et tu scrolles vers le bas. Quand même ...

pierrotlalune · 19/11/2019 18:46:51

nouvo09 a écrit :

Ben tu prends ta fleche en bas et tu scrolles vers le bas. Quand même ...

Oups ! Effectivement.... J'ai pas fait fort:roll:.

pierrotlalune · 19/11/2019 20:26:10

J'ai réussi à démarrer en niveau 3 (pour la première fois) sur le dernier noyau, et j'ai lancé ceci pour compiler le pilote Nvidia:

# akmods --force

sans succès:-(,
puis j'ai démarré sur l'avant dernier noyau pour tenter ceci:

# akmods --force --kernels 5.3.11-300.fc31.x86_64

toujours sans succès:-(:-(.
Qu'est ce qui empêche la compilation, le grub ou autre chose ???
a+
pll

madko · 19/11/2019 20:45:02

aucune erreur ?

modinfo nvidia

trouve rien ?

pierrotlalune · 19/11/2019 21:37:32

madko a écrit :

aucune erreur ?
modinfo nvidia
trouve rien ?

Bonsoir madko:-),
voici:

$ modinfo nvidia
filename:       /lib/modules/5.3.11-300.fc31.x86_64/extra/nvidia-390xx/nvidia.ko
alias:          char-major-195-*
version:        390.132
supported:      external
license:        NVIDIA
srcversion:     C9CBE920F0195665AFA8A5C
alias:          pci:v000010DEd00000E00sv*sd*bc04sc80i00*
alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
alias:          pci:v000010DEd*sv*sd*bc03sc00i00*
depends:        ipmi_msghandler
retpoline:      Y
name:           nvidia
vermagic:       5.3.11-300.fc31.x86_64 SMP mod_unload 
parm:           NVreg_Mobile:int
parm:           NVreg_ResmanDebugLevel:int
parm:           NVreg_RmLogonRC:int
parm:           NVreg_ModifyDeviceFiles:int
parm:           NVreg_DeviceFileUID:int
parm:           NVreg_DeviceFileGID:int
parm:           NVreg_DeviceFileMode:int
parm:           NVreg_UpdateMemoryTypes:int
parm:           NVreg_InitializeSystemMemoryAllocations:int
parm:           NVreg_UsePageAttributeTable:int
parm:           NVreg_MapRegistersEarly:int
parm:           NVreg_RegisterForACPIEvents:int
parm:           NVreg_CheckPCIConfigSpace:int
parm:           NVreg_EnablePCIeGen3:int
parm:           NVreg_EnableMSI:int
parm:           NVreg_TCEBypassMode:int
parm:           NVreg_UseThreadedInterrupts:int
parm:           NVreg_EnableStreamMemOPs:int
parm:           NVreg_EnableBacklightHandler:int
parm:           NVreg_RestrictProfilingToAdminUsers:int
parm:           NVreg_EnableUserNUMAManagement:int
parm:           NVreg_EnableIBMNPURelaxedOrderingMode:int
parm:           NVreg_MemoryPoolSize:int
parm:           NVreg_KMallocHeapMaxSize:int
parm:           NVreg_VMallocHeapMaxSize:int
parm:           NVreg_IgnoreMMIOCheck:int
parm:           NVreg_RegistryDwords:charp
parm:           NVreg_RegistryDwordsPerDevice:charp
parm:           NVreg_RmMsg:charp
parm:           NVreg_AssignGpus:charp
$

J'ai remarqué ceci:

vermagic:       5.3.11-300.fc31.x86_64 SMP mod_unload

Je pense qu'il faudrait charger ce module... Que préconiserais tu ?
a+
pll

madko · 19/11/2019 22:20:32

Pour le charger tu peux tenter un

modprobe nvidia

mais tu peux aussi voir la liste des modules actuellement chargés avec la commande

lsmod

Peut être que le module nouveau est chargé, ce qui empeche le module nvidia d'être chargé.

Vérifie même en mode 3, dans les options de boot que tu peux voir en faisant un

cat /proc/cmdline

tu as bien une option blacklist pour nouveau (rd.driver.blacklist=nouveau). Avec toute tes manip sur grub ça a peut être sauté.

pierrotlalune · 20/11/2019 12:06:52

Bonjour madko,
merci pour ton aide:-).
Voici le retour des commandes:

$ su -
Mot de passe : 
# modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': No such device
[root@tales ~]# lsmod
Module                  Size  Used by
usblp                  28672  0
rfcomm                 90112  4
xt_CHECKSUM            16384  1
xt_MASQUERADE          20480  3
xt_conntrack           16384  1
ipt_REJECT             16384  2
nf_reject_ipv4         16384  1 ipt_REJECT
ip6table_mangle        16384  1
ip6table_nat           16384  1
iptable_mangle         16384  1
iptable_nat            16384  1
nf_nat                 49152  3 ip6table_nat,iptable_nat,xt_MASQUERADE
nf_conntrack          159744  3 xt_conntrack,nf_nat,xt_MASQUERADE
nf_defrag_ipv6         24576  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
libcrc32c              16384  2 nf_conntrack,nf_nat
ebtable_filter         16384  0
ebtables               40960  1 ebtable_filter
ip6table_filter        16384  1
ip6_tables             32768  3 ip6table_filter,ip6table_nat,ip6table_mangle
iptable_filter         16384  1
tun                    57344  1
bridge                208896  0
stp                    16384  1 bridge
llc                    16384  2 bridge,stp
cmac                   16384  2
bnep                   28672  2
sunrpc                462848  1
vfat                   20480  1
fat                    86016  1 vfat
squashfs               65536  4
zstd_decompress        90112  1 squashfs
loop                   36864  8
ath9k                 151552  0
ath9k_common           28672  1 ath9k
ath9k_hw              503808  2 ath9k_common,ath9k
mac80211              974848  1 ath9k
ath                    36864  3 ath9k_common,ath9k,ath9k_hw
snd_hda_codec_realtek   126976  1
cfg80211              835584  4 ath9k_common,ath9k,ath,mac80211
snd_hda_codec_generic    94208  1 snd_hda_codec_realtek
ledtrig_audio          16384  2 snd_hda_codec_generic,snd_hda_codec_realtek
snd_hda_codec_hdmi     65536  1
libarc4                16384  1 mac80211
snd_hda_intel          53248  5
snd_usb_audio         270336  2
snd_hda_codec         159744  4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
snd_usbmidi_lib        40960  1 snd_usb_audio
dcdbas                 20480  0
snd_hda_core          102400  5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep              16384  2 snd_usb_audio,snd_hda_codec
snd_rawmidi            45056  1 snd_usbmidi_lib
snd_seq                86016  0
snd_seq_device         16384  2 snd_seq,snd_rawmidi
uvcvideo              114688  0
snd_pcm               118784  5 snd_hda_codec_hdmi,snd_hda_intel,snd_usb_audio,snd_hda_codec,snd_hda_core
snd_timer              40960  2 snd_seq,snd_pcm
snd                    98304  27 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_usb_audio,snd_usbmidi_lib,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm,snd_rawmidi
videobuf2_vmalloc      20480  1 uvcvideo
videobuf2_memops       20480  1 videobuf2_vmalloc
ath3k                  24576  0
videobuf2_v4l2         28672  1 uvcvideo
videobuf2_common       57344  2 videobuf2_v4l2,uvcvideo
btusb                  57344  0
btrtl                  24576  1 btusb
videodev              237568  3 videobuf2_v4l2,uvcvideo,videobuf2_common
soundcore              16384  1 snd
btbcm                  16384  1 btusb
btintel                28672  1 btusb
mc                     61440  5 videodev,snd_usb_audio,videobuf2_v4l2,uvcvideo,videobuf2_common
bluetooth             626688  32 btrtl,btintel,btbcm,bnep,ath3k,btusb,rfcomm
joydev                 28672  0
ecdh_generic           16384  1 bluetooth
rfkill                 28672  4 bluetooth,cfg80211
ecc                    32768  1 ecdh_generic
intel_rapl_msr         20480  0
intel_rapl_common      28672  1 intel_rapl_msr
x86_pkg_temp_thermal    20480  0
intel_powerclamp       20480  0
coretemp               20480  0
kvm_intel             299008  0
i2c_i801               32768  0
dell_smm_hwmon         20480  0
mei_hdcp               24576  0
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt
kvm                   770048  1 kvm_intel
ipmi_devintf           20480  0
ipmi_msghandler        73728  1 ipmi_devintf
irqbypass              16384  1 kvm
mei_me                 45056  1
mei                   122880  3 mei_hdcp,mei_me
lpc_ich                28672  0
crct10dif_pclmul       16384  1
crc32_pclmul           16384  0
ghash_clmulni_intel    16384  0
intel_cstate           20480  0
intel_uncore          147456  0
intel_rapl_perf        16384  0
binfmt_misc            24576  1
ip_tables              32768  3 iptable_filter,iptable_nat,iptable_mangle
ums_realtek            24576  0
uas                    28672  0
usb_storage            77824  2 uas,ums_realtek
nouveau              2273280  18
mxm_wmi                16384  1 nouveau
wmi                    36864  2 mxm_wmi,nouveau
i2c_algo_bit           16384  1 nouveau
drm_kms_helper        212992  1 nouveau
ttm                   122880  1 nouveau
drm                   512000  7 drm_kms_helper,ttm,nouveau
crc32c_intel           24576  4
r8169                  94208  0
video                  49152  1 nouveau
fuse                  139264  5
[root@tales ~]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.3.11-300.fc31.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet
# déconnexion
$

Je suis étonné de ce retour:

modprobe: ERROR: could not insert 'nvidia': No such device

nouveau est chargé et non blacklisté.
Avant de le blacklister sur le grub, j'aimerais avoir ton avis sur l'erreur de modprobe.
Merci.
a+
pll

pierrotlalune · 20/11/2019 14:47:22

Bon, je me suis lancé pour blacklister "nouveau", et je fus surpris à la vue du fichier de configuration existant du "grub":

$ cat /etc/default/grub
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="0"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"
$

Il est similaire à celui de Refuznik et m'a paru correct.
Je me suis donc contenté de régénérer le "grub":

# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Et bingo ! Après redémarrage, tout est rentré dans l'ordre:

$ uname -r
5.3.11-300.fc31.x86_64
$ inxi -G
Graphics:
  Device-1: NVIDIA GF119 [GeForce GT 705] driver: nvidia v: 390.132 
  Display: x11 server: Fedora Project X.org 1.20.5 driver: nvidia 
  unloaded: fbdev,modesetting,nouveau,vesa resolution: 1280x1024~60Hz 
  OpenGL: renderer: GeForce GT 705/PCIe/SSE2 v: 4.6.0 NVIDIA 390.132 
$

Je me demande pourquoi la commande d'installation du pilote:

# dnf install xorg-x11-drv-nvidia-390xx akmod-nvidia-390xx

a modifié le fichier de configuration du "grub" sans le régénérer.
Bizarre !
Merci pour votre aide. ça marche:pint:.
Reste à savoir ce qui se passera à l'installation d'un nouveau noyau ou à la maj du grub.
Amicalement.
pll

Dernière modification par pierrotlalune (20/11/2019 14:52:52)

nouvo09 · 20/11/2019 16:57:40

L'installation d'un nouveau noyau provoque la reconstruction du fichier grub.cfg, ce qui n'est pas le cas d'un nouveau module.

pierrotlalune · 20/11/2019 20:10:56

nouvo09 a écrit :

L'installation d'un nouveau noyau provoque la reconstruction du fichier grub.cfg, ce qui n'est pas le cas d'un nouveau module.

Bonne nouvelle:-). Auparavant, l'installation du "akmod-nvidia**" ne nécessitait aucune intervention...

pierrotlalune · 27/11/2019 13:01:56

nouvo09 a écrit :

L'installation d'un nouveau noyau provoque la reconstruction du fichier grub.cfg.

Salut nouvo09;
Pas encore pour moi.
J'ai dû régénérer manuellement le grub:

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

pour que le noyau de la dernière maj apparaisse...

$ uname -r
5.3.12-300.fc31.x86_64
$

J'espère que la prochaine fois, ce sera automatique !
J'ai toujours deux lignes "rescue" dans le prompt du grub:roll:.
Bonne journée.
Amicalement.
pll

pierrotlalune · 29/11/2019 12:57:50

Bonjour à tous:-);
le "grub" a été mis à jour ce matin suite à un:

# dnf upgrade

La pagaille est revenue: le système a tenté par défaut de redémarrer sur un noyau ancien, qui avait déjà été supprimé par les maj ( le 5.3.6-200.fc30.x86_64).
J'ai résolu provisoirement cela, en supprimant la ligne:

GRUB_ENABLE_BLSCFG=true

dans "/etc/default/grub" puis en regénérant le "grub".
J'aimerais maintenant résoudre définitivement le problème.
Au vu de ceci:

# ls -l /boot/loader/entries
total 16
-rw-r--r--. 1 root root 383 29 nov.  09:29 f78e00f22e9d47c3814a60a9dffa8afb-0-rescue.conf
-rw-r--r--. 1 root root 253 12 nov.  20:30 f78e00f22e9d47c3814a60a9dffa8afb-5.3.11-300.fc31.x86_64.conf
-rw-r--r--. 1 root root 253 22 nov.  00:23 f78e00f22e9d47c3814a60a9dffa8afb-5.3.12-300.fc31.x86_64.conf
-rw-r--r--. 1 root root 249  6 nov.  17:35 f78e00f22e9d47c3814a60a9dffa8afb-5.3.9-300.fc31.x86_64.conf
-rw-r--r--. 1 root root 379 19 nov.  20:20 fb0c7db0921149639d5f00295eb34d23-0-rescue.conf
-rw-r--r--. 1 root root 428 19 nov.  20:20 fb0c7db0921149639d5f00295eb34d23-5.2.18-200.fc30.x86_64.conf
-rw-r--r--. 1 root root 424 19 nov.  20:20 fb0c7db0921149639d5f00295eb34d23-5.3.5-200.fc30.x86_64.conf
-rw-r--r--. 1 root root 424 19 nov.  20:20 fb0c7db0921149639d5f00295eb34d23-5.3.6-200.fc30.x86_64.conf
# déconnexion
$

Je pense qui faudrait arriver à dégager la ligne:

-rw-r--r--. 1 root root 379 19 nov.  20:20 fb0c7db0921149639d5f00295eb34d23-0-rescue.conf

qui correspond aux noyaux de F30.
Je ne sais, ni si cette piste est bonne, ni comment faire si c'est le cas.
Je m'en remets à vos lumières.
Bonne journée.
pll

nouvo09 · 29/11/2019 13:09:32

Tu peux si tu as mis BLSCFG à false, faire un rm -f * dans /boot/loader/entries

pierrotlalune · 29/11/2019 14:03:33

nouvo09 a écrit :

Tu peux si tu as mis BLSCFG à false, faire un rm -f * dans /boot/loader/entries

J'ai rajouté:

GRUB_ENABLE_BLSCFG=false

dans "/etc/default/grub" puis j'ai suivi tes consignes.
Et j'ai régénéré le "grub".
J'ai bien ceci:

# ls -l /boot/loader/entries
total 0
#

Cependant, les deux lignes "rescue" sont toujours présente sur le prompt du "grub".
Mais si lors du passage à un nouveau noyau, à la mise à jour du "grub" tout se passe bien; ça m'ira:-D. A suivre...
Merci à toi.
pll

nouvo09 · 29/11/2019 16:28:16

Conserve les entrées "rescue" elles ne sont pas là juste pour décorer.

pierrotlalune · 29/11/2019 16:32:52

Bien noté. Merci.

pierrotlalune · 22/12/2019 11:15:34

Bonjour à tous:-),
après quelques mises à jour du "grub", et plusieurs du noyau, il apparaît que:

1/ avec ce réglage:

$ cat /etc/default/grub
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="0"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"
GRUB_ENABLE_BLSCFG=false
$

et en particulier, cette ligne:

GRUB_ENABLE_BLSCFG=false

Le grub se met à jour sans engendrer de dysfonctionnement.

2/ En revanche, chaque mise à jour du noyau nécessite une reconstruction manuelle du grub, dans mon cas:

# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

pour que le dernier noyau soit pris en compte.
J'aimerais donc que ceci se fasse automatiquement comme cela devrait être le cas.
Je n'ai aucune idée de ce qu'il faudrait faire pour y parvenir. Une idée ? Merci.
Bonne fêtes à tous.
pll

nouvo09 · 22/12/2019 12:49:10

Il serait quand même intéressant de vérifier si tu n'as pas un autre fichier grub.cfg ailleurs dans ton système qui serait susceptible (c'est une hypothèse) de tromper la mise à jour.

essaie un

locate grub.cfg

Fedora-Fr - Communauté francophone Fedora - Linux

#26 17/11/2019 18:22:48

Re : [Résolu] Grub abimé...

#27 17/11/2019 23:47:38

Re : [Résolu] Grub abimé...

#28 18/11/2019 00:03:19

Re : [Résolu] Grub abimé...

#29 18/11/2019 00:40:40

Re : [Résolu] Grub abimé...

#30 18/11/2019 00:56:14

Re : [Résolu] Grub abimé...

#31 18/11/2019 09:09:27

Re : [Résolu] Grub abimé...

#32 19/11/2019 17:21:20

Re : [Résolu] Grub abimé...

#33 19/11/2019 18:28:05

Re : [Résolu] Grub abimé...

#34 19/11/2019 18:46:51

Re : [Résolu] Grub abimé...

#35 19/11/2019 20:26:10

Re : [Résolu] Grub abimé...

#36 19/11/2019 20:45:02

Re : [Résolu] Grub abimé...

#37 19/11/2019 21:37:32

Re : [Résolu] Grub abimé...

#38 19/11/2019 22:20:32

Re : [Résolu] Grub abimé...

#39 20/11/2019 12:06:52

Re : [Résolu] Grub abimé...

#40 20/11/2019 14:47:22

Re : [Résolu] Grub abimé...

#41 20/11/2019 16:57:40

Re : [Résolu] Grub abimé...

#42 20/11/2019 20:10:56

Re : [Résolu] Grub abimé...

#43 27/11/2019 13:01:56

Re : [Résolu] Grub abimé...

#44 29/11/2019 12:57:50

Re : [Résolu] Grub abimé...

#45 29/11/2019 13:09:32

Re : [Résolu] Grub abimé...

#46 29/11/2019 14:03:33

Re : [Résolu] Grub abimé...

#47 29/11/2019 16:28:16

Re : [Résolu] Grub abimé...

#48 29/11/2019 16:32:52

Re : [Résolu] Grub abimé...

#49 22/12/2019 11:15:34

Re : [Résolu] Grub abimé...

#50 22/12/2019 12:49:10

Re : [Résolu] Grub abimé...

Pied de page des forums