Die Linux-Distribution Pop!_OS ist von Ubuntu abgeleitet und wird von der amerikanischen Firma system76 entwickelt. Diese Firma verkauft Notebooks, auf denen standardmäßig Pop!_OS installiert ist. Im Vergleich zu anderen Distributionen ist Pop!_OS besonders gut für Notebooks mit NVIDIA-Grafik optimiert.

Ursprünglich dachte ich, Pop!_OS sei nur ein weiterer Ubuntu-Klon mit modifiziertem Gnome-Desktop und integrierten NVIDIA-Treibern. Seit ich die Distribution auf mein neues Lenovo-P1-Notebook installiert habe, weiß ich, dass Pop!_OS weit mehr Eigenheiten hat.

Varianten

Pop!_OS steht aktuell in den Versionen 18.04 LTS und 18.10 sowie in jeweils zwei Varianten zur Auswahl. Diese beiden Varianten unterscheiden sich darin, ob die NVIDIA-Treiber bereits inkludiert sind oder nicht. Ich habe für meinen Tests Pop!_OS 18.10 in der NVIDIA-Variante verwendet.

Notebook-spezifische Vorbereitungsarbeiten

Vor der Installation von Pop!_OS auf meinem Lenovo P1 habe ich das auf einer zweite SSD befindliche Windows aktualisiert und dann ein BIOS-Update durchgeführt (siehe auch diesen heise-Artikel).

Des Weiteren habe ich zwei BIOS-Optionen verändert:

• UEFI Secure Boot = No

• F1-F12 as Primary Keys = Enabled

Die erste Option ist zwingend erforderlich, weil Secure Boot in Kombination mit den nicht GPL-kompatiblen NVIDIA-Treibern unmöglich ist.

Die zweite Option entspricht meinen Gewohnheiten. Ich will die Funktionstasten als solche verwenden (F1 bis F12). In meiner Emacs-Konfiguration sind diese Tasten alle mit häufig verwendeten Funktionen verbunden.

Für die Installation von Pop!_OS ist es hingegen nicht erforderlich, Veränderungen am Grafiksystem durchzuführen. Ich habe die Einstellung Graphics Device = Hybrid Graphics also belassen und nicht auf Discrete umgestellt.

Installation

Bei der Installation lautet das Motto von Pop!_OS: Alles oder nichts. Es gibt nur zwei Installationsvarianten:

• Clean Install verwendet die gesamte Festplatte. (Wenn es mehrere Festplatten/SSDs gibt, können Sie das gewünschte Gerät auswählen.) Diese Variante eignet sich nur, wenn Sie keine Rücksicht auf vorhandene Betriebssysteme nehmen müssen. Sie haben keine Wahlmöglichkeiten bei der Partitionierung. Standardmäßig richtet Pop!_OS eine relativ große Swap-Partition, eine EFI- oder eine boot-Partition sowie eine Datenpartition ein, die die restliche Festplatte/SSD ausfüllt (ext4-Dateisystem). Immerhin können Sie zum Schluss entscheiden, ob das Dateisystem verschlüsselt werden soll oder nicht.

• Custom (Advanced): Hinter dieser Option verbirgt sich das andere Extrem. Wenn Sie sich dafür entscheiden, müssen Sie sich um die Partitionierung selbst kümmern. Das Pop!_OS-Installationsprogramm öffnet dazu GParted, Sie können aber natürlich auch in einem Terminal mit parted arbeiten. Auf jeden Fall erhalten Sie keine Unterstützung durch das Installationsprogramm, das keinen Partitionseditor hat. Stattdessen zeigt es die mit GParted oder parted erzeugten Partitionen nur an. Sie können nun über kleine Dialoge entscheiden, wie Sie die Partitionen für die Installation nützen möchten.

Selbstredend habe ich mich für die zweite Variante entschieden. Mein Ziel war, auf der SSD Platz für weitere Linux-Installationen zu lassen. Das Problem besteht nun darin, dass Pop!_OS bei der Custom-Variante keine Verschlüsselungsoption anbietet. Vielmehr müssen Sie die Datenpartition mit crypt_setup selbst vorbereiten.

Ich habe daher in einem Terminal die notwendigen Vorbereitungsarbeiten selbst durchgeführt. Zuerst habe ich auf der SSD eine GPT-Partitionstabelle eingerichtet. (Vorsicht! Alle auf der SSD befindlichen Daten gehen dabei verloren.)

parted /dev/nvme0n1
>   mklabel gpt

Immer noch in parted habe ich eine EFI-Partition eingerichtet:

> mkpart EFI 1mib 1024mib
> set 1 hidden
> set 1 esp

Und schließlich die Datenpartition, wobei die letzten 250 GiB der SSD frei bleiben sollten:

> mkpart encryptedpop 1025mib -250gib
> exit

Die EFI-Partition benötigt ein VFAT-Dateisystem:

mkfs.vfat /dev/nvme0n1p1

Die Datenpartition wird mit crypt_setup verschlüsselt. (Dabei müssen Sie zweimal das gewünschte Passwort angeben.) Damit entsteht die neue Device-Datei /dev/mapper/cryptlvm:

cryptsetup luksFormat --type luks2 /dev/nvme0n1p2
ls /dev/mapper/cryptlvm 
    /dev/mapper/cryptlvm

Diese Device-Datei soll nun als Physical Volume für ein Volume Group für LVM dienen. In der Volume Group habe ich mit lvcreate ein Logical Volume eingerichtet.

pvcreate /dev/mapper/cryptlvm
vgcreate popvg /dev/mapper/cryptlvm
lvcreate -L 1500G popvg -n poproot

Auf eine Swap-Partition habe ich angesichts 32 GByte RAM verzichtet. Damit ist der Terminal-Voodoo beendet. Das Pop!_OS-Installationsprogramm erkennt sowohl die EFI-Partition als auch die verschlüsselte Partition und das darin enthaltene LVM-Setup.

Recovery-Partition: Wenn Sie möchten, dass Ihnen nach der Installation auf der Festplatte/SSD ein Recovery-System zur Verfügung steht, müssen Sie eine weitere 4 GByte große Partition vorsehen (VFAT, unverschlüsselt, außerhalb von LVM) und dieser im Installationsprogramm das Verzeichnis /recovery zuweisen. Das Recovery-System ist einfach ein Pop!_OS-Live-System.

Die weitere Installation erfolgt dann ohne weitere Rückfragen und innerhalb weniger Minuten. Nach dem Neustart muss noch ein Benutzer eingerichtet werden — das war’s.

Hinweis: Wenn Sie Pop!_OS in VirtualBox ausprobieren, passt sich die Auflösung der virtuellen Maschine nicht automatisch an die Fenstergröße an. Standardmäßig stehen u.U. nur 800×600 Pixel zur Verfügung. Abhilfe: Öffnen Sie in der virtuellen Maschine die Gnome-Einstellungen, öffnen Sie das Dialogblatt *Devices/Displays* und wählen Sie dort die gewünschte Auflösung aus.

Desktop

Nach dem ersten Login offenbart sich der Pop!_OS-Desktop als ziemlich gewöhnliches Gnome-System mit wenigen Modifikationen, die durch Shell Extensions, eigene Fonts und Themes realisiert sind.

NVIDIA-Unterstützung

Das Alleinstellungsmerkmal von Pop!_OS ist sicherlich die gute NVIDIA-Unterstützung out of the box, also ohne irgendwelche Konfigurationsarbeiten. Pop!_OS verfolgt dabei einen sehr pragmatischen Ansatz: Über zwei in das Gnome-Systemmenü eingebauten Kommandos kann zwischen der NVIDIA- und der Intel-GPU gewechselt werden. Jeder Wechsel erfordert einen Neustart. Das ist weniger bequem als unter Windows, aber es funktioniert (zumindest bei meinen Tests) zuverlässig.

Der GPU-Wechsel kann auch durch Kommandos initiiert werden, wobei auch diese Änderungen erst nach einem Reboot wirksam werden.

sudo system76-power graphics nvidia
sudo system76-power graphics intel

Hinter den Kulissen erzeugt system76-power eine neue Initrd-Datei. Anschließend werden die Dateien in /boot/efi/EFI/Pop_OS-xxx erneuert. Neugierig wie ich bin, habe ich die Initrd-Images ausgepackt (unmkinitramfs) und verglichen (diff -rq). Das Ergebnis: Die Initrd-Datei für NVIDIA enthält erwartungsgemäß die NVIDIA-Kernelmodule (nvidia-drm.ko, nvidia-modset.ko). Dafür enthält die Intel-Variante die folgende Datei:

# Datei /etc/modprobe.d/system76-power.conf 
blacklist nouveau
blacklist nvidia
blacklist nvidia-drm
blacklist nvidia-modeset
alias nouveau off
alias nvidia off
alias nvidia-drm off
alias nvidia-modeset off

Sowohl das system76-power als auch die dazugehörige Gnome-Erweiterung sind Open-Source-Projekte auf GitHub zu finden. Als Programmiersprache wurde Rust verwendet.

• https://github.com/pop-os/system76-power
• https://github.com/pop-os/gnome-shell-extension-system76-power

Als Grafiksystem kommt in Pop!_OS Xorg zum Einsatz. Diverse Wayland-Pakete sind zwar installiert, beim Login gibt es aber keine Möglichkeit, Wayland zu aktivieren. Das ist insofern konsequent, als die NVIDIA-Treiber ja inkompatibel zu Wayland sind).

Energieverwaltung

Mit system76-power und den dazugehörige Gnome Extension können Sie auch zwischen drei Nutzungsprofilen umschalten:

sudo system76-power profile battery 
sudo system76-power profile balanced
sudo system76-power profile performance

Ich habe keine schlüssige Dokumentation gefunden, was die obigen Kommandos exakt tun.

Sicher ist, dass das Battery-Profil die Hintergrundbeleuchtung des Bildschirms stark reduziert. (Die Helligkeit kann per Tastatur natürlich wieder angehoben werden.) Außerdem wird im Battery-Profil der Turbo-Modus der CPU deaktiviert:

cat /sys/devices/system/cpu/intel_pstate/no_turbo
  0

In den beiden anderen Modi lautet das Ergebnis jeweils 1, d.h. bei Bedarf taktet die CPU höher. Der CPU-Governor bleibt bei allen drei Profilen auf powersave:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq
  powersave

Kurzum, der Unterschied zwischen Balanced und Performance ist unklar geblieben. Ich habe keine wesentliche Änderung des CPU-Verhaltens feststellen können. Benchmarks mit Geekbench ergaben jeweils (im Rahmen der üblichen Schwankungen) dieselben Ergebnisse.

Hintergrundinformationen:

https://github.com/pop-os/system76-power/wiki
https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Paketverwaltung

Pop!_OS verwendet zusätzlich zu den Ubuntu-Paketquellen eine eigene Paketquelle:

http://ppa.launchpad.net/system76/pop/ubuntu

Mit meinem im Blogbeitrag Die LTS-Frage vorgestellten Script habe ich ermittelt, wie viele Pakete aus der Pop!_OS-eigenen Paketquelle stammen. Das Ergebnis ist verblüffend. Es sind über 100 Pakete!

accountsservice appstream-data-pop appstream-data-pop-icons
com.github.donadigo.eddy curl dmeventd dmsetup gdm3 geary
gir1.2-accountsservice-1.0 gir1.2-gdm-1.0:amd64
gir1.2-gnomedesktop-3.0:amd64 gnome-control-center
gnome-control-center-data gnome-control-center-faces
gnome-desktop3-data gnome-online-accounts
gnome-shell-extension-alt-tab-raise-first-window
gnome-shell-extension-always-show-workspaces
gnome-shell-extension-do-not-disturb
gnome-shell-extension-pop-battery-icon-fix
gnome-shell-extension-pop-shop-details
gnome-shell-extension-pop-suspend-button
gnome-shell-extension-system76-power hidpi-daemon initramfs-tools
initramfs-tools-bin initramfs-tools-core kernelstub
libaccountsservice0:amd64 libc-bin libc-dev-bin libc6:amd64 libc6:i386
libc6-dev:amd64 libcurl3-gnutls:amd64 libcurl4:amd64
libdevmapper-event1.02.1:amd64 libdevmapper1.02.1:amd64
libegl-mesa0:amd64 libegl1-mesa:amd64 libgbm1:amd64 libgdm1
libgl1-mesa-dri:amd64 libgl1-mesa-dri:i386 libglapi-mesa:amd64
libglapi-mesa:i386 libglx-mesa0:amd64 libglx-mesa0:i386
libgnome-desktop-3-17:amd64 libgoa-1.0-0b:amd64 libgoa-1.0-common
libgoa-backend-1.0-1:amd64 libgranite-common libgranite5:amd64
liblvm2app2.2:amd64 liblvm2cmd2.02:amd64 libnvidia-cfg1-418:amd64
libnvidia-common-418 libnvidia-compute-418:amd64
libnvidia-compute-418:i386 libnvidia-decode-418:amd64
libnvidia-decode-418:i386 libnvidia-encode-418:amd64
libnvidia-encode-418:i386 libnvidia-fbc1-418:amd64
libnvidia-fbc1-418:i386 libnvidia-gl-418:amd64 libnvidia-gl-418:i386
libnvidia-ifr1-418:amd64 libnvidia-ifr1-418:i386 libxatracker2:amd64
linux-generic linux-headers-4.18.0-16 linux-headers-4.18.0-16-generic
linux-headers-generic linux-image-4.18.0-16-generic
linux-image-generic linux-libc-dev:amd64
linux-modules-4.18.0-16-generic linux-modules-extra-4.18.0-16-generic
linux-signed-generic locales lvm2 mesa-va-drivers:amd64
mesa-vdpau-drivers:amd64 mesa-vulkan-drivers:amd64 multiarch-support
nvidia-compute-utils-418 nvidia-dkms-418 nvidia-driver-410
nvidia-driver-418 nvidia-kernel-common-418 nvidia-kernel-source-418
nvidia-utils-418 plymouth-theme-pop-basic pop-default-settings
pop-desktop pop-fonts pop-gnome-initial-setup pop-gnome-shell-theme
pop-gtk-theme pop-icon-theme pop-session pop-shop pop-theme
pop-wallpapers popsicle popsicle-gtk repoman system76-dkms
system76-io-dkms system76-power xserver-xorg-video-nvidia-418

Das macht, offen gesagt, ein wenig skeptisch: Ein modifizierter Kernel, diverse modifizierte Gnome-Pakete (inklusive des eigenen Paketmanagers pop-shop, der natürlich auf Gnome Software basiert und ebenso schlecht wie dieses Programm funktioniert) etc. Ist system76 wirklich in der Lage, all diese Pakete langfristig solide zu warten? Gerade mit modifizierten Gnome-Paketen ist selbst Canonical gescheitert und letztlich zurück in das Mainstream-Lager gewechselt.

Standardmäßig sind keine Snap-Pakete installiert. Selbst auf die Installation des Snap-Dämons hat system76 verzichtet. (Sie können das mit apt install snapd beheben, wenn Sie wirklich wollen.)

systemd-boot statt GRUB

Technisch gesehen die größte Überraschung ist, dass Pop!_OS auf Rechnern oder virtuellen Maschinen mit EFI nicht GRUB verwendet, sondern die systemd-Komponente systemd_boot. (Wenn Sie Pop!_OS hingegen in VirtualBox installieren, wo standardmäßig ein traditionelles BIOS aktiv ist, kommt GRUB zum Einsatz.)

Pop!_OS mit systemd-boot benötigt richtig viel Platz in der EFI-Partition. Auf meinem Notebook ohne Recovery-System sind es ca. 160 MByte:

cd /boot/efi/EFI/
du -h 
  155M  ./Pop_OS-e16cb407-87e1-4333-90b3-e3a05f8e80f7
  92K   ./systemd
  92K   ./BOOT
  155M  .

Bei der Clean Install-Variante beträgt der Platzbedarf sogar 200 MByte, weil ein weiteres Image zum Start des Recovery-Systems eingerichtet wird.

Noch ein paar Anmerkungen zur EFI-Partition: Hier speichern alle auf einem Rechner installierten Betriebssysteme (also Windows sowie alle Linux-Distributionen) ihren Bootloader. Üblicherweise beanspruchen die Dateien ca. 10 bis 20 MByte pro Betriebssystem. Bei Pop!_OS ist der Platzbedarf deswegen so viel größer, weil die Boot-Dateien auch den Kernel und das Initrd-Image mit einschließen. Das ist insofern praktisch, als keine unverschlüsselte Boot-Partition erforderlich ist. Alle für den Boot-Vorgang erforderlichen Dateien sind direkt in der EFI-Partition.

Auf Notebooks mit vorinstalliertem Windows ist die EFI-Partition zumeist 256 MByte groß. Mit Windows und Pop_OS! ist die EFI-Partition dann so gut wie voll. Eine Vergrößerung mit einem Partitions-Manager scheitert zumeist daran, dass sich oft unmittelbar hinter der EFI-Partition eine 16 MByte große reserved windows Partition befindet (siehe z.B. superuser.com).

Weil ich Probleme bei zukünftigen Linux-Installationen ausschließen wollte, habe ich während der Installation eine zweite EFI-Partition eingerichtet. Der EFI-Standard sieht dies vor (nochmals superuser.com), Windows ist aber anscheinend nicht immer glücklich damit. In meinem Fall gab es aber keine Probleme, Windows lässt sich weiter starten und liest die Boot-Dateien aus ’seiner‘ EFI-Partition, während Pop!_OS die zweite EFI-Partition nutzt.

Im Betrieb bleibt systemd-boot normalerweise komplett unsichtbar. Nur wenn Sie exakt zum richtigen Zeitpunkt die Leertaste drücken, erscheint ein Menü mit den zur Auswahl stehenden Systemen. Im Prinzip handelt es sich dabei um Pop!_OS mit dem aktuellen Kernel, Pop!_OS mit dem vorigen Kernel sowie gegebenenfalls ein Recovery-System.

Die Menüeinträge wählen Sie mit den Cursortasten aus. Bei Bedarf gelangen Sie mit [E] in einen Editor, in dem Sie die Kernelparameter verändern können. Weitere interaktive Funktionen gibt es nicht.

Die Konfiguration von systemd-boot erfolgt durch die Datei /boot/efi/loader/loader.conf. Dort können Sie unter anderem mit timeout n die Zeit in Sekunden einstellen, während der das systemd-boot-Menü angezeigt wird. (Die Defaulteinstellung lautet 0.) Standardmäßig enthält loader.conf nur die Zeile default osname, die auf eine der Menüdateien im loader-Verzeichnis verweist. Mehr Details zu den (spärlichen) Konfigurationsmöglichkeiten finden Sie im archlinuxwiki.

Ist systemd-boot nun besser oder schlechter als GRUB? Das ist schwer zu sagen. An sich gefällt der minimalistische Ansatz im Vergleich zu dem mit Funktionen überladenen GRUB. Sollten allerdings Boot-Probleme auftreten, ist eine allfällige Reparatur vermutlich schwieriger als bei GRUB — schon alleine deswegen, weil systemd-boot wenig verbreitet ist. Im Web sind nur wenige Anleitungen und eine dürftige offizielle Dokumentation und zu finden:

• https://wiki.archlinux.org/index.php/systemd-boot
• https://www.freedesktop.org/software/systemd/man/systemd-boot.html
• https://blog.system76.com/post/170539007243/distinst-updates-boot-sequence-optimization
• https://support.system76.com/articles/pop-recovery/

Recovery-System