Liegt also wirklich am Neustart. Heute Updates durchgeführt, anschließend schnell noch einen Neustart durchgeführt und... F*** , 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.
Beiträge von Mavalok2 im Thema „Mageia 9 - Grub2 leidet an Gedächtnisschwund“
-
-
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?
-
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.
-
Code
$ cat /proc/driver/rtc | grep batt cat: /proc/driver/rtc: Datei oder Verzeichnis nicht gefunden
Bei
lässt mich diese Aussage hier etwas zögern:
https://linux.die.net/man/8/sensors-detectZitatThis 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.
-
Sorry die späte Antwort. Bin erst jetzt wieder auf dem Mageia PC.
Interessant. Eigentlich sollte hier der Legacy Mode aktiv sein. Werde dies im BIOS nochmals prüfen.
Code
Alles anzeigen# parted --list Modell: ATA WD Blue SA510 M. (scsi) Festplatte /dev/sda: 1000GB Sektorgröße (logisch/physisch): 512B/512B Partitionstabelle: gpt Disk-Flags: Nummer Anfang Ende Größe Dateisystem Name Flags 1 1049kB 315MB 314MB fat32 boot, esp 2 316MB 139GB 138GB ext4 3 139GB 165GB 26.2GB linux-swap(v1) swap 4 165GB 1000GB 835GB ext4
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.
-
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.
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.
Hast du probiert ob das System im BIOS-Modus besser funktioniert?
Bin schon im Legacy (BIOS) Mode, von Beginn an.
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.
-
Keiner eine Idee oder Ansatz? Schade. Ist schon wieder passiert, nach folgenden Updates.
Code
Alles anzeigenNov 27 22:07:55 localhost drakrpm-update: transaction on / (remove=0, install=0, upgrade=5) Nov 27 22:07:57 localhost [RPM][100727]: erase systemd-253.10-1.mga9.x86_64: success Nov 27 22:07:57 localhost [RPM][100727]: erase lib64systemd0-253.10-1.mga9.x86_64: success Nov 27 22:07:57 localhost [RPM][100727]: erase nss-myhostname-253.10-1.mga9.x86_64: success Nov 27 22:07:57 localhost [RPM][100727]: erase pavucontrol-qt-1.3.0-1.mga9.x86_64: success Nov 27 22:07:57 localhost [RPM][100727]: erase lib64udev1-253.10-1.mga9.x86_64: success Nov 27 22:07:57 localhost [RPM][100727]: install nss-myhostname-253.10-1.1.mga9.x86_64: success Nov 27 22:07:57 localhost [RPM][100727]: install lib64systemd0-253.10-1.1.mga9.x86_64: success Nov 27 22:07:59 localhost [RPM][100727]: install systemd-253.10-1.1.mga9.x86_64: success Nov 27 22:07:59 localhost [RPM][100727]: install pavucontrol-qt-1.4.0-1.mga9.x86_64: success Nov 27 22:07:59 localhost [RPM][100727]: install lib64udev1-253.10-1.1.mga9.x86_64: success Nov 27 22:08:00 localhost [RPM][100727]: erase systemd-253.10-1.mga9.x86_64: success Nov 27 22:08:00 localhost [RPM][100727]: erase lib64systemd0-253.10-1.mga9.x86_64: success Nov 27 22:08:00 localhost [RPM][100727]: erase nss-myhostname-253.10-1.mga9.x86_64: success Nov 27 22:08:00 localhost [RPM][100727]: erase pavucontrol-qt-1.3.0-1.mga9.x86_64: success Nov 27 22:08:00 localhost [RPM][100727]: erase lib64udev1-253.10-1.mga9.x86_64: success Nov 27 22:08:00 localhost [RPM][100727]: install systemd-253.10-1.1.mga9.x86_64: success Nov 27 22:08:03 localhost [RPM][100727]: install nss-myhostname-253.10-1.1.mga9.x86_64: success Nov 27 22:08:03 localhost [RPM][100727]: install lib64systemd0-253.10-1.1.mga9.x86_64: success Nov 27 22:08:05 localhost [RPM][100727]: install systemd-253.10-1.1.mga9.x86_64: success Nov 27 22:08:05 localhost [RPM][100727]: install pavucontrol-qt-1.4.0-1.mga9.x86_64: success Nov 27 22:08:05 localhost [RPM][100727]: install lib64udev1-253.10-1.1.mga9.x86_64: success
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.
-
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 -
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
Systemdatenneofetch
.°°.
°° .°°. ----------------
.°°°. °° 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.
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.
Code
Alles anzeigen$ efibootmgr BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,0001,0002,0003,0004,0005,0006,0007 Boot0000* mageia HD(1,GPT,d74c010b-2a74-4404-a345-3dc958fa57e7,0x800,0x95822)/File(\EFI\mageia\grubx64.efi) Boot0001* USB Floppy/CD VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0500000001)0000424f Boot0002* USB Hard Drive VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0200000001)0000424f Boot0003* USB Floppy/CD VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0500000000)0000424f Boot0004* Hard Drive BBS(HD,,0x0)0000474f00004e4fbd000000010000006f0057004400200042006c007500650020005300410035003100300020004d002e00320020003200320038003000200031003000300030004700420000000501090002000000007fff040002010c00d041030a0000000001010600001103120a000000ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce63300320038003100590033003000380035003000310039002000200020002000200020002000200000007fff04000000424f Boot0005* UEFI:CD/DVD Drive BBS(129,,0x0) Boot0006* UEFI:Removable Device BBS(130,,0x0) Boot0007* UEFI:Network Device BBS(131,,0x0)
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
Code
Alles anzeigen$ flatpak uninstall org.gnome.Platform Info: applications using the runtime org.gnome.Platform branch 45: com.dropbox.Client Really remove? [y/n]: y KENNUNG Zweig Op 1. [✗] org.gnome.Platform 45 r 2. [ ] org.gnome.Platform.Locale 45 r 3. [ ] org.freedesktop.Platform.openh264 2.2.0 r Error: Can't remove org.gnome.Platform/x86_64/45, it is needed for: com.dropbox.Client Fehler: Failed to uninstall org.gnome.Platform: Can't remove org.gnome.Platform/x86_64/45, it is needed for: com.dropbox.Client
Aber ob hier ein Zusammenhang besteht?
Code
Alles anzeigen$ flatpak list Name Anwendungskennung Version Zweig Installation Dropbox com.dropbox.Client 186.4.6207 stable system Synology Assistant com.synology.SynologyAssistant 7.0.2 stable system Freedesktop Platform org.freedesktop.Platform 22.08.19 22.08 system Freedesktop Platform org.freedesktop.Platform 23.08.6 23.08 system Mesa org.freedesktop.Platform.GL.default 23.1.9 22.08 system Mesa (Extra) org.freedesktop.Platform.GL.default 23.1.9 22.08-extra system Mesa org.freedesktop.Platform.GL.default 23.2.1 23.08 system Mesa (Extra) org.freedesktop.Platform.GL.default 23.2.1 23.08-extra system openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0 system Freedesktop SDK org.freedesktop.Sdk 22.08.19 22.08 system GNOME Application Platform version 45 org.gnome.Platform 45 system Breeze GTK theme org.gtk.Gtk3theme.Breeze 5.27.8 3.22 system Thunderbird org.mozilla.Thunderbird 115.4.2 stable system Firefox org.mozilla.firefox 119.0.1 stable system
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