Win11 in freien unbenutzten Bereich installieren.

[Caramon2]

Starte es doch mal im DOS-Fenster. Vielleicht gibt es dort brauchbare Fehlerausgaben.

So mache ich das bei Linux (natürlich im Terminal), wenn irgendwas nicht mehr will oder Probleme macht.

Oder was ist, wenn du es aus dem Autostart nimmst und erst nach 10 Min. Laufzeit startest? - Wenn es dann normal startet, muss ja irgendwas stören, was Windows während oder kurz nach dem booten macht.

Noch eine Idee: Mein Board ist von MSI und es hat eine Option "MSI Schnellstart": Dadurch wird vieles blockiert, dass das booten bremst und erst nach 2 Min. freigeschaltet.

Ich weiß nicht mehr was das war, aber war das aktiviert, startete irgendwas gleich nach dem Booten von Windows 10 (das hatte ich damals extra um das auszuprobieren installiert und anschließend gleich wieder platt gemacht) nicht mehr und waren die 2 Minuten um, war es plötzlich da. Habe ich den "MSI Schnellstart" deaktiviert, konnte ich es wieder sofort starten.

Übrigens bootete Windows damit kein bisschen schneller.

 

[linuxnutzer]

Starte es doch mal im DOS-Fenster

Das ist eine Idee, aber ich will einfach nur mehr, dass es im Hintergrund startet

Bei
https://www.computerbase.de/forum/t...ich-installieren.2271322/page-4#post-31510530
ist der 3. Block das Notebook,

Ich mag da eigentlich nichts am BIOS/UEFI rumtun, es hat schon viel schlechter funktioniert.

Problem ist ja, dass der Messenger sehr selten verwendet wird und man den Account nach 1 Jahr verliert, aber nicht, wenn man sich nur anmeldet und nichts schreibt. Daher macht der Autostart schon Sinn.

Ergänzung (25. Mai 2026)

PS: Dein KI-Link hilft mir gut auf neue Ideen zu kommen, passiert zwar fast immer das kapital falsche Sachen kommen, aber wenn man nachhakt, kommt eine Entschuldigung und bessre Antwort.

 

[Caramon2]

Das ist eine Idee, aber ich will einfach nur mehr, dass es im Hintergrund startet

Das soll nicht dauerhaftes sein, nur zur Diagnose. Genau wie das andere was ich vorgeschlagen habe.

 

[Caramon2]

Hast du dir schon mal MX Linux angesehen? Die AHS-Version hat besonders aktuelle Kernel, Mesa, usw. und deren MX-Tools werden von vielen gelobt.

Der Vollständigkeit halber noch eine aktuelle Meldung dazu:

MX Linux 25.2 bringt Linux 7 AHS Kernel für moderne Hardware

Die regulären Ausgaben verwenden den LTS-Kernel 6.12. Die AHS Edition mit Xfce nutzt den Liquorix Kernel 7.0. Mesa 26.0 sorgt dort für eine moderne Grafikunterstützung.
…
Bestehende Installationen benötigen keine Neuinstallation.

---

Da steht zwar was von textbasierten Installer, aber standardmäßig wird weiterhin der grafische, sehr gut dokumentierte *) Installer genutzt:

*) man muss es nur lesen - und verstehen

---

Wenn man es neben Windows installiert, muss man die Partitionierung zwar selbst mit GParted anpassen (Windows verkleinern, Linux-Partitionen erstellen - ich hatte sie unformatiert erstellt), aber dann kann man schon im Installer beliebige Mountpoints vergeben, die dann automatisch erstellt werden:

Cool ist, dass die Installation dann sofort startet, während man die weiteren Eingaben macht:

So sah dann die fstab aus (ich habe nur Tabulatoren eingefügt, damit es übersichtlicher ist):

Da dort dmask und fmask genutzt werden, ich mich damit aber noch nicht beschäftigt hatte, habe ich mich per Opera-KI darüber informieren und das relevante zusammengefasst:

Bei vfat/FAT steuern diese Optionen, welche Unix-Rechte Linux beim Mounten entfernt.

Der Unterschied ist:

umask

Allgemeine Maske für alle Objekte.
Sie wirkt auf Dateien und Verzeichnisse gleichermaßen, sofern nicht speziellere Optionen gesetzt sind.
Typisch, wenn du einfach einheitlich festlegen willst, welche Rechte standardmäßig verborgen werden.

dmask

Directory mask = Maske nur für Verzeichnisse.
Überschreibt bzw. verfeinert die Wirkung von umask für Ordner.
Nützlich, wenn Verzeichnisse andere Rechte haben sollen als Dateien, z. B. Ordner schreibbar, Dateien aber nicht ausführbar.

fmask

File mask = Maske nur für Dateien.
Überschreibt bzw. verfeinert die Wirkung von umask für Dateien.
Nützlich, wenn du z. B. Dateien generell ohne Ausführungsrechte mounten willst.

Merksatz

umask = Standard für alles
dmask = speziell für Verzeichnisse
fmask = speziell für Dateien

Priorität

Wenn mehrere Optionen gesetzt sind, gilt praktisch:

dmask für Verzeichnisse
fmask für Dateien
umask als allgemeiner Basiswert, falls keine spezifischere Maske greift

Beispiel


UUID=XXXX-XXXX /mnt/usb vfat defaults,umask=0022,dmask=0002,fmask=0113 0 0


Das bedeutet:

umask=0022 setzt eine allgemeine Grundmaske
dmask=0002 macht Verzeichnisse etwas anders als die allgemeine Maske
fmask=0113 macht Dateien noch restriktiver, z. B. ohne Ausführungsrechte


Bei FAT/vfat wird standardmäßig oft 666 für Dateien und 777 für Verzeichnisse angenommen, weil das Dateisystem selbst keine Unix-Rechte speichert.

Warum gerade 666 für Dateien?

666 bedeutet:

Besitzer: rw-
Gruppe: rw-
Andere: rw-

Also: lesen und schreiben, aber nicht ausführen.

Das ist ein sinnvoller Standard für Dateien, weil:

die meisten normalen Dateien nicht ausführbar sein sollen,
FAT keine echten Unix-Mode-Bits kennt,
Linux beim Mounten nur eine Rechte-Attrappe erzeugt.

Warum nicht gleich 777 ?

777 würde auch das Ausführungsbit setzen:

Besitzer: rwx
Gruppe: rwx
Andere: rwx

Das wäre für normale Dateien auf einem FAT-Medium meist unpraktisch, weil dann jede Datei als ausführbar erscheinen würde. Das will man in Unix/Linux normalerweise nicht.

Warum Verzeichnisse oft 777 ?

Verzeichnisse brauchen das x -Bit, damit man sie betreten kann. Ohne x kann man nicht in ein Verzeichnis hineinwechseln oder darin arbeiten.

Darum ist für Verzeichnisse ein Standard wie 777 sinnvoller:

r = Inhalt auflisten
w = Dateien anlegen/löschen
x = Verzeichnis betreten

Also dmask=0002 ist für Verzeichnis:

• Besitzer: rwx
• Gruppe: rwx
• Andere: r-x

und fmask=0113 ist für Dateien (3 = 2 und 1):

• Besitzer: rw-
• Gruppe: rw-
• Andere: r--

---

Beim Neustart habe ich zuerst Windows 11 gebootet, aber auch danach kam weiterhin das Menü:

Auch das mit /win hat funktioniert:

Verbatim und V-Daten (dort sind meine Notizen für die Partitionierung, usw.) ist mein Ventoy-Stick mit Datenpartition:

Inhalt:

$ ls -1 *.iso
Artix-Xfce-Runit-2604.iso
CommodoreOS-2.0.iso
Hirens-WinPE-1.0.1.iso
LMDE-7.iso
MX-25.2-Xfce-AHS.iso
Windows-11-22H2.iso
Zorin-OS-18.1.iso

 

[Caramon2]

Das ist der Punkt, die User sind unterschiedlich und man kann das auch allgemein machen. Ich hatte das schon mal, glaube man braucht dafür umask.

Diesbezüglich oben ein Nachtrag:

Da dort dmask und fmask genutzt werden, ich mich damit aber noch nicht beschäftigt hatte, habe ich mich per Opera-KI darüber informieren und das relevante zusammengefasst:
[…]

 

[Caramon2]

@linuxnutzer:

aber dann kann man schon im Installer beliebige Mountpoints vergeben, die dann automatisch erstellt werden

Das habe ich für eine exFAT-Partition mit /windaten getestet, aber die bekam dann nur noatime in der fstab, so dass man als normaler Nutzer nicht darauf zugreifen konnte. - Ich hatte erwartet, dass das dann wie beim FAT der ESP gemacht wird.

Nachdem ich das auf noatimemumask=0000 geändert und rebootet habe, konnte ich als normaler Nutzer alles machen: Einschließlich ausführbare Dateien ausführen, was, wie oben beschrieben, ein Sicherheitsrisiko sein kann.

Btw:

Interessanterweise bietet MX Linux in den Dateieigenschaften einen Tab "Prüfsummen", was ich bei Xfce/Thunar noch nie hatte (testweise hatte ich alle aktiviert und unten mit "Hash" generieren lassen):

 

[Caramon2]

Vielleicht weißt du zufällig wie man die fstab anpasst, damit alle User auf (ex)FAT schreiben können.

Bzgl. der Mountoptionen hatten wird das ja geklärt, aber da (ex)FAT primär auf USB-Sticks und SD-Cards eingesetzt wird, gibt es dort (generell bei langsamen USB-Speichermedien, unabhängig vom Dateisystem) ein anderes "Problem", mit dem ich mich die letzten Tage beschäftigt habe:

Wenn man eine größere Datenmenge darauf kopiert, startet die Fortschrittsanzeige erst sehr schnell und bleibt dann förmlich hängen (erst Burst, dann Stau), was am sehr großen Schreibcache liegt: Der ist standardmäßig auf 20% vom RAM limitiert, was bei 32 GiB RAM 6,4 GiB sind.

Beim kopieren entsprechender Datenmengen gehen die ersten 6,4 GiB also mit maximaler Geschwindigkeit in den Schreibcache und erst wenn der voll ist, begrenzt die langsame Schreibgeschwindigkeit des Sticks (z. B. 20 MiB/s).

Daher kommt es dann auch, dass wenn die Fortschrittsanzeige bei 100% ist, es trotzdem noch elend lange dauert, bis es endlich fertig ist: Die 6,4 GiB im Schreibcache müssen ja noch geschrieben werden, eben mit den 20 MiB/s = 5½ Minuten.

Die Lösung: Der Schreibcache muss stark verkleinert werden.

Das hat auch gleich den Vorteil, dass das entsprechende RAM für anderes frei bleibt (z. B. einen größeren Lesecache) und das System weniger belastet wird, da der "Burst" entsprechend geringer ist.

Ich habe das per /etc/sysctl.d/50-write-cache.conf auf 512 MiB begrenzt, wodurch im obigen Beispiel von den 5½ Min. "Stau" nur noch 25 Sek. bleiben *):

# für zRAM-Swap optimiert:
vm.swappiness=120
vm.vfs_cache_pressure=50

# Schreibcache-Tuning:
vm.dirty_background_bytes=268435456
vm.dirty_bytes=536870912
vm.dirty_writeback_centisecs=1000
vm.dirty_expire_centisecs=10000

# damit dmesg ohne sudo funktioniert:
kernel.dmesg_restrict=0

Bei einer physischen Swap sollte man meine zRAM-Optimierungen besser auskommentieren, oder entfernen, damit das auf Standard bleibt.

*) der vollständige Kopiervorgang dauert natürlich gleich lange, nur der Fortschrittsbalken zeigt damit realistischere Werte.

Ich habe es ausführlich getestet:

Für's kopieren auf USB-Sticks ist das ein deutlicher Vorteil (ich war begeistert!) und für alles andere (z. B. kopieren zwischen SSDs, oder umfassende Datensicherungen per rsync, egal ob auf ext. SSD oder HDD) ist es kein Nachteil. - Lt. Gnome-Systemmonitor belegte der Cache nach den Sicherungen wirklich die 6 GiB weniger: 13 GiB statt vorher 19 GiB - reproduzierbar (ich habe mehrere Sicherungslaufwerke und hatte immer nur eins eingehängt).

Demnach ist für Desktop-Nutzer ein sehr großer Schreibcache nicht nur unnötig sondern sogar kontraproduktiv. - Davon profitieren vermutlich eher Serversysteme mit großen, stark frequentierten Datenbanken, usw.