ubuntuusers.de

Hallo zusammen,

seit dem Umstieg auf 26.04 (kein Dualboot-System) erscheint bei ca. jedem 2. Bootvorgang zunächst das Grub-Menü mit 30 Sekunden Timeout. Vorher mit 24.04 auf dem Rechner war das nicht so.

Im Grub-Skript habe ich einen 30 Sekunden Timeout nur im Zusammenhang mit "recordfail" gefunden.

Kann das noch einen anderen Grund haben und wenn ja, welchen?

Hinsichtlich Recordfail habe ich auf einigen Webseiten z.B. https://nelsonslog.wordpress.com/2022/08/16/grub-recordfail-30-seconds/ und https://docs.hetzner.com/de/robot/dedicated-server/operating-systems/deactivate-grub2-recordfail/ entsprechende Hinweise gefunden, die sich jedoch auf ältere Linux-Versionen beziehen. Gelten die auch für 26.04 ?

Gruß Langolier

Und? Wir sollen jetzt raten wie deine Grub config aussieht?

Führe folgenden Befehl in einem Terminal aus und zeige uns die vollständige Ein- und Ausgabe hier im Forum als Codeblock formatiert:

cat /etc/default/grub

(Benutze Kopieren Strg + C und Einfügen Strg + V . Im Terminal braucht es zusätzlich die ⇧ -Taste.)

Langolier schrieb:

[…] Im Grub-Skript habe ich einen 30 Sekunden Timeout nur im Zusammenhang mit "recordfail" gefunden.

Damit bist Du vermutlich schon auf der richtigen Fährte.

Kann das noch einen anderen Grund haben und wenn ja, welchen?

Wenn es keine andere Stelle gibt, die die Variable auf 30 setzt, nein.

Hinsichtlich Recordfail habe ich auf einigen Webseiten z.B. https://nelsonslog.wordpress.com/2022/08/16/grub-recordfail-30-seconds/ und https://docs.hetzner.com/de/robot/dedicated-server/operating-systems/deactivate-grub2-recordfail/ entsprechende Hinweise gefunden, die sich jedoch auf ältere Linux-Versionen beziehen. Gelten die auch für 26.04 ?

Du traust uns also zu, verbindlich etwas über das zu sagen, was andere Leute an anderer Stelle gesagt haben und noch besser, wir sollen beurteilen, ob fremde Aussagen auch für die Zukunft gelten?

Vielen Dank für Dein Vertrauen in die Fähigkeiten der Helfer bei UbuntuUsers, aber ehrlicherweise ist das nicht realistisch. Wir sind nicht allwissend, auch wenn das manchmal realitätsfern vermutet wird.

Zeige aus dem gestarteten System:

findmnt -lt vfat 

Grub config:

:~$ cat /etc/default/grub
# If you change this file or any /etc/default/grub.d/*.cfg file,
# run 'update-grub' afterwards to update /boot/grub/grub.cfg.
# For full documentation of the options in these files, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR='Kubuntu'
GRUB_CMDLINE_LINUX_DEFAULT='quiet splash'
GRUB_CMDLINE_LINUX=""

# If your computer has multiple operating systems installed, then you
# probably want to run os-prober. However, if your computer is a host
# for guest OSes installed via LVM or raw disk devices, running
# os-prober can cause damage to those guest OSes as it mounts
# filesystems to look for things.
#GRUB_DISABLE_OS_PROBER=false

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE/GOP/UGA
# you can see them in real GRUB with the command `videoinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Aus dem gestarteten System:

:~$ findmnt -lt vfat
TARGET    SOURCE    FSTYPE OPTIONS
/boot/efi /dev/sda1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro

kB schrieb:

Du traust uns also zu, verbindlich etwas über das zu sagen, was andere Leute an anderer Stelle gesagt haben und noch besser, wir sollen beurteilen, ob fremde Aussagen auch für die Zukunft gelten?

Ich habe nur Fragen gestellt und es könnte ja sein, dass hier jemand die Antworten kennt oder Hinweise geben kann. Wenn das nicht der Fall ist, ist das völlig in Ordnung.

kB schrieb:

Vielen Dank für Dein Vertrauen in die Fähigkeiten der Helfer bei UbuntuUsers, aber ehrlicherweise ist das nicht realistisch. Wir sind nicht allwissend, auch wenn das manchmal realitätsfern vermutet wird.

Keine Sorge, ich vermute nicht, dass hier jemand allwissend ist.

Das muss ja eine Ursache haben, warum Grub ein fehlgeschlagenen Bootversuch aufgezeichnet hat und entsprechend dann das GRUB Menü aktiviert.

Ich boote ohne das Plymouth Bildchen, habe den Systemd plymouth-start.service maskiert, so sehe ich dann immer auf dem TTY, was beim Startvorgang passiert. Überdies fällt das bei mir auch direkt anhand der niedrigen Auflösung im TTY-Modus während des Bootvorgangs auf, falls der vorige Bootvorgang abgebrochen wurde, oder fehlschlug, und die GRUB recordfail Funktion aktiv wurde.

Wenn man das journald Log nicht wegschmeißt, wie beispielsweise Logs nur ins tmpfs schreiben lässt, dann ließe sich auch im journald Log nachschauen, was passiert ist. Im Wiki gibts was zu lesen:

• systemd/journald

• systemd/journalctl

Du kannst mal die Ausgaben von

1

journalctl -b 0 -p 3 -e

und

1

journalctl -b -1 -p 3 -e

zeigen.

Nutzt du LVM oder eine Verschlüsselung?

Der Rechner bootet normal - abgesehen vom Auftauchen des Grub-Menüs - und fährt auch wieder herunter. Hinsichtlich Journal ist die Frage, wonach ich suchen muss Mit "fail" als Suchbegriff findet sich das hier:

11.05.26 14:23	sddm-helper	Failed to write utmpx:  Datei oder Verzeichnis nicht gefunden

LVM wird nicht genutzt und die Laufwerke (1x System und 1x Daten) sind nicht verschlüsselt.

:~$ journalctl -b 0 -p 3 -e
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
Mai 11 14:23:27 ortis kernel: x86/cpu: SGX disabled or unsupported by BIOS.
Mai 11 14:23:40 ortis org_kde_powerdevil[1730]: [  1730] Error(s) opening ddc devices
Mai 11 14:23:40 ortis org_kde_powerdevil[1730]: [  1730] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-1
Mai 11 14:23:40 ortis org_kde_powerdevil[1730]: [  1730] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-2
Mai 11 14:23:40 ortis org_kde_powerdevil[1730]: [  1730] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-3
Mai 11 14:23:40 ortis org_kde_powerdevil[1730]: [  1730] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-4
Mai 11 14:23:40 ortis org_kde_powerdevil[1730]: [  1730] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-5
Mai 11 14:23:40 ortis org_kde_powerdevil[1730]: [  1730] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-6
Mai 11 14:23:40 ortis obexd[1817]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolutio>
Mai 11 14:23:40 ortis obexd[1817]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolutio>
lines 1-10/10 (END)

:~$ journalctl -b -1 -p 3 -e
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
Mai 11 07:45:15 ortis kernel: x86/cpu: SGX disabled or unsupported by BIOS.
Mai 11 07:45:35 ortis org_kde_powerdevil[1755]: [  1755] Error(s) opening ddc devices
Mai 11 07:45:35 ortis org_kde_powerdevil[1755]: [  1755] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-1
Mai 11 07:45:35 ortis org_kde_powerdevil[1755]: [  1755] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-2
Mai 11 07:45:35 ortis org_kde_powerdevil[1755]: [  1755] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-3
Mai 11 07:45:35 ortis org_kde_powerdevil[1755]: [  1755] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-4
Mai 11 07:45:35 ortis org_kde_powerdevil[1755]: [  1755] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-5
Mai 11 07:45:35 ortis org_kde_powerdevil[1755]: [  1755] Error EACCES(-13): Keine Berechtigung opening /dev/i2c-6
Mai 11 07:45:36 ortis obexd[1838]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolutio>
Mai 11 07:45:36 ortis obexd[1838]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolutio>
lines 1-10/10 (END)

In deinem System sind jedenfalls keine Fehler, die das Booten so beeinflussen, dass grub deine Timeoutzeit ignoriert. Probiere mal die Zeile in deine /etc/default/grub hinzuzufügen:

GRUB_RECORDFAIL_TIMEOUT=0

und danach nicht vergessen

1

sudo update-grub

auszuführen.

Edit: Zeige bitte auch mal die Ausgabe von

1

lsblk -f

Bei mir schnüffelt der org_kde_powerdevil über den i2c Bus auf meiner Nvidia Grafikkarte mit Maxwell2 GPU, die mittels properitärem nvidia-driver-580 läuft, an den Ausgängen der Grafikkarte herum, und guckt, wo was angeschlossen ist.

ddc ist auch ein Hinweis auf den Display Data Channel, über den die Eigenschaften und Möglichkeiten des Monitors ausgelesen werden.

• Display_Data_Channel

obexd ist ein Daemon für Datenübertragung via Bluetooth.

Hallo Langolier,

Firmware des BIOS / EFI aktuell ?

Gruss Lidux

Lidux schrieb:

Firmware des BIOS / EFI aktuell ?

Ja, ist aktuell.

Patsche schrieb:

In deinem System sind jedenfalls keine Fehler, die das Booten so beeinflussen, dass grub deine Timeoutzeit ignoriert. Probiere mal die Zeile in deine /etc/default/grub hinzuzufügen:

GRUB_RECORDFAIL_TIMEOUT=0

Das wollte ich ohnehin probieren - allerdings mit einem Timeout von 5 Sekunden. Timeout=0 scheint mir für den Fehlerfall suboptimal.

Patsche schrieb:

Edit: Zeige bitte auch mal die Ausgabe von

1

lsblk -f

~$ lsblk -f
NAME        FSTYPE   FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs 4.0                                                           0   100% /snap/bare/5
loop1       squashfs 4.0                                                           0   100% /snap/core24/1587
loop2       squashfs 4.0                                                           0   100% /snap/gnome-46-2404/153
loop3       squashfs 4.0                                                           0   100% /snap/gtk-common-themes/1535
loop4       squashfs 4.0                                                           0   100% /snap/gtk-theme-breeze/8
loop5       squashfs 4.0                                                           0   100% /snap/mesa-2404/1165
loop6       squashfs 4.0                                                           0   100% /snap/icon-theme-breeze/5
loop7       squashfs 4.0                                                           0   100% /snap/snapd/26865
loop9       squashfs 4.0                                                           0   100% /snap/thunderbird/1093
loop10      squashfs 4.0                                                           0   100% /snap/thunderbird/1104
sda                                                                                         
├─sda1      vfat     FAT32              7A81-294F                             291,3M     3% /boot/efi
└─sda2      ext4     1.0   kubuntu_2604 8b26bdcb-011e-4921-9749-e0bb56715fc1   97,3G    11% /
nvme0n1                                                                                     
└─nvme0n1p1 ext4     1.0   Data         728f5d80-760a-4eb4-9dc3-8310efb17800  170,9G    22% /home/orti/Daten

SDA ist eine SATA-SSD mit dem Betriebssystem, auf der bis vor 1 Woche noch Kubuntu 24.04 installiert war. Nvme0n1p1 ist eine NVME, die nur Daten enthält.

Patsche schrieb:

Probiere mal die Zeile in deine /etc/default/grub hinzuzufügen:

GRUB_RECORDFAIL_TIMEOUT=0

Die Änderung des Timeout hat funktioniert. Insofern sind die Eingangsfragen beantwortet und habe ich das als gelöst markiert.

Weshalb Recordfail gesetzt wird, obwohl es kein offensichtliches Bootproblem gibt, konnte ich noch nicht klären. Der Vorgang um Recordfail läuft laut Gemini so:

Sobald GRUB startet und das Menü lädt (oder den Kernel lädt), wird die Variable recordfail in der Boot-Umgebungsdatei (meist /boot/grub/grubenv) auf 1 gesetzt.

Wenn das Betriebssystem vollständig und erfolgreich hochgefahren ist, führt ein Systemdienst (unter Ubuntu/Debian meist das Skript /etc/init.d/grub-common oder ein entsprechender Systemd-Service) den Befehl grub-editenv aus, um die Variable wieder auf 0 zu setzen (bzw. zu löschen).

Falls das System während des Bootens abstürzt, der Strom ausfällt oder der Kernel hängen bleibt, wird der Reset-Befehl nie ausgeführt. Beim nächsten Neustart sieht GRUB den Wert 1 und weiß: "Der letzte Boot-Versuch war nicht erfolgreich."

Wenn recordfail auf 1 gesetzt ist, sieht der Inhalt der Datei normalerweise so aus:

# GRUB Environment Block recordfail=1

Ich werde mir künftig nach jedem Systemstart die /boot/grub/grubenv ansehen, ob recordfail gesetzt ist. Mal sehen, ob die Variable tatsächlich gesetzt bleibt.

Interessant. Kannst du diese Wert nicht einmal testweise selbst auf "0" setzen?.

Ändert natürlich nichts daran, warum das nicht automatisch passiert. Man könnte das dann automatisieren mit einem Skript. Wäre aber auch nur eine Krücke, die wir gegen eine andere Krücke tauschen. Anderseits könnte man dann herausfinden, ob das stimmt, was die KI sagt.

Patsche schrieb:

Interessant. Kannst du diese Wert nicht einmal testweise selbst auf "0" setzen?.

Die Idee hatte ich auch schon. Wenn ich allerdings mit grub-editenv mal nur die aktuellen Variablen aufliste, kommt folgendes heraus:

~$ grub-editenv /boot/grub/grubenv list
grub-editenv: Achtung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-editenv: Achtung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-editenv: Achtung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-editenv: Achtung: cannot open device hostdisk//dev/sda2: Laufwerk »hostdisk//dev/sda2« wurde nicht gefunden..
recordfail=1

Wenn recordfail nicht gesetzt ist, fehlt die letzte Zeile, die ersten vier Zeilen bleiben. Offenbart sich in den ersten vier Zeilen womöglich das eigentliche Problem? Auffällig ist auch, dass ich den Pfad komplett angeben muss. Laut der grub-editenv Manpage sollte ein "-" ausreichen:

If FILENAME is `-', the default value /boot/grub/grubenv is used.

Vor diesem Hintergrund habe ich das "unset" Kommando nicht ausprobiert und beobachte das erstmal weiter.

Nachtrag - zur Info für Interessierte / Betroffene.

Der Rechner startet mal ohne und mal mit Grub-Bootmenü, obwohl der Bootvorgang ohne erkennbare Probleme verläuft. Mal wechselt das von Bootvorgang zu Bootvorgang, mal bootet er mehrere Male hintereinander ohne Bootmenü oder mehrere Male hintereinander mit. Es ist in keiner Weise regelmäßig - auch nicht von Tag zu Tag oder Woche zu Woche ect..

Nach meinen Beobachtungen kommt das Bootmenü tatsächlich nur, wenn recordfail nach dem vorherigen Bootvorgang gesetzt war. Es könnte daher tatsächlich so ablaufen, wie Gemini (siehe Beitrag vom 14. Mai) es beschreibt. Davon ausgehend, funktioniert offenbar das Rücksetzen der Variable nicht immer. Die Frage nach dem Grund ist nach wie vor offen. Allerdings gibt es ein paar Auffälligkeiten:

Diese Rückmeldung kommt sowohl, wenn recordfail gesetzt ist, als auch wenn recordfail nicht gesetzt ist (dann fehlt die letzte Zeile):

~$ grub-editenv - list
grub-editenv: Achtung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-editenv: Achtung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-editenv: Achtung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-editenv: Achtung: cannot open device hostdisk//dev/sda2: Laufwerk »hostdisk//dev/sda2« wurde nicht gefunden..
recordfail=1

sda2 ist definitiv vorhanden. Die Datei /boot/grub/grubenv ist ebenfalls vorhanden, lesbar und mittels grub-editenv auch bearbeitbar (siehe ganz unten).

Dann habe ich noch das hier gefunden:

$~ systemctl status grub-initrd-fallback.service
○ grub-initrd-fallback.service - GRUB failed boot detection
     Loaded: loaded (/usr/lib/systemd/system/grub-initrd-fallback.service; enabled; preset: enabled)
     Active: inactive (dead) since Fri 2026-06-05 07:48:59 CEST; 53min ago
 Invocation: 632e1d058c454544817c726fde786abe
    Process: 6227 ExecStart=/usr/bin/grub-editenv /boot/grub/grubenv unset initrdfail (code=exited, status=0/SUCCESS)
    Process: 6238 ExecStart=/usr/bin/grub-editenv /boot/grub/grubenv unset prev_entry (code=exited, status=0/SUCCESS)
   Main PID: 6238 (code=exited, status=0/SUCCESS)
   Mem peak: 4.5M
        CPU: 52ms

Jun 05 07:38:36 ortis systemd[1]: Starting grub-initrd-fallback.service - GRUB failed boot detection...
Jun 05 07:48:59 ortis systemd[1]: grub-initrd-fallback.service: Deactivated successfully.
Jun 05 07:48:59 ortis systemd[1]: Finished grub-initrd-fallback.service - GRUB failed boot detection.

Das "GRUB failed boot detection." wird nicht als Fehler dargestellt. Diese Ausgabe kommt immer, d.h. sowohl bei gesetztem als auch bei nicht gesetztem recordfail. Von daher hat es für die Problematik wohl keine Bedeutung.

Patsche schrieb:

Interessant. Kannst du diese Wert nicht einmal testweise selbst auf "0" setzen?.

Ich habe jetzt das folgende Skript in Betrieb, das bei gesetztem recordfail diese Variable löscht. Das löst zwar nicht das Problem, funktioniert aber.

#!/bin/bash
# Recordfail löschen, falls gesetzt

BootFlag=$(cat /boot/grub/grubenv)              #grubenv auslesen
BootFlag="${BootFlag#*ord}"                     #alles vor und einschließlich "ord" wegschneiden
BootFlag="${BootFlag%%=*}"                      #ab dem "=" alles wegschneiden, so dass von dem "recordfail=1" am Anfang des Strings nur noch "fail" übrigbleibt

if [ "$BootFlag" == "fail" ]
    then
        sudo grub-editenv - unset recordfail
        echo "recordfail zurückgesetzt."
        echo
    else
        echo "recordfail ist nicht gesetzt."
        echo
fi
read -p "Fertig. (ENTER)" name                  # Damit das Terminalfenster nach Abschluss des Skrips geöffnet bleibt