ubuntuusers.de

Hallo,

ich habe ein seltsames Bootproblem und weiß es nicht recht einzuordnen.

Wenn ich ganz normal booten lasse bekomme ich zunächst das Grubterminal und wenn ich dann Ubuntu auswähle kommt :

Fehler: no such device d1813..................
Linux 5.4.0-72-generic wird geladen ...
Fehler: Datei >>/boot/vmlinuz-5.4.0-72-generic nicht gefunden.
Initiale Ramdisk wird geladen ...
Fehler: Sie müssen zuerst den Kernel lade

Beliebige Taste drücken, um fortzusetzen ...

aber es läuft dann nicht weiter und ich muss das System abschalten

Wenn ich dann aber mit de CD SUPER GRUb 2 boote, läuft alles perfekt.

Die Datei "/boot/vmlinuz-5.4.0-72-generic" ist aber einwandfrei vorhanden.

Ich bin ziemlich ratlos 🙄

Gruß, Alex

Hej Bencotto,

hast Du an den Partitionen etwas verändert? (könnte dann sein, das die UUID nicht mehr stimmt). Zeige

• lsblk -f

• cat /boot/grub/grub.cfg | grep "Ubuntu, mit Linux 5.4.0-72"

Mach einfach mal ein sudo update-grub wenn Du per SGD² im laufenden System bist.

Gruß black tencate

Hallo black tencate,

hier die beiden Ausgaben:

~$ lsblk -f
NAME   FSTYPE  LABEL        UUID                                 MOUNTPOINT
loop0  squashf                                                   /snap/core18/18
loop1  squashf                                                   /snap/gnome-sys
loop2  squashf                                                   /snap/gtk-commo
loop3  squashf                                                   /snap/gnome-3-3
loop4  squashf                                                   /snap/gnome-cal
loop5  squashf                                                   /snap/gnome-log
loop6  squashf                                                   /snap/snapd/854
loop7  squashf                                                   /snap/gnome-cha
sda                                                              
├─sda1 ext4    RAID-1       378a7f8b-7c3e-4430-b50d-a559ac3a3a5d 
├─sda2 ntfs    Arbeitsdaten B8242021241FE164                     
├─sda3 ext4    RAID-Temp    8054b7d5-2afe-4623-8ff5-ae83587e649e 
├─sda4 ext4    Backup       a10cd3b1-b738-4656-b4d4-6030c3010edb 
└─sda5 ext4    RAID-Bilder  2f0ea519-3c95-4593-9fce-eb5ab169224f 
sdb                                                              
├─sdb1 ext4                 c1583dcc-5f45-41f9-8ac9-9dc05125d801 /
└─sdb2 ext4                 800ad759-e0b0-4d87-9f50-c15cb961e50b /home
sdc                                                              
└─sdc1 ext4                 971e3723-a556-43ad-bf21-ae2b6f40aa8a 
sr0                                                              
sr1                                                              
~$ 

und

~$ cat /boot/grub/grub.cfg | grep "Ubuntu, mit Linux 5.4.0-72"
	menuentry 'Ubuntu, mit Linux 5.4.0-72-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-72-generic-advanced-d18135ac-0377-41e4-b11b-9659e570a598' {
	menuentry 'Ubuntu, mit Linux 5.4.0-72-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-72-generic-recovery-d18135ac-0377-41e4-b11b-9659e570a598' {
~$ 

zusätzlich noch

~$ blkid /dev/sdb1 /dev/sdb2 /dev/sdc1
/dev/sdb1: UUID="c1583dcc-5f45-41f9-8ac9-9dc05125d801" TYPE="ext4" PARTUUID="8fcc41c7-01"
/dev/sdb2: UUID="800ad759-e0b0-4d87-9f50-c15cb961e50b" TYPE="ext4" PARTUUID="8fcc41c7-02"
/dev/sdc1: UUID="971e3723-a556-43ad-bf21-ae2b6f40aa8a" TYPE="ext4" PARTUUID="052e0776-01"
~$ 

wobei /dev/sdb1 die Bootpartition ist. /etc/fstab habe ich auch schon überprüft und die Einträge stimmen exakt überein.

Gruß, Alex

Hej Bencotto,

wie ich sagte, Du hast an den Partitionen rumgefummelt,

sdb                                                              
├─sdb1 ext4                 c1583dcc-5f45-41f9-8ac9-9dc05125d801 /

menuentry 'Ubuntu, mit Linux 5.4.0-72-generic' --[...]-d18135ac-0377-41e4-b11b-9659e570a598' 

schau auch noch in die Zeile linux /boot/vmlinuz…, auch dort steht d18135ac-0377-41e4-b11b-9659e570a598, oder etwa nicht?

Ein sudo update-grub im laufenden System hast Du nicht gemacht(?!)

EDIT.: und die neue UUID muß dann natürlich auch in die /etc/fstab

Gruß black tencate

Hallo black tencate,

wie ich sagte, Du hast an den Partitionen rumgefummelt, schau auch noch in die Zeile linux /boot/vmlinuz…, auch dort steht d18135ac-0377-41e4-b11b-9659e570a598, oder etwa nicht?

Nein, gefummelt habe ich nicht 😲 , aber ich weiß jetzt wie es entstanden ist. Ich hatte nach einer Neuordnung der Partitionen eine Neuinstallation gemacht und anschließend eine Wiederherstellung aus dem backup vorgenommen. Dann habe ich fstab angepasst und grub update und grub install vorgenommen.

Dass es diese Einträge noch /boot/grub/cfg gibt hatte ich nicht bedacht bzw. einfach nicht gewusst.

Da diese Einträge dort zig mal vorhanden sind, sollten die alle ausgetauscht werden und ist es damit erledigt oder gibt es noch woanders welche?

Gruß, Alex

Hej Bencotto,

Bencotto schrieb:

... Dann habe ich fstab angepasst und grub update und grub install vorgenommen.

dann wundert mich aber, daß dort nicht die "richtigen" UUID verwendet werden, oh, oh!

Boot mit SGD² ins Systems, und mache dort ein sudo update-grub, das (sollte) reich(t/en). Falls immer noch nicht, dann mußt Du grub aus dem laufenden System neu in den MBR installieren (also sudo grub-install /dev/sdx, wobei "x" für die Platte mit "/" gewählt werden sollt, sicherstellen, daß die dann in der Bootreihenfolge 'vorne' steht)

Gruß black tencate

Hallo black tencate,

nach dem Ersetzten der Einträge in /boot/grub/cfg läuft jetzt alles perfekt 😀 😀 😀

Vielen Dank für Deine schnelle und kompetente Hilfe sowie die Erweiterung meines Wissens über ubuntu/Linux um einige Promille

Also nochmals herzlichen Dank.

Gruß, Alex

Hej Bencotto,

Bencotto schrieb:

... nach dem Ersetzten der Einträge in /boot/grub/cfg läuft jetzt alles perfekt 😀 😀 😀

falls Du das "händisch" in der /boot/grub/grub.cfg gemacht hast, ist das nicht von Dauer – grub wird durch scripte gesteuert – daher → sudo update-grub (und ggf. Neuinstallation von grub, falls da irgend etwas 'verquer' ist.

Gruß black tencate

Bencotto schrieb:

Nein, gefummelt habe ich nicht 😲 , aber ich weiß jetzt wie es entstanden ist. Ich hatte nach einer Neuordnung der Partitionen eine Neuinstallation gemacht und anschließend eine Wiederherstellung aus dem backup vorgenommen.

Aha, was auch Deine seltsamen Inkonsistenzen mit diversen Libs in zwei Applikationen / Threads erklären könnte... 😉

Aha, was auch Deine seltsamen Inkonsistenzen mit diversen Libs in zwei Applikationen / Threads erklären könnte... 😉

Nein, eigentlich nicht, da die Wiederherstellung von einem System gemacht wurde, das exakt gleich ist und wo alles auch lief.

Bencotto schrieb:

Aha, was auch Deine seltsamen Inkonsistenzen mit diversen Libs in zwei Applikationen / Threads erklären könnte... 😉

Nein, eigentlich nicht, da die Wiederherstellung von einem System gemacht wurde, das exakt gleich ist und wo alles auch lief.

Wenn Du meinst... Nur soviel: Sämtliche von Dir in den beiden Threads aufgeführten, nicht gefundenen Libs sind symlinks

balu@CELSIUS-W520:~$ ls -la /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
lrwxrwxrwx 1 root root 23 Aug 19  2020 /usr/lib/x86_64-linux-gnu/libQt5Network.so.5 -> libQt5Network.so.5.14.2
balu@CELSIUS-W520:~$ ls -la /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
lrwxrwxrwx 1 root root 20 Aug 19  2020 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 -> libQt5Core.so.5.14.2
balu@CELSIUS-W520:~$ ls -la /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1
lrwxrwxrwx 1 root root 21 Mär 21  2020 /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1 -> libatkmm-1.6.so.1.1.0
balu@CELSIUS-W520:~$

Und genau diese (relativen) symlinks gehen bei so backup / restore Übungen oft baden! Ev. solltest Du Dich doch mal mit Deiner Backup-Methode und deren Umgang mit symlinks beschäftigen... 😉 Aber Du kannst Dich natürlich auch weiter mit seltsamen (wohl selbst verursachten) Fehlern rumschlagen. 😬

Und genau diese (relativen) symlinks gehen bei so backup / restore Übungen oft baden! Ev. solltest Du Dich doch mal mit Deiner Backup-Methode und deren Umgang mit symlinks beschäftigen... 😉 Aber Du kannst Dich natürlich auch weiter mit seltsamen (wohl selbst verursachten) Fehlern rumschlagen.

Als Backup benutze ich Backintime und bin bisher auch gut damit gefahren, lediglich dieser Full restore macht scheinbar diese Probleme.

Ich kann mit diesen Problemen im Moment sehr gut leben, da es nichts lebensnotwendiges betrifft und ich ohnehin in nächster auf auf 20.04 mit einer kompletten Neuinstallation umsteigen will.

Aber trotzdem würde mich schon interessieren ob man das reparieren kann, einfach nur im Zukunft nötigenfalls schon etwas besser gerüstet zu sein.

Du kannst das ja mal verifizieren. Im einem Deiner anderen Threads wurde ja die libatkmm-1.6.so.1 moniert. Da hast Du vermutlich noch nichts gemacht. Also einfach mal

ls -la /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1

Die korrekte Ausgabe wäre dann

lrwxrwxrwx 1 root root 21 Mär 21  2020 /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1 -> libatkmm-1.6.so.1.1.0

Wenn es kein Link ist, ist definitiv was im Argen. Du kannst auch mal ganz grob prüfen, was sonst noch alles schief gegangen ist - /usr/lib/x86_64-linux-gnu/ beinhaltet auf der obersten Ebene ca. 1200 - 1600 Links (je nach Installation). Wenn das deutlich weniger sind, ist das ein klarer Indikator, dass grundsätzlich was schiefgelaufen ist. Lass Dir das in ein Textfile ausgeben, dann ist das im Texteditor mit den Anzahl Zeilen etwas einfacher

find /usr/lib/x86_64-linux-gnu -maxdepth 1 -type l -ls > ./link-lib.txt

Grundsätzlich: Standardmässig sollte das mit BiT kein Problem sein - aber nur Du kennst Deine Config 😉 Du siehst ja schon im Backup (anhand der Icons), ob Links vorhanden sind oder nicht - dann weisst Du auch, ob sie erst gar nicht gesichert wurden oder "nur" nicht ge-restored.

Das scheint dann wohl zu stimmen

~$ ls -la /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1
lrwxrwxrwx 1 root root 21 Dez 20  2017 /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1 -> libatkmm-1.6.so.1.1.0
alex@ago:~$ 

Du kannst auch mal ganz grob prüfen, was sonst noch alles schief gegangen ist - /usr/lib/x86_64-linux-gnu/ beinhaltet auf der obersten Ebene ca. 1200 - 1600 Links (je nach Installation). Wenn das deutlich weniger sind, ist das ein klarer Indikator, dass grundsätzlich was schiefgelaufen ist

Tatsächlich zeigt er mir hier 759 Zeilen.

~$ find /usr/lib/x86_64-linux-gnu -maxdepth 1 -type l -ls > ./link-lib.txt
alex@ago:~$ 

Grundsätzlich: Standardmässig sollte das mit BiT kein Problem sein - aber nur Du kennst Deine Config

ich habe das Standardmäßige Ausschlussmuster von BiT akzeptiert so wie es automatisch vorgeschlagen ist.

Du siehst ja schon im Backup (anhand der Icons), ob Links vorhanden sind oder nicht - dann weisst Du auch, ob sie erst gar nicht gesichert wurden oder "nur" nicht ge-restored.

Das habe ich nicht verstanden, wo sollen diese zu sehen sein. In der Datei mit dem Snapshot auf dem Backup?

Bencotto schrieb:

Das habe ich nicht verstanden, wo sollen diese zu sehen sein. In der Datei mit dem Snapshot auf dem Backup?

Im Sicherungsordner von BiT siehst Du a) ob beide Dateien (Original und Link) vorhanden sind und b) hat das Link-Icon unten rechts einen Link-Pfeil (siehe Anhang). Daran kannst Du sehen, ob beides im Backup existiert. Entsprechend weisst Du dann auch, ob das Backup oder der Restore die Ursache ist.

Du kannst Dir die Files auch direkt auf dem Sicherungsmedium anschauen:

cd /Pfad/zu/Deinem/Backup/backup/backup/usr/lib/x86_64-linux-gnu
file ./libatkmm-1.6.so.1
file ./libatkmm-1.6.so.1.1.0

Die Ausgaben sehen dann etwa so aus:

balu@CELSIUS-W520:~$ cd /Pfad/zu/Deinem/Backup/backup/usr/lib/x86_64-linux-gnu
balu@CELSIUS-W520:/Pfad/zu/Deinem/Backup/backup/usr/lib/x86_64-linux-gnu/backup/usr/lib/x86_64-linux-gnu$ file ./libatkmm-1.6.so.1
./libatkmm-1.6.so.1: symbolic link to libatkmm-1.6.so.1.1.0
balu@CELSIUS-W520:/Pfad/zu/Deinem/Backup/backup/usr/lib/x86_64-linux-gnu$ file ./libatkmm-1.6.so.1.1.0
./libatkmm-1.6.so.1.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5ad9643b235cbb9a22d10db0a42f37068362d0c7, stripped
balu@CELSIUS-W520:$