Moin, 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? Vielen Dank.
:
Bearbeitet durch User
Wie kann ich das prüfen? Ich nutze die CPU interne Grafik.
Nee, war ein Irrtum. Du kannst ja aus dem Recovery Modus heraus die GUI starten.
Ah, hab gerade eine Intelseite gefunden, das steht, wie man deren Treiber installiert. Aber ich dachte, dass Linux das von sich aus richtig macht. Falsche Annahme?
Wie gesagt, wenn die GUI startet, dann hast du bereits einen passenden Treiber.
Stefan F. schrieb: > Du kannst ja aus dem Recovery Modus heraus die GUI starten. Vielleicht nutzt er da eine Art Standard-Mode, der "immer" geht?
:
Bearbeitet durch User
Also Auflösung u.s.w. passen schon. Hmmm.... ich hab keine Ahnung. :-/
Hast Du viele alte Kernel noch im /boot? 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
:
Bearbeitet durch User
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.
Wenn du die Platte einfach kopiert hast, musst du die UUID für /boot und / in der fstab anpassen. blkid gibt sie dir aus.
Moin, 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.
900ss D. schrieb: > Ich habe auch schon mal mit und ohne Secure Boot gebootet, keine > Änderung. Welche Optionen gibt es denn sonst noch im Bios - und dann noch: Uefi oder nicht Uefi?
> 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. Vanye
Vanye R. schrieb: > Wieso glaubst du das sowas funktionieren kann? Weil es scheinbar andere erfolgreich genauso gemacht haben? Ansonsten vielleicht erstmal lesen und verstehen? Siehe unten.... Vanye R. schrieb: > Grub wird dein Image nicht finden, muss also neu installiert werden. 900ss D. schrieb: > Dann hab ich noch folgendes augeführt: > > sudo update-grub > sudo grub-install /dev/sdx Vanye R. schrieb: > oder aber ueber Partitions-IDs und die sind > jetzt > auch anders. Also fstab editieren. 900ss D. schrieb: > Ich habe eben die BLKIDs in der fstab geprüft. Die stimmen alle. Wenn du jetzt noch einen hilfreichen Hinweis hast, bin ich dir dankbar.
Angehängte Dateien:
-
BIOS_OS-Selection.jpg
130 KB
Es gibt seit einiger Zeit Boards, bei denen man im BIOS/UEFI einstellen muss, welche Art von Betriebssystem man booten will. Da gibts dann so Einträge wie "OS-TYPE" oder wie im Bild "OS-SELECTION" und bei dem gezeigten muss ich für Linuxe "Android" wählen Beitrag "BIOS - OS-Type einstellen!"
:
Bearbeitet durch User
Rbx schrieb: > 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.
●DesIntegrator ●. schrieb: > bei denen man im BIOS/UEFI einstellen muss, > welche Art von Betriebssystem man booten will. Das ist bei diesem BIOS nicht möglich. Hab ich gerade geprüft.
●DesIntegrator ●. schrieb: > bei denen man im BIOS/UEFI einstellen muss, > welche Art von Betriebssystem man booten will. Das ist bei diesem BIOS nicht möglich. Hab ich gerade geprüft.
Andreas M. schrieb: > Man > kann die initrd neu erstellen lassen. 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 :)
bootet denn überhaupt ein Live-System?
●DesIntegrator ●. schrieb: > bootet denn überhaupt ein Live-System? Ich habe ja die alte SATA-SSD mit Clonezilla (Live vom Stick) auf die NVMe-SSD kopiert. Also ja :)
900ss D. schrieb: > ●DesIntegrator ●. schrieb: >> bootet denn überhaupt ein Live-System? > > Ich habe ja die alte SATA-SSD mit Clonezilla (Live vom Stick) auf die > NVMe-SSD kopiert. Also ja :) ich meinte da schon eher ein Mint21 Installationsmedium, nicht nur so ein Terminal
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).
:
Bearbeitet durch User
Zum Aktualisieren des initramfs:
1 | sudo update-initramfs -c -k $(uname -r) |
Mario M. schrieb: > Zum Aktualisieren des initramfs:
1 | sudo update-initramfs -c -k $(uname |
2 | > -r) |
Gerade versucht: 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 |
Das ist die swap Partition. Siehe:
1 | oot@Mint21:/home/joachim# blkid |
2 | /dev/nvme0n1p3: UUID="eb9a578b-7c71-4351-b867-8aaf827a9de1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b3347c9c-8345-4f22-97de-ec2dec51546e" |
3 | /dev/nvme0n1p1: UUID="3967-55B8" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="736a32b7-b778-42b8-9fe4-381c393ea034" |
4 | /dev/nvme0n1p4: UUID="a9474bb7-dbc9-47b4-b27d-3fd8439bed4b" TYPE="swap" PARTUUID="f9735fc2-8964-45e9-a97a-54a5cd53d730" |
5 | /dev/nvme0n1p2: UUID="af400826-932e-4503-b893-69e637053214" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="16f153d0-dfdc-4e17-82b7-d10165904c00" |
Ob er jetzt noch bootet, weiß ich gleich ;)
> 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.
Vanye
Vanye R. schrieb: > Oh..und sei vorsichtig mit sdxx Devices. Es stehen bei mir nur die blkids in der fstab keine /dev/sd* 900ss D. schrieb: > 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, läuft er. 900ss D. schrieb: > Ob er jetzt noch bootet, weiß ich gleich ;) Auch nach erzeugen der initramfs bleibt es so. Ich vermute er sucht die initramfs auf der falschen Partition, siehe oben. Aber wie ändere ich das? grub hab ich auch schon neu "installiert".
Le X. schrieb: > Auf meinem Desktop, Tablet und Laptop benutze ich mittlerweile > systemd-boot. Danke für en Hinweis. Aber ich möchte es erstmal so lassen, nur booten soll er auch ;)
Zeig mal wie Deine fstab und die Ausgabe von lsblk und blkid aussieht
:
Bearbeitet durch User
Vanye R. schrieb: >> 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? Frage ich mich auch, noch dazu, wo die "alte" Hardware, auf der das kopierte System lief, nicht bekannt ist. Das koennte auch ein ...386 gewesen sein.
Wendels B. schrieb: > Das koennte auch ein ...386 gewesen sein. Da gab es noch kein UEFI: 900ss D. schrieb: > Es ist ein UEFI System. War es auch vorher.
:
Bearbeitet durch User
War das alte System möglicherweise ein 32-Bit-UEFI-System?
900ss D. schrieb: > 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? 900ss D. schrieb: > 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: 1) In Grub den "Normal" Eintrag auswählen 2) Taste "e" drücken um in Grub in den Editiermodus zu wechseln. 3) In einer der Zeilen müssten die Schlüsselwörter "quiet" und "splash" stehen, diese beiden löschen 4) 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.
Stephan S. schrieb: > Zeig mal wie Deine fstab und die Ausgabe von lsblk und blkid aussieht
1 | root@Mint21:/boot# lsblk |
2 | NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS |
3 | nvme0n1 259:0 0 1,8T 0 disk |
4 | ├─nvme0n1p1 259:1 0 190M 0 part /boot/efi |
5 | ├─nvme0n1p2 259:2 0 93,1G 0 part / |
6 | ├─nvme0n1p3 259:3 0 346,5G 0 part /home |
7 | └─nvme0n1p4 259:4 0 26G 0 part [SWAP] |
8 | |
9 | root@Mint21:/boot# blkid |
10 | /dev/nvme0n1p3: UUID="eb9a578b-7c71-4351-b867-8aaf827a9de1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b3347c9c-8345-4f22-97de-ec2dec51546e" |
11 | /dev/nvme0n1p1: UUID="3967-55B8" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="736a32b7-b778-42b8-9fe4-381c393ea034" |
12 | /dev/nvme0n1p4: UUID="a9474bb7-dbc9-47b4-b27d-3fd8439bed4b" TYPE="swap" PARTUUID="f9735fc2-8964-45e9-a97a-54a5cd53d730" |
13 | /dev/nvme0n1p2: UUID="af400826-932e-4503-b893-69e637053214" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="16f153d0-dfdc-4e17-82b7-d10165904c00" |
14 | |
15 | # /etc/fstab: static file system information. |
16 | # |
17 | # Use 'blkid' to print the universally unique identifier for a |
18 | # device; this may be used with UUID= as a more robust way to name devices |
19 | # that works even if disks are added and removed. See fstab(5). |
20 | # |
21 | # <file system> <mount point> <type> <options> <dump> <pass> |
22 | # / was on /dev/sdb2 during installation |
23 | UUID=af400826-932e-4503-b893-69e637053214 / ext4 errors=remount-ro 0 1 |
24 | # /boot/efi was on /dev/sdb1 during installation |
25 | UUID=3967-55B8 /boot/efi vfat umask=0077 0 1 |
26 | # /home was on /dev/sdb3 during installation |
27 | UUID=eb9a578b-7c71-4351-b867-8aaf827a9de1 /home ext4 defaults 0 2 |
28 | # swap was on /dev/sdb4 during installation |
29 | UUID=a9474bb7-dbc9-47b4-b27d-3fd8439bed4b none swap sw 0 0 |
Andreas M. schrieb: > SWAP Partition gesichert. Evtl ist > die kleiner als 32 GB? └─nvme0n1p4 259:4 0 26G 0 part [SWAP] Ja, ist sie. Ich hatte im alten System nur 16GB Ram. Danke für deine Tips, ich werde die heute noch probieren, jetzt ist es gerade schlecht. Oder ist die 26GB SWAP partition schon die Ursache?
:
Bearbeitet durch User
> 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.
Vanye
Andreas M. schrieb: > 1) In Grub den "Normal" Eintrag auswählen > 2) Taste "e" drücken um in Grub in den Editiermodus zu wechseln. > 3) In einer der Zeilen müssten die Schlüsselwörter "quiet" und "splash" > stehen, diese beiden löschen > 4) 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?
900ss D. schrieb: > nomodeset in den Bootparametern ergänzen Das hab ich jetzt in /boot/grub/grub.cfg gemacht und er bootet jetzt ohne manuellem Eingriff. Aber ist es ohne die Änderung an grub.cfg zu lösen? Edit: Aktuell ist eine Code I5-13500 CPU. Oben war eine "5" verloren gegangen.
:
Bearbeitet durch User
> Irgendwie scheint er nicht mit der neuen CPU-Grafik zurechtzukommen. > Was ist jetzt die Lösung? Den neuesten Kernel runterladen und uebersetzen? :-D Vanye
Vanye R. schrieb: > 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.
Das System hätte man bis jetzt sicherlich auch neu installieren können. So vom Zeitaufwand her.
Andreas M. schrieb: > 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. Im Mint-Forum gibt es dazu einen hinweis:
1 | sudo apt install linux-oem-22.04c |
Danach kannst du nomodeset wieder entfernen. https://forums.linuxmint.com/viewtopic.php?t=391456
●DesIntegrator ●. schrieb: > 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)
Andreas M. schrieb: > ●DesIntegrator ●. schrieb: >> 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. ich auch nicht, seit einigen Jahren schon nicht mehr (spät, ich weiss, aber immerhin) Heisst also auf diesen Rechner lässt sich kein aktuelles Mint installieren? Womit werden dann die aktuellen Betriebbsysteme geschrieben? auf Alt-kisten?
Andreas M. schrieb: > "nomodeset" ist normalerweise keine gute Idee. Die Karte läuft dann nur > in einem kastrierten Modus. Ja, das hab ich mir schon gedacht. Aber besser als ein weißes Logo auf schwarzem Hintergrund ;) Andreas M. schrieb: > Im Mint-Forum gibt es dazu einen hinweis: Danke für den Link. Ich hatte schon etwas gesucht aber diesen Forumseintrag noch nicht entdeckt. Das mit dem Update werde ich nachher probieren. Andreas M. schrieb: > ●DesIntegrator ●. schrieb: >> 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. Das hab ich auch gedacht, aber ich wollte nicht darauf eingehen. Es gibt noch mehr Gründe, weshalb das Zeit-Argument nicht stimmt.
900ss D. schrieb: > Andreas M. schrieb: >> ●DesIntegrator ●. schrieb: >>> 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. > > Das hab ich auch gedacht, aber ich wollte nicht darauf eingehen. Es gibt > noch mehr Gründe, weshalb das Zeit-Argument nicht stimmt. heisst: das läuft jetzt bei Dir?
●DesIntegrator ●. schrieb: > heisst: > das läuft jetzt bei Dir? 900ss D. schrieb: > Und solange ich nomodeset den Kernel Parametern hinzufüge, bootet der > Rechner auch. > > Also im Prinzip schon alles hübsch so.
900ss D. schrieb: > Andreas M. schrieb: >> Im Mint-Forum gibt es dazu einen hinweis: > > 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.
:
Bearbeitet durch User
900ss D. schrieb: > Und jetzt klappt es auch ohne nomodeset in den Kernelparametern. Es > funktionierte alles ohne weiteren Eingriff nach dem Update. Schön, das es jetzt geht.
Andreas M. schrieb: > 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)
Stephan S. schrieb: > bis zu 5 Jahre (Ubuntu LTS) 10 Jahre bei Red Hat, SuSE und Ubuntu - wenn man zahlt.
Stephan S. schrieb: > 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.