Archiv verlassen und diese Seite im Standarddesign anzeigen : Linux auf NVMe installieren ohne Windows-Festplatten anzurühren
Julius
2022-10-21, 14:12:29
Ich spiel gerne mit neuen Linux Distros rum.
Normal nutz ich Linux Mint und Windoff.
Frage:
Bei meinem neuen Rechner kann ich im Bios keine NVME Festplatte deaktivieiren.
Ich würde gerne aber einfach nur eine NVME Festplatte anzeigen lassen beim Installieren und diese nutzen. D.h. die anderen sollen gar nicht da sein und auch nicht angerührt werden.
Am Ende wähle ich einfach per Boot Menü von welcher NVME Platte ich starten möchte.
Weis einer eine Lösung OHNE das ich die anderen NVME Platten raus baue?
Berniyh
2022-10-21, 14:23:19
Wenn du eine zweite NVMe hast, dann installier einfach und lass beide aktiviert. Du kannst bei der Installation ja auswählen, welche SSD verwendet werden soll.
Welche die mit Windows ist kannst du ja daran erkennen, dass die NTFS Partition(en) enthält.
Wahrscheinlich ist auf der auch die EFI Partition (FAT32), die kannst du schlicht mitnutzen, da spricht überhaupt nichts dagegen.
(Letztendlich werden einfach zusätzliche Dateien für zusätzliche EFI Einträge in der Partition abgelegt.)
Das zu startetende OS kannst du dann über das EFI Bootmenü auswählen.
Andererseits: wenn du Linux nur zum Rumspielen nutzen willst: was spricht gegen eine VM unter Windows?
(Ich persönlich mache es genau umgekehrt, aber das ist hier ja nicht Thema. :D)
universaL
2022-10-21, 15:49:31
je nachdem wie groß die "windows-efi" partition ist, kann sie auch mal zu klein werden ;-)
Berniyh
2022-10-21, 19:19:50
je nachdem wie groß die "windows-efi" partition ist, kann sie auch mal zu klein werden ;-)
Ach komm, als ob …
Eine GRUB efi Datei wiegt 276 kB. Ich weiß jetzt nicht, wie das bei anderen Bootloadern ist, aber die dürften auch nicht viel größer sein.
Wenn das nicht mehr drauf passt, dann weiß ich auch nicht mehr … :freak:
Es ist gut, dass du zwei SSDs hast; Windows und Linux auf einer "Platte" gibt immer gerne Probleme. Vor allem, wenn wenn man noch relativ neu in der Linux-Welt unterwegs ist.
Habe ich aber auch schon verbaselt, :tongue:
Wie Berniyh schon geschrieben hat, bei der Installation einfach doppel checken, dass alles bei der Linux-Installation nur auf der Linux-SSD ist und die Windows-Installation nicht angefasst wird.
Nach dem Linux-Install in BIOS das Start Device auf die Linux Platte umstellen.
Bei den gängigen Linux-Distros wird OS-Prober automatisch installiert, d.h. Grub (der Boot-Manager) sollte Windows erkannt und einen Boot-Eintrag dafür erstellt haben.
Wenn du nur einen Linux-Eintrag in Grub beim booten findest, kein Problem: Boote Linux und installiere "os-prober" nach und nochmal "grub-mkconfig" ausführen: https://wiki.archlinux.org/title/GRUB#Detecting_other_operating_systems
Aber ich bin ziemlich sicher, dass Mint mit os-prober kommt, :smile:
Rooter
2022-10-23, 10:42:06
Aber ich bin ziemlich sicher, dass Mint mit os-prober kommt, :smile:Ja, ist dabei.
MfG
Rooter
Berniyh
2022-10-23, 11:43:16
Nach dem Linux-Install in BIOS das Start Device auf die Linux Platte umstellen.
Bei den gängigen Linux-Distros wird OS-Prober automatisch installiert, d.h. Grub (der Boot-Manager) sollte Windows erkannt und einen Boot-Eintrag dafür erstellt haben.
An der Stelle sollte man evtl. erwähnen, dass das:
1. Nicht unbedingt notwendig ist, man kann auch das EFI Menü nutzen, wenn man GRUB nicht traut (oder Probleme damit hat).
2. Das die Windows Installation in keiner Weise modifiziert. Man kann Windows nach wie vor ohne Einschränkungen über das EFI Menü starten.
Ich persönlich bin ein Fan von GRUB, aber im Prinzip spricht nicht wirklich viel dagegen mittels EFI Menü zwischen den Systemen zu wechseln.
Mir würde zwar auf den Keks gehen, dass man dafür immer einen Button drücken muss um das Menü aufzurufen, aber das ist Meckern auf hohem Niveau.
universaL
2022-10-23, 20:03:54
Ach komm, als ob …
Eine GRUB efi Datei wiegt 276 kB. Ich weiß jetzt nicht, wie das bei anderen Bootloadern ist, aber die dürften auch nicht viel größer sein.
Wenn das nicht mehr drauf passt, dann weiß ich auch nicht mehr … :freak:
da ich das Problem praktisch schon hatte mit systemd-boot: hier sind initrd.img Dateien > 100mb, für jede Kernelversion eine... Dementsprechend kann es mal eng werden.
fezie
2022-10-23, 20:12:20
Normalerweise ist aber die /boot Partition nicht die EFI FAT32 Partition sondern eine ext4/btrfs etc. formatierte.
Berniyh
2022-10-23, 20:41:18
Normalerweise ist aber die /boot Partition nicht die EFI FAT32 Partition sondern eine ext4/btrfs etc. formatierte.
Es scheint wohl Distributionen zu geben, die das so umsetzen, d.h. die Kernel auf die ESP ablegen.
Meiner Meinung nach eine schlechte Idee, denn die ist ja FAT32 und FAT32 ist kein wirklich sicheres Dateisystem (i.e. kein journaling), würde also – wie von dir auch angemerkt – /boot separat machen und die ESP also /boot/efi mounten.
(Oder halt /boot in der / Partition lassen, aber halt nicht die ESP als /boot verwenden.)
systemd-boot scheint zudem auch die ESP/EFI/BOOT/BOOTX64.EFI zu überschreiben, die auch von Windows kommen würde.
Meiner Meinung nach in so einem Dual-Boot System eher eine schlechte Idee (auch wenn es keine unmittelbaren Auswirkungen hätte, ggf. aber nach einem UEFI Update), kann jetzt aber auch nicht sagen, ob/wie man das systemd-boot abgewöhnen kann.
Julius
2022-10-24, 11:26:49
Naja was ich er meinte wahr die Probleme die Windoff und Grub gerne machen.
Ich hatte bei meinen alten Rechner gerne mal das Windoff bei einem Update einfach Grub komplett gekillt hat. Gott sei dank gibts bei Linux Mint Live Stick ein extra Programm um sowas zu fixen.
Ich mach halt gerne die Festplatte aus / raus und installiere dann nur mit dieser eine Festplatte Linux oder was auch immer. Nur das ist sein NVME sehr nervig mit der kleine Schraube und Abdeckungen etc....
Wenn man alle Platten drin lässt weis man nicht immerw was wo genau wirklich geschriebn wird. Linux und auch Windoff macht gerne bei den anderen Partionen rum...
fezie
2022-10-24, 12:23:23
Es scheint wohl Distributionen zu geben, die das so umsetzen, d.h. die Kernel auf die ESP ablegen.
Meiner Meinung nach eine schlechte Idee, denn die ist ja FAT32 und FAT32 ist kein wirklich sicheres Dateisystem (i.e. kein journaling), würde also – wie von dir auch angemerkt – /boot separat machen und die ESP also /boot/efi mounten.
(Oder halt /boot in der / Partition lassen, aber halt nicht die ESP als /boot verwenden.)
Achso. Hab schon lange keine Distro mehr installiert. Ich update immer nur meine vor Ewigkeiten eingerichtete Debian Installationen.
Aber der einzige Vorteil /boot komplett auf ESP wäre, wenn / luks verschlüsselt ist oder so. Ansonsten kann /boot ja auch auf dem / liegen. Wenn man keine 3 Partion dafür haben will.
Berniyh
2022-10-24, 14:27:41
Naja was ich er meinte wahr die Probleme die Windoff und Grub gerne machen.
Ich hatte bei meinen alten Rechner gerne mal das Windoff bei einem Update einfach Grub komplett gekillt hat. Gott sei dank gibts bei Linux Mint Live Stick ein extra Programm um sowas zu fixen.
Ich mach halt gerne die Festplatte aus / raus und installiere dann nur mit dieser eine Festplatte Linux oder was auch immer. Nur das ist sein NVME sehr nervig mit der kleine Schraube und Abdeckungen etc....
Wenn man alle Platten drin lässt weis man nicht immerw was wo genau wirklich geschriebn wird. Linux und auch Windoff macht gerne bei den anderen Partionen rum...
Das ist eher ein Problem bei klassischem BIOS Boot, wo man den MBR auf einer Platte schreiben muss, Partitionen "aktivieren" muss etc.
So schrottig UEFI auch ist, ein Vorteil ist tatsächlich, dass ein neues Betriebssystem erstmal nur durch eine neue Datei auf der ESP repräsentiert wird (sowie dem zugehörigen Eintrag im EFI).
Wenn eine GRUB efi Datei dort liegt, dann gibt es auch keinen Grund seitens Windows die anzurühren. (Tatsächlich muss auch Linux die im Normalfall nicht anrühren, solange sich nichts wesentlich an GRUB ändert. Die zeigt ja im Wesentlichen nur auf die Partition die den restlichen Teil von GRUB enthält.)
Wenn Windows da rumpfuschen würde, dann wäre mir das neu und wäre wohl auch eher ein Bug seitens Windows.
"Unbekannte" Partitionen rührt Windows generell nicht an, bzw. nur auf explizites Kommando (also wenn du im Volume Manager was da dran machst). Habe jedenfalls noch nie anders erlebt.
Worum sich Windows und Linux streiten könnten ist die besagte BOOTX64.efi
Das ist so eine Art "Standard-Booteintrag", für den Fall, dass keine Einträge im EFI vorhanden sind.
Also z.B. nach einem UEFI Update, bei dem zumindest ich die Erfahrung gemacht habe, dass gerne mal alle Einträge verschwinden.
Das ist auch einer der vielen Kritikpunkte am EFI … ich meine, wenn man das schon so designed, dass eine Datei abgelegt wird um ein System zu booten, warum packt man da nicht auch gleich alle Infos mit rein um die Einträge automatisch erstellen zu lassen?
Wirkt halt dann wieder irgendwie halbgar …
Aber der einzige Vorteil /boot komplett auf ESP wäre, wenn / luks verschlüsselt ist oder so. Ansonsten kann /boot ja auch auf dem / liegen. Wenn man keine 3 Partion dafür haben will.
GRUB kann auch eine verschlüsselte /boot öffnen. Gibt da bei LUKS2 noch Einschränkungen (siehe https://savannah.gnu.org/bugs/?55093), aber mit LUKS1 sollte es funktionieren.
Für ein verschlüsseltes / würde ich aber generell überlegen, ob es nicht Sinn machen könnte /boot auf einen externen Stick zu packen, sei es jetzt verschlüsselt oder nicht. Den Stick braucht man dann nur beim /boot und ohne den startet der Computer dann auch nicht.
Das kann ggf. z.B. bei Diebstahl hilfreich sein.
@Julius: das könnte übrigens auch für dich eine Variante sein, wenn du unbedingt für Linux eine separate ESP haben willst. Statt die NVMe zu entfernen machst einfach die ESP (und ggf. /boot) auf einen USB Stick, den kannst du dann entfernen, wenn du Windows nutzt und bist auf der sicheren Seite.
Notwendig sollte es aber nicht sein. ;)
Edit: in solchen Fällen am Besten 2 USB Sticks nutzen und nach der Installation den zweiten als Klon vom ersten erstellen. USB Sticks gehen ja leider doch gerne mal kaputt. Kosten aber zum Glück auch recht wenig.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.