Leserartikel [How-To] Arch Linux installieren (verschlüsselt, gehärtet, spieletauglich, modular)

Erstmal vielen Dank für den Guide, ziehmlich erschöpfend. Hat Spaß gemacht ihn durchzugehen.

Ich habe ein paar Verständnisfragen zum Kapitel 4.12.2 Kernel Command Line:
  • 4.12.2.2 Nop LUKS und 4.12.2.3 No Hibernation: was dort steht tue ich nur, wenn ich LUKS bzw hibernation nicht nutze, richtig?
  • 4.12.4 Later: Other kernel parameters: wo genau füge ich die optionen hinzu? Einfach in der /etc/kernel/cmdline ans Ende der Zeile mit ran? Und muss dann nochmal mkinitcpio -P nochmal ausgeführt werden?

Ich denke ich bin mir unsicher, was mit dem "Later" gemeint ist.
 
  • Gefällt mir
Reaktionen: agon
todschick schrieb:
4.12.2.2 Nop LUKS und 4.12.2.3 No Hibernation: was dort steht tue ich nur, wenn ich LUKS bzw hibernation nicht nutze, richtig?
Genau.

todschick schrieb:
4.12.4 Later: Other kernel parameters: wo genau füge ich die optionen hinzu? Einfach in der /etc/kernel/cmdline ans Ende der Zeile mit ran?
Ja.

todschick schrieb:
Und muss dann nochmal mkinitcpio -P nochmal ausgeführt werden?
Ja. Mit Secure Boot dann jedoch bspw. einfach den Kernel "nochmal" installieren, um den "pacman hook" für's Signieren anzustoßen.

todschick schrieb:
Ich denke ich bin mir unsicher, was mit dem "Later" gemeint ist.
Nach einem erfolgreichen Reboot, kann man dann die anderen Parameter ergänzen.
Ich habe das u.a. für die bessere Übersicht so unterteilt. Um "staggered spin-up" zu deaktivieren, müsste man ja dann sowieso nochmal an die kernel command line. Und so erkennt man dann auch besser den Effekt der Parameter.
 
Danke für die Antwort.
Das bedeutet im Guide überspringe ich dann 4.12.4 erstmal und setze das erst nach Kapitel 5, also dem Einrichten von Secure Boot um? Oder kann ich das an jedem Punkt später noch umsetzen?

Was meinst du hiermit:
agon schrieb:
Ja. Mit Secure Boot dann jedoch bspw. einfach den Kernel "nochmal" installieren, um den "pacman hook" für's Signieren anzustoßen.

Ich bin mir mit dem Punkt 4.12.4 insgesamt unsicher :D
 
Arch Linux [Update]

todschick schrieb:
Oder kann ich das an jedem Punkt später noch umsetzen?
Ja. In der neuen Version ist nun übrigens quiet loglevel=4 standardmäßig mit dabei.

todschick schrieb:
Ich bin mir mit dem Punkt 4.12.4 insgesamt unsicher
Einfach überspringen und später (egal wann) ergänzen.
 
Wenn ich solche Änderungen umsetzen möchte, kann ich dann einfach die Hooks und kernel parameter ändern und danach die initframs images neu generieren? Oder muss ich da noch irgendwas beachten?
 
Irgendwie empfinde ich diesen Thread zusätzlich als eine Art Newsletter für Änderungen an Arch, spezifisch der Installations- und Bootänderungen. :D
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Guten Tag, meine Lieben!

Seid ihr schon gespannt auf KDE Plasma 5.27, welches am 14. Feb. erscheinen wird? Danach kommt das lang ersehnte KDE Plasma Seggs, welche uns hoffentlich pure Befriedigung bringen sollte!
Etwas später im Februar kommt dann auch Linux 6.2 mit einer freshen Zstandard-Version – für einen noch buttrigeren Datentransfer mit Btrfs!

Seid gespannt auf kommende Änderungen im Guide. Wie immer – liken, teilen, kommentieren & die Glocke aktivieren, damit ihr nichts verpasst!


Ich bin am Überlegen, Wine raus zu hauen, da man das meiste ja über Lutris mit bspw. lutris-GE-Proton erledigen kann(?)
Meinungen?

Habe übrigens nun V4L2 für PipeWire ergänzt.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
agon schrieb:
Ich bin am Überlegen, Wine raus zu hauen, da man das meiste ja über Lutris mit bspw. lutris-GE-Proton erledigen kann(?)
Meinungen?
Jein, WINE halte ich mittlerweile auch eher für optional, aber nicht ganz.
Nutze das relativ wenig. Z.B. CRU unter Linux war mir schon eine Hilfe.

Sinn macht eine WINE-Installation im System allerdings, wenn man Windows-Anwendungen nutzen möchte.
Auch ist WINE für Spieler, die keine Launcher (HGL, Lutris, PlayOnLinux, Steam) nutzen, grundsätzlich von Interesse.

Mein Fazit momentan:
Wine als optional drin lassen ... oder zumindest verlinken.

Grüße
 
Tanzmusikus schrieb:
Wine als optional drin lassen ... oder zumindest verlinken.
Wine ist erst mal draußen, da ich schlussendlich nur ein paar nennenswerte Pakete genannt hatte. Die Wine-Pakete sind ja noch in den Paketlisten enthalten.

Ich füge erst Wine wieder ein, wenn ich bspw. weiß, welche dlls man installieren muss, um möglichst viele Windows-Programme funktionstüchtig zu machen (siehe hier):
  • Visual C++ libraries: vcrun2005 vcrun2008 vcrun2010 vcrun2012 vcrun2013 vcrun2019?
  • DirectX 9 (June 2010): d3dx9 d3dx9_43? DX11/12?
  • .NET Frameworks: dotnet35 dotnet35sp1 …?
  • MS Media Foundation: mf, da "Win7 Ultimate N"?
  • …?
Hinzu kommt, dass einige(?) 32bit-Programme in der 64bit-Umgebung immer noch Probleme verursachen. Gibt es eigentlich Kompatibilitätsprobleme bei Wine-Updates? Wine ohne bspw. AppArmor+Firejail empfehle ich nicht, da Malware-kompatibel.


In der neuen Version wird ja jetzt bspw. btrfs filesystem mkswapfile -s 32g /swap/swapfile benutzt. Nach der Installation ging Hibernation nicht, da zu wenig Swap.

swapon --show spuckte 1024M aus, obwohl die Swapdatei 32G groß ist
-> Neue Swapdatei eingerichtet -> Hibernation funktioniert nun mit 32G.
Vielleicht hat ja jemand ein ähnliches Problem.


Mit systemd v253 erscheint das Tool ukify to build, measure, and sign Unified Kernel Images.
Ich hoffe, dass sich das Tool gut integrieren lässt.


Gibt es eigentlich "moderne" Mainboards, bei denen man für Secure Boot kein "Microsoft Corporation UEFI CA 2011 certificate" benötigt. Ich habe u.a. gelesen, dass NVIDIA-GPUs dieses Cert. benötigen. Ich habe bspw. ein Dell-Notebook (mit Intel CPU) für das ich kein MS-Zertifikat brauche. Wie sieht es da bei AMD aus?
 
Zuletzt bearbeitet:
agon schrieb:
Ich füge erst Wine wieder ein, wenn ich bspw. weiß, welche dlls man installieren muss, um möglichst viele Windows-Programme funktionstüchtig zu machen (siehe hier):
Das ist bereits sehr weit gedacht, wenn nicht sogar zu weit. Es geht doch erstmal um die Installation. Also wäre es nach meinem Verständnis zunächst wichtig zu wissen, auf welchen Wegen man WINE installieren kann.

Unter Pop'buntu kann ich z.B. ein PPA von WineHQ installieren & mich dann im weiteren Verlauf für Wine-Staging, Wine-Development oder Wine-Stable Branch entscheiden. Die Unterschiede zu erklären sehe ich als hilfreich an.

Unter Arch ist das durch das AUR sicherlich etwas anders. Hier gibt es außerdem Multi-Arch, was vermutlich unterschiedlich zur Wirkweise von x86-64 neben i386 ist.

Mit 8.0 sollte auch das Multilib/-Arch nochmals erweitert integriert sein, oder?

agon schrieb:
Hinzu kommt, dass einige(?) 32bit-Programme in der 64bit-Umgebung immer noch Probleme verursachen.
Dazu habe ich bisher keine verwertbaren Erfahrungen sammeln können. Mittlerweile sind die meisten Spiele 64-bit'ig angelegt. Die Spiele-Launcher sind allerdings häufig in 32-bit programmiert.

agon schrieb:
Gibt es eigentlich Kompatibilitätsprobleme bei Wine-Updates?
Kann ich so nicht sagen. Bisher sind mir immer nur die positiven Verbesserungen neuer Versionen aufgefallen.
Zurück (in der Kompatibilität) kommt man nur, wenn man Native Linux-Spiele-Launcher wie z.B. Lutris, HGL oder Steam nutzt. Dort kann man sehr leicht den jeweiligen Runner auf eine ältere WINE/PROTON-Version wechseln.

Grüße
 
Tanzmusikus schrieb:
Das ist bereits sehr weit gedacht, wenn nicht sogar zu weit.
Wenn meine SW mit Wine nicht (stabil) funktioniert, dann ist Wine für mich uninteressant und somit auch nicht im Guide zu finden.
https://wiki.winehq.org/FAQ#My_application_says_some_DLL_or_font_is_missing._What_do_I_do.3F

Tanzmusikus schrieb:
Also wäre es nach meinem Verständnis zunächst wichtig zu wissen, auf welchen Wegen man WINE installieren kann.
Die erforderlichen & nennenswerten Pakete wären dann im Wine-Abschnitt enthalten.
-> https://wiki.archlinux.org/title/Wine

Tanzmusikus schrieb:
Wine-Staging, Wine-Development oder Wine-Stable […]. Die Unterschiede zu erklären sehe ich als hilfreich an.
Erklärung: https://wiki.winehq.org/FAQ#Which_version_of_Wine_should_I_use.3F
Ich hätte wine genommen, da Wine 8.1 ganz nett ist, und wine-stable in der AUR ist.

Tanzmusikus schrieb:
Mittlerweile sind die meisten Spiele 64-bit'ig angelegt. Die Spiele-Launcher sind allerdings häufig in 32-bit programmiert.
Bsp.: https://wiki.winehq.org/FAQ#Does_Wine_support_.NET.3F_Should_I_install_native_.NET_in_Wine.3F
-> Für neuere Apps benötigt man mitunter natives .NET, welches nur im 32 bit wineprefix funktioniert -> 64 bit Apps funktionieren dort nicht.

Tanzmusikus schrieb:
[In Steam, Lutris, etc.] kann man sehr leicht den jeweiligen Runner auf eine ältere WINE/PROTON-Version wechseln.
Deswegen bevorzuge ich auch Steam & Lutris über Wine.

tl;dr: Abschnitt "Wine" wird wahrscheinlich später wieder kommen.
 
Zuletzt bearbeitet: (dumme Grütze beseitigt)
Arch Linux [Update]
  • Update: /etc/mkinitcpio.d/linux-zen.preset
    • ALL_microcode=(/boot/*-ucode.img)
    • default_uki="/efi/EFI/Linux/archlinux-zen.efi"
    • default_options="--splash=/usr/share/systemd/bootctl/splash-arch.bmp"
    • fallback_uki="/efi/EFI/Linux/archlinux-zen-fallback.efi"
    • Comment out: PRESET_image=
      => doas rm /boot/initramfs-linux*.img
  • New:Ubisoft Connect fix
    • Network settings > Change MTU: 1452 bytes

Bemerkungen zu dem Update:
  • Ihr müsst die Änderungen übernehmen, da euer System sonst womöglich zukünftig nicht mehr booten würde!
  • Die Änderungen wurden aus dem Arch Wiki bzw. von mkinitcpio übernommen.
    Bsp. – 3. Feb. 2023: "added = to default_options in example preset as of version mkinitcpio-git 34.r36.gc65cfba-1 with out an = sign package generation fails with error 'must be a file'."
  • Aufmerksam wurde ich durch die Warnung von mkinitcpio.
  • Evtl. bevorstehende Änderungen:
    • /efi/EFI/Linux/archlinux-zen.efi => /efi/EFI/Linux/arch-linux-zen.efi
    • /efi/EFI/Linux/archlinux-zen-fallback.efi => /efi/EFI/Linux/arch-linux-zen-fallback.efi
    • Meinungen? Ich finde ja meine Version immer noch besser. Vielleicht ändern sie ja das Preset noch.
    • Edit: Es bleibt alles so wie es ist.
 
Zuletzt bearbeitet: (Bemerkungen)
Sehr interessant gemacht, finde ich gut. Für jeden mit ein wenig Verständnis geeignet.

Was eventuell für den ein oder anderen noch interessant ist, zwecks Gaming für EAC.
Ist GPU Passthrough bzw Single GPU Passthrough.

Single GPU Passthrough (Graka an Virtuelle Maschine durchreichen)

Läuft bei mir sehr gut, sind auch gleich alle Scripte dabei.

3700X & RX6800
 
  • Gefällt mir
Reaktionen: agon und Archivar
@Jeronimoh
Gründe, warum eine Win11-VM für mich uninteressant ist:
Ich hatte ja "PCI passthrough via OVMF" auf der TODO-Liste. Virt-Manager beschert(e) mir aber Probleme (kleinere System-Freezes & siehe Seite 4) und flog somit aus der Liste (da es nicht stabil genug ist).

Das Thema ist mMn. auch ziemlich komplex, fehleranfällig & umständlich. Bspw. wenn man die Maus & Tastatur weiterreichen möchte, dann sollte eine andere Maus oder Tastatur am Host angeschlossen sein, wenn der Gast Probleme verursachen sollte.

Fragen:
  • Q1: Kann man in einer Win11-VM den Bootloader eines Smartphones (Google & OP ausgeschlossen) entsperren?
  • Q2: Kann man in einer Win11-VM die Firmware von USB-Geräten (bspw. DualSense Controller) updaten?
  • Q3: Warum installiert man nicht einfach Win11 auf einer anderen NVMe-SSD? Ja, die monatlichen Windows-Updates dauern extrem lange.
 
Das stimmt wohl, ist sehr fordernd und für Anfänger definitiv nicht geeignet. Habe es für games Laufen, die wegen eac nicht unter Linux laufen. Da läuft es dann aber sehr rund.

Edit1:

Zu 1 und 2: geht auch alles unter Linux, aber sollte wenn man die USB ports durchreicht mit iommu auch kein Problem sein (iommu fähiges System vorausgesetzt)

Zu 3: das wäre zu einfach 🤪

Edit2:

Bei mir läuft ein Single GPU passthrough

Edit 3:

Gerade erst gesehen, du nimmst in deiner Anleitung für ntfs Laufwerke den ntfs-3g Treiber, würde ich ändern auf den ntfs3 Treiber den es mittlerweile im Kernel gibt. Hat mehr Umfang und läuft viel Performanter.

Wenn man kde benutzt , dann gibt es einen workaround damit es läuft mit Dolphin.

If you have udisks2 2.9.4+, as a temporary fix you can create the file /etc/udisks2/mount_options.conf with the following contents:

[defaults]
ntfs_defaults=uid=$UID,gid=$GID

...and you'll be set.

For udisks 2.9.3 and earlier, because it lacks the necessary logic to recognize and use the ntfs3 driver in the first place, you apparently can "patch" the support in by also creating the file /etc/udev/rules.d/ntfs3.rules with the following contents:

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3"

In this case, /etc/udisks2/mount_options.conf should also include some extra stuff added with udisks2 2.9.4 for ntfs3 to work properly:

[defaults]
ntfs_defaults=uid=$UID,gid=$GID
ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names,compression,nocompression,big_writes,nls,nohidden,sys_immutable,sparse,showmeta,prealloc

Do keep in mind that these fixes will force-disable the 'windows_names' flag, which has the potential to cause you some pain if you dual-boot with Windows and mount the NTFS partitions.

Quelle: https://bugs.kde.org/show_bug.cgi?id=445468#c2
 
Zuletzt bearbeitet:
Jeronimoh schrieb:
Zu 1 und 2: geht auch alles unter Linux, aber sollte wenn man die USB ports durchreicht mit iommu auch kein Problem sein (iommu fähiges System vorausgesetzt)
Bei Virt-Manager wird ja auch jedes neu-angeschlossenes USB-Gerät weitergereicht.
An sich kann man die Firmware auch mit Wine updaten.
Die Frage ist nur, ob es genauso zuverlässig wie mit nativem Windows ist.

Jeronimoh schrieb:
Bei mir läuft ein Single GPU passthrough
Da nun auch die Ryzen CPUs eine iGPU besitzen, bevorzuge ich eine Anleitung (vorzugsweise für Arch) für "PCI passthrough via OVMF", welche ich dann auch verlinken würde.

Jeronimoh schrieb:
Gerade erst gesehen, du nimmst in deiner Anleitung für ntfs Laufwerke den ntfs-3g Treiber, würde ich ändern auf den ntfs3 Treiber den es mittlerweile im Kernel gibt. Hat mehr Umfang und läuft viel Performanter.
ntfs-3g ist als Abhängigkeit für kpmcore -> partitionmanager mit dabei.
Also schlussendlich für mkfs.ntfs(8) da (siehe: https://wiki.archlinux.org/title/File_systems).
Beim Mounten dann einfach ntfs3 & nicht ntfs-3g nehmen (in fstab).
Die Option windows_names sollte schon dabei sein.


Mit plasma-meta 5.27-1 wird nun flatpak-kcm -> flatpak mit flathub installiert.
Edit: Mit 5.27-2 ist flatpak-kcm nun optional.

Edit: Bei Samsung entsperrt man doch den Bootloader per Tastenkombination am Smartphone selber. Heimdall benutzt man zum Flashen.
 
Zuletzt bearbeitet:
Das kann ich dir nicht sagen, habe ein Samsung Smartphone.

Da nutze ich Heimdall

Edit: ADB gibt es ja auch für Linux

Edit2: du fragtest ja wegen Firmware Flashen und nicht Bootloader entsperren. Und wenn es geknackt ist und z.b twrp drauf ist, dann kann man die Firmware darüber flashen direkt vom Gerät, bei lineageos geht es z.b über eine sd card oder per ADB sideload was es ja gibt unter Linux.

Edit3: gerade gesehen fragtest auch wegen entsperren, dass kann ich dir nicht sagen. Aber bei den meisten Geräten nimmt man ja ADB dafür und das läuft ja nativ unter Linux
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Jeronimoh
Arch Linux [Update]
  • New: "Notes for MS Windows dual booters"
  • Update: mkinitcpio is (now) a "UKI generator" > See: "Mkinitcpio (for UKI)"
  • Update: "ROCm & HIP" should be working now

"Full-system emulation can be expanded with some QEMU modules present in separate packages: qemu-block-gluster, qemu-block-iscsi and qemu-guest-agent." – Source.
->

Deinorius schrieb:
Es ist eine optionale Abhängigkeit.
Mit "Abhängigkeit" meine ich eine optionale, sonst würde ich die nicht extra angeben.
Ich habe das nochmal kenntlich gemacht, dass es sich um optionale Pakete handelt. ntfs-3g ist auch eher als Ergänzung zu sehen, da ich auch e2fsprogs angegeben habe. Übrigens verweigert ntfs-3g den Zugriff auf eine tiefschlafende Windows-Platte (was auch gut so ist).

Jeronimoh schrieb:
Aber bei den meisten Geräten nimmt man ja ADB dafür und das läuft ja nativ unter Linux
Ich habe extra "Google & OP ausgeschlossen", weil das bei den beiden sehr gut mit adb & fastboot funktioniert. Bei bspw. Xiaomi geht es nur mit einer Windows-SW, um den BL zu entsperren.

Aber was ich vergessen habe zu schreiben: Wenn man (schwerwiegendere) Probleme mit dem Gerät bekommt, dann ist Stock-ROM drauf hauen the way to go. Und dies funktioniert des Öfteren "nur" mit spezieller Windows-SW. Bei Samsung-Geräten könnte man bspw. "Patched Odin" benutzen. (Bis jetzt habe ich leider keine guten Erfahrungen mit Samsung-Smartphones gemacht.)
 
Zuletzt bearbeitet:
Zurück
Oben