ich habe hier einen Rechner mit Linux Mint21.
Heute gab es ein neues Mainbord mit Intel Core I 13500 CPU, 32GB Ram und eine NVMe-SSD.
Hardware installiert und die alte SATA-SSD (ganze Disk) mittels Clonezilla (vom Stick gebootet) auf die neue NVMe SSD kopiert.
Alte Platte raus, reboot. Grub startet, d.h. es wird das Menu angezeigt wo ich "normal boot" oder kernel advanced option ausählen kann. Wenn ich "normal" boote, dann kommt direkt danach ein weißer Schriftzug "Asrock" auf schwarzem Hintergrund. Das bleibt dann so. :(
Reset gedrückt und im Grub Menu advanced kernel options ausgewählt. Dort erscheinen mehrere Kernel jeweils "normal" oder im Recovery Mode starten.
"Normal" führt zum weißen Schiftzug.
Recovery führt zu einem Menu mit ca. 10 Einträgen.
Unter anderem kann man grub neu installieren. Das hab ich gemacht.
Nach booten kommt der weiße Schriftzug und Schluß.
Wenn ich in dem Recovery Menu "normal boot" auswähle, dann bootet der Rechner und ich kann mich einloggen.
Ich habe auch in der /etc/fsstab alle Einträge auskommentiert, die auf anderen Platten (vom alten Rechner) und Netzwerk liegen. Hilft alles nicht.
Ich finde diese Art den Rechner zu booten etwas umständlich ;)
Wer hat eine Idee, weshalb er nur über die Recovery Methode bootet?
Ich habe auch schon mal mit und ohne Secure Boot gebootet, keine Änderung.
Hat jemand eine Idee was ich machen kann?
Bootet er von der alten SATA problemlos oder auch so?
Wenn Du mal umständlich gebootet hast, mach mal
1
sudo update-grub
2
sudo grub-install /dev/sdx
wobei sdx auf Deine NVMe weist, z.B. sda
UND: stimmt die UUID der alten SATA mit der UUID der NVMe überein oder hat Clonezilla eine neue UUID vereteilt, ggf musst DU die in der /etc/fstab anpassen
Möglicherweise fehlt deiner initrd auch der Treiber für NVMe. Recovery-Modus bedeutet normalerweise eine initrd mit allen Treibermodulen während "Normal" Nur die notwendigen Treiber enthält, also das was beim Installieren des Kernels gerade im System war. Man kann die initrd neu erstellen lassen.
vielen Dank an alle, die mir Hinweise gegeben haben. Auch das mich der Negativbewerter mit Punkten bedacht hat, ich wäre sonst enttäuscht :)
Ich habe eben die BLKIDs in der fstab geprüft. Die stimmen alle.
Dann hab ich noch folgendes augeführt:
sudo update-grub
sudo grub-install /dev/sdx
Beides lief ohne Fehlermeldungen.
Leider keine Änderung. Ich muss im Kernel Recovery-Mode booten.
Wenn ich die alte SSD in den Rechner baue, bootet er auch nicht, das Verhalten ist gleich.
Es gab von Andreas noch den Hinweis auf die initrd.
Da werde ich mich mal mit beschäftigen wie man die neu erzeugt.
Hardware installiert und die alte SATA-SSD (ganze Disk) mittels
Clonezilla (vom Stick gebootet) auf die neue NVMe SSD kopiert.
Wieso glaubst du das sowas funktionieren kann?
Grub wird dein Image nicht finden, muss also neu installiert werden.
Ausserdem wird dein System deine Platten entweder ueber sdxx referenzieren
und das ist nun anders, oder aber ueber Partitions-IDs und die sind jetzt
auch anders. Also fstab editieren.
Welche Optionen gibt es denn sonst noch im Bios - und dann noch: Uefi
oder nicht Uefi?
Es ist ein UEFI System. War es auch vorher.
Und im BIOS kann ich noch die Keys vom Secure Boot auf default setzen und noch mehr. Hab ich jetzt nicht im Kopf. Ich habe nur mit und ohne Secure Boot getestet, die Keys habe ich nicht angefasst.
Aber wenn es ein Secure Boot Problem wäre, dann dürfte er doch garnicht booten? Das würde ja dieses "Konzept" ziemlich in Frage stellen weil ich booten kann (im Recovery Mode) trotz "falscher" Secure Boot Konfiguration.
Da habe ich einerseits Hoffnung aber der Rechner bootet auch nicht, wenn ich die alte SATA-SSD anschließe.
Aber wenn ich im grub Menu nicht den Standarteintrag wähle sondern "... mit erweiterten Kernel" Optionen und bei den danach angebotenen Kernel nicht reccovery wähle sondern einen "normalen" dann sehe ich als letzte Zeile:
"... loading initial ramdisk" und dann erscheint das Asrock Logo in weiß und der Rechner steht.
Wenn ich Recovery wähle, dann startet er an der Stelle.
Das spricht schon dafür das initrd scheinbar nicht passt. Muss ja nicht der NVMe-Treiber sein.
Aber ich habe noch keine gute Anleitung gefunden, initrd neu zu erzeugen.
Es gibt etliches im Netz und alles sieht anders aus :)
Das ist zwar nicht die Antwort auf deine Frage, könnte allerdings auch helfen.
Ich bin mittlerweile weg von grub, auf allen Systemen (außer auf den SingleBoot Debian VMs).
Auf meinem Desktop, Tablet und Laptop benutze ich mittlerweile systemd-boot.
Entgegen dem Namen ist es nicht mit der restlichen systemd-Infrastruktur verzahnt sondern arbeitet völlig unabhängig davon.
Nach einigen Jahren der Benutzung ist mein Eindruck dass es wesentlich simpler und robuster ist als grub, allerdings auch weniger Features hat (die aber ein normaler User nicht vermisst).
root@Mint21:/home/joachim# update-initramfs -c -k $(uname -r)
update-initramfs: Generating /boot/initrd.img-5.15.0-75-generic
I: The initramfs will attempt to resume from /dev/nvme0n1p4
I: (UUID=a9474bb7-dbc9-47b4-b27d-3fd8439bed4b)
I: Set the RESUME variable to override this.
Was mich stuzig macht ist:
1
The initramfs will attempt to resume from /dev/nvme0n1p4
Wenn du jetzt noch einen hilfreichen Hinweis hast, bin ich dir dankbar.
HM..ich verstehe ich dich aber so als wenn dein grub startet,
aber den kernel nicht findet.
Oh..und sei vorsichtig mit sdxx Devices. Die koennen auf verschiedenen
Systemen unterschiedlich sein und sich auch schonmal aendern wenn man z.B
eine neue Platte an oder absteckt. Deshalb ist man ja irgendwann
auf Device IDs umgestiegen.
Aber wenn ich im grub Menu nicht den Standarteintrag wähle sondern "...
mit erweiterten Kernel" Optionen und bei den danach angebotenen Kernel
nicht reccovery wähle sondern einen "normalen" dann sehe ich als letzte
Zeile:
"... loading initial ramdisk" und dann erscheint das Asrock Logo in weiß
und der Rechner steht.
Was mich stuzig macht ist:The initramfs will attempt to resume from
/dev/nvme0n1p4
Das ist in Ordnung. Linux verwendet die SWAP Partition für Suspend to Disk, d.h. der RAM wird dabei in die SWAP Partition gesichert. Evtl ist die kleiner als 32 GB?
Auch nach erzeugen der initramfs bleibt es so. Ich vermute er sucht die
initramfs auf der falschen Partition, siehe oben.
Nicht unbedingt. Das Asrock Logo erscheint vermutlich, weil der Linux Kernel "Bootsplash" macht und da kann es sein, das er sich das Logo aus dem Bios zieht, (So wie Windows auch) Probiere mal bitte das folgende um Bootsplash abzuschalten und die Kernel-Logs zu sehen:
In Grub den "Normal" Eintrag auswählen
Taste "e" drücken um in Grub in den Editiermodus zu wechseln.
In einer der Zeilen müssten die Schlüsselwörter "quiet" und "splash" stehen, diese beiden löschen
Dann den Bootvorgang starten (Ich glaube das ist "F10", müsste aber irgendwo auf dem Bildschirm stehen)
Damit änderst du temporär die Startup-Parameter vom "Normal" Eintrag so dass er nicht den Splash sondern die normalen Kernel Messages anzeigt Vielleicht findet sich da ein Hinweis, wo er hängt.
Aber wie ändere ich das? grub hab ich auch schon neu "installiert".
Also ich gebe ja zu das es jetzt schon 10-15Jahre her ist seitdem
ich das letzte mal solche Spielchen gemacht habe, aber so aus
der Erinnerung:
In grub kannst du doch irgendwo einen Prompt bekommen.
Da muesstet du die Zeile zum booten mit dem Pfad auf deinem Kernel
eintippen koennen.
Dann sollte er den kernel finden und starten und wenn dann noch
die Eintraege in fstab stimmen dann bootet das System.
Wenn es dann laeuft dann solltest du grub einfach neu installieren
koennen und er muesste dann den korrekten Pfad eintragen.
Wenn du es aus dem Rescue-System machst dann kann es sein
das die Pfade wieder anders sind. Von dort wird man das sicher
auch installieren/anpassen koennen, aber vermutlich auch mit
ein paar geschickten Parametern auf der Kommandozeile und nicht
durch einfaches aufrufen eines Scriptes.
Ausserdem muss dein Kernel natuerlich Treiber fuer deine neue nvme
Hardware haben, allerdings wuerde ich mal erwarten das dies der Fall
ist falls du dir nicht extra einen speziellen Kernel fuer dein System erstellt hast. Aber sowas macht ja heute kaum noch einer.
Taste "e" drücken um in Grub in den Editiermodus zu wechseln.
In einer der Zeilen müssten die Schlüsselwörter "quiet" und "splash"
stehen, diese beiden löschen
Dann den Bootvorgang starten (Ich glaube das ist "F10", müsste aber
irgendwo auf dem Bildschirm stehen)
So, ich war zu motiviert ;)
Nach ein paar Versuchen kam raus...
Ich habe mit "e" dann im "Standard Booteintrag" nur "nomodeset" ergänzt und dann startet er ohne recovery.
Irgendwie scheint er nicht mit der neuen CPU-Grafik zurechtzukommen. Es war vorher ein Core I5-6700 (in mir nicht ganz sicher) und jetzt ist es ein
Code I 13500.
Was ist jetzt die Lösung? nomodeset in den Bootparametern ergänzen oder kann man ihn anders motivieren dass es ohne manueller Änderung der Parameter klappt?
Den neuesten Kernel runterladen und uebersetzen? :-D
Für einen RPi hab ich das vor ein paar Jahren mal gemacht.
Aber jetzt hab ich keine Lust mehr dazu. Das Ding soll einfach ein funktionierendes Werkzeug sein.
SWAP Partition gesichert. Evtl ist die kleiner als 32 GB?
Die SWAP Partition hab ich inzwischen auch vergrößert.
Und solange ich nomodeset den Kernel Parametern hinzufüge, bootet der Rechner auch.
Also im Prinzip schon alles hübsch so.
Ich habe gesehen, dass wohl erst die 6-er Version des Kernels die neuen Intel CPUs + Grafik unterstützt.
Mint ist aber noch bei 5.xx.
Ist ein Update des Kernels dann ratsam? Scheinbar gibt es die 6-er Kernel bei Ubuntu. Aber ob der auch passend zu Mint konfiguriert ist? Oder sind die eh gleich da Mint ja von Ubuntu abstammt.
"nomodeset" ist normalerweise keine gute Idee. Die Karte läuft dann nur in einem kastrierten Modus. (3D) Beschleunigung geht oftmals nicht und man kann auch nicht die Auflösung ändern. Der Kernel ist zu alt.
Das System hätte man bis jetzt sicherlich auch neu installieren können.
So vom Zeitaufwand her.
Was absolut nichts gebracht hätte, da der Standardkernel trotzdem zu alt ist. Wir sind hier nicht bei Windows. Ein Linux braucht man nicht neu zu installieren. Das zieht ohne zu murren von einem zum nächsten System mit. (Meins nun schon seit über 15 Jahren, inklusive mehreren Linuxupgrades und sogar Dateisystemwechseln)
Danke für den Link. Ich hatte schon etwas gesucht aber diesen
Forumseintrag noch nicht entdeckt. Das mit dem Update werde ich nachher
probieren.
So, ich hab das Update auf Kernel 6 gemacht:
1
uname -r
2
6.1.0-1015-oem
Und jetzt klappt es auch ohne nomodeset in den Kernelparametern. Es funktionierte alles ohne weiteren Eingriff nach dem Update. Aber mal sehen, was noch für Überraschungen schlummern ;)
Und der Rechner rennt, das muss ich sagen. Der Unterschied zu dem I5-6700 ist schon deutlich. Allerdings wird die NVMe-SSD auch ihren Teil beitragen.
Meine Windows-Partition hatte ich schon in eine VM gepackt und es lief. Allerdings war es schon spürbar "langsam". Aber jetzt bootet die VM schneller als das System vorher nativ. :)
Nur die Grafik ist trotz aktivierter 3D-Unterstützung etwas "hakelig".
Danke vor allem an Andreas. An alle anderen, die hier Tips abgegeben haben natürlich auch.
Was absolut nichts gebracht hätte, da der Standardkernel trotzdem zu alt
ist. Wir sind hier nicht bei Windows. Ein Linux braucht man nicht neu zu
installieren. Das zieht ohne zu murren von einem zum nächsten System
mit. (Meins nun schon seit über 15 Jahren, inklusive mehreren
Linuxupgrades und sogar Dateisystemwechseln)
Das hängt vom Linux ab. Manche haben nur 9 Monate Support (Ubuntu ohne LTS) bis zu 5 Jahre (Ubuntu LTS), manche haben eine rolling release (z.B. Kali, Arch oder Manjaro)
Das hängt vom Linux ab. Manche haben nur 9 Monate Support (Ubuntu ohne
LTS) bis zu 5 Jahre (Ubuntu LTS), manche haben eine rolling release
(z.B. Kali, Arch oder Manjaro)
Was hat das damit zu tun? Nicht nur das einen keiner daran hindert ein Release Upgrade bei Debian/Ubuntu/Suse/RedHat o.ä. zu machen, es ist sogar der übliche Weg. Man macht sich bei Debian sogar die Mühe dafür eine mehrere Seiten lange Upgrade-Anleitung zu schreiben, für jedes Release.