Linux Mint Installation für Umsteiger unter Beibehaltung Windows 10

[wolfi089]

Hallo zusammen,

um einen weichen Weg zu Linux zu gehen hatte ich folgende Anforderung.

- Der T570 sollte die ursprüngliche Windows 10 Umgebung behalten.
- Linux/Mint auf einem persistent USB Stick (SanDisk ExtremePro 512 GB).
- Ist der Stick gesteckt, startet Mint, sonst Windows 10. Ohne Auswahlbox beim Booten.

Ich habe lange Zeit mit Mint und Windows 10 gearbeitet, aber auf dedizierten Rechnern.

Den Weg wollte ich für unerfahrene Linux Nutzer im Bekanntenkreis promoten.
Jeder hätte die sichere Rückfallposition.

Nach einigen Stunden in den Tiefen des UEFI bin ich recht frustiert. Es funktioniert
jetzt zwar, aber das kann ich keinem Linux unerfahrenem Benutzer zumuten. Die
o.a. Installation sollte mit ein paar wenigen Anweisungen zum laufen kommen.

Wenn jemand eine +einfache und sichere+ Installationsanleitung für das Szenario hat,
bitte her damit.

Meine Problem, in die ich reingetreten bin

Während der Installation des Target Sticks wird nach 'Installations Type' gefragt.
Default ist 'Install Linux Mint alongside Windows Boot Manager' ausgewählt
und hörte sich gar nicht schlecht an. In meinem Fall war das katastrophal.
Grub hat sich im NVRAM eingenistet. Neu in UEFI habe ich mit einigem
Aufwand über efibootmgr das NVRAM wieder in den Griff bekommen.
An dieser Stellen muss man mit dem letzten Menüpunkt 'Something else'
weiter machen. Ich hielt meine vorgesehene Installation für etwas typisches
und hatte gar nicht an einen besonderen Weg gedacht.
Die Erläuterung an dieser Stelle im Menü hat mich auch nicht auf die
Idee gebracht, etwas genauer nachzudenken.

Weiter muss man grub modifizieren, dass es auf dem target stick bleibt
und nicht meint, sich im NVRAM gemütlich zu machen. Leider scheint
das UEFI keinen sauberen Ansatz zu bieten, nur bei eingestecktem Stick
dahin rüber zu wechseln. Was genau in der BootOrder notwendig ist oder
ob ohne Eintrag in der BootOrder (bzw. nur USB HDD) ein bootfähiger
Stick ausgeführt wird, ist mir nicht klar. Kommentare sagen, dass machen
UEFI Inkarnationen nach gutdünken. Hmm

Auf dem target Stick musste ich per Hand die EFI Umgebung und grub
bootbar machen.

Wie gesagt, habt Ihr einen Weg, der die Installation für einen Linux unerfahrenen
sicher zu Ende bringt, bitte link dazu.

danke

 

[wolfi089]

Ich meine damit, dass der Verbreitungsgrad ein wichtiges Argument ist, was ich weiterempfehle
...
2. Desktop-Distributionen im Linux-Umfeld (Schätzung nach Nutzung)
Laut Mobilestalk (Januar 2025, Anteil innerhalb der Linux-Desktop-Nutzer):
Ubuntu: ca. 30 %
Debian: ca. 15 %
Linux Mint: ca. 9 %
Manjaro: ca. 6 %
Fedora: ca. 10 %

 

[Crisser67]

Ich meine damit, dass der Verbreitungsgrad ein wichtiges Argument ist, was ich weiterempfehle

Nun ja.
MX-Linux ist Debian, Ubuntu basiert auf Debian.
Ich empfehle, was ich persönlich durch Vergleich in der Praxis kenne.
Das ist mein Maßstab und nicht der Verbreitungsgrad.
Wie gesagt: Einfach ausprobieren und vergleichen, kostet ja nichts...

 

[Ravensberger]

Wie soll man etwas empfehlen, was man nicht selber gut (!) kennt?
Ubuntu, weil es 'alle' nutzen? Da kann man auf die nahe liegende Frage "Warum empfiehlst du das?" nur stammeln, wenn man einfach eine Umfragestatistik als Empfehlung ausgibt.

Ich empfehle übrigens, sich auf eine Technologie zu konzentrieren und hierin das Wissen zu vertiefen. Wenn man verschiedene Grafische Oberflächen ausprobieren möchte, kann man einfach zu einer großen Distribution wie Debian zu greifen und der Reihe nach die Desktop-Umgebungen darauf installieren. Es gibt auch ein tolles Script, eine solche Installation mit apt-rollback vollständig wieder zurückzunehmen.

Ubuntu empfehle ich persönlich nicht, Fedora kenne ich nicht, von OpenSuse bin ich nach langer Zeit vor Jahren mit Grauen weg, Mandrake gibt es nicht mehr und Mint ist immer einen Blick wert.

 

[hikaru]

Ich empfehle, was ich persönlich durch Vergleich in der Praxis kenne.
Das ist mein Maßstab und nicht der Verbreitungsgrad.

Das kann man gar nicht genug betonen!

Wenn du anderen Leuten Linux empfiehlst, dann werden sie zu dir wegen des Supports kommen, und der wird auch an dir hängenbleiben. D.h, du musst deren Probleme fixen, auch solche, die dir selbst nie über den Weg gelaufen sind.
Ob die Leute dann die am weitesten verbreitete Distribution nutzen oder irgendeinen Exoten ist reichlich irrelevant. Relevant ist lediglich, ob du die auftretenden Probleme fixen kannst. Und dabei hilft es nicht, wenn du die Distribution nur aus der Ferne kennst.

 

[pelouse]

Wie wäre es mit einer virtuelle Maschine?

 

[Crisser67]

Hier noch ein interessanter Thread im Computerbase-Forum zu einen Live-USB-System mit Persistenz mit (MX) Linux.

Edit:
Thematisiert ist einerseits ein (Multi)boot-Live-USB-System mit Persistenz erstellt mit Ventoy , eigentlich unabhängig von der Linux-Distribution, in diesem Fall aber nur mit MX-Linux.

Andererseits wird erklärt, wie man ein MX-Linux-Singleboot-Live-USB-System wahlweise mit Persistenz baut mit den speziellen grafischen MX-Linux-Tools. Man kann dieses auch verschlüsseln.

MX-Linux-Tools:



Erklärung zu den Live-MX-Tools zitiert aus dem Thread:

• MX Snapshot: erzeugt ein ISO-Abbild eines laufenden MX-Systems. Die selbstgenerierte ISO enthält alle nachträglich aufgespielten Programme, Datenobjekte, Konfigurationsanpassungen und System-Updates. Wahlweise läßt sich das ISO entpersonalisiert erstellen (also ohne Benutzerordner wie bei originalen ISOs) oder zusätzlich inklusive der aktuellen Benutzerordner (samt Passwörter und nutzerbezogene Konfigurationsanpassungen).
• USB-Live Maker: erzeugt einen startfähigen (USB-)Datenträger auf der Grundlage einer (modifizierten) MX-ISO. Es empfiehlt sich, dieses MX-eigene Tool zu verwenden anstatt universeller Kreatoren wie Rufus oder Balena Etcher. Denn der USB-Live Maker ist für MX optimiert (Persistenz, zusätzliche Datenpartition, etc.).
• 
  
• Übrigens gibt es neben MX Snapshot und USB-Live Maker noch ein weiteres Tool zur Modifikation von (Live-)Systemen mit MX:
  - Remaster CC
  Während MX Snapshot auf der Basis des laufenden Systems ein angepasstes ISO-File auf einen verfügbaren Datenträger kopiert (um als Basis eines neu aufzusetzenden Systems zu dienen), schreibt Remaster die Änderungen direkt in das Live-Image (linuxfs) der aktuellen Live-Session. Beim nächsten Boot startet das Live-System dann dauerhaft mit allen Anpassungen. Das heißt, die Änderungen, die zuvor nur im persistenten Image (rootfs) lagerten, gehören nunmehr ebenfalls zum eigentlichen Live-System (unabhängig von Persistenz). Alle nachfolgenden Modifikationen landen dann wieder im neu sich aufbauenden rootfs-Image (bei Betrieb mit Persistenz).
  
  Ohne das vorzügliche Offline-Handbuch von MX (liegt jedem Quellmedium von MX bei) hätte ich wohl bis heute keine Ahnung von diesem mächtigen Features. Es lohnt sich also, da mal genauer reinzuschauen. Und auch die sonstigen Hilfs-Features sind sehr einsteigerfreundlich gehalten.

Manche werden sich natürlich fragen, was dabei der Vorteil gegenüber einer normalen Installation auf ein USB-Medium ist.

1. Es ist möglich, immer sein eigenes aktuelles Betriebssystem dabeizuhaben, das durch die Verschlüsselung auch sicher ist.
2. Man kann dieses System jederzeit, auch unterwegs, auf Hardware installieren.
3. Mit einem entpersonalisierten Snapshot kann man ein installierbares ISO-Image seines persönlichen aktuellen eingerichteten Systems erstellen, das man dann anderen zur Installation zur Verfügung stellt.
Man kann dieses natürlich auch als Live-System oder personalisiert als seine eigene Sicherung verwenden.

 

[JogHurt]

Ich hab zwar keine Ahnung, versuche es aber trotzdem

Mit Rufus habe ich mir ein Linux gebaut, ist eine NVME SSD im Gehäuse mit USB-C Anschluss. Per Rufus die Persistenz festgelegt und ein Linux Mint ISO reingespielt. Wenn ich USB in der Bootreihenfolge an erster Stelle einstelle, startet die Maschinen von diesem "Stick". Ist dieser abgezogen startet er ganz normal vom internen Laufwerk.

War das gemeint?

 

[fakiauso]

Mit Rufus habe ich mir ein Linux gebaut, ist eine NVME SSD im Gehäuse mit USB-C Anschluss. Per Rufus die Persistenz festgelegt und ein Linux Mint ISO reingespielt.

Genau so etwas hätte ich mir auch gedacht. Da ist die Performance auch nicht viel schlechter als intern. Wobei ich jetzt unabhängig vom Gerät auch nicht mit den Problemen des TE mit dem Bootloader betroffen war.

 

[wolfi089]

Mit Rufus habe ich mir ein Linux gebaut, ist eine NVME SSD im Gehäuse mit USB-C Anschluss. Per Rufus die Persistenz festgelegt und ein Linux Mint ISO reingespielt. Wenn ich USB in der Bootreihenfolge an erster Stelle einstelle, startet die Maschinen von diesem "Stick". Ist dieser abgezogen startet er ganz normal vom internen Laufwerk.

War das gemeint?

Nein, genau so nicht. Ich habs gerade ausprobiert.

Rufus baut einen live-Stick mit Persistence, aber keinen vollwertigen USB-Stick mit Mint.

Bei mir kommt ein grub Menü hoch, wenn ich den Stick eingesteckt habe. Da muss ich den ersten Eintrag bestätigen.
Möchte jetzt aber nicht an meinem BIOS rumtesten um einen autostart hinzubekommen. Der erste Punkt erfüllt meine Anforderung schon nicht.

trotzdem danke

 

[fakiauso]

Tja - dann ist der Weg, wie Du das vor hast, anscheinend nicht möglich.

Szenario 1 ist das, was hier mehrmals beschrieben wurde:

Persistente Installation auf Stick, Bootauswahl des T570 so einstellen, dass USB als erstes angefahren wird - fertig.

Mit angestecktem Stick = Linux
Ohne angesteckten Stick = Windows

Szenario 2:

SSD mit Windows ausbauen, deaktivieren, dann Stick, externe NVMe an USB anschließen und eine persistente oder "echte" Installation darauf machen. Dann bleibt grub auf dem einzigen Laufwerk und damit die Windows-Platte unberührt.

Anschließend Bootauswahl s.o. und es sollte mit Stick/USB-Laufwerk Linux zünden oder ohne halt Windows.
-----------------------
Ob das für einen anderen Benutzer handlicher ist als eine ggf. zweite interne SSD, auf der grub und Linux installiert werden, damit die Windows-Platte unverändert bleibt, und dann mittels F12 das jeweilige OS händisch ausgewählt wird, sei dahingestellt.

So funktioniert das jedenfalls bei mir auf einem P50, P1, T410 uswusf. mit mehreren Distributionen im Dualboot völlig problemlos selbst bei Nur-Nutzern. Ob dabei oldschooled per MBR oder zeitgemäß über UEFI + SecureBoot gebootet wird, spielt keine Rolle. Ein Katastrophen-Linux hatte ich schon zu Zeiten von T40 problemlos auf externen USB-Laufwerken.

 

[wolfi089]

Tja - dann ist der Weg, wie Du das vor hast, anscheinend nicht möglich.

Doch, ich mußte aber post-install von Hand über den install-Stick grub auf dem target-Stick updaten

chroot
und dann so ähnlich wie hier

    grub-install --target=x86_64-efi \
                 --efi-directory=/boot/efi \
                 --boot-directory=/boot \
                 --removable

    # Grub-Menü aktualisieren
    update-grub

dass 'removable' ist der wesentliche Trick

 

[linrunner]

@wolfi089 : genau, mit --removable hab ich das auch bei meinen Arch-Sticks gemacht. Es ist nicht so leicht, gute Infos zu dem Schalter zu finden. Im "allwissenden" Arch-Wiki steht dazu:

If you use the option --removable then GRUB will be installed to esp/EFI/BOOT/BOOTX64.EFI [...] and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself, similar to how you would using BIOS.

Eine weitere Wirkung des Schalters ist, dass kein UEFI-Booteintrag ins NVRAM des Erzeuger-Rechners geschrieben wird. Was man ja in dem Fall auch nicht haben möchte, da es keinen Sinn macht.

Ob eventuell fortgeschrittene Distri-Installer das von sich aus so machen, habe ich nicht erprobt. Arch selbst hat ja keinen Installer.

Den ungewollten Booteintrag auf dem Erzeuger-Rechner kann man nachträglich mit efibootmgr -b NNNN -B entsorgen.

 

[wolfi089]

Ich fände es schön, wenn die Distribution einen post-install hook anbieten würde. Ich verstehe ja, wenn man den Wartungsaufwand in Grenzen halten will. Aber wenn ein post-install Script aufgerufen wird, könnte man die Installation als tainted markieren.

Unix hat immer das Paradigma verfolgt, dass seine Tools klein und modular sind. Es ist gern gesehen, dass Nutzer damit mehr machen kann, als sich der ursprüngliche Entwickler vorgestellt hat.