siduction: grub zurueck zu pure ASCII

Das grafische Grub-Menu in siduction widerspricht meinem Schönheitsempfinden. Lieber pure ASCII (bin ich eh ein Fan von).

In einer root-Shell ausführen:

1
2
apt purge patience-grub-theme
update-grub

Vergißt man das Aktualisieren von grub, ist dieser zwar nichtgrafisch, weil schlicht entsprechende Files weg sind, aber es kommt zu einer Fehlermeldung, daß “/usr/share/grub/themes/patience/theme.txt” nicht gefunden wird. Weitergebootet wird nach einigen Sekunden trotzdem.

Danach sollte man sich ansehen, ob man nicht bei einem

1
apt --purge autoremove

zu deinstallierende Pakete doch noch brauchen könnte, bspw. die Icons. In einer siduction-Test-VM würden “breeze-cursor-theme* creativecommons3* patience-lxqt-artwork* patience-sddm-settings* siduction-icons*” gepurged werden. Will man das nicht, setzt man gewünschte(s) Paket(e) zuvor auf manuell installiert, im Beispiel:

1
apt-mark manual siduction-icons*

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!

[siduction] Uebergang auf GCC5

Seit 2 Wochen läuft in debian sid die Transition auf GCC5 und damit natürlich auch in siduction. Dieser Übergang ist kein wirklicher, sondern ein Bruch. Entsprechend bringen seitdem Aktualisierungsversuche enorme Abhängigkeitsprobleme. Als User ganz einfach nichts zu machen, sprich keine Updates fahren (und damit das System potenziellen Sicherheitsrisiken auszusetzen), wie im siduction-Forum wiederholend geraten wird, halte ich für eine schlechte Idee, zumal das noch lange dauern wird, bis sämtliche betroffenen Pakete angefaßt worden sind. Selbstredend auch Augen zu und durch.

Da derzeit testing und sid wenig auseinander liegen, habe ich bis auf weiteres das unstable-Repository durch das von testing ersetzt (alle anderen bleiben). Funktioniert hier in einer VM seit 14 Tagen einwandfrei. Ist zwar nicht mehr ganz so aktuell, aber lauffähig, man bekommt keinen Herzkasper, wenn da x-undneunzig Pakete deinstalliert werden sollen. ;)

Aus siduction mach testuction:

1
2
3
su
sed -i 's!debian/ unstable main!debian/ testing main!g' /etc/apt/sources.list.d/debian.list
apt-get update

Rückgängig Machen sollte klar sein:

1
sed -i 's!debian/ testing main!debian/ unstable main!g' /etc/apt/sources.list.d/debian.list

Welches Unbill dann zu erwarten ist, insbesondere je länger das dauert, kann ich jetzt freilich noch nicht sagen.

kernel-remover aus siduction in Ubuntu

siduction kernel-remover

Ältere bzw. nicht mehr benötigte Kernels werden unter Ubuntu nicht automatisch deinstalliert (was seine Richtigkeit hat). Ewig und 3 Tage hat es gedauert, bis durch ein “apt-get autoremove” dies (für Linux-Beginners, denen sonst /boot auf separater Partition vollläuft) mit berücksichtigt worden ist, wobei nur “alles oder nichts” möglich ist (selbstverständlich kann man das immer in einem Terminal oder in Synaptic bewerkstelligen).

Andere Distributionen können das besser. In siduction kann man das kleine Tool kernel-remover laufen lassen. Der Aufbau der Kernel-Pakete von debian sid und Ubuntu unterscheidet sich, weshalb es interessant gewesen ist, kernel-remover einfach mal in einer Lubuntu-Trusty-VM auszuprobieren (für derlei hat man sowas ja). Dazu habe ich extra unterschiedliche Kernels wie einen Mainline-Kernel (die ich sonst nicht verwende) und unterschiedliche Dev-Versions aus Wily installiert.

Read more “kernel-remover aus siduction in Ubuntu”

siduction: Update-Warning xorg

In siduction wird derzeit auf Kernel 3.13.2 sowie auf xorg 1.15.0 aktualisiert. Wer siduction in einer VBox-VM fährt, landet nach Reboot nur in tty. Zur Abwechslung kann VirtualBox zwar mit einem aktuellen Kernel umgehen, aber nicht mit einem aktuellen XServer (wie auch manche proprietäre GPU-Treiber).

Man sollte also vor dem Update pinnen:

1
2
3
su
echo "xserver-common hold" | dpkg --set-selections
echo "xserver-xorg-core hold" | dpkg --set-selections

Nun kann normal geupdatet werden:

1
apt-get update && apt-get dist-upgrade

Bevor es keine neue VBox-Version (derzeit v4.3.6) gibt, braucht man auch nicht wieder entsperren. Dies geschieht wie folgt:

1
2
3
su
echo "xserver-common install" | dpkg --set-selections
echo "xserver-xorg-core install" | dpkg --set-selections

Update 2014-02-25: VBox v4.3.8 final ist soeben auf den Server gelegt worden (Changelog). Bereits GuestAdditions v4.3.8rc1 ist mit xorg 1.15 kompatibel und siduction läuft damit in einer VM einwandfrei. Das entsprechende hold-Tag kann und sollte daher nach Installation der aktuellen Gasterweiterungen entfernt werden.

Update 2014-07-10: Mit xorg 2:1.15.99.904-1 ist das Problem zurück. Die vorherige Version 2:1.15.1-1 läuft noch einwandfrei mit GuestAdditions bis 4.3.14rc1 (VBox v4.3.14rc1 selbst sollte jedoch wegen weiterer offensichtlicher Inkompatibilitäten nicht installiert werden).

siduction 2013.2.0 noX mit E17

siduction ist ein Fork von aptosid, dem Nachfolger von sidux, dem Fork von Kanotix – alles klar? ;-)

Als eine Rolling Release Distribution sind neue Versionen Snapshots eines derzeitigen Standes, den man auch, einmal installiert, durch normales Updaten erreicht im Gegensatz zu den meisten Linux-Distributionen wie Ubuntu, bei denen man neue Versionen ausschließlich durch Distupgrades oder Neuinstallationen erhält. Beide Konzepte haben ihr Für und Wider, wobei mich RR um einiges mehr anspricht (Diskussionen und entsprechende Bewegungen von Ubuntu-Entwicklern in Richtung RR sind vom Big Boss stets abgewürgt worden).

Read more “siduction 2013.2.0 noX mit E17”