Ich bin dabei, meinen Rechner mit einem neuen Mainboard auszustatten, einem Z690 Aorus Elite. Der Rechner hat einen SATA-Wechselrahmen und ein DVD-Laufwerk. Nach etlichem BIOS-Gefummel gelingt es jetzt, von einer Linux Mint 19.2 DVD zu booten – das Secureboot-Geraffel musste abgeschaltet werden. Im BIOS wird die Platte angezeigt, aber nicht als Bootmedium gelistet. Dafür steht in der Liste der Bootmedien hartnäckig ein "Windows Boot Manager", der ist aber reine Fantasie… Die im Wechselrahmen liegende LUKS-Platte mit Mint 19.3 wird zwar beim Boot kurz zugegriffen, aber vom BIOS hartnäckig ignoriert. Unter dem DVD-OS lässt sich die Platte aber mounten. Warum wird der Bootlader auf HD nicht erkannt?
Kann es sein, dass bei Linux hardwareabhänige Bootsektoren benutzt werden?
Taucher schrieb: > Kann es sein, dass bei Linux hardwareabhänige Bootsektoren benutzt > werden? Eigentlich nicht, ich konnte bis heute meine Linux Systeme sogar von einem in den anderen PC stecken und sogar mit Adapter von USB Booten. Und zwar an jedem Rechner den ich wollte. Das ging nachweisbar mit Ubuntu (20.4 zuletzt) und Debian. (Kali)
Taucher schrieb: > Warum wird der Bootlader auf HD nicht erkannt? "Old School"-Partitionstabelle oder GPT? "Boot"-Flag gesetzt? "CSM" im Bios aktiv? EFI-Bootmanager von Mint oder Bootsektor? Distributions-Unabhängigen Bootmanager mal ausprobiert, z.B. https://www.rodsbooks.com/refind/
Taucher schrieb: > Warum wird der Bootlader auf HD nicht erkannt? Moderne BIOSse haben CSM (MBR Kompatibilität) per default deaktiviert, denn Win11 braucht zwingend UEFI und Secure Boot.
Jim M. schrieb: > Moderne BIOSse haben CSM (MBR Kompatibilität) per default deaktiviert, > denn Win11 braucht zwingend UEFI und Secure Boot. Ich habe den Rechner im Moment nicht laufbereit, kann es also nicht ausprobieren, aber was du schreibst, klingt plausibel. Über CSM bin ich gestolpert, es sagte mir aber leider rein gar nichts. Ich habe mit dem BIOS-Jargon so meine Probleme und die Hilfe im BIOS ist nicht gerade hilfreich… Kennt jemand eine Site, die diesen Jargon in was halbwegs Verständliches übersetzt?
Εrnst B. schrieb: > "Old School"-Partitionstabelle oder GPT? > "Boot"-Flag gesetzt? > "CSM" im Bios aktiv? > EFI-Bootmanager von Mint oder Bootsektor? Die Platte an das alte Mainboard gekoppelt und das Linux startet ohne Probleme. (Ich habe das alte MB in eine andere Kiste eingebaut und benutze es gerade mit eben dieser Platte.)
Kilo S. schrieb: > Eigentlich nicht, ich konnte bis heute meine Linux Systeme sogar von > einem in den anderen PC stecken und sogar mit Adapter von USB Booten. > Und zwar an jedem Rechner den ich wollte. So kannte ich das auch…
Taucher schrieb: > Über CSM bin ich > gestolpert, es sagte mir aber leider rein gar nichts. Das ist die alte Art, PCs zu booten, die vor UEFI verwendet wurde. CSM steht wohl für "compatibility support mode". Früher wurden Festplatten im "MBR"-Modus partitioniert, d.h. der allererste Sektor der Festplatte enthält die Partitionstabelle mit ihren vier Einträgen und den Code des Bootloaders. (MBR steht für "master boot record", siehe auch https://en.wikipedia.org/wiki/Master_boot_record) Dieses Verfahren nutzen PCs seit IBM-/PC-DOS 2.0, dem ersten PC-Betriebssystem, das Partitionen auf Festplatten kannte. Durch die Struktur der Partitionstabelle ist die Größe der Platte, die so gebootet werden kann, auf 2 TB beschränkt. Für größere Platten musste also ein anderes Verfahren her, und das ist "GPT" (guid partition table), das von der UEFI-Firmware neuerer PCs unterstützt wird. Wenn in Deinem "BIOS" (genauer: der UEFI-Firmware, die das eigentliche BIOS ersetzt hat( nicht "legacy" oder "CSM" aktiviert ist, bootet es nicht von Festplatten mit MBR.
Jim M. schrieb: > Moderne BIOSse haben CSM (MBR Kompatibilität) per default deaktiviert, > denn Win11 braucht zwingend UEFI und Secure Boot. Im BIOS kann ich CSM aktivieren. Es erscheinen dann 3 Unterpunkte: LAN PXE Boot Option ROM – hab ich nicht Storage Boot Option Control Other PCI Devices Außerdem kann man das OS einstellen: Windows oder Other OS – also letzeres. Egal was ich einstelle – nach Save&Exit und Neustart öffnet sich wieder BIOS und CSM wird als Disable angezeigt. Es ist zum Kotzen…
Steck ein Graka rein, ohne geht CSM nicht, da die CPU graka nur mit Windoof will. MfG Michael
Michael O. schrieb: > Steck ein Graka rein, ohne geht CSM nicht, da die CPU graka nur mit > Windoof will. Definitiv Quatsch! Keiner meiner 4 Linuxrechner hat eine dedizierte Graka. Alle laufen über CSM.
Michael O. schrieb: > Steck ein Graka rein, ohne geht CSM nicht, da die CPU graka nur mit > Windoof will. Wenn du Recht hättest, dann müsste auch ein Boot von einer Linux-Installations-DVD unmöglich sein – das geht aber ohne Probleme und die Platte lässt sich anschließend auch problemlos mounten…
Taucher schrieb: > Im BIOS kann ich CSM aktivieren. Boote doch erstmal von DVD, mounte die Platte und guck Dir dann z.B. mit GParted die Partitionierung an, ob das MBR (oldschool BIOS/CSM) oder GPT (modern UEFI) ist. Außerdem kannst Du in GParted mal Menu, View, Devices anchecken. Siehe Screenshot - so sollte das aussehen, falls Du GPT-partitioniert hast. Wenn nicht, dann hast Du MBR.
GParted ist ein guter Tipp… Ich hab ihn auf dem Rechner mit dem alten MB auf der Mint 19 Platte – die auf dem neuen MB nicht gebootet wird – installiert und siehe da, die Platte hat gpt… CSM sollte also unnötig sein – oder habe ich da was falsch verstanden? Trotzdem bootet die Kiste nicht.
Michael O. schrieb: > Steck ein Graka rein, ohne geht CSM nicht, da die CPU graka nur > mit Windoof will. Jein. IIRC geht CSM mit der Intel-iGPU ab 11th Gen nicht, dazu braucht man eine Graka - aber auch keine ab Nvidia 3000, die unterstützen auch kein CSM.
Nop schrieb: > CSM mit der Intel-iGPU ab 11th Gen nicht, dazu braucht > man eine Graka - aber auch keine ab Nvidia 3000, die unterstützen auch > kein CSM. Wo findet man solche Informationen?
Taucher schrieb: > CSM sollte also unnötig sein – oder habe ich da was falsch verstanden? Ja, wenn die schon gpt-partitioniert ist, braucht man normal kein CSM. Wie sieht denn das aus, was rechts im abgeschnittenen Teil ist? > Trotzdem bootet die Kiste nicht. Aktuellstes reguläres (non-beta) BIOS ist auf dem neuen Mobo? Alles auf defaults zurückgesetzt?
Nop schrieb: > Aktuellstes reguläres (non-beta) BIOS ist auf dem neuen Mobo? Alles auf > defaults zurückgesetzt? Weder mit der BIOS-Originaleinstellung noch nach Reset auf Defaults bootet irgend was, wegen des Secure Boot Zeugs. Was da für ein BIOS drauf ist, ist leider nicht ersichtlich. Irgend eine Versionsnummer habe ich nicht gefunden. Ein BIOS-Update allerdings auch nicht.
Taucher schrieb: > Wo findet man solche Informationen? Ich kenne das hier von Asus - 500er Chipsets sind ja Rocket Lake, also 11th Gen: https://www.asus.com/us/support/FAQ/1045467 Und bei den 3000er-Karten entsinne ich solche Probleme. Hier hat einer mal Gigabyte dazu angeschrieben, die sagten "But gigabyte answered me, the 3000 series nvidia gpus dont support csm anymore same for the 12th gen." https://www.hardwareluxx.de/community/threads/z690-ud-doesnt-boot-with-csm-enabled.1308479/#post-28857316
Ich habe einen Verdacht - die "bios_grub"-Partition. Es könnte sein, daß Du zwar GPT-partitioniert hast, dies aber auf einem BIOS-Rechner, also auf dem alten Mobo. Kannst Du mal checken, ob das alte Mobo mit UEFI oder BIOS/CSM läuft? https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation Dort ganz unten geht es um GPT auf BIOS-Systemen, und da wird genau so eine bios_grub-Partition vorgeschlagen.
Nop schrieb: > https://www.asus.com/us/support/FAQ/1045467 Dort wird CSM ausgegraut… Das haben die sich in dem BIOS des Z690 Aorus Elite Mainboards einfach gespart. Was nicht passt, wird erst beim nächsten Boot und wortlos zurechtgedengelt… Dazu passt die "Hilfe" im BIOS auch ganz hervorragend: häufig wiederholt sie einfach das Label des Feldes. Das ist natürlich hochgradig hilfreich.
Taucher schrieb: > Dort wird CSM ausgegraut… Das haben die sich in dem BIOS des Z690 Aorus > Elite Mainboards einfach gespart. Was nicht passt, wird erst beim > nächsten Boot und wortlos zurechtgedengelt… Nicht sehr nutzerfreundlich, aber es ginge noch schlechter: die Settings zu akzeptieren, kein Bild zu haben und dann die Batterie entfernen müssen. Was für eine Graphik hast Du denn, die iGPU in der CPU? Dann wäre zumindest schonmal klar, wie die Konfliktlinie aussieht: einerseits kann die iGPU kein CSM, aber wenn meine Vermutung von oben stimmt, ist die Platte für BIOS (d.h. CSM) eingerichtet worden, weswegen das Board sie ohne CSM nicht als Bootplatte akzeptiert.
Nop schrieb: > Was für eine Graphik hast Du denn, die iGPU in der CPU? Die On-Board-GPU. Der Prozessor ist 12. Generation. Im Anhang sind Fotos der BIOS-Bildschirme des alten MB. Ob das UEFI oder BIOS ist, erkenne ich nicht.
Der nächste Versuch wäre dann wohl, ein aktuelles Mint auf der neuen Platte mit SSD einzurichten, in der Hoffnung, dass Linux es richtig macht.
Taucher schrieb: > Im Anhang sind Fotos der BIOS-Bildschirme des alten MB. Ob das UEFI oder > BIOS ist, erkenne ich nicht. In allen Bildern ganz oben steht "UEFI BIOS Utility", also ist es ein UEFI-fähiges Mobo. Im Abschnitt "Boot" ist ganz unten ein Punkt mit CSM, da sollte man mal reingucken, wie das eingestellt ist. Ich schätze, CSM ist aktiviert - und wenn Du es testhalber mal deaktivierst, wird die Platte im alten Mobo nicht mehr booten. Ich sehe vier Lösungen für das neue Mobo: 1) Eine Graka einstecken, die CSM kann. Das ist aber nicht nur wegen der Graka-Preise blöd, wenn Du sonst eigentlich keine Graka brauchst, sondern Du vergibst Dir damit auch den Vorteil, bei einem Graka-Defekt mit Intels iGPU ein nutzbares System zu haben, und spätestens bei einem Graka-Upgrade ginge der Zirkus von vorne los. 2) Auf dem alten Mobo die Daten auf eine externe Platte exportieren und auf dem neuen Mobo eine neue Installation vornehmen. Dann sinnigerweise gleich mit Mint 20.3, wobei der Zeitpunkt dafür jetzt auch sehr ungünstig ist, weil Mint 21 voraussichtlich Ende des Monats rauskommen sollte. Immerhin soll es aber ein Upgrade-Tool von 20.3 nach 21 geben. 3) Wie 2), aber Du wartest mit dem Mobo-Umbau bis zum Release von Mint 21. 4) Auf dem alten Mobo Clonezilla live von USB booten, ein komplettes Disk-Image auf eine externe Platte ziehen (d.h. die verschlüsselten Daten sichern). Oder, noch eleganter, Du spiegelst Deine alte Platte mittels Clonezilla auf eine neue und führst nur dort die Änderungen durch. Dann die Installation von BIOS auf UEFI ändern (könnte so gehen: https://wiki.ubuntuusers.de/GRUB_2_von_BIOS_nach_EFI_umstellen/ ), aber ich bin mir nicht ganz im Klaren, ob das auch mit der Verschlüsselung funktioniert. Das könnte sogar im alten Mobo booten, evtl. wenn Du dort CSM deaktivierst. Im neuen müßte das eh booten.
Ach ja, nochwas: die Clonezilla-Images könnten groß werden. Sehr groß, nämlich genauso groß wie die alte Platte. Wenn man das verschlüsselt sichert und die alte Platte korrekterweise vor der Linux-Installation mit Zufallsdaten gefüllt wurde, um die Dateisystemgröße zu verschleiern, dann sieht das alles wie Rauschen aus. Also keine Kompression, und wegen des verschlüsselten Dateisystems auch keine Sicherung nur der verwendeten Blöcke, wie CLonezilla das sonst tut.
Ich werde wohl warten, bis Mint 21 raus ist und dann eine Installation mit einer SSD und einer (neuen) 4 TB-Platte aufsetzen – beides habe ich schon da. Dann bleibt die alte Platte arbeitsfähig auf dem alten Rechner und es besteht kein Risiko, dass die verschlüsselte Partition Schaden nimmt. Da müsste sich doch auf der SSD auf dem neuen Rechner was machen lassen, dass man nach Plattentausch über die SSD mit 19.3 booten kann, also zwei Bootpartitionen auf der SSD: eine Mint 19.3, eine Mint21. Dann wäre zumindest für das Mint 19.3 eine Ausweich-Rechner vorhanden.
Taucher schrieb: > Da müsste sich doch auf der SSD auf dem neuen Rechner was machen lassen, > dass man nach Plattentausch über die SSD mit 19.3 booten kann Das hat nichtmal mehr ein Jahr Support, würde ich nicht machen. Eher so, daß Du Mint 21 dann auch auf dem alten Rechner booten könntest. Dazu könntest Du testhalber auf dem alten Rechner mal im BIOS das CSM abschalten und auf einer rumfliegenden Gammelplatte Mint 20.3 installieren - ohne Verschlüsselung und so, nur um mal zu sehen, wie die Partitionstabelle dann aussieht. Die müßte so ähnlich wie meine aussehen, wobei ich manuell ein separates /home vergeben habe, aber das wäre für den Test ja egal.
Wie wärs das Gelump zurück zu schicken und eins zu holen das funktioniert. Ein Mobo das kein Linux booten kann ist einfach unbrauchbar, das sollte der Hersteller lernen.
A. H. schrieb: > Ein Mobo das kein Linux booten kann Kann es doch, wie man schon dem OP entnehmen konnte, wenn man es sinnerfassend gelesen hat.
Nop schrieb: > Das hat nichtmal mehr ein Jahr Support, würde ich nicht machen. Eher so, > daß Du Mint 21 dann auch auf dem alten Rechner booten könntest. Ich will nur die Möglichkeit haben, das alte System auch auf dem neuen Rechner zu booten, für den Notfall… Prinzipiell müsste man doch auf der SSD zwei Boot-Partitionen einrichten können: eine für Mint 21 und eine für Mint 19.3. Die jeweilige Festplatte würde dann von der SSD aus gebootet. Prinzipiell müsste das doch gehen, oder?
Taucher schrieb: > Ich will nur die Möglichkeit haben, das alte System auch auf dem neuen > Rechner zu booten, für den Notfall… Prinzipiell müsste man doch auf der > SSD zwei Boot-Partitionen einrichten können: eine für Mint 21 und eine > für Mint 19.3. Die jeweilige Festplatte würde dann von der SSD aus > gebootet. Ohne CSM wirst Du dafür zu qemu-kvm greifen müssen. Damit kannst Du Dein altes System in eine virtuelle Maschine packen, die dann auch auf neuerer Hardware läuft - nur halt nie wieder auf aktueller physikalischer Hardware. Die Zeiten ändern sich. fchk
Auf der SSD kann man doch die passende Boot-Partition anlegen, die das entsprechende System auf der Platte bootet – oder liege falsch? Dann würde die Bootpartition auf dem neuen MB angelegt und das Problem sollte aus der Welt sein – auch ohne CSM…
Ich habe mit dem alten MB etwas mit CSM experimentiert. Sehr gestört haben dabei Kontaktprobleme mit den SATA-Datensteckern und es hat ziemlich gedauert, bis ich das heraus gefunden hatte. Also: die Platte lässt sich auf dem alten MB mit ausgeschaltetem CSM nicht booten. Die BIOS-Einstellung dafür ist "Auto" und damit funktioniert es. Damit ist die Lösung eine CSM-fähige Graphikkarte. Da ich sowieso vor habe, mir einen zweiten Bildschirm zuzulegen, brauche ich sowieso für jeden Rechner eine. Bisher habe ich VGA benutzt, in Zukunft soll es HDMI sein. Welche GraKas sind für diese Problemstellung empfehlenswert?
Taucher schrieb: > Welche GraKas sind für diese Problemstellung empfehlenswert? Bevor du dir extra Hardware dafür anschaffst: Wenn sowohl das neue als auch das alte Board UEFI haben, dann gibt es doch überhaupt keinen Grund für die Wechselfestplatte am CSM festzuhalten. -> installier dir da einen aktuellen EFI-Bootmanager drauf und schon ist die Platte wieder mit allen möglichen aktuellen PCs kompatibel, auch wenn diese nicht den 1981er-IBM-PC-Modus aktiviert haben. Dadurch bist du mit der Grafikkarten-Wahl auch nicht mehr eingeschränkt, und kannst gefahrlos zu aktuellen Modellen greifen.
Taucher schrieb: > Damit ist die Lösung eine CSM-fähige Graphikkarte. Die einfachere Lösung ist eine UEFI-Installation von Mint, die dann auch auf dem alten Board laufen sollte, schließlich ist das ja UEFI. Deswegen brauchst Du auch keine zwei Installationen mit einem veralteten Mint 19 für das alte Board. > Welche GraKas sind für diese Problemstellung empfehlenswert? Eigentlich sollte zumindest das Teil auf dem neuen Mobo auch ohne Graka mehrere Monitore unterstützen.
In dem Artikel https://wiki.ubuntuusers.de/EFI_Bootmanagement/ steht ein Test, der anzeigt, wie das aktuelle System gebootet wurde: [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS Wenn ich den auf dem Rechner mit dem alten MB und der Mint 19.3-Platte ausführe, wird BIOS angezeigt. Ich werde jetzt erst mal die Artikel unter https://wiki.ubuntuusers.de/EFI_Bootmanagement/ durcharbeiten, in der Hoffnung, dass mir hinterher etwas klarer ist, was da überhaupt gespielt wird.
Nop schrieb: > Eigentlich sollte zumindest das Teil auf dem neuen Mobo auch ohne Graka > mehrere Monitore unterstützen. Wie das? Geht das über einen HDMI-Stecker?
Ich habe mich jetzt getraut, den efibootmgr auf der Mint 19.3-Platte auf dem alten Rechner zu installieren. $ sudo efibootmgr -v EFI variables are not supported on this system. Was schließt man daraus? Im Artikel https://wiki.ubuntuusers.de/EFI_Problembehebung/#Komme-nicht-ins-EFI-BIOS wird folgendes empfohlen, um mehr Infos zu UEFI zu bekommen: $ sudo dmidecode -t0 | grep -Ei "BIOS boot|UEFI" BIOS boot specification is supported UEFI is supported Was schließt man daraus?
Taucher schrieb: > Wenn ich den auf dem Rechner mit dem alten MB und der Mint 19.3-Platte > ausführe, wird BIOS angezeigt. Das war zu erwarten, deswegen ja das grub_bios vorne auf der Platte. Taucher schrieb: > Ich habe mich jetzt getraut, den efibootmgr auf der Mint 19.3-Platte auf > dem alten Rechner zu installieren. Die wurde aber als BIOS gebootet, während EFI nur vorhanden ist, wenn als UEFI gebootet wurde. Ich würde mal auf ner rumliegenden Gammelplatte Mint 20.3 als UEFI installieren und gucken, ob das auf dem alten Mobo bootet. Taucher schrieb: > Wie das? Geht das über einen HDMI-Stecker? Dein neues Mobo hat einen HDMI- und einen DP-Anschluß am IO-Shield. Also gehen mindestens zwei (evtl. mehr mit Daisy-Chaining). Obwohl die CPU ja auch mehr könnte, aber der Mobo-Hersteller hat sich auf zwei begrenzt, weil kaum jemand wirklich mehr als zwei Monitore will, dann aber keine potente Graphik braucht.
Nop schrieb: > Dein neues Mobo hat einen HDMI- und einen DP-Anschluß am IO-Shield. Also > gehen mindestens zwei Und was für einen KVM-Switch braucht man dann, um 2 Bildschirme zwischen zwei Rechnern hin und her zu schalten?
Taucher schrieb: > Und was für einen KVM-Switch braucht man dann, um 2 Bildschirme zwischen > zwei Rechnern hin und her zu schalten? Achso, ich dachte, Du wolltest den alten Rechner nur noch als Reserve auf Halde halten. Dann steckt man ggf. einfach um.
Heißt das, man brauch doch eine weitere Graphikkarte mit HDMI-Ausgang und einen KVM, der zwei HDMI-Eingänge für jeden Rechner und je einen Ausgang für jeden Bildschirm hat?
Taucher schrieb: > Heißt das, man brauch doch eine weitere Graphikkarte Wenn Du keinen KVM nehmen willst, der auch DP-in kann (sowas in der Art: https://kvm-switch.de/en/HDK0402A1U.html), dann ja.
Taucher schrieb: > Dann sind zwei einfache GraKas billiger… Auch nicht viel - eine popelige GT 1030 liegt derzeit (neu) bei 90 Euro.
Ich dachte an die GT 710 – besondere Graphikanforderungen habe ich nicht und Videospiel mag ich sowieso nicht. Ich finde nur keine Infos, ob das Teil auch von Linux unterstützt wird.
Taucher schrieb: > Ich finde nur keine Infos, ob das Teil auch von Linux unterstützt wird. Wenn Du Dich mit dem proprietären Nvidia-Treiber abfinden kannst, dann schon: https://www.nvidia.com/Download/driverResults.aspx/188877/en-us Ist für mich ein Grund, wieso ich nichts von Nvidia kaufe, und ob ihr jüngster Kehrtwechsel zu OSS wirklich gut ist, muß sich erst noch zeigen.
Taucher schrieb: > Im BIOS wird die Platte angezeigt, aber nicht als Bootmedium gelistet. Hier riecht es ein wenig nach "Dualboot". Ich nutze das nicht, sondern würde das so machen: Die Festplatte formatieren, und per DVD eine Minimal-Installation drauf. Dann die Minimalinstallation booten, was ja nun gehen müsste -und den Rest nachinstallieren. Wichtig ist u.a. auch, dass man sich die Situation, die ist - und die, die man haben möchte, im Partitionsmanager ansieht - sofern verfügbar. Die Installationsroutine sollte ein wenig mithelfen, also so, wie neulich die Mitabeiterin an der Tanke auf Nachfrage zum Autowaschen: "Wo fahr ich denn jetzt lang?" zu mir sagte: "Die Waschanlage zeigt den Weg".
Bitte 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.