Mageia 9 - Grub2 leidet an Gedächtnisschwund

    Hallo zusammen

    Habe wieder mal ein sehr eigenartiges Problem. Vielleicht könnt Ihr mir hier weiterhelfen.

    Kurze Problembeschreibung
    Bei einem Systemstart melde das BIOS, dass kein System vorhanden ist. Nach Analyse stellt sich heraus, dass der Eintrag für die Bootpartition fehlt. Das Problem ist wiederkehrend.

    Distribution
    Mageia 9

    Systemdaten

    neofetch

    .°°.                
    °° .°°. ----------------
    .°°°. °°          OS: Mageia 9 x86_64
    . .             Host: HP t630 Thin Client
    °°° .°°°.        Kernel: 6.4.16-desktop-3.mga9
    .°°°. '___'        Uptime: 24 mins
    .'___' .       Packages: 2596 (rpm), 14 (flatpak)
    :dkxc;'. ..,cxkd;      Shell: bash 5.2.15
    .dkk. kkkkkkkkkk .kkd.    Resolution: 1280x1024, 1920x1200
    .dkk. ';cloolc;. .kkd    DE: Plasma 5.27.5
    ckk. .kk;   WM: KWin
    xO: cOd   WM Theme: Breeze
    xO: lOd   Theme: [Plasma], Breeze [GTK2/3]
    lOO. .OO:   Icons: [Plasma], breeze [GTK2/3]
    .k00. .00x    Terminal: konsole
    .k00; ;00O.    CPU: AMD Embedded G-Series GX-420GI Radeon R7E (4) @ 2.000GHz
    .lO0Kc;,,,,,,;c0KOc.     GPU: AMD ATI Radeon R5/R6/R7 Graphics
    ;d00KKKKKK00d;        Memory: 2837MiB / 14957MiB
    .,KKKK,.

    inxi -Fz

    System:
    Kernel: 6.4.16-desktop-3.mga9 arch: x86_64 bits: 64 Desktop: KDE Plasma
       v: 5.27.5 Distro: Mageia 9
    Machine:
    Type: Desktop System: HP product: HP t630 Thin Client v: N/A
       serial: <superuser required>
    Mobo: HP model: 8158 v: A01 serial: <superuser required> UEFI: AMI
       v: M40 v01.14 date: 01/04/2023
    CPU:
    Info: quad core model: AMD Embedded G-Series GX-420GI Radeon R7E bits: 64
       type: MT MCP cache: L2: 2 MiB
    Speed (MHz): avg: 897 min/max: 900/2000 cores: 1: 898 2: 897 3: 898 4: 898
    Graphics:
    Device-1: AMD Wani [Radeon R5/R6/R7 Graphics] driver: amdgpu v: kernel
    Device-2: DisplayLink USB3.0 Dual Video Dock type: USB
       driver: cdc_ncm,snd-usb-audio
    Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
       loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu
       resolution: 1: 1280x1024~60Hz 2: 1920x1200~60Hz
    API: OpenGL v: 4.6 Mesa 23.1.7 renderer: AMD Radeon R7E Graphics (carrizo
    LLVM 15.0.6 DRM 3.52 6.4.16-desktop-3.mga9)
    Audio:
    Device-1: AMD Kabini HDMI/DP Audio driver: snd_hda_intel
    Device-2: AMD Family 15h Audio driver: snd_hda_intel
    Device-3: DisplayLink USB3.0 Dual Video Dock type: USB
       driver: cdc_ncm,snd-usb-audio
    API: ALSA v: k6.4.16-desktop-3.mga9 status: kernel-api
    Server-1: PulseAudio v: 16.1 status: active
    Network:
    Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
       driver: r8169
    IF: enp1s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
    IF-ID-1: enp0s16u2u1i5 state: down mac: <filter>
    Drives:
    Local Storage: total: 931.51 GiB used: 340.54 GiB (36.6%)
    ID-1: /dev/sda vendor: Western Digital model: WD Blue SA510 M.2 2280
    1000GB size: 931.51 GiB
    Partition:
    ID-1: / size: 125.82 GiB used: 21.52 GiB (17.1%) fs: ext4 dev: /dev/sda2
    Swap:
    ID-1: swap-1 type: partition size: 24.41 GiB used: 0 KiB (0.0%)
       dev: /dev/sda3
    Sensors:
    System Temperatures: cpu: 41.1 C mobo: N/A gpu: amdgpu temp: 41.0 C
    Fan Speeds (RPM): N/A
    Info:
    Processes: 208 Uptime: 27m Memory: 14.61 GiB used: 2.86 GiB (19.6%)
    Shell: Bash inxi: 3.3.26


    Das Problem
    Beim Start des PCs meldet das BIOS, dass kein System vorhanden ist. Im BIOS selbst wird jedoch eine Festplatte angezeigt. Auch eine Prüfung selbiger ergibt kein Problem.
    Das Problem trat schon unter Mageia 8 auf. Daraufhin habe ich, und weil Mageia 9 herausgekommen ist und das System zum meinem Hauptrechner geworden ist, die Festplatte, RAM, Netzteil, Monitor, Tastatur, Maus, Lautsprecher, Dock gewechselt. Festplatte und RAM sind neu, die anderen Teile Bestand. Der Rechner ist noch der Selbe. BIOS ist auf aktuellem Stand. Danach wurde Mageia 9 frisch installiert.

    Das Problem trat dann etwa 2 Monate lang nicht mehr auf und das Thema war für mich eigentlich gegessen. Aber seit dieser Woche tritt es wieder auf, zum 3. Mal. :cursing:

    Temporäre Lösung
    Ich habe mir ein Boot-Stick mit SuperGrub erstellt und boote damit das System, was ganz gut funktioniert.

    Mit

    efibootmgr

    lasse ich mir die Booteinträge anzeigen. Hier sieht man dann, dass der entsprechende Eintrag für die Bootpartition und Mageia fehlt. Mit

    efibootmgr -c -d /dev/sda -p 1 -w -L mageia -l \\EFI\\mageia\\grubx64.efi

    lasse ich den Eintrag wieder ergänzen.

    Das funktioniert dann wieder ein Weile.

    Aber irgend etwas ist hier nicht ganz sauber. Was kann ich machen, dass dies nicht wieder auftritt?
    Das Problem ist zwar schnell behoben, nervt aber auf Dauer etwas.

    Ich hatte ein Weile eine Flatpak App - Spotify - in Verdacht, da das Problem nach einer De- und erneuten Installation punktgenau 2x auftrat. Aber die App ist inzwischen deinstalliert, wobei

    GNOME Application Platform version 45          org.gnome.Platform 

    immer noch meint, dass Spotify installiert ist. Es lässt sich auch nicht deinstallieren, da

    Aber ob hier ein Zusammenhang besteht?

    Auf jeden Fall, trat das Problem unter Mageia das erste Mal wieder auf, als der Spotify Client zusammen mit GNOME Application Platform version 45 aktualisiert wurde. Allerdings wurde in dem Zuge auch Thunderbird, Firefox und anderes aktualisiert.

    Im Moment sind mir die Ansätze / Ideen ausgegangen.
    Auch wenn es im Moment funktionert, würde ich gerne den Bootstick wieder wegpacken können. :)

    Gruß
    Mavalok2

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    Ergänzung, da es hier eine Zeichenbegrenzung gibt:

    flatpak history

    Nov 16 22:21:02 deploy update org.freedesktop.Platform.GL.default 23.08 system flathub
    Nov 16 22:21:09 deploy update org.freedesktop.Platform.GL.default 23.08-extra system flathub
    Nov 16 22:21:10 deploy update org.freedesktop.Platform.Locale 23.08 system flathub
    Nov 16 22:21:10 deploy update org.gnome.Platform.Locale 44 system flathub
    Nov 16 22:21:11 deploy install org.gnome.Platform.Locale 45 system flathub
    Nov 16 22:22:01 deploy install org.gnome.Platform 45 system flathub
    Nov 16 22:22:39 deploy update com.dropbox.Client stable system flathub
    Nov 16 22:23:00 deploy update org.gnome.Platform 44 system flathub
    Nov 16 22:23:06 deploy update org.freedesktop.Platform 23.08 system flathub
    Nov 16 22:23:59 deploy update com.spotify.Client stable system flathub
    Nov 16 22:24:00 deploy update org.mozilla.Thunderbird.Locale stable system flathub
    Nov 16 22:24:26 deploy update org.mozilla.Thunderbird stable system flathub
    Nov 16 22:24:26 deploy update org.mozilla.firefox.Locale stable system flathub
    Nov 16 22:24:56 deploy update org.mozilla.firefox stable system flathub
    Nov 16 23:16:29 uninstall org.gnome.Platform 44 system
    Nov 16 23:16:29 uninstall org.gnome.Platform.Locale 44 system
    Nov 16 23:16:29 uninstall org.freedesktop.Platform.openh264 2.2.0 system
    Nov 16 23:17:02 uninstall com.spotify.Client stable system
    Nov 16 23:24:41 pull org.freedesktop.Platform.openh264 2.2.0 system flathub
    Nov 16 23:24:41 deploy install org.freedesktop.Platform.openh264 2.2.0 system flathub
    Nov 16 23:25:00 pull com.spotify.Client stable system flathub
    Nov 16 23:25:03 deploy install com.spotify.Client stable system flathub
    Nov 16 23:26:54 uninstall com.spotify.Client stable system
    Nov 16 23:29:52 pull com.spotify.Client stable system flathub
    Nov 16 23:29:55 deploy install com.spotify.Client stable system flathub
    Nov 16 23:38:07 uninstall com.spotify.Client stable system
    Nov 16 23:46:57 pull com.spotify.Client stable system flathub
    Nov 16 23:47:01 deploy install com.spotify.Client stable system flathub
    Nov 16 23:47:38 pull org.gnome.Platform.Locale 45 system flathub
    Nov 16 23:47:38 deploy install org.gnome.Platform.Locale 45 system flathub
    Nov 16 23:47:39 pull org.gnome.Platform 45 system flathub
    Nov 16 23:47:42 deploy install org.gnome.Platform 45 system flathub
    Nov 16 23:50:01 uninstall com.spotify.Client stable system
    Nov 17 00:05:00 pull org.gnome.Platform.Locale 45 system flathub
    Nov 17 00:05:00 deploy install org.gnome.Platform.Locale 45 system flathub
    Nov 17 00:05:00 pull org.gnome.Platform 45 system flathub
    Nov 17 00:05:02 deploy install org.gnome.Platform 45 system flathub

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    Keiner eine Idee oder Ansatz? Schade. Ist schon wieder passiert, nach folgenden Updates.

    Möglicherweise hiermit zu tun:

    Nov 27 22:08:05 localhost [RPM][100727]: install systemd-253.10-1.1.mga9.x86_64: success

    Aber dies war letztes Mal nicht. Da waren nur Flatpak Updates.

    Weiß jemand wohin der efibootmgr schreibt? Wird letzten Endes auch eine "Konfig-Datei" sein. Habe so den Verdacht, dass hier eine "Standard" Konfig wieder hergestellt wird. Wenn ich die auf meine eigene umbiegen könnte... dann ist mir egal wenn zurückgesetzt wird.

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    efibootmgr ist ein Programm um die Booteinträge im NVRAM-Chip (das ist nicht flüchtiger Speicher) des UEFI zu bearbeiten. Vielleicht verstellt sich nur die Bootreihenfolge? Vielleicht lassen sich unnütze Einträge entfernen? Hier steht mehr zu efibootmgr: --> https://wiki.mageia.org/en/Efibootmgr

    Hast du probiert ob das System im BIOS-Modus besser funktioniert? Hast du die CMOS-/BIOS-Batterie mal geprüft?

    Zitat von Kater

    Hast du die CMOS-/BIOS-Batterie mal geprüft?

    Das hätte ich auch vorgeschlagen, zumal der Rest des PC ja aus dem "Bestand" war. Könnte ein erstes Anzeichen sein.

    "Es gibt ein Prinzip, das als Schranke gegen jede Information dient, als Beweis gegen jedes Argument und das niemals fehlschlagen wird die Menschheit in immerwährender Unwissenheit zu halten, dieses Prinzip heißt: Verurteilung vor der Untersuchung." Carl Sagan

    Tja, die habe ich erst vor ein paar Monaten gewechselt. Allerdings nicht mit einer neuen aus der Packung, sondern einer gebrauchten. Hatte keine passende neue mehr auf Lager. Aber der Batterietester meinte im grünen Bereich. Wie wahrscheinlich ist es, dass die jetzt schon zu schwach ist? :/ Ich sehe schon, ausbauen und nochmals testen und / oder ersetzen. Nun dann ist es eindeutig.

    Zitat von Kater

    efibootmgr ist ein Programm um die Booteinträge im NVRAM-Chip (das ist nicht flüchtiger Speicher) des UEFI zu bearbeiten.

    Das ist schon einmal eine wichtig Information. Da hätte ich jetzt nicht gesucht. Dachte, dafür ist evt. die EFI-Partition da.

    Zitat von Kater

    Hast du probiert ob das System im BIOS-Modus besser funktioniert?

    Bin schon im Legacy (BIOS) Mode, von Beginn an.

    Zitat von Kater

    Vielleicht verstellt sich nur die Bootreihenfolge?

    Nö. Der Eintrag von Mageia ist komplett weg. Sieht so aus, als wäre es auf Standard zurückgesetzt worden.

    Die letzten 2 - 3 Male hatte ich das Problem nach einem Update mit anschließendem Neustart. Klingt hier dann weniger nach der CMOS-Batterie. :/ Aber kann ein Neustart so etwas auslösen? Muss ich mal testen und darauf achten.

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    Hier steht wie du die Batterie aus dem laufenden Linux testen kannst: --> https://askubuntu.com/questions/9460…he-cmos-battery

    Zitat von Mavalok2

    Das ist schon einmal eine wichtig Information. Da hätte ich jetzt nicht gesucht. Dachte, dafür ist evt. die EFI-Partition da.

    efibootmgr › Wiki › ubuntuusers.de

    Zitat

    Das Paket efibootmgr ist ein Linux-Programm, um die Konfiguration des (U)EFI‐Boot-Menüs (siehe Beispielbild links) im NVRAM aus Ubuntu heraus im Terminal zu verändern.

    Neben dem Auflisten können EFI-Boot-Einträge eingerichtet, vorhandene entfernt oder die Boot-Reihenfolge festgelegt werden.

    Du schreibst:

    Zitat von Mavalok2

    Bin schon im Legacy (BIOS) Mode, von Beginn an.

    Bitte zeige die Ausgabe von:

    Code
    [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

    und:

    Code
    sudo parted --list

    sowie:

    Code
    df -h

    Dann sehen wir ob der Modus mit der Partitionierung übereinstimmt. Wenn noch jemand anderes eine Idee hat, nur zu! :thumbup:

    Sorry die späte Antwort. Bin erst jetzt wieder auf dem Mageia PC.

    Code
    $ [ -d /sys/firmware/efi ] && echo UEFI  echo BIOS
UEFI

    Interessant. Eigentlich sollte hier der Legacy Mode aktiv sein. Werde dies im BIOS nochmals prüfen.

    Code
    $ df -h 
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf 
devtmpfs 7.3G 0 7.3G 0% /dev 
tmpfs 7.4G 0 7.4G 0% /dev/shm 
tmpfs 7.4G 1.6M 7.4G 1% /run 
/dev/sda2 126G 22G 98G 18% / 
tmpfs 7.4G 0 7.4G 0% /tmp 
/dev/sda1 299M 172K 299M 1% /boot/EFI 
/dev/sda4 765G 390G 336G 54% /media/Daten 
tmpfs 1.5G 136K 1.5G 1% /run/user/1000

    Speicher sollte überall ausreichend vorhanden sein.

    Mehr später.

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    Code
    $ cat /proc/driver/rtc | grep batt
cat: /proc/driver/rtc: Datei oder Verzeichnis nicht gefunden

    Bei

    Code
    $ sensors-detect

    lässt mich diese Aussage hier etwas zögern:
    https://linux.die.net/man/8/sensors-detect

    Zitat

    This means that it can access chips in a way these chips do not like, causing problems ranging from SMBus lockup to permanent hardware damage (a rare case, thankfully.)

    The authors made their best to make the detection as safe as possible, and it turns out to work just fine in most cases, however it is impossible to guarantee that sensors-detect will not lock or kill a specific system.

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    Zitat von Mavalok2

    Sorry die späte Antwort. Bin erst jetzt wieder auf dem Mageia PC.

    Code
    $ [ -d /sys/firmware/efi ] && echo UEFI  echo BIOS
UEFI

    Interessant. Eigentlich sollte hier der Legacy Mode aktiv sein. Werde dies im BIOS nochmals prüfen.

    Das habe ich schon vermutet, da meines Verständnisses nach efibootmgr nur im UEFI Modus zum Einsatz kommt.

    Zitat von Mavalok2

    Als ich mein Ubuntu im Bios-Modus installiert habe, habe ich bei mir die SSD mit Partitionstabelle: gpt , meine sonst als UEFI-Partion genutzte Partition mit dem den Flag bios_grub versehen. Wenn man Partitionstabelle mbr nutzt braucht man keine extra Partition.

    Zitat von Mavalok2
    Code
    $ cat /proc/driver/rtc | grep batt
cat: /proc/driver/rtc: Datei oder Verzeichnis nicht gefunden

    Bei

    Code
    $ sensors-detect

    lässt mich diese Aussage hier etwas zögern:
    https://linux.die.net/man/8/sensors-detect

    Der 1. Befehl funktioniert bei meiner Hardware. Danke, das mit sensors-detect ist interessant. Ich habe das laufen weil ich es für meine Lüftersteuerung brauche, da wenn das UEFI meine Lüfter steuert, diese nach dem Ruhezustand nicht richtig funktionieren.

    So kurzer Zwischenstand:

    Legacy Support ist aktiviert. Allerdings wird in der Bootorder "Mageia" unter "UEFI Boot Source" gelistet, die Festplatte selbst aber unter "Legacy Boot Source". Ähm ja. Möglicherweise ist dies das Problem. Bin allerdings der Meinung, das Legacy Support von Beginn an aktiviert war. Aber vielleicht ist dies auch so ein Mageia Ding.

    Aber im Moment habe ich keine Aussetzer mehr. Habe auch nichts mehr installiert / upgedatet. Irgendwie hängt das Problem auch damit zusammen. Möglicherweise auch der Neustart. Denn den benötige ich nur nach einem Update / Installation.

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    Nachtrag:

    Gerade eben die nativen App und System aktualisiert, heruntergefahren, kurz gewartet, eingeschalten (also kein Neustart > alles i.o.
    Anschliessend flatpak aktualisiert, ebenfalls wieder heruntergefahren (kein Neustart), eingeschalten > alles i.o. Hier hatte ich die letzten Male immer danach Probleme.

    Zeitgleich war ich ein T640 (Nachfolgemodell vom meinem T630 mit Mageia) am Installieren. Neustart, und was soll ich sagen, das Teil hat auch kein Medium gefunden, wenn auch USB-Medium. Aus und wieder einschalten und Medium wieder da.
    Da ist mir in den Sinn gekommen, dass mein Baugleiches T630 mit Ubuntu auch gelegentlich bei einem Neustart keine Medium findet. Aus und wieder einschalten und gut.
    Ob diese Baureihe ein Problem mit der Erkennung der Medien hat, zumindest nicht schnell genug für Linux? ;)

    Was ist, wenn Mageia im UEFI den Eintrag der vermeintlich "fehlenden" Festplatte einfach entfernt, weil es zu diesem Zeitpunkt dieses Medium nicht findet?

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

    Liegt also wirklich am Neustart. Heute Updates durchgeführt, anschließend schnell noch einen Neustart durchgeführt und... F*** :cursing: , da war doch was. KEINEN NEUSTART MACHEN. Also wieder SuperGrub bemüht und Eintrag neu gemacht. Dann noch ein Post-IT auf Neustart geklebt: Nicht verwenden. :D

    Mageia (KDE Plasma) - LMDE (Cinnamon) - Ubuntu (Gnom) - Lubuntu (LXQt) - MX Linux (KDE Plasma) - ChromeOS

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden