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

[Jeronimoh]

ah ok.

Aber zum Beispiel für xiaomi 😉

Bl unlock

Aber soll auch mit Wine gehen.

 

[agon]

Roadmap
Im März teste ich nochmal die Installation. Danach kommen wahrscheinlich nicht all zu viele Updates.
Das liegt auch daran, dass

• ich die meisten TODOs nicht umsetzen kann (-> Warten auf SW-Updates) &
• der Guide nun stabil ist.

Ich schreibe bei Lust & Laune weiterhin am Guide weiter (wie bisher auch).

 

[Beelzebot]

Reicht es eigentlich nicht aus nur ein Subvolume für /var zu erstellen und dann noch die beiden für /var/lib/...?

 

[Deinorius]

Wenn du ein ganzes subvolume von /var/ erstellst, wieso dann noch weitere in /var/lib/ erstellen? Das macht doch keinen Sinn...
Es wird kein ganze subvolume geschaffen, weil der Rest backupfähig bleiben soll.

 

[Beelzebot]

Stimmt. Ich hatte völlig übersehen, dass die Subvolumes nur dazu dienen damit sie nicht im Snapshot auftauchen und der Rest aus /var hingegen schon. Umgekehrt die Frage: Machen /var/lib/libvirt/images und /var/lib/containers dann Sinn? Passiert in den Ordner soviel um sie aus den Snapshots auszuklammern?

 

[agon]

Machen /var/lib/libvirt/images und /var/lib/containers dann Sinn? Passiert in den Ordner soviel um sie aus den Snapshots auszuklammern?

Die wenigen "qcow2"-Dateien (bei libvirt) sind halt relativ riesig. Das Snapshotten würde dadurch unnötig lange dauern.

Bsp. – Aus dem Guide: "Libvirt now makes storage pools nocow when on btrfs automatically".
Aus dem ArchWiki: "A snapshot is simply a subvolume that shares its data (and metadata) with some other subvolume, using btrfs's COW capabilities."

 

[LochinSocke]

Als Einzelnutzer des Rechners lege ich die qcow2 Dateien in mein Userverzeichnis.

 

[agon]

[…] lege ich die qcow2 Dateien in mein Userverzeichnis.

Das macht man doch nur in einer "user-session".
Aus dem Guide – GOAL: "Therefore, libvirt will be running on a system-level with default NAT/DHCP networking."
"PCI passthrough via OVMF" funktioniert bspw. nicht in einer "user-session".

Jedem steht es frei, diese Subvolumes nicht anzulegen. Ich habe ja verlinkt, für was die da sind.
(Ja, das Backupen wird dadurch umständlicher.)

 

[LochinSocke]

Das macht man doch nur in einer "user-session".

Welchen Grund gibt es denn das als Einzelnutzer nicht zu machen?

 

[agon]

Welchen Grund gibt es denn das als Einzelnutzer nicht zu machen?

"PCI passthrough via OVMF" funktioniert bspw. nicht in einer "user-session".

Wenn ich bei virt-manager eine user-session einrichten möchte, dann kommt eine Warnung, dass die "usermode session" nicht der Default von virt-manager ist.
Für mich bedeutet das, dass "system-level" stabiler bzw. fehlerärmer sein sollte.

Bei einem Mehrbenutzersystem macht doch eine "user-session" mehr Sinn.

 

[LochinSocke]

Genau. Trotzdem können die VMs im Userverzeichnis liegen.

 

[agon]

Achso. Aber warum sollte man das machen? Die qcow-Dateien gehören doch dann sowieso root:root? Ich dachte, man möchte HOME root-frei bekommen.
Hinzu kommt, dass /var/lib für "Variable state information for programs" gedacht ist (siehe file system hierarchy).

 

[LochinSocke]

Die Berechtigungen kannst du anpassen. Dinge die ein User benutzt, sollten im ~ liegen. War schon immer so. Bei Virt-manager lassen sich ja Pools überall anlegen.

Aber mein Initialposting hat sich auf den Punkt der Subvolumes und Snapshots aus Beiträgen #105 und #106 bezogen.

 

[agon]

Die Berechtigungen kannst du anpassen. Dinge die ein User benutzt, sollten im ~ liegen. War schon immer so. Bei Virt-manager lassen sich ja Pools überall anlegen.

Ich habe versucht, den "default storage pool" auf ~/.local/share/libvirt/images/ zu setzen. Hat auch soweit funktioniert. Ownership vom Verzeichnis ist "1000:libvirt-qemu".

Nun aber zum Problem:
Starte ich eine VM (mit der dazugehörigen qcow2-Datei), dann hat sie den Ownership "libvirt-qemu:libvirt-qemu" -> Somit kann man als User diese Dateien bspw. nicht kopieren.
Schließe ich die VM, dann ändert sich der Ownership zu "root:root".

Q: Wo kann ich bitte einstellen, dass der Ownership der qcow2-Dateien "1000:libvirt-qemu" wird?
Da es ja bei euch zu funktionieren scheint, könntet ihr mir schreiben, was ich falsch gemacht habe bzw. wie eure Konfiguration aussieht. (Ich werde nicht extra für jede neue qcow2-Datei den Ownership ändern.)

Spoiler: Folgende Befehle habe ich eingegeben

13.7.4.5.1 Destroy & undefine default storage pool "/var/lib/libvirt/images/"​

doas virsh pool-destroy default;
doas virsh pool-undefine default;

13.7.4.5.2 Create the new default storage pool​

mkdir -p ~/.local/share/libvirt/images/;
Disable CoW: chattr +C ~/.local/share/libvirt/images/;
doas chown -R 1000:libvirt-qemu ~/.local/share/libvirt/images/;
doas virsh pool-define-as --name default--type dir --target ~/.local/share/libvirt/images/;

13.7.4.5.3 Start default pool (automatically on system boot)​

doas virsh pool-autostart default;
doas virsh pool-start default;

doas systemctl restart libvirtd;

In Virt-Manager sieht das dann so aus:
<permissions>
<mode>0755</mode>
<owner>1000</owner>
<group>959</group>
</permissions>

Generell bin ich mit dem Thema "Virtualization" im Guide nicht zufrieden (da es nicht stabil ist). Ich habe vorhin schon wieder ein System-Freeze bekommen…

 

[LochinSocke]

Das Problem habe ich fast auch, allerdings ist die Berechtigung direkt nach der Erstellung user:user. Nach dem ersten schließen ist es auch root:root. Ich ändere die Berechtigungen in der Tat einmal. Danach bleiben die qcow2 auch immer so.


Bei mir läuft die Virtualisierung sehr stabil. Ich nutze VMs für alltägliche Dinge.

 

[agon]

• "OPT: Change default storage pool location" ist nun enthalten. Sollte so funktionieren.
• Bei "Create a storage pool for ISO images" sollten nun auch alle ISOs mit doas chown 1000:libvirt-qemu ~/Downloads/ISO/ richtig erkannt werden.

 

[agon]

Also die Installation in der VM (bis KDE, ohne Swap & SB) funktioniert immer noch gut.
Übrigens ist gerade ein sehr guter Zeitpunkt, um Arch zu installieren

Arch Linux [Update]

• For VM guest:
  New: Change sector size to 4K (for 4Kn)
• ~/.config/firejail/keepassxc.local > Add:
  noblacklist ${RUNUSER}/app

 

[agon]

Arch Linux [Future Update]

• Update: mkinitcpio for v35
  • Update: .preset file
  • TODO: Add post-generation hook for signing the UKIs
• Delete: libavif & libjxl since they are now installed as a dependency
  • JPEG XL screenshot creation with mpv works now (bc dep of ffmpeg)
  • Note: JXL > {AVIF, PNG, BMP, JPG} for high-fidelity

 

[jenzen]

Übrigens ist gerade ein sehr guter Zeitpunkt, um Arch zu installieren

Ich würde ja sagen es ist immer ein guter Zeitpunkt für Arch, aber was genau ist denn das Besondere an dem Zeitpunkt jetzt?

Danke für den Guide btw, sind ein paar nette Konfigurationstipps drin. Ist nur überhaupt nicht einsteigerfreundlich, aber das ist bei Arch auch nicht nötig, das ist eine Distri für Power User. Gut finde ich dass sehr viele Themen und Details drin vorkommen aber auf langwierige Erklärungen oft verzichtet wird, wer mehr wissen will weiß ja wo er gucken kann.

 

[agon]

Ich würde ja sagen es ist immer ein guter Zeitpunkt für Arch, aber was genau ist denn das Besondere an dem Zeitpunkt jetzt?

• Linux 6.2 (auch in ISO). Bspw. updated Zstd kernel implementation. Der Bug, den ich mit mkswapfile hatte, sollte behoben sein.
• KDE Plasma 5.27 (LTS). Für ~6 Monate gibt es übrigens keine größeren Updates.
• Die Installation wurde erfolgreich getestet.

Aber ja, es ist immer ein guter Zeitpunkt, Arch zu installieren.

Ist nur überhaupt nicht einsteigerfreundlich, aber das ist bei Arch auch nicht nötig

Habe ich doch nicht im Guide behauptet(?)