Liquorix-Kernel

Steven Barrett (erinnert mich irgendwie an TBBT, grin) bewirbt seinen Liquorix-Kernel als the better distro kernel, “gebaut mit der besten Konfiguration (…) für Desktop-Systeme, Multimedia und Gaming” (sinng.).

Ob nun “the best” in jedem Fall tatsächlich das Beste ist, sei dahingestellt (das klingt nach unsäglicher 1-Click-Wartung). Fakt ist, daß Steven Barrett seit vielen Jahren ein sehr hohes Maß an Kontinuität beweist (und das ist äußerst selten). So habe ich Liquorix-Kernel schon unter sidux/aptosid installiert gehabt (aus Interesse, nicht für konkretes). Seit der Einstellung der 32-bit-Unterstützung für siduction (man kann ein solches Image zwar noch installieren oder siduction 32 bit installiert haben, erhält aber keine towo-Kernel-Updates mehr) wird sogar quasioffiziell auf Liquorix-Kernel verwiesen.

Debian-Systeme also. Wenig bekannt ist, daß auch Liquorix-Kernel für Ubuntu (dessen Kernel sind anders paketiert) über ein launchpad.net-PPA bereitgestellt werden. Wer nicht ununterbrochen manuell aktuellere Kernel-Pakete aus den Ubuntu-Repositories klauben, deren automatische Installation einbinden oder aktuelle Mainline-Kernel ziehen will, kann Liquorix-Kernel als Alternative nutzen.

Zur Installation (ob nun unter Debian oder Ubuntu) muß sicherlich nicht viel gesagt werden.

Unter zwei nativen Installationen (i3 und C2D, Systeme, die ich alleinig in der Fa. nutze), zu dem Zeitpunkt noch LArtful/64, mittlerweile LBionic/64, tritt jeweils ein anderer Fehler beim Boot auf. Keiner im Sinne von Stichflamme, sondern von bestimmter Operation fehlgeschlagen (failed), sprich der Boot läuft trotzdem weiter und scheinbar ohne negative Auswirkungen.

Je nach Auftreten sind entsprechende Bootoptionen zu setzen:

  • “kfd: kgd2kfd_probe failed”
    modprobe.blacklist=amdkfd
  • “DMAR: Failed to map DMAR1”
    Hier könnte man zwar

    intremap=off

    setzen, eine bessere Bootoption ist jedoch

    intel_iommu=pt

    DMAR (DMA Read Request) wird damit im Kernel disabled, KVM unterstützt jedoch weiterhin IOMMU und Interrupt Remapping.

Update 2018-09-02: Siehe auch Warnung vor Liquorix-Kernel!

Artful Dot One mit gefixtem Kernel

Wer derzeit Ubuntu 17.10 oder eines der Derivate neu installieren will oder muß, hat durch das UEFI korrumpierende Ubuntu-Kernel ein arges Problem, denn ein gefixter Kernel ist in diesen Images nicht enthalten, der zum Fixen auf einem Teil der Notebooks geeignete Mainline-Kernel ohnehin nicht, sondern eben gerade einer der korrumpierenden Kernel.

Es müssen folglich neue Images mit Kernel 4.13.0-21 gebaut werden. Es gibt sie “bereits” als Daily Images für bspw. Lubuntu, auf der QA-Site “Artful Dot One” genannt, also 17.10.1 (das erste Pointrelease für eine nicht-“LTS”-Version überhaupt). Wie im Manifest zu lesen, hat die Version vom 2018-01-06 Kernel 4.13.0.21.

Wenn ich jetzt Lubuntu neu installieren würde, würde ich dieses Image verwenden, auch, wenn das UEFI nicht anfällig wäre (das ist natürlich keine Garantie für irgendwas). Es sind insgesamt Updates eingeflossen (ich habe live in einer VM gebootet), z.B. Fx 57.0.4 (wichtig als ein Punkt gegen Meltdown), nicht “nur” der neuere Kernel.

Update 2018-01-12: Nun sind endlich die Images für 17.10.1, Ubuntu und offizielle Derivate, auf den Servern freigegeben worden (Torrents für Lubuntu).

Fix fuer corrupted UEFI

Auch, wenn zur corrupted-UEFI-Story weiterhin nichts offiziell hilfreiches von Canonical kommt, User im Alleingang versuchen müssen, ihre Hardware zu retten, gibt es nun zumindest für diverse Lenovo-, Acer- und Toshiba-Modelle eine Rückkehr zu einem funktionierenden UEFI. Voraussetzung ist, daß Ubuntu noch booten kann.

Es wird der Mainline-Kernel 4.14.9 installiert. Da sich der proprietäre Treiber nvidia bislang damit nicht verträgt (eine andere ewige Geschichte), muß er zuerst deinstalliert werden (sofern man eine entsprechende GPU und ihn installiert hat, versteht sich).

Nach Installation des Mainline-Kernels ist mit diesem zu rebooten. Dazu sollte kein Eingriff nötig sein, da er an erster Stelle steht. Anderenfalls wählt man ihn im Grub-Menu aus.

Nach diesem Boot rebootet man erneut, diesmal ins UEFI. Man lädt Optimized Defaults und geht die Settings durch, um ggf. gewünschtes/nötiges wie Fastboot disabled etc. zu setzen. Nun sollte das Speichern wieder möglich sein. Es gibt in den Comments des Bugreports bereits mehrere Bestätigungen.

Im nunmehrigen Ubuntu-Boot aktualisiert man Paketquellen, Paketquelleninhalte und installierte Pakete, erhält so auch Kernel 4.13.0-21.24, falls noch nicht installiert, der das UEFI nicht korrumpiert (aber offensichtlich nicht fixen kann wie besagter Mainline-Kernel). Nach einem weiteren Boot mit ausgewähltem 4.13.0-21.24 kann man den Mainline-Kernel wieder deinstallieren und ggf. nvidia-3xx und nvidia-settings wieder installieren.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
sudo apt-get purge nvidia*
mkdir -p ~/Downloads/kernel/4.17.2/
cd ~/Downloads/kernel/4.17.2/
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/linux-headers-4.17.2-041702_4.17.2-041702.201806160433_all.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/linux-headers-4.17.2-041702-generic_4.17.2-041702.201806160433_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/linux-image-unsigned-4.17.2-041702-generic_4.17.2-041702.201806160433_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/linux-modules-4.17.2-041702-generic_4.17.2-041702.201806160433_amd64.deb
#
# mkdir -p ~/Downloads/kernel/4.14.9/
# cd ~/Downloads/kernel/4.14.9/
# wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.9/linux-headers-4.14.9-041409_4.14.9-041409.201712251541_all.deb
# wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.9/linux-headers-4.14.9-041409-generic_4.14.9-041409.201712251541_amd64.deb
# wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.9/linux-image-4.14.9-041409-generic_4.14.9-041409.201712251541_amd64.deb
#
sudo dpkg -i *
sudo reboot

Update 2018-06-17: Aktualisiert auf 4.17.2.
Update 2018-04-20: Aktualisiert auf 4.15.17.
Update 2018-03-31: Aktualisiert auf 4.14.32.
Update 2018-02-03: Aktualisiert auf 4.14.16.
Update 2018-01-06: Aktualisiert auf 4.14.12.
Update 2018-01-03: Aktualisiert auf 4.14.11.
Update 2017-12-29: Aktualisiert auf eben erschienene Version 4.14.10. Die 4.14.9-Links lasse ich einstweilen stehen, bis erwiesen ist, daß auch der neue Kernel fixen kann.

Warnung: Ubuntu-Kernel zerstoert UEFI

Auf bugs.launchpad.net wird gemeldet, daß Ubuntu 17.10 Artful das UEFI bestimmter Lenovo-Modelle unwiederbringlich zerstört.

Auch, wenn da auf der Canonical-Download-Website nun endlich “The download of Ubuntu 17.10 is currently discouraged due to an issue on certain Lenovo laptops. Once fixed this download will be enabled again.” zu lesen ist, wirklich zurückgezogen hat Canonical bis jetzt nichts, auf releases.ubuntu.com – und das ist der Mainserver – liegen nach wie vor die Oktober-Releases. Mit dessen Derivaten auf cdimage.ubuntu.com sieht es nicht anders aus.

Und das ist der wirkliche Skandal. Der Bugreport ist vom 2017-11-23 (!). Canonicals Kernel schrottet UEFIs von bisher durch User gemeldet Lenovo, Acer, Toshiba, Dell – und Canonical hält es nicht für nötig, sofort die Downloads zu verhindern und eindeutige Warnungen an x Stellen zu bringen.

Und selbst, wenn da für Artful und bisher nur für Artful ein Fix released ist (und der klingt auch erstmal nur nach Workaround), obwohl es auch Xenial mit hwe-edge betreffen soll, bekommt man den nur über Update, hat da aber zwangsläufig schon die zerstörerischen Images geladen (Man könnte sich ein eigenes angepaßtes Image in einer VM erstellen, um davon zu booten/installieren, aber wieviel Ubuntu-User können/machen sowas? Wieviel wissen überhaupt vom Problem?). Ebenso sind die gefährlichen Kernels 4.13.0-17 und -19 noch ziehbar.

Das ist das Allerletzte, was Canonical da abliefert, und man hat dort zudem offenbar nichts aus 2012 gelernt (damals haben “wenigstens auch” andere geschlampt).

Update 2017-12-27: Fix fuer corrupted UEFI

Lubuntu 17.10: 80 % Blackscreen mit Intel-IGP

Auf Rechnern mit altägyptischen Intel-IGPs wie GMA 945/950 in Netbooks mit Atom 270/280 gibt es unter Lubuntu Artful, logischerweise 32 bit, seit geraumer Zeit das Problem, daß nur ein vertikaler Streifen am rechten Rand Bild zeigt, 80 % dagegen sind schlicht schwarz. Da man zur Ursachenfindung offenbar noch Zeit braucht, hier der als funktionierend allgemein bestätigte Workaround. Um ihn durchführen zu können, kann man beispielsweise das System kurz in Standby schicken und wiederholen (an sich schon ein halber, jedoch unschöner Workaround).

  1. Starte den Editor mit root-Rechten:
    1
    
    sudo -H leafpad /etc/default/grub
  2. Füge folgende Zeile hinzu bzw. ersetze die möglicherweise vorhandene:
    GRUB_GFXPAYLOAD_LINUX=text
  3. Aktualisiere grub:
    1
    
    sudo update-grub
  4. Reboote:
    1
    
    sudo reboot

Mit der Option text wird auf Werte aus einer Blacklist für problematische GPUs zugegriffen.

Artful-Kernel in Zesty und Xenial

Man kann sich’s zwar auch selbst aus meinen früheren Blogposts (6, 5, 4, 3, 2, 1) schmieden, aber der Einfachheit halber und zum direkten Verlinken als aktualisierter Post:

Artful-Kernels können in Zesty (und Xenial) installiert werden.

Führe über copy & paste in einem Terminal aus (Achtung, erst bis zum Schluß lesen):

1
2
3
4
sudo bash -c "echo 'deb http://archive.ubuntu.com/ubuntu/ artful main' >> /etc/apt/sources.list.d/artful.list"
sudo bash -c "echo -e 'Package: *\nPin: release a=artful\nPin-Priority: 100\n' >> /etc/apt/preferences.d/artful.pref"
sudo apt-get update
sudo apt-get install -t artful linux-image-generic linux-generic linux-headers-generic linux-libc-dev

Direkt vor dem Distupgrade auf Artful (Final Release 2017-10-19) führe aus:

1
2
sudo rm /etc/apt/sources.list.d/artful.list
sudo rm /etc/apt/preferences.d/artful.pref

Die freien GPU-Treiber intel, nouveau und radeon sowie vboxvideo (VBox 5.1.26, VBox 5.2.0b2) kommen mit derzeit Kernel 4.12 klar (Vanilla- und Ubuntu-Mainline-Kernel 4.13 Final werden für 2017-09-03 erwartet, in Artful soll letztendlich 4.13 einfließen), nicht jedoch der proprietäre Treiber aus den Ubuntu-Paketquellen nvidia für bis inkl. Zesty. Daher ist zuerst der jeweils aktuelle nvidia-304 (GF 6 und 7), nvidia-340 (GF 8 – GF 300) bzw. nvidia-375 (GF 400 und höher) für Artful aus den Ubuntu-Repositories zu installieren.

Ubuntu-(Mainline-)Kernel 4.12 mit VirtualBox 5.1.22

Auch VirtualBox läuft derzeit nicht mit Kernel 4.12 im Host (im Guest kann man einen aktuellen Testbuild der GuestAdditions installieren).

Dank eines Postings im siduction-Forum kann man VBox 5.1.22 für Kernel 4.12 patchen:

  1. Wechsel des Verzeichnisses:
    1
    
    cd /usr/share/virtualbox/src
  2. Ziehen des Patchfiles:
    1
    
    sudo wget http://paste.siduction.org/20170629003423 -O vbox.patch
  3. Ausführen des Patches:
    1
    
    sudo patch -Np0 < vbox.patch
  4. Installation (Mainline-)Kernel 4.12.

Update 2017-07-17: Durch Fixes in VirtualBox 5.1.24 benötigt es keinen Patch mehr für Kernel 4.12 und 4.13rc in Host/VM.

Ubuntu-(Mainline-)Kernel 4.12 mit nvidia-340

Ständig gibt es Inkompatibilitäten zwischen Kernel- und XServer-Versionen auf der einen und proprietären Treibern auf der anderen Seite, namentlich nvidia. Ist schon Ubuntu-(Mainline-)Kernel 4.11 nur mit nvidia-340 (340.102-0ubuntu4) für Artful installierbar, gibt es bislang für Kernel 4.12 weder seitens des Graphics Drivers teams auf launchpad.net noch und gerade von Nvidia selbst eine Lösung.

Der freie Treiber nouveau hat zwar mit Kernel 4.12 keine Probleme, wegen mangelnder Stromsparmechanismen läuft die GPU freilich permanent mit voller Leistung, was die Temperatur je nach GPU locker um 10 Grad hochtreibt.

Erst ein Dritter namens Piotr Oniszczuk (warpme) setzt einen Patch für nvidia-340 (GF8 – GF GTX800M Series) auf Github.

  1. Installation nvidia-340, falls noch nicht geschehen.
  2. Wechsel des Verzeichnisses:
    1
    
    cd /usr/src/nvidia-340-340.102/
  3. Ziehen des Patchfiles:
    1
    
    sudo wget https://github.com/warpme/minimyth2/blob/master/script/nvidia/nvidia-340.102/files/4.12.0_kernel.patch
  4. Ausführen des Patches:
    1
    
    patch -N < 4.12.0_kernel.patch
  5. Installation (Mainline-)Kernel 4.12.

Installation von und Betrieb mit Mainline-Kernel 4.12 laufen so einwandfrei mit nvidia-340 unter Zesty.

Zesty-Kernel in Yakkety und Xenial

Analog zu früheren Blogposts (5, 4, 3, 2, 1) können Zesty-Kernels in Yakkety (und Xenial) installiert werden.

Führe über copy & paste in einem Terminal aus (Achtung, erst bis zum Schluß lesen):

1
2
3
4
sudo bash -c "echo 'deb http://archive.ubuntu.com/ubuntu/ zesty main' >> /etc/apt/sources.list.d/zesty.list"
sudo bash -c "echo -e 'Package: *\nPin: release a=zesty\nPin-Priority: 100\n' >> /etc/apt/preferences.d/zesty.pref"
sudo apt-get update
sudo apt-get install -t zesty linux-image-generic linux-generic linux-headers-generic linux-libc-dev

Direkt vor dem Distupgrade auf Zesty (Final Release 2017-04-13) führe aus:

1
2
sudo rm /etc/apt/sources.list.d/zesty.list
sudo rm /etc/apt/preferences.d/zesty.pref

Die freien GPU-Treiber intel, nouveau und radeon sowie vboxvideo (VBox 5.1.12) kommen mit Kernel 4.9 klar, nicht jedoch der proprietäre Treiber aus den Ubuntu-Paketquellen nvidia für bis inkl. Yakkety. Daher ist zuerst der jeweils aktuelle nvidia-304 (GF 6 und 7), nvidia-340 (GF 8 – GF 300) bzw. nvidia-367 (GF 400 und höher) für Zesty aus den Ubuntu-Repositories zu installieren.

Hierzu kann man sich nvidia-3xx und dessen Abhängigkeiten aus den Repos fischen oder temporär neben main auch restricted und multiverse einbinden (erste Shell-Zeile). Letztere beide würde ich sicherheitshalber danach auskommentieren (Doppelkreuz davor).

Yakkety-Kernel in Xenial

Nachdem nun endlich Ubuntu-Kernel 4.6 aus dem Kernel-PPA in die offiziellen Repositories für Yakkety übernommen worden ist, vorerst noch als proposed (Warnung, nicht aktivieren), können analog zu früheren Blogposts (4, 3, 2, 1) automatisch Yakkety-Kernels in Xenial installiert werden.

Führe über copy & paste in einem Terminal aus:

1
2
3
4
sudo bash -c "echo 'deb http://archive.ubuntu.com/ubuntu/ yakkety main' >> /etc/apt/sources.list.d/yakkety.list"
sudo bash -c "echo -e 'Package: *\nPin: release a=yakkety\nPin-Priority: 100\n' >> /etc/apt/preferences.d/yakkety.pref"
sudo apt-get update
sudo apt-get install -t yakkety linux-image-generic linux-generic linux-headers-generic linux-libc-dev

Direkt vor dem Distupgrade auf Yakkety (Final Release 2016-10-13) führe aus:

1
2
sudo rm /etc/apt/sources.list.d/yakkety.list
sudo rm /etc/apt/preferences.d/yakkety.pref