Ich habe eine einzelne Festplatte mit folgendem Partitionsaufbau:
- sda1&2 sind Windows-Partitionen
- sda4 ist eine erweiterte Partition, die die logischen Partitionen sda5&6 enthält
- sda5 ist die Swap-Partition für Ubuntu
- sda6 ist die Root-Ubuntu-Partition (Version 20.04)
- sda3 ist eine Partition, die nur Grub-Dateien enthält. Der Computer bootet von hier und lädt dann je nach Auswahl im Grub-Menü Windows- oder Ubuntu-Bootloader.
Im Grunde habe ich versucht, mein Grub-Menü mit Grub Customizer anzupassen, einer GUI zum Bearbeiten der Grub-Konfigurationsdateien und zum Generieren von grub.cfg. Obwohl ich es erfolgreich mit einer anderen Timeout-Dauer und einem Hintergrundbild angepasst habe, bleibt es nach der Auswahl des Bootvorgangs mit Ubuntu hängen und zeigt das folgende „[ OK ]“-Protokoll an (ich weiß nicht, wie ich es aufrufen soll):
Bitte beachten Sie, dass ich mich an dieser Stelle immer noch ohne GUI mit Strg+Alt+F2 anmelden kann.
Ich habe den Diff-Befehl verwendet, um zu bestätigen, dass Grub Customizer dieselbe grub.cfg generiert wie der Befehl grub-mkconfig (fast gleichwertig mit update-grub lautdiese Diskussion), sodass das Problem auf die Grub-Konfiguration selbst beschränkt war. Nach Verwendung von kdiff3 und ausgiebigem Experimentieren entdeckte ich, dass das Problem behoben war, wenn ich den Ubuntu-Menüeintrag in grub.cfg (natürlich den auf der Grub-Partition) folgendermaßen manuell änderte, während die gewünschten Anpassungen erhalten blieben:
fehlerhafter Bootvorgang:
### BEGIN /etc/grub.d/10_linux_proxy ###
function gfxmode {
set gfxpayload="${1}"
if [ "${1}" = "keep" ]; then
set vt_handoff=vt.handoff=7
else
set vt_handoff=
fi
}
if [ "${recordfail}" != 1 ]; then
if [ -e ${prefix}/gfxblacklist.txt ]; then
if hwmatch ${prefix}/gfxblacklist.txt 3; then
if [ ${match} = 0 ]; then
set linux_gfx_mode=keep
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=keep
fi
else
set linux_gfx_mode=text
fi
export linux_gfx_mode
menuentry "Ubuntu" --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-c1cf0131-85a4-4147-b74c-38df34cd47cc' {
recordfail
savedefault
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos6'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6 --hint='hd0,msdos6' c1cf0131-85a4-4147-b74c-38df34cd47cc
else
search --no-floppy --fs-uuid --set=root c1cf0131-85a4-4147-b74c-38df34cd47cc
fi
linux /boot/vmlinuz-5.4.0-45-generic root=UUID=c1cf0131-85a4-4147-b74c-38df34cd47cc ro acpi_sleep=nonvs quiet splash $vt_handoff
initrd /boot/initrd.img-5.4.0-45-generic
}
### END /etc/grub.d/10_linux_proxy ###
Arbeitsstiefel:
...
linux /boot/vmlinuz-5.4.0-42-generic root=UUID=c1cf0131-85a4-4147-b74c-38df34cd47cc ro acpi_sleep=nonvs quiet splash $vt_handoff
initrd /boot/initrd.img-5.4.0-42-generic
}
### END /etc/grub.d/10_linux_proxy ###
(Ich habe einfach vmlinuz-5.4.0-45-generic und initrd.img-5.4.0-45-generic in vmlinuz-5.4.0-42-generic bzw. initrd.img-5.4.0-42-generic geändert)
Ich möchte:
- wissen, wie die Verwendung der 5.4.0-42-Bilder anstelle der 5.4.0-45-Bilder einen Unterschied macht
- Finden Sie die richtigen Grub-Konfigurationsoptionen, die mit den „45s“ funktionieren, sodass ich grub.cfg nicht jedes Mal manuell bearbeiten muss, wenn ich es anpassen möchte.
UPDATE 11:31 UTC+2, 9.9.20: Gerade vor einer Stunde habe ich den neuen Linux-Kernel (5.4.0-47) heruntergeladen und versucht, damit zu booten, aber es trat das gleiche Problem wie bei 5.4.0-45 auf. Also habe ich grub.cfg wieder auf 5.4.0-42 geändert. Jetzt stehen mir also 3 verschiedene Kernel zur Verfügung: 5.4.0-{42,45,47}. Nur so ein Gedanke, aber wenn man bedenkt, dass der Gnome-Desktop laut dem Boot-Protokoll „[OK]“ (ich weiß immer noch nicht, wie es heißt) erfolgreich zu starten scheint, ist das nicht der Hauptverdächtige? Das und der NVIDIA-Daemon, der weiter oben im Protokoll fehlschlägt.
UPDATE 13:14 UTC+2 9/9/20: Hier ist das Ergebnis sudo systemctl status nvdia-persistenced.servicenach einem fehlgeschlagenen GUI-Boot:
● nvidia-persistenced.service - NVIDIA Persistence Daemon
Loaded: loaded (/lib/systemd/system/nvidia-persistenced.service; static; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2020-09-09 11:54:44 EEST; 1min 43s ago
Process: 876 ExecStart=/usr/bin/nvidia-persistenced --user nvidia-persistenced --no-persistence-mode --verbose (code=exited, status=1/FAILURE)
Process: 896 ExecStopPost=/bin/rm -rf /var/run/nvidia-persistenced (code=exited, status=0/SUCCESS)
Σεπ 09 11:54:43 george-Aspire-E5-571G nvidia-persistenced[882]: Failed to query NVIDIA devices. Please ensure that the NVIDIA device files (/dev/nvidia*) exist, and that user 126 has read and write permissions for those files.
Σεπ 09 11:54:43 george-Aspire-E5-571G nvidia-persistenced[882]: PID file unlocked.
Σεπ 09 11:54:43 george-Aspire-E5-571G nvidia-persistenced[882]: PID file closed.
Σεπ 09 11:54:43 george-Aspire-E5-571G nvidia-persistenced[882]: The daemon no longer has permission to remove its runtime data directory /var/run/nvidia-persistenced
Σεπ 09 11:54:43 george-Aspire-E5-571G nvidia-persistenced[876]: nvidia-persistenced failed to initialize. Check syslog for more details.
Σεπ 09 11:54:43 george-Aspire-E5-571G nvidia-persistenced[882]: Shutdown (882)
Σεπ 09 11:54:42 george-Aspire-E5-571G systemd[1]: Starting NVIDIA Persistence Daemon...
Σεπ 09 11:54:43 george-Aspire-E5-571G systemd[1]: nvidia-persistenced.service: Control process exited, code=exited, status=1/FAILURE
Σεπ 09 11:54:44 george-Aspire-E5-571G systemd[1]: nvidia-persistenced.service: Failed with result 'exit-code'.
Σεπ 09 11:54:44 george-Aspire-E5-571G systemd[1]: Failed to start NVIDIA Persistence Daemon.
Antwort1
Es stellte sich heraus, dass ich eine ältere Version des NVIDIA-Treibers verwendete, die nicht mit neueren Kerneln kompatibel war. Das Entfernen der alten NVIDIA-Treiber und die Installation der neuesten aus den Ubuntu-Repos hat das Problem gelöst.
Da ich davon ausging, dass der Nvidia-Treiber schuld war, führte ich ein Manöver mit hohem Risiko und hoher Belohnung durch, indem ich dieses Skript ausführte (eine leicht modifizierte Version eines gefundenenHier), um alle NVIDIA-Treiber zu deinstallieren und die neuesten aus den Ubuntu-Repos zu installieren:
#!/bin/bash
sudo apt remove --purge '^nvidia-.*' -y
sudo apt install ubuntu-desktop -y
sudo apt --purge remove "*cublas*" "cuda*" -y
sudo apt --purge remove "*nvidia*" -y
sudo add-apt-repository --remove ppa:graphics-drivers/ppa -y
sudo trash /etc/X11/xorg.conf
sudo apt autoremove -y
sudo ubuntu-drivers devices
sudo ubuntu-drivers autoinstall
sudo reboot
Nach der Installation der neuen Nvidia-Treiber habe ich grub.cfg nicht so geändert, dass der neueste Kernel (5.0.4-47) verwendet wird, um zu sehen, wie der ältere Kernel (5.0.4-42) funktioniert. Das führte zu demselben Fehler wie in der Frage beschrieben. Danach habe ich die Kernelversion in grub.cfg auf 5.0.4-47 geändert und konnte endlich korrekt in den Gnome-Desktop booten.
Mein Fazit ist, dass das Problem letztlich durch eine Inkompatibilität zwischen dem Linux-Kernel und dem NVIDIA-Grafiktreiber verursacht wurde. Wenn Sie ein ähnliches Problem haben, empfehle ich Ihnen, sowohl Ihren Linux-Kernel als auch die Grafiktreiber auf dem neuesten Stand zu halten und die NVIDIA-Treiber gegebenenfalls neu zu installieren.