Forum: PC Hard- und Software Devuan ohne initrd?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bauform B. (bauformb)


Bewertung
-3 lesenswert
nicht lesenswert
Servus!

Benutzt hier jemand Devuan ohne initrd? Das sollte eigentlich weniger 
Bastelei kosten als unter Debian?

Meine PCs laufen schon immer ohne initrd unter Debian. Der Trend geht 
anscheinend dahin, dass die initrd immer unersetzlicher wird. Jetzt 
steht die nächste Neu-Installation an, meine erste AMD64, deshalb dachte 
ich, kann ich auch gleich auf Devuan umsteigen. Ist Devuan immer noch 
das bessere Debian?
The release even has won an endorsement from Bruce Perens,
a coder widely credited as the founder of the open source
software movement.

"I was the second Debian project leader. These days, I prefer
to run Devuan, a true Debian derivative engineered the way
I would probably have decided to make it. It's efficient and
trouble-free. Thanks to the Devuan developers for all of
the work!" Perens wrote. ®
https://www.theregister.com/2018/06/12/devuan_ascii_stable_ships/

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Ist Devuan immer noch
> das bessere Debian?

War’s das je? Ich hab’s eher als ein Trotzprodukt irgendwelcher 
selbsternannten Admin-Veteranen (die nannten sich wirklich selbst so) in 
Erinnerung, die mit Neuerungen nicht recht umgehen konnten. Das Problem 
ist, dass viele Projekte mehr und mehr die Möglichkeiten der Neuerungen 
nutzen, und damit nicht mehr für Devuan zur Verfügung stehen. Ob das für 
dich relevant ist, kannst du nur selbst entscheiden – außer dir weiß ja 
keiner was zur Konzeption deiner Systeme.

Wie auch immer – ein modernes System dürfte sich ohne initramfs nicht 
hochbekommen lassen, insofern wäre Devuan schon ein besserer Ansatz, als 
solche Systeme. Allerdings ist auch das auf ein initramfs ausgelegt, so 
dass da recht tiefgreifende Basteleien nötig sein werden.

Beitrag #6357634 wurde von einem Moderator gelöscht.
von Hmmm (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jack V. schrieb:
> Das Problem ist, dass viele Projekte mehr und mehr die Möglichkeiten der
> Neuerungen nutzen, und damit nicht mehr für Devuan zur Verfügung stehen.

Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine 
Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand 
systemd.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:

> Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine
> Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand
> systemd.

Was gibt es denn außer Windows und Linux noch? Ich meine jetzt: wirklich 
relevantes...

Das, was da bleibt, sind sterbende Nischen. Nicht mehr. Einzig in den 
USA hat Apple mit seinem weitgehend propräitarisierten BSD noch einen 
nennenswerten Marktanteil. Naja, Amis sind halt in ihrer Mehrheit 
schlicht strunzdoof. 40% von denen halten ja sogar die Tatsache der 
Evolution für einen Fake...

Wird also über kurz oder lang auch noch sterben...

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine
> Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand
> systemd.

Stimmt. Ich halte es aber nicht für ein Verbrechen, die Möglichkeiten 
eines Systems zu nutzen, ohne sich mit Blick auf andere Systeme 
einzuschränken. Ist ja nicht so, dass es auf anderen Systemen nicht 
genauso gemacht würde.
Und wer Wert auf die Portabilität seiner Sachen legt, ist nicht 
gezwungen, linuxspezifische Funktionalität zu nutzen. Nur eben von allen 
anderen zu verlangen, dass sie’s auch so zu machen haben, ist, meiner 
Ansicht nach, daneben.

Ist das Gleiche, wie diese ewige Diskussion um Abwärstkompatibilität: 
klar ist’s schön, wenn jahrzehntealter Kram noch zum Laufen zu bringen 
ist. Aber wenn der Preis dafür ist, dass aktuelle Möglichkeiten nicht 
genutzt werden können, oder der Code sich immer mehr aufbläht und 
unwartbar wird, dann kann man auch schonmal ’nen Schnitt machen. Die 
dann am lautesten maulen, können ja die alte Version forken und 
weiterpflegen – dann sehen sie mal, was für Arbeit das ist.

von Hmmm (Gast)


Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Was gibt es denn außer Windows und Linux noch? Ich meine jetzt: wirklich
> relevantes...

Wenn Du Relevanz aus der "Millionen Fliegen fressen 
Scheisse"-Perspektive siehst, nicht viel.

Ansonsten findet man BSDs sowohl bei namhaften Unternehmen wie Netflix 
als auch haufenweise in Appliances (IronPort, Juniper, NetApp etc.)

Auch Solaris ist wohl gerade im Enterprise-Umfeld immer noch nicht tot.

Aber dass es eine Welt ausserhalb von Linux gibt, scheinen viele einfach 
nicht zu wissen. Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts, 
die jede Bourne Shell verdaut, nicht erklären.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hmmm schrieb:

> Aber dass es eine Welt ausserhalb von Linux gibt, scheinen viele einfach
> nicht zu wissen

Das ist gut möglich angesichts der schieren Irrelevanz des Rests...

> Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts,
> die jede Bourne Shell verdaut, nicht erklären.

Wenn das dein einziges Problem ist, dann beherrschst du deine 
BSD-basierte Umgebung nicht wirklich. Es wäre ein Kinderspiel, das z.B. 
auf sh umzulenken...

Du kannst nicht erwarten, dass die weit überwiegende Mehrheit sich 
Gedanken um die Sorgen und Nöte einer jetzt schon geringen und 
potentiell völlig aussterbenden Minderheit macht.

Wenn es dir Spaß macht, zu dieser Minderheit zu gehören, kein Problem. 
Dann löse aber auch die Probleme selber, die sich daraus ergeben, wenn 
man anders als (fast) alle anderen sein will...

von Christobal M. (c_m_1)


Bewertung
0 lesenswert
nicht lesenswert
Keine initrd kann man machen wenn das root Blockdevice und Filesystem 
einfach so vom Kernel erkannt und gemounted werden kann. "sda1" z.b.
Sobald das Root Filesystem zuerst konfiguriert werden muss 
(Verschlüsselung, LVM, "SCSI Treiber", Kernelmodul laden...) geht afaik 
nichts an einer initrd vorbei.
Zu meinen Gentoo Zeiten hab ich mir eine Zeit lang meine initrd selbst 
gebaut um zum Spass das Betriebssystem in einem tmpfs laufen zu 
lassen... War schön schnell, dann kamen SSD's auf den Markt.

Also was genau ist schlimm an initrd's?

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Aber dass es eine Welt ausserhalb von Linux gibt, scheinen viele einfach
> nicht zu wissen. Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts,
> die jede Bourne Shell verdaut, nicht erklären.

Ich spreche da mal für mich: wissen kann ich es schon. Beziehungsweise: 
ich weiß es. Warum ich trotzdem keine Rücksicht auf andere Systeme 
nehme? Weil ich selbst nur Linux habe, und es daher auf anderen 
Systemen weder testen, noch sonst irgendwie Support geben kann. Warum 
sollte ich mich da also einschränken, um die mit zu bedienen?

Wenn jemand meinen Kram nimmt, und ihn auf ’nem anderen System zum 
Laufen bringt: da freu’ ich mich drüber. Und wenn er an mich herantritt, 
und konkrete Änderungen dafür anfragt (nicht: „verlangt“. Das ist 
wichtig), setze ich das im Rahmen meiner Möglichkeiten auch gerne um. 
Aber pauschal mir unbekannte Systeme berücksichtigen? Wozu soll das gut 
sein?

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
>> Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts, die jede Bourne
>> Shell verdaut, nicht erklären.
>
> Wenn das dein einziges Problem ist, dann beherrschst du deine
> BSD-basierte Umgebung nicht wirklich.

Wie kommst Du auf die Idee, dass das für mich mehr als ein Ärgernis 
wäre?

c-hater schrieb:
> Du kannst nicht erwarten, dass die weit überwiegende Mehrheit sich
> Gedanken um die Sorgen und Nöte einer jetzt schon geringen und
> potentiell völlig aussterbenden Minderheit macht.

Selbst unter Linux kann und sollte man das Vorhandensein einer Bash 
nicht voraussetzen.

Aber warum an Standards halten, wenn man auch planlos rumbasteln kann...

von Jack V. (jackv)


Bewertung
3 lesenswert
nicht lesenswert
Hmmm schrieb:
> Selbst unter Linux kann und sollte man das Vorhandensein einer Bash
> nicht voraussetzen.

 … das ist aber in ungefähr die Argumentation, wie „du kannst unter 
Linux das Vorhandensein eines Python-Interpreters nicht voraussetzen – 
schreib deinen Kram also gefälligst in ’ner anderen Sprache“.

Die Lösung kann sein: ich definiere in diesem Beispiel Python als 
Abhängigkeit, oder im Fall der Bash, eben diese. Wo ist das Problem?

: Bearbeitet durch User
von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Die Lösung kann sein: ich definiere in diesem Beispiel Python als
> Abhängigkeit, oder im Fall der Bash, eben diese. Wo ist das Problem?

Der Vergleich hinkt. In 99% der Fälle wird faktisch gar keine Bash 
benötigt, sondern eine POSIX-konforme /bin/sh.

Das ist fast so, als würdest Du bei der Installation Python 
voraussetzen, es dann aber gar nicht benutzen.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Das ist fast so, als würdest Du bei der Installation Python
> voraussetzen, es dann aber gar nicht benutzen.

Okay – ich ging davon aus, dass auch Bash-Features genutzt würden. In 
dem von dir gezeichneten Bild wäre die She-Bang-Zeile mit der Bash in 
etwa das, was dem Buntu-User sein ›sudo‹ – wird überall vorgeklatscht, 
egal, ob sinnvoll, sinnlos, oder gar gefährlich. Das ist in der Tat 
doof.

von Bauform B. (bauformb)


Bewertung
1 lesenswert
nicht lesenswert
Christobal M. schrieb:
> Sobald das Root Filesystem zuerst konfiguriert werden muss
> (Verschlüsselung, LVM, "SCSI Treiber", Kernelmodul laden...) geht afaik
> nichts an einer initrd vorbei.

Verschlüsselung lasse ich gelten und / auf LVM finde ich unangebracht. 
SCSI- und Filesystem-Treiber kann man fest einbauen und die meisten 
anderen Module werden nicht zum Booten gebraucht. Also brauche ich für 
meine Rechner keine initrd.

> Also was genau ist schlimm an initrd's?

Die bzw. die initramfstools sind ein unnötiges Risiko, dass bei einem 
Update etwas schief geht. Und beim nächsten Rechner macht evt. jemand 
ein Update, der dann hilflos ist.

Inzwischen frage ich mich allerdings, wann die initrd überhaupt neu 
gebaut wird. Natürlich bei einem Kernel-Update, aber sonst? Kann es 
sein, dass es auch bei udev-Updates passiert (und schief gegangen) ist? 
Das sollte ja bei Devuan nicht nötig sein und den Aufwand, einen eigenen 
Kernel zu bauen, würde ich schon gerne sparen.

Inzwischen habe ich eine freie Partition gefunden und Devuan (ohne 
Desktop) installiert. Soweit merkt man praktisch keinen Unterschied zu 
Debian, naja, bis auf den einen, "ifconfig eth0" funktioniert wieder ;)

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> / auf LVM finde ich unangebracht.

Sehr nützlich. Weil mühelos bei Bedarf vergrösserbar, 
unterbrechungsfrei.

: Bearbeitet durch User
von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Die bzw. die initramfstools sind ein unnötiges Risiko, dass bei einem
> Update etwas schief geht. Und beim nächsten Rechner macht evt. jemand
> ein Update, der dann hilflos ist.

Sorry, aber eigentlich verhält’s sich genau andersrum: während bei mir 
in den vergangenen zwanzig Jahren keine Systeme wegen fehlgeschlagener 
initrd-/initramfs-Erstellung (initrd wird schon länger nicht mehr 
benutzt) unbootbar waren, ist die Gefahr bei ’nem selbstgebauten Kernel 
höher, dass „jemand“ (also nicht der, der’s System aufgesetzt hat) ein 
Update fährt und anschließend nix mehr geht.

Bauform B. schrieb:
> Soweit merkt man praktisch keinen Unterschied zu
> Debian, naja, bis auf den einen, "ifconfig eth0" funktioniert wieder

Funktionierte bei mir durchgehend. Waren einmalig wenige Tastendrücke.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Bauform B. schrieb:
>> / auf LVM finde ich unangebracht.
>
> Sehr nützlich. Weil mühelos bei Bedarf vergrösserbar,
> unterbrechungsfrei.

Tja, vielleicht war früher doch manches einfacher? Vieleicht war /usr 
auf einer eigenen Partition keine so dumme Idee?

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
>> Sehr nützlich. Weil mühelos bei Bedarf vergrösserbar,
>> unterbrechungsfrei.
>
> Tja, vielleicht war früher doch manches einfacher? Vieleicht war /usr
> auf einer eigenen Partition keine so dumme Idee?

Bei /, /opt und /usr ist das nur unnötige Arbeit, reduzierte 
Flexibilität und bringt keinen Vorteil. Erst recht, wenn sich der Kram 
untenrum auf dem gleichen Medium wieder einfindet, nicht auf getrennten 
HDDs.

Routinemässig gibts bei mir heutzutage ein Root-FS mit allem weitgehend 
statischem Zeug drin, ggf plus /var für viel Logging und zusätzliche 
Filesysteme für die Anwendung, wenn es lohnt. Und das alles im LVM. Bei 
Systemen mit grossem Anwendungsbereich landen die gerne in zweiter VG.

Was mehr Platz braucht wird dann eben bei Bedarf vergrössert, das ist 
trivial und ohne Betriebsunterbrechung möglich, so lange die VG nicht 
voll ist (lvresize + resize2fs/xfs_sonstwas). Die VGs werden dafür 
erheblich grösser angelegt als anfangs verwendet, weil angelegter aber 
nicht benutzter LVM-Space bei VMs nichts kostet (thin provisioning).

Bereits IBMs AIX liess sich vor 3 Jahrzehnten so ähnlich betreiben, es 
hatte aber in alter Tradition noch etliche getrennte Filesysteme im LVM. 
Gebootet hat das übrigens grob ähnlich wie Linux heute.

: Bearbeitet durch User
von Club der toten Pferde (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Jack V. schrieb:
> War’s das je? Ich hab’s eher als ein Trotzprodukt irgendwelcher
> selbsternannten Admin-Veteranen (die nannten sich wirklich selbst so) in
> Erinnerung, die mit Neuerungen nicht recht umgehen konnten. Das Problem
> ist, dass viele Projekte mehr und mehr die Möglichkeiten der Neuerungen
> nutzen, und damit nicht mehr für Devuan zur Verfügung stehen.
Kommt drauf an, was man alles so "Neuerung" nennen will. Habe vor ca. 
1/2 Jahr nach mehrjährigem problemlosem Betrieb auf allen meinen 
Rechnern mal einen Rechner mit Debian neu aufgesetzt, um die tollen, 
heute erzwungenen Web-Neuerungen überhaupt nutzen zu können (müssen). 
Ging alles soweit problemlos. Aber ach: Was soll ich sagen? Als dann mal 
ein simples ifconfig anstand war ich echt bedient. Vollkommen neue 
Befehlsstruktur mit allem drum und dran. Ekelhaft. Abstoßend. Alles in 
einen Monolithen gekloppt, ganz in systemd Manier. Durch die Manpage zu 
steigen ist eine Kunst. Da braucht man schon das Internet um selbigem 
Rechner das Interface zu konfigurieren.
Neenee, wer sowas verzapft ist in meinen Augen nicht wirklich an 
produktiven Neuerungen interessiert. Da wende ich mich dankend nach über 
20 Jahren Debian ab. Schön war die Zeit, aber nun ist Schluß.
Auch der Kernel wird mit seinen erzwungenen politischen Korrektheiten 
und dem ganzen sinnlosen Zinnober sterben. Ganz sicher.
Welches Bild soll man da jetzt von den jungen, nachwachsenden 
Entwicklern haben?

von Jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Club der toten Pferde schrieb:
> Welches Bild soll man da jetzt von den jungen, nachwachsenden
> Entwicklern haben?

auch Club der toten Pferde:
- Wird von der seit min. 9 Jahren absehbaren Ablösung durch ein min. 19 
Jahre* altes Werkzeug völlig überrumpelt


*(systemd ist übrigens deutlich jünger)

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Club der toten Pferde schrieb:
> Als dann mal
> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue
> Befehlsstruktur mit allem drum und dran. Ekelhaft. Abstoßend.

Entschuldige, aber: Hä??

›ifconfig‹ lässt sich bedienen, wie all die Jahrzehnte bislang auch. Was 
genau hat dich daran nun abgestoßen und das Ekelgefühl erzeugt?

von S. Ramon (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wieso wird hier initramfs mit systemd gleichgesetzt oder zumindest in 
Verbindung gebracht. Du kannst dein System auch über PXE booten, es 
einen initramfs nachladen und dein spezielles /init ausführen lassen. 
Diskless. Funktioniert und ist nichts ungewöhnliches.

von Netplan.YAML (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Was
> genau hat dich daran nun abgestoßen und das Ekelgefühl erzeugt?

"ifconfig" ist nicht mehr als default installiert!

man muss bei einem neu aufgesetztem System sofort ekelhafte Kommandos 
wie
>> apt install net-tools
eintippen, und damit seine Tastatur besudeln.

Geheimtipp: Statt dem Krasser-Hipster-Ekelkommando "apt" geht auch heute 
noch das gute, althergebrachte
>> apt-get install net-tools

Damit ist die Sache doch nur noch halb so schlimm, oder?

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Netplan.YAML schrieb:
> "ifconfig" ist nicht mehr als default installiert!

Ja, aber wie du schon schreibst: man kann es problemlos 
nachinstallieren, wenn man Probleme hat, sich auf Neues einzulassen. Das 
ist auch völlig problemlos: wer nämlich schon Probleme hat, ’ne neue 
Syntax zu nutzen, der würde die neuen Funktionen, wie etwa das einfache 
Handling mehrerer IPs und Routen pro Interface, wohl auch gar nicht erst 
angucken.

›apt‹ ist eher ’n Wrapper, der einige Funktionalität der anderen Sachen 
zusammefasst. Auch da ist man nicht drauf angewiesen, sondern es stehen 
die hergebrachten Sachen einzeln zur Verfügung. Aber auch da verzichtet 
man halt auf Annehmlichkeiten, die’s mit sich bringt, wie etwa das 
einfache Installieren lokal vorliegender Pakete mit automatischer 
Auflösung der Abhängigkeiten. Wenn man’s vorher mit ›dpkg‹ gemacht hat, 
durfte man alles selbst raussuchen, ›gdebi‹ kann’s zwar auch 
automatisch, hat aber andere Nachteile.

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
Club der toten Pferde schrieb:
> Kommt drauf an, was man alles so "Neuerung" nennen will. Habe vor ca.
> 1/2 Jahr nach mehrjährigem problemlosem Betrieb auf allen meinen
[...]
> Ging alles soweit problemlos. Aber ach: Was soll ich sagen? Als dann mal
> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue

Wenn man die Entwicklung mehr als ein Jahrzehnt lang verschläft, dann 
wird man natürlich mal überrascht. Aber das sollte man nicht den 
Maintainern der Distribution anlasten, sondern eher der eigenen 
Faulheit.

ifconfig wurde aus sehr guten Gründen durch iproute und iproute2 
abgelöst, auch wenn du diese Funktionalität vielleicht nie gebraucht 
hast. Und wenn man sich die Syntax ansieht, dann versteht man auch 
schnell, warum bei den vielen Gemeinsamkeiten daraus keine zig getrennte 
Tools gebaut wurden.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
S. Ramon schrieb:
> Wieso wird hier initramfs mit systemd gleichgesetzt oder
> zumindest in Verbindung gebracht.

Eigentlich wollte ich genau das vermeiden, weil es immer ausartet, wenn 
man dieses Wort benutzt. Ich installiere entweder Debian mit sysvinit 
oder eben, vielleicht, demnächst, Devuan. Das ist nicht verhandelbar.

> Du kannst dein System auch über PXE booten, es einen initramfs
> nachladen und dein spezielles /init ausführen lassen. Diskless.
> Funktioniert und ist nichts ungewöhnliches.

Bei meinen Rechnern mache ich gerne solche Sachen und natürlich würde 
ich Devuan ohne initrd betreiben, kein Problem. Aber jetzt muss ich 
einen Rechner installieren, bei dem jemand root wird, der sich dafür 
nicht interessiert - "es muss nur funktionieren". Also sollte ich auf 
meine Spezial-Konfigurationen verzichten. Entscheidend ist, was 
zuverlässiger funktioniert.

Aber erzählt doch mal etwas von praktischen Erfahrungen mit Devuan...

von Sheeva P. (sheevaplug)


Bewertung
4 lesenswert
nicht lesenswert
Hmmm schrieb:
> Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine
> Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand
> systemd.

Auch wenn ich als alter SunOS-Entwickler dabei ein bisschen Wehmut 
empfinde, komme ich trotzdem nicht um die Erkenntnis herum, daß es im 
UNIXoiden Umfeld außerhalb der "Pinguinwelt" mittlerweile gar nicht mehr 
so viel gibt.

Tatsächlich ist systemd aber in vielerlei Hinsicht viel besser als sein 
Ruf, aber letztens habe ich einen sehr zutreffenden Satz gelesen: "Nerds 
have a complicated relationship to change; it's awesome when we are the 
ones creating the change, but it's untrustworthy when it comes from 
outside".

Außerdem ist es ebenfalls eine Tatsache, daß das alte SysV-Init schon 
seit geraumer Zeit... ziemlich in die Jahre gekommen war. Auf modernen 
SMP-Systemen nicht parallel booten zu können, war ein Punkt, und wenn 
man Abhängigkeiten zwischen verschiedenen Diensten berücksichtigen mußte 
-- zum Beispiel: starte den Webserver erst, wenn die Datenbank 
hochgefahren und initialisiert wurde -- war mit SysV-Init oft ein fieser 
Krampf. Und -- ich kann da natürlich nur für mich sprechen -- ich fand 
es ärgerlich und nervig, für die Distributionsfamilien X und Y jeweils 
Init-Skripte schreiben, testen, ausliefern und pflegen zu müssen.

Eine Folge der zunehmenden Schwierigkeiten mit SysV-Init war, daß dann 
verschiedene Distributoren angefangen haben, wieder jeweils eigene 
Süppchen zu kochen. Sun hat, wie so oft in einer Vorreiterrolle, schon 
2004 mit der Service Management Facility (SMF) begonnen, sich von 
SysV-Init abzuwenden, und auch im Linux-Umfeld kam dann Bewegung in die 
Sache -- seien es Exoten wie Void und Artix Linux, die auf runit gesetzt 
haben, oder auch Canonical mit seiner Eigenentwicklung Upstart, Apple 
mit SystemStarter und später launchd oder Gentoo mit OpenRC. Sogar das 
hier so gelobte Devuan benutzt meines Wissens gar kein reines SysV-Init 
mehr, sondern OpenRC. Und die BSDs hatten noch nie ein SysV-Init, 
nebenbei bemerkt...

Jetzt auf einmal zu behaupten, die bööösen systemd-Leute hätten auf 
einmal (und, natürlich, aus unbekannten, aber zweifellos sinistren 
Gründen) die ganze schöne Harmonie und Einheitlichkeit im UNIX-Umfeld 
kaputtgemacht, ist also ganz offensichtlich entweder inkompetenter 
Unsinn oder üble Nachrede, jedenfalls aber falsch. De facto hat systemd 
mehr für die Vereinheitlichung zumindest der größten (verbreitetsten) 
Linux-Distributionen gebracht als die meisten anderen bekannten 
Standardisierungsbemühungen, als Beispiele seien nur FHS und LSB 
genannt.

Und wer nun -- aus welchen Gründen auch immer -- nun trotzdem kein 
systemd haben will, der kann ja auf etwas anderes ausweichen. Aber immer 
diese Seitenhiebe und Falschbehauptungen sind doch nur kindischer Trotz. 
systemd funktioniert ziemlich reibungslos (ja, das war anfangs nicht 
immer so, aber Kinderkrankheiten gehören bedauerlicherweise nun einmal 
dazu), alle großen und vor allem kommerziellen Distributoren haben sich 
aus guten Gründen dafür entschieden, und irgendwelche Meckerer in einem 
Mikrocontroller-Forum werden sie nicht mehr davon abbringen.

systemd ist die Realität, und es wird die Realität bleiben. Findet Euch 
damit ab, geht im Garten ein paar Scheite Holz hacken oder fahrt 
meinetwesen nach China und schubst ein paar Säcke Reis um. ;-)

von 🐧 DPA 🐧 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Ich werde die Systemd fanatiker mal ignorieren – immerhin hatten wir da 
woanders schon differenzierte Diskussionen spezifisch zu der Thematik – 
und mal versuchen, zum Thema zurückzukommen.


Also, nun zu Devuan. Ich verwende es momentan auf all meinen Geräten - 
auf meinem Surface Pro 3, auf meinem Server, in meinen zahlreichen 
libvirt-lxc Containern (die ich statt VMs verwende), auf meinem RPI3 
basierten Backup Server, ja sogar auf meinem Librem 5 Smartphone. Auch 
Netzwerkboot per PXE hab ich mir eingerichtet, geht alles einwandfrei.

Ich bin soweit sehr zufrieden damit. Ich verwende es schon seit einigen 
Jahren, und hatte noch nie ernsthafte Probleme damit. Mein Server und 
meine >10 libvirt-lxc Container darauf updaten täglich automatisch mit 
cron-apt, und ich erinnere mich nicht daran, das da je etwas schief 
gelaufen wäre.

Zur Installation kann ich nicht viel sagen, ich bootstrappe meine 
Systeme immer manuell. Ich denke diese sollte aber problemlos laufen.

Zu initrd/initramfs, ich hatte Zeitweise schon Systeme, die ich ohne 
verwende. Es geht, aber ich bevorzuge es, ein initramfs zu haben. Einer 
der Hauptgründe ist, dass wenn z.B. das Dateisystem mal beschädigt ist, 
und man fsck laufen lassen muss, ist es unpraktisch, wenn fsck auf der 
Partition drauf ist, die man fsckn will. Und auf meinem Smartphone hab 
ich ein Keyboard für die linux console, das ich erstellt habe, mit rein 
gepackt, so dass ich z.B. das Passwort für ein verschlüsseltes root 
eingeben kann, oder sonstige boot Probleme beheben könnte, falls mal 
welche auftreten. Bei Servern mit verschlüsseltem rootfs packen dort 
manche einen ssh Server rein, damit sie das Passwort remote eingeben 
können. Also für all solches early-boot zeug ist es schon praktisch. 
Probleme damit hatte ich auch noch nie. Falls bei nem kernel update was 
schief ginge, kann  ich ja einfach den letzten Kernel auswählen. Wäre 
doch ein mal was mit allen initramfs kaputt, kann ich z.B. in grub 
immernoch einfach die entsprechende Zeile rauslöschen, und ohne booten. 
Das dürfte in Debian eigentlich alles genauso sein.

Zum init system in devuan, sysvinit und openrc sind offiziell supportet, 
und können glaube ich bei der Installation beim regulären Installer 
sogar direkt ausgewählt werden. Nachträgliches ändern ist aber auch 
möglich. runit als init soll anscheinend auch machbar sein, ausprobiert 
hab ich es aber noch nicht.

Zum Verhältnis zwischen Debian und Devuan. Devuan versucht, einen 
Reibungslosen systemd-freien Betrieb der selben Software, die auch in 
Debian existiert, zu gewährleisten. Dabei wird versucht, so nahe wie 
irgendwie möglich an Debian zu bleiben. Ein paar Packete werden 
exkludiert (https://pkgmaster.devuan.org/bannedpackages.txt). Ein paar 
Devuan spezifische als für den reibungslosen Betrieb zur Verfügung 
gestellt. Man läuft also kaum Gefahr, sich versehentlich per dependency 
Systemd einzufangen, oder mit einem kaputten System aufzuwachen.
Die restlichen, guten Packete werden direkt von Debian geholt. Hin und 
her wechseln sollte eigentlich problemlos gehen, mischen sollte man die 
Repos aber nicht. Auch zukünftig wird das voraussichtlich so bleiben.
Zudem versucht Devuan, soweit möglich, mit Debian zusammenzuarbeiten. 
Das beinhaltet, soweit möglich, hilfe bei der Maintance von in sysvinit 
upstream, upstreamen von änderungen soweit möglich, und die Intergration 
von Packeten wie z.B. elogind als ersatz für libsystemd & logind.

Es ist noch zu beachten, dass devuan nur sehr wenige Entwickler & 
Maintainer hat, vielleicht ein Dutzend oder so. Das schränkt deren 
Möglichkeiten etwas ein. Um die Belastung der Entwickler zu reduzieren, 
sollten z.B. Bugs für Packete, die z.B. Direkt von Debian und nicht von 
Devuan kommen, in der regel zuerst bei Debain gemeldet werden, da dort 
bei verwendung von sysvinit die selben Probleme zu erwarten sind, und 
erst, wenn dort nichts gemacht wird, wird diskutiert, ob es geforkt 
werden muss.

In vielen Aspekten ist Devuan eher ein Pflaster als eine Lösung für die 
durch systemd verursachten Probleme. elogind z.B. ist glaub ich 
eigentlich ein Fork von Systemd, aber mit dem eigentlichen systemd teil 
usw. entfernt. Um alle Packete die Systemd voraussetzen zu Forken sind 
schlicht nicht genug Ressourcen vorhanden, und viele APIs von Systemd 
lassen sich Architekturbedingt nicht einzeln zur run-time ersetzen, 
deshalb müssen leider solche Kompromisse gemacht werden. Aber es 
verschafft immerhin etwas zeit, um mit neuen Strategien den totalen 
systemd-lockin abzuwenden, aufkommen zu können.

In sehr seltenen fällen gibt es bei neueren Paketen manchmal welche, die 
noch kein init script haben. In bilden sich Debian Maintainer auch mal 
ein, sie müssten aus unerfindlichen gründen das Initscript entfernen. 
Wie gegen diese Debian seitige Sabotage am besten vorgegangen wird, ist 
momentan noch in diskussion. In der regel ist es aber einfach, mit z.B. 
init-d-script 
(https://manpages.debian.org/stretch/sysvinit-utils/init-d-script.5.en.html) 
ein kleines simples initscript zu erstellen.

Bei externen Repos / Packeten ist es etwas Wahrscheinlicher, dass mal 
eines nur Systemd units anbietet. Es kann auch sein, pre- / post- 
install Scripte bei derartigen Paketen stark systemd spezifisch sind, 
auch wenn die Software ansonsten auf Devuan funktionieren würde. Es 
kommt zwar recht selten vor, nodejs, tor, etc. gehen problemlos, aber 
externe Repos sind halt bei jeder Distro immer eine Glückssache, und 
sollten sowieso vermieden werden.

Bei Firmen und Projekten gibt es gibt wohl auch vereinzelte (z.B. 
devuanhosting.com), die Devuan einsetzen. Die meisten Firmen 
interessieren sich aber nur für die Grossen und bekannten Distros. Die 
kleinen Distributionen werden von Firmen und Projekten meistens in 
Situationen eingesetzt, wo die grossen Distributionen nicht sinnvoll, 
oder Systemd problematisch oder gar nicht verwendbar, sind.

Bei Problemen gibt es eine aktive Community. IRC und die Mailingliste 
kann ich sehr empfehlen. Es gibt auch ein unabhängiges Forum 
dev1galaxy.org, das relativ aktiv zu sein scheint.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:

den besten Beitrag den ich je in diesem Forum lesen durfte

> Also, nun zu Devuan. Ich verwende es momentan auf all meinen Geräten -
> auf meinem Surface Pro 3, auf meinem Server, in meinen zahlreichen
> libvirt-lxc Containern (die ich statt VMs verwende), auf meinem RPI3
> basierten Backup Server, ja sogar auf meinem Librem 5 Smartphone. Auch
> Netzwerkboot per PXE hab ich mir eingerichtet, geht alles einwandfrei.
o.k., das geht als praktische Erfahrung durch

> Zur Installation kann ich nicht viel sagen, ich bootstrappe meine
> Systeme immer manuell. Ich denke diese sollte aber problemlos laufen.
Eine Installation mit dem netinstall.iso und eine per netboot liefen mit 
priority=low problemlos. Praktisch genau wie Debian, auch die 
grub-Installation hat erst beim 2. Versuch geklappt ;)

> Zu initrd/initramfs, ich hatte Zeitweise schon Systeme, die ich ohne
> verwende. Es geht, aber ich bevorzuge es, ein initramfs zu haben.
Es ging mal drum, beim booten jede Millisekunde zu sparen, da war die 
initrd natürlich das erste Opfer. Und bis heute war es reine Gewohnheit.

> Also für all solches early-boot zeug ist es schon praktisch.
Einverstanden.

> Zum init system in devuan, sysvinit und openrc sind offiziell supportet,
> und können glaube ich bei der Installation beim regulären Installer
> sogar direkt ausgewählt werden.
Das geht, sysvinit ist (noch?) Default.

> Nachträgliches ändern ist aber auch möglich.
Sogar mit aptitude ;)

> Man läuft also kaum Gefahr, sich versehentlich per dependency
> Systemd einzufangen.

Das ist für mich das entscheidende Argument, weil man auch Debian 
absolut problemlos mit sysvinit betreiben kann -- solange man bei der 
nachträglichen Installation von einzelnen Paketen genau aufpasst. 
Deshalb fällt mir die Entscheidung Devuan/Debian auch nicht so leicht.

> elogind z.B. ist glaub ich eigentlich ein Fork von Systemd, aber
> mit dem eigentlichen systemd teil usw. entfernt. Um alle Packete
> die Systemd voraussetzen zu Forken sind schlicht nicht genug
> Ressourcen vorhanden

Das ist ja auch nicht so wichtig, es gibt doch fast immer Alternativen, 
bis jetzt hab' ich noch nichts vermisst, auch policykit nicht. Deshalb 
werde ich vermutlich auch elogind nicht brauchen. Die beiden werden 
scheinbar nur für wenige, ziemlich spezielle Funktionen gebraucht.

> Bei externen Repos / Packeten ist es etwas Wahrscheinlicher, dass mal
> eines nur Systemd units anbietet. Es kann auch sein, pre- / post-
> install Scripte bei derartigen Paketen stark systemd spezifisch sind
Egal, traue keinem Script, dass du nicht selber gefälscht hast ;)

> Bei Problemen gibt es eine aktive Community. IRC und die Mailingliste
> kann ich sehr empfehlen. Es gibt auch ein unabhängiges Forum
> dev1galaxy.org, das relativ aktiv zu sein scheint.

Danke!

von Marcus H. (mharnisch) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Bei /, /opt und /usr ist das nur unnötige Arbeit, reduzierte
> Flexibilität und bringt keinen Vorteil. Erst recht, wenn sich der Kram
> untenrum auf dem gleichen Medium wieder einfindet, nicht auf getrennten
> HDDs.

So ist es. Man hat dann eine “volle” Platte mit /n/-1 halbleeren 
Partitionen und einer bei der es knapp wird. Dann beginnt das große 
Verschieben und Verändern.

Vor längerer Zeit bin ich daher auf Desktop und Laptop dazu übergegangen 
eine einzige BTRFS Partition (plus EFI) und ggf. mehrere Subvolumes (@, 
@home) einzurichten. Dazu kommen noch etliche weitere Subvolumes für 
tägliche, wöchentliche und monatliche Snapshots (timeshift). Partitionen 
haben sich spätestens mit GPT irgendwie überlebt.

Beitrag #6360090 wurde vom Autor gelöscht.
von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Club der toten Pferde schrieb:
> Aber ach: Was soll ich sagen? Als dann mal
> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue
> Befehlsstruktur mit allem drum und dran. Ekelhaft. Abstoßend. Alles in
> einen Monolithen gekloppt, ganz in systemd Manier. Durch die Manpage zu
> steigen ist eine Kunst. Da braucht man schon das Internet um selbigem
> Rechner das Interface zu konfigurieren.

Das Problem sitzt hier eher vor dem Bildschirm.

Zum konfigurieren des Netzwerks verwendet man das nmcli Tool, also das 
Network Manager Command Line Interface. Damit ist das auch extrem 
einfach.
Sogar vlan lassen sich damit kinderleicht konfigurieren und aufbauen.

Der ip Befehl, der ipconfig ersetzt, konfiguriert den Kernel direkt und 
daher ist das auch etwas komplexer und weniger abstrahiert.
Wenn man kein Masochist ist, lässt man das bleiben und nutzt den 
bequemeren nmcli oder gleich eine GUI für den NM.

Der ip Befehlt bietet sich für den Nutzer allerdings an, um lediglich 
die IP Adressen und Mac Adressen anzuzeigen (mit "ip a"). ipconfig 
dürften die meisten früher auch nicht anders genutzt haben.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Netplan.YAML schrieb:
> Jack V. schrieb:
>> Was
>> genau hat dich daran nun abgestoßen und das Ekelgefühl erzeugt?
>
> "ifconfig" ist nicht mehr als default installiert!
>
> man muss bei einem neu aufgesetztem System sofort ekelhafte Kommandos
> wie
>>> apt install net-tools
> eintippen, und damit seine Tastatur besudeln.

Nein, muss man nicht.
Man nimmt dafür einfach den nmcli und dieses Tool ist bei jedem modernen 
Debian ein vorinstalliertes Standardtool.

von Nano (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Bei meinen Rechnern mache ich gerne solche Sachen und natürlich würde
> ich Devuan ohne initrd betreiben, kein Problem. Aber jetzt muss ich
> einen Rechner installieren, bei dem jemand root wird, der sich dafür
> nicht interessiert - "es muss nur funktionieren". Also sollte ich auf
> meine Spezial-Konfigurationen verzichten. Entscheidend ist, was
> zuverlässiger funktioniert.

Dann nimm Debian wie es vanilla unverändert daherkommt.
Das hat von den Debiansystemen die breiteste Nutzerbasis und er kriegt 
dafür auch am ehesten Support.

Devuan würde ich dafür ganz gewiss nicht verwenden. Devuan will kein 
systemd und will somit am ewig Gestrigen festhalten, das kann allerdings 
nur solange funktionieren, solange es dafür auch genug Leute gibt, die 
das pflegen.
Tja und die alten Hasen sterben aus und die jungen lernen Debian mit 
systemd kennen. Also ist klar wo das am Ende hinführt.

Solange er keine triftigen Gründe gegen systemd hat, ist Debian so wie 
es offiziell geliefert wird, die sinnvollste Variante und wenn er 
ohnehin Anfänger ist, dann wird er auch sowieso keine triftigen Gründe 
gegen systemd haben und diese argumentativ verteidigen können.
Und könnte er das, dann bräuchte er nicht deine Hilfe.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> dieses Tool ist bei jedem modernen
> Debian ein vorinstalliertes Standardtool.

Nein, ist es nicht. Und wenn’s das irgendwann mal sein sollte, lösche 
ich die restlichen Debiansysteme, und mache mir Devuan oder so drauf.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Bauform B. schrieb:
>> Aber jetzt muss ich einen Rechner installieren, bei dem jemand
>> root wird, der sich dafür nicht interessiert - "es muss nur
>> funktionieren".
>
> Dann nimm Debian wie es vanilla unverändert daherkommt.

Recht hast du, vernünftig wäre das. Aber das kann ich nicht bzw. das 
würde viel zu lange dauern.

> Devuan will kein systemd und will somit am ewig Gestrigen festhalten,
> das kann allerdings nur solange funktionieren, solange es dafür auch
> genug Leute gibt, die das pflegen.
> Tja und die alten Hasen sterben aus und die jungen lernen Debian mit
> systemd kennen. Also ist klar wo das am Ende hinführt.

Für meine Alternative, Debian mit sysvinit, gilt ja das gleiche. Die 
Frage ist, was wohl länger unterstützt wird. Im Prinzip ist mir das 
sogar egal, ich hatte deshalb schon ein Debian mit meinem eigenen 
init-"System" laufen. Aber momentan sehe ich schwarz.

Die dritte Alternative: Windows, kombiniert mit einem uC für den Teil, 
der mit Windows nicht so einfach geht. Die Leiterplatten sind bestellt 
und Windows kann ja jeder...

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Ich werde die Systemd fanatiker mal ignorieren

Wer nicht Deiner Meinung ist, ist also ein Fanatiker. Wenn jemand anders 
so etwas schriebe, würde ich lachen. Aber bei Dir nicht.

Solche "Argumentationen" kenne ich nur von Fanatikern, die es sich 
dadurch einfach machen, andere Meinungen einfach zu ignorieren, statt 
sich damit auseinandersetzen. Denn "Fanatiker aller Couleur kennen keine 
Ambivalenzen, keinen Kompromiss und keinen Dialog. Sie würden dies als 
Verrat an ihrer heiligen Sache verurteilen." (Ernst-Dieter Lantermann)

Es ist und bleibt aber eine Tatsache, daß ausnahmslos alle großen 
Distributoren trotz aller -- mal mehr und mal weniger -- berechtigten 
Kritikpunkte zu systemd gewechselt sind. Diese Entscheidungen waren 
meistens Mehrheitsentscheidungen von Menschen, die zum Teil deutlich 
mehr Erfahrung haben und von denen viele sehr viel mehr Maschinen 
betreiben als wir beide zusammen -- oft auch für andere wie ihren 
Arbeitgeber oder gar für diese widerspenstigen Besserwisser, genannt 
Kunden.

Ich für meinen Teil kann nur sagen, daß ich schon mehr als genug Arbeit 
habe und aus diesem Grunde alles begrüße, was mir etwas davon abnimmt 
oder sie erleichtert. Nach einigen Jahren Erfahrung damit kann ich 
sagen: das tut systemd, auch wenn ich -- wie Du weißt -- auch selbst 
einige Kritikpunkte daran habe. Aber ich habe -- und wie mir scheint, im 
Gegensatz zu Dir -- keinerlei emotionale Bindung an ein Init-System, und 
im Laufe der letzten dreißig Jahre auch schon mit verschiedenen davon 
gearbeitet. Es gab dabei allerdings keines, an dem ich keine 
Kritikpunkte gefunden hätte, und ich würde niemals auf die Idee kommen, 
mein Betriebssystem oder dessen Distribution von der Frage abhängig zu 
machen, welches Init-System darin benutzt wird.

Und hey, wenn morgen ein neues Init-System kommt, das genausogut 
funktioniert, sich genauso weit verbreitet und mir noch mehr Arbeit 
abnimmt als systemd: dann werde ich das nutzen und mich darüber freuen, 
interessantere Dinge tun zu können. Solch eine Einstellung ist nicht 
fanatisch, sondern einfach nur pragmatisch.

Sei mir bitte nicht böse, lieber Daniel, Du weißt, ich mag Dich und 
halte Dich für einen klugen, talentierten, kompetenten und netten 
Menschen. Darum mache ich mir langsam ernsthafte Sorgen um Dich, weil Du 
Dich nach meiner Wahrnehmung immer mehr in eine Wagenburgmentalität 
zurückzuziehen scheinst. Du opponierst momentan gegen alle aktuellen 
Strömungen in der Linux- und IT-Welt, egal ob es Python, Docker oder 
systemd ist. Deswegen mache ich mir ernsthaft Sorgen um Dich, sowohl 
menschlich als auch fachlich: menschlich, weil Dir früher niemals so 
eine Entgleisung wie dieser dumme Fanatiker-Spruch herausgerutscht wäre, 
und fachlich, weil Du Dich selbst von der Weiterentwicklung abhängst, 
Deine Energie auf Schlachten vergeudest, die längst geschlagen sind und 
die Du niemals gewinnen kannst, und weil ich das, was Du grade machst, 
als sinn-, zweck- und nutzlose Verschwendung Deines großen Talents sehe.

Ich bin niemand, der jemandem wegen einiger launischer Beiträge in einem 
Forum plötzlich seine Hochachtung oder seine Sympathien entzieht, 
schließlich haben wir alle mal bessere, mal schlechtere Tage, und auch 
immer mal wieder unsere eigenen psychotischen Zustände, das ist völlig 
normal und menschlich. Aber was ich von Dir in letzter Zeit lese, macht 
mir Angst. Natürlich, nur tote Fische schwimmen immer mit dem Strom. 
Aber wer immer gegen jeden Strom kämpft, endet irgendwann wie der Lachs 
nach dem Ablaichen: erst läuft er puterrot an, und dann stirbt er.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
Nano schrieb:
> Club der toten Pferde schrieb:
>> Als dann mal
>> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue
>> Befehlsstruktur mit allem drum und dran.
>
> Das Problem sitzt hier eher vor dem Bildschirm.

Unbedingt!

> Zum konfigurieren des Netzwerks verwendet man das nmcli Tool

Oder halt ip(8).

> Der ip Befehl, der ipconfig ersetzt, konfiguriert den Kernel direkt und
> daher ist das auch etwas komplexer und weniger abstrahiert.

Der IP-Befehl hat zudem und vor Allem den großen Vorteil, daß sich seine 
Ausgabe(n) deutlich einfacher maschinell parsen und weiterverarbeiten 
lassen -- und daß diese neuen Befehle neue Funktionen des 
Betriebssystemkernels zugänglich machen, die es früher noch nicht 
gegeben hat.

Leuten die nur ihren Desktop und vielleicht einige kleine kleine Server 
manuell zu betreuen haben, kann das natürlich gleichgültig sein. Aber 
wer ernsthaftes (und in der Regel automatisiertes) Computing in 
Netzwerken jenseits dieser "Größe" machen will oder muß, für den sind 
die neuen Funktionen und die Werkeuge, die die neuen Funktionen 
zugänglich machen, ein Gewinn.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Nano schrieb:
>> Bauform B. schrieb:
>>> Aber jetzt muss ich einen Rechner installieren, bei dem jemand
>>> root wird, der sich dafür nicht interessiert - "es muss nur
>>> funktionieren".
>>
>> Dann nimm Debian wie es vanilla unverändert daherkommt.
>
> Recht hast du, vernünftig wäre das. Aber das kann ich nicht bzw. das
> würde viel zu lange dauern.

Entschuldige, aber das ist ja Unsinn. Du bootest vom 
Installationsmedium, dann setzt Du ein Huhn vor die Tastatur, und legst 
in periodischen Abständen ein Weizenkorn auf die Return-Taste. Bisschen 
warten, fertig. Danach nochmal tasksel(8) und eventuell einige Male 
apt(8) oder, für Traditionalisten, apt-get(8) aufrufen, und schon hast 
Du ein System auf der Platte, das zu allen verfügbaren, seriösen 
Dokumentationen und zu allen Best Practices kompatibel ist, ohne nach 
jeder Installation größere Nacharbeit leisten zu müssen. Ach, es könnte 
alles so einfach sein... ;-)

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Du bootest vom Installationsmedium, dann setzt Du ein Huhn vor
> die Tastatur (...) und schon hast Du ein System auf der Platte

Die klassische Debian-Installation. Kenne ich. Funktioniert nach einem 
"apt install sysvinit-core" einwandfrei. Mit Devuan spart man diesen 
Schritt. Das sind die beiden Möglichkeiten.

Meine Frage war, welche die bessere ist. Die Antwort ist offenbar 
"keine", mein Plan ist nicht realisierbar. Ein System, das "zu allen 
Best Practices kompatibel ist", kommt wegen unkalkulierbarem Risiko 
nicht in Frage.
Dankeschön.

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Sheeva P. schrieb:
>> Du bootest vom Installationsmedium, dann setzt Du ein Huhn vor
>> die Tastatur (...) und schon hast Du ein System auf der Platte
>
> Die klassische Debian-Installation. Kenne ich. Funktioniert nach einem
> "apt install sysvinit-core" einwandfrei.

Nein. Mit GNOME wirst Du damit vermutlich Probleme bekommen, weil einige 
Komponenten nun einmal von systemd abhängen sollen.

> Mit Devuan spart man diesen
> Schritt. Das sind die beiden Möglichkeiten.
>
> Meine Frage war, welche die bessere ist. Die Antwort ist offenbar
> "keine", mein Plan ist nicht realisierbar. Ein System, das "zu allen
> Best Practices kompatibel ist", kommt wegen unkalkulierbarem Risiko
> nicht in Frage.

"Unkalkulierbares Risiko"... So ein Unsinn. Du bastelst manuell an 
Deinem System herum, und kreierst Deine eigene Abart davon, ohne Initrd 
und Systemd und... hälst Deine Ergebnisse für stabiler und 
kalkulierbarer als Software, die auf Millionen von Rechnern installiert 
und getestet wird?

Na klar. Und die Erde ist eine Scheibe.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Mit GNOME wirst Du damit vermutlich Probleme bekommen, weil einige
> Komponenten nun einmal von systemd abhängen sollen.

Diese Komponenten lassen sich nicht installieren, also machen sie auch 
keine Probleme. Genau hier kommt Devuan ins Spiel, da werden diese 
garnicht angeboten, bei Debian muss man aufpassen. Man kann nicht alles 
haben, vor allem nicht alles gleichzeitig. Manche Windows-Programme 
lassen sich auch nicht installieren, na und?

> "Unkalkulierbares Risiko"... So ein Unsinn.

Kein Unsinn, praktische Erfahrung. Man könnte es anders formulieren, 
vielleicht: "ich kann den Arbeitsaufwand, bis es funktioniert, nicht 
abschätzen". Zum Beispiel haben die meisten PCs 2 oder 3 
Netzwerk-Interfaces. Ich brauche aber genau 1, aber mit mehreren 
Adressen. Zum Beispiel habe ich mich an eine eigene Keymap gewöhnt... 
Von DNS und NTP liest man auch Schauergeschichten. Und das sind nur 
Beispiele, die mir jetzt schon einfallen. Spannender sind ja die 
Probleme, von denen ich jetzt noch nichts ahne.

> Du bastelst manuell an Deinem System herum

Naja, das wollte ich ja bei der nächsten Installation vermeiden, genau 
darum geht's hier eigentlich.

> hälst Deine Ergebnisse für stabiler und kalkulierbarer als Software,
> die auf Millionen von Rechnern installiert und getestet wird?

langzeitstabiler vielleicht nicht, kalkulierbarer auf jeden Fall. Schon 
alleine, weil weniger Features im Spiel sind.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Zum Beispiel haben die meisten PCs 2 oder 3
> Netzwerk-Interfaces. Ich brauche aber genau 1, aber mit mehreren
> Adressen. Zum Beispiel habe ich mich an eine eigene Keymap gewöhnt...
> Von DNS und NTP liest man auch Schauergeschichten.

Und inwiefern sind das nun Argumente für oder gegen ein initramfs?

Netzwerkinterfaces habe ich genau so konfiguriert, eigene Keymap (Neo) 
ist gar schon beim Eintippen der Passphrase der verschlüsselten 
Systempartition aktiv und von da aus durchgängig, und weder mit DNS, 
noch mit NTP habe ich irgendwelche Probleme. Und das auf modernen 
Systemen mit initramfs und systemd.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Und inwiefern sind das nun Argumente für oder gegen ein initramfs?

Meine Frage ist eigentlich "kann man Devuan empfehlen", "initrd" ist nur 
ein Aufhänger. Es ist aber ein interessantes Detail, inwieweit sich 
Devuan und Debian unterscheiden. Mir scheint, der Trend geht dahin, dass 
etwas wie initramfs zwingend nötig sein soll, genau wie manch andere 
Neuerungen.

> weder mit DNS, noch mit NTP habe ich irgendwelche Probleme.

Schön für dich, aber auch wenn 99.9% der Benutzer keine Probleme haben, 
hilft mir das garnichts. Mehrere Leute hatten Probleme. Es waren 
genug, dass es in der Zeitung stand und mir deshalb aufgefallen ist.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Meine Frage ist eigentlich "kann man Devuan empfehlen", "initrd" ist nur
> ein Aufhänger. Es ist aber ein interessantes Detail, inwieweit sich
> Devuan und Debian unterscheiden. Mir scheint, der Trend geht dahin, dass
> etwas wie initramfs zwingend nötig sein soll, genau wie manch andere
> Neuerungen.

Wenn du mit den Einschränkungen leben kannst, spricht zumindest nix 
gegen Devuan.

Ein initramfs hast du trotzdem, wenn du nicht verhältnismäßig tief ins 
System eingreifst (in Form von selbstgebautem Kernel, um die zum Booten 
benötigten Sachen drin zu haben).

Der Trend geht zum initramfs (bzw.: ist gegangen zu, vor vielen, vielen 
Jahren schon – Ausnahme ist der Embedded-Bereich), weil das nunmal 
einfach praktisch ist, und zudem die Folgen von Fehlern abfangen kann. 
Außerdem sind einige Sachen gar nicht ohne das möglich, siehe 
verschlüsselte Systempartition und Ähnliche.

Bauform B. schrieb:
> Schön für dich, aber auch wenn 99.9% der Benutzer keine Probleme haben,
> hilft mir das garnichts. Mehrere Leute hatten Probleme.

99,9% der Leute verdrehen sich beim Aufstehen aus dem Bett heraus nicht 
den Fuß. Hilft dir wahrscheinlich gar nichts, weil es mehreren Leuten 
passiert ist. Du solltest liegenbleiben. [scnr]

von 🐧 DPA 🐧 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Ich werde die Systemd fanatiker mal ignorieren
>
> Wer nicht Deiner Meinung ist, ist also ein Fanatiker. Wenn jemand anders
> so etwas schriebe, würde ich lachen. Aber bei Dir nicht.
>
> Solche "Argumentationen" kenne ich nur von Fanatikern, die es sich
> dadurch einfach machen, andere Meinungen einfach zu ignorieren, statt
> sich damit auseinandersetzen.

Klar, das Wort zu verwenden war etwas krass. Duden Definiert einen 
Fanatiker als:
> jemand, der von bestimmten Ideen, einer bestimmten Weltanschauung o. Ä. so
> überzeugt ist, dass er sich leidenschaftlich, mit blindem Eifer [und
> rücksichtslos] dafür einsetzt

Also warum habe ich die Systemd Diskussion diesmal ignoriert, und warum 
hab ich dieses Wort gewählt?

Nun, der TO schien die Systemd Diskussion vermeiden zu wollen. Soweit 
ich das sehe wollte er nur wissen, ob Devuan sorgenfrei und einfach zu 
verwenden ist, oder ein Identisches Setup mit Debian weniger 
problematisch ist.

Aber was machen die anderen hier? Ihr seht, jemand schreibt Devuan -> oh 
nein, das war das ohne Systemd, schnell Systemd empfehlen und sysvinit 
schlecht reden! Nun, wie würdet ihr das bezeichnen?

Aber warum habe ich die Diskussion ignoriert, und keine Gegenargumente 
gebracht?

Kurzgesagt, weil es sinnlos gewesen wäre. Fürs erste hab ich das im 
Forum schon mal durchgekaut. Zum anderen macht es auch sonst keinen 
Unterschied. Es würde eure Position nicht verändern, es würde meine 
nicht verändern, es würde wohl auch dem TO nicht weiterhelfen. Ausserdem 
habe ich schlicht die Zeit und Energie nicht mehr, mich auf solche 
Diskussionen einzulassen.
Also warum sollte ich die Diskussion anfangen?

Sheeva P. schrieb:
> Du opponierst momentan gegen alle aktuellen
> Strömungen in der Linux- und IT-Welt, egal ob es Python, Docker oder
> systemd ist.

Gegen Python und Docker habe ich eigentlich nichts. Es mögen nicht meine 
Favoriten sein, aber das heisst nicht, dass ich diese schlecht finde 
oder nicht verwenden würde, wenn es sinnvoll ist. Ich habe durchaus 
Projekte, in denen ich diese verwende. So würde ich z.B. meinen eigenen 
ACME2 client (https://github.com/Daniel-Abrecht/DPA-ACME2) definitiv 
nicht in c oder bash schreiben wollen.

Auch mit Systemd kann ich gut umgehen. Auf der Arbeit betreue ich solche 
Systeme auch. Aber Privat werde ich es nicht nutzen, das ist etwas 
anderes, als ein simples nicht gerne haben. Natürlich beobachte ich 
trotzdem genau, welche Neuerungen es bei Systemd gibt, denn diese 
betreffen jene, die systemd vermeiden wollen, viel mehr, als jene, die 
es verwenden.

Aber wisst ihr, es gibt einige simple Prinzipien und Ideale, an die ich 
mich so gut es geht halte:
 1) Ich Trinke und Rauche nicht
 2) Ich versuche jegliche lock-in Möglichkeit zu vermeiden, wenn dies 
möglich ist und Ich betrachte alles zuerst aus der Perspektive "wer 
kontrolliert was, und was für Konsequenzen kann das haben"
 3) Ich bin für möglichst vielfältige & möglichst uneingeschränkte 
persönliche Freiheiten, sowie für die Optimierung des Wohlstandes aller 
natürlicher Personen (wobei Kapitalismus eine brauchbare Methode dafür 
ist). Das heist aber auch, das ich dagegen bin, diese durch Firmen und 
Technologien automatisiert einschränken zu lassen.

Klar, Ideale zu haben, das bringt auch Opfer mit sich. Ich habe keine 
Ahnung, wie Wein oder Bier schmeckt. Ich habe meinen Google Account 
geschlossen, und nutze keine Google Services mehr. Ich nutze kein 
Systemd. Ich bin dabei, mein Android Smartphone durch ein reines Linux 
Smartphone zu ersetzen. Und Google, Facebook, etc. haben keine Ahnung, 
was meine Interessen sind, wie ich aussehe, ja nicht einmal welche 
Sprachen ich Spreche.

Klar, die Dinge wären Komfortabel. Aber wisst ihr, darauf zu verzichten, 
das ist es mir wert. Ich kenne die Alternativen, ich weiss wie alles 
unter der Haube funktioniert, ich kenne den Preis, den man für die 
Verwendung diversen Sachen da draussen zahlt, und ich weiss, welche 
Zukunft ich anstrebe!

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> und ich weiss, welche
> Zukunft ich anstrebe!

World domination

von Andreas M. (amesser)


Bewertung
2 lesenswert
nicht lesenswert
Es wurde ja schon einiges zum Thema geschrieben, vielleicht kann ich als 
Devuan Nutzer auch noch was dazu beitragen.

Ich nutze seit Jahren Devuan auf all meinen Systemen hier: NAS, 
Workstation, Wohnzimmer PC, Notebook. Und ich darf mich auch gleich als 
einer der ewig gestrigen outen, ich bin nämlich einer der wenigen Devuan 
Maintainer....

Nun, der Grund für Devuan ist auch bei mir - wie sollte es anders sein - 
systemd, bzw. das man Debian nur noch anständig mit systemd verwenden 
kann. Ja, auch auf Debian kann man immer noch ein SysV benutzen, 
allerdings gibt es viele Stolpersteine, z.B. das o.g. Gnome.

Nun ist es nicht so, dass ich systemd grundsätzlich schlecht finde. 
Gerade am Anfang als er noch frisch war, (damals war ich noch auf 
ArchLinux) war ich davon geradezu begeistert. Der Bootvorgang war eine 
Erfrischung. Ab und an mal gab es irgendwelche Dependency-Loops, aber 
gut, war ja alles noch neu. Mit der Zeit habe ich jedoch einige 
Erfahrungen gemacht, später auch mit Debian/systemd, die mich haben 
umdenken lassen:

Nach Aktualisierungen von systemd ist es regelmäßig dazu gekommen, das 
ich das system per "systemctl reboot/poweroff" oder auch per 
Logout-Dialog im Grafikmodus nicht mehr einfach so neu starten oder 
herunterfahren konnte. (Irgendwas mit Filedescriptor, erinnere mich 
nicht mehr) Das einzige was noch ging war es, dass Herunterfahren per 
Powerknopf auszulösen. Nach dem nächsten Start ging dann wieder alles.

Weiter ging es dann, dass zwei mal nach Updates das System nicht mehr 
gebootet hat (allerdings beim ArchLinux) weil irgendeine Lib vom Systemd 
nicht sauber installiert wurde und sich das Programm mit einem 
Symbolfehler direkt beendet hat.

Den letzten, und der für mich schwerwiegenste Punkt, war jedoch das man 
mit so ziemlich jedem größeren systemd Update im Hintergrund eine 
Veränderung ins System bekommen hat bei der man nicht mal gefragt wurde 
ob man das will. Z.b hab ich einmal verwundert festgestellt, das mein 
/tmp plötzlich ein tmpfs war und nicht wie vorher die normale Platte. 
War ganz toll, weil war halt ein paar GByte kleiner als vorher. Dann hat 
hat sich systemd auf einmal als DNS Resolver in system gesetzt usw.

Damit sind wir auch bei meinem größten Kritikpunkt, das durch systemd 
über die Hintertür Änderungen gemacht werden und Festlegungen getroffen 
werden, die ich persönlich nicht möchte und das aktiv meine Wahlfreiheit 
eingeschränkt wird. Weil es eben nur den in systemd vorgesehenen Weg 
gibt. Merged /bin /sbin ist eine weitere solche Sache, von dem Unsinn 
mit den Home-Verzeichnissen möchte ich gar nicht erst sprechen: Nein ich 
möchte nicht das jeder dahergelaufene Hanswurst seinen USB-Stick an 
meinen Rechner steckt und sich dann anmelden kann.

Problematisch finde ich auch die immer größer werdende Abhängigkeit 
verschiedener grundlegender Tools von systemd. So sind inzwischen sogar 
apt und lvm gegen die libsystemd gelinkt. Dadurch wird das Gesamtsystem 
einfach viel fragiler. Nehmen wir z.B. an, dass aus irgendeinem Grund 
ein Update schief geht, die libsystemd nicht richtig installiert wurde 
aber das System noch nicht neu gestartet wurde. Dann kann ich trotzdem 
kein apt mehr starten, weil die lib weg ist, die Möglichkeiten das 
Problem zu beheben sind unnötig eingeschränkt. Natürlich gibt es auch 
andere Libs, wie z.B. die libc von der so ziemlich alles abhängt. 
Allerdings ändert sich die libc bei weitem nicht so regelmäßig wie 
systemd. Ich denke man sollte mögliche Fehlerquellen soweit wie möglich 
minimieren, gerade bei den wirklich wichtigen Programmen.

Mein generelles Gefühl zu systemd ist, (als jemand der systemd in der 
aktuellen Form ablehnt, also möglicherweise mit Vorurteilen) dass eben 
gerade von systemd heraus eine Haltung propagiert wird, dass es eben nur 
einen richtigen Weg gibt, und das ist der den systemd geht. Das ist aber 
genau nicht das für was Linux steht. Da kann ich auch gleich Windows 
einsetzten, ob ich mich nun von Microsoft oder RedHat bevormunden lasse 
spielt doch keine Rolle.

Für den Fall das man sich bei systemd dazu entscheidet das Teil zu 
entbündeln, zu modularisieren, so dass man die reine "Dienstverwaltung" 
ohne riesigen Aufwand wieder unabhängig vom Rest einsetzen kann (so wie 
am Anfang) dann wäre ich sofort wieder dabei.

Ich versuche dann nochmal auf ein paar der Beiträge oben im Detail 
einzugehen:

Jack V. schrieb:
> Wie auch immer – ein modernes System dürfte sich ohne initramfs nicht
> hochbekommen lassen, insofern wäre Devuan schon ein besserer Ansatz, als
> solche Systeme. Allerdings ist auch das auf ein initramfs ausgelegt, so
> dass da recht tiefgreifende Basteleien nötig sein werden.

Unsinn. Das mag bei systemd so sein, bei SysV mit Sicherheit nicht. Das 
einzige was es dafür braucht, ist das alle zur Bootzeit benötigen 
Treiber in den Kernel hineincompiliert werden. Man muss sich dann eben 
einschränken, im allgemeinen kein lvm oder md für /. Wobei ich mir da 
gar da nicht mal so sicher bin, man kann dem Kernel über Komandozeile 
und Device-Tree so allerlei beibringen.

Inzwischen ist Btrfs eine ganz gute Alternative zu lvm. Da kann man auch 
zu Laufzeit neue Physical devices hinzufügen oder entfernen. Es hat 
(u.a.) sogar den Vorteil, das der gesamte Speicherplatz allen Subvolumes 
zur Verfügung steht. Man muss sich nicht Entscheiden wie man den Platz 
aufteilt und hat trotzdem sowas wie Partitionen. Ich nutze es daher auf 
meiner NAS (mit vielen thematischen Subvolumes)

Jack V. schrieb:
> Wenn jemand meinen Kram nimmt, und ihn auf ’nem anderen System zum
> Laufen bringt: da freu’ ich mich drüber. Und wenn er an mich herantritt,
> und konkrete Änderungen dafür anfragt (nicht: „verlangt“. Das ist

Wäre schön wenn das alle Debian Maintainer so sehen würden. Leider 
fallen einige einzelne aber damit auf, ohne Not vorhandene SysV Init 
Skripte zu entfernen und auch nicht wieder hinzuzufügen. Darüber sind 
auch einige Debian-Devs nicht erfreut und es wird vermutlich auch 
Debian-intern Diskussionen auslösen.

Bauform B. schrieb:
> Inzwischen frage ich mich allerdings, wann die initrd überhaupt neu
> gebaut wird. Natürlich bei einem Kernel-Update, aber sonst? Kann es
> sein, dass es auch bei udev-Updates passiert (und schief gegangen) ist?

Updates finden immer dann statt, wenn  ein neuer Kernel installiert 
wurde, oder aber irgend ein Programm installiert/aktualisiert wurde, 
welches ebenfalls Bestandteil der initrd ist weil es beim Bootvorgang 
frühzeitig benötigt wird. z.B. udev aber auch lvm.

Nano schrieb:
> Zum konfigurieren des Netzwerks verwendet man das nmcli Tool, also das
> Network Manager Command Line Interface. Damit ist das auch extrem

Warum, wer hat das festgelegt? Wenn ich einen Server habe der genau ein 
Netzwerkinterface hat, was immer mit der gleichen, festen IP ohne DHCP 
laufen soll, von mir aus auch DHCP, warum soll ich dann so ein Monstrum 
wie Network-Manager installieren, der dann auch noch an Dateien wie z.B. 
/etc/resolv.conf rumspielt? Und dazu noch alle möglichen Tools für 
Modems, WLan und LTE als Abhängikeiten nach zieht.

Im übrigen ist das Benutzen von "nmcli" auf einem systemd-System schon 
längst veraltet. Poettering hat entschieden, das er das auch besser kann 
und deswegen hat ein echter systemd Jünger hat gefälligst 
systemd-networkd zu benutzen.

Auf einem Desktop oder Notebook, keine Frage da nutze ich auch 
Network-Manager aber das schöne an Linux ist ja gerade das man die 
Möglichkeit hat, dass passende Tool für seinen Anwendungsfall frei zu 
wählen.

Bauform B. schrieb:
> Sheeva P. schrieb:
>> Mit GNOME wirst Du damit vermutlich Probleme bekommen, weil einige
>> Komponenten nun einmal von systemd abhängen sollen.
>
> Diese Komponenten lassen sich nicht installieren, also machen sie auch
> keine Probleme. Genau hier kommt Devuan ins Spiel, da werden diese
> garnicht angeboten, bei Debian muss man aufpassen. Man kann nicht alles

Aha, als auf meinem Devuan schon:
andi@bla:~$ sudo aptitude install task-gnome-desktop
Die folgenden NEUEN Pakete werden zusätzlich installiert:
aisleriot{a} argyll{a} argyll-ref{a} atril{a} atril-common{a} baobab{a} bolt{a} caribou{a} cheese{a} 
  chrome-gnome-shell{a} dconf-cli{a} dleyna-server{a} eog{a} espeak-ng-data{a} evince{a} evince-common{a} 
  evolution{a} evolution-common{a} evolution-data-server{a} evolution-data-server-common{a} 
....
0 Pakete aktualisiert, 342 zusätzlich installiert, 0 werden entfernt und 96 nicht aktualisiert.
288 MB/288 MB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 902 MB zusätzlich belegt sein.
Möchten Sie fortsetzen? [Y/n/?] n
Abbruch.
andi@bla:~$ 

Genau aus dem Grunde gibt es ja den elogind im Devuan statt dem systemd. 
Dieser implementiert alle notwendigen Dinge bzgl. Login und Session 
Management. Und natürlich kann ich bei Devuan einfach einen USB Stick 
einstecken und als normaler Benutzer mounten.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Jack V. schrieb:
>> Wie auch immer – ein modernes System dürfte sich ohne initramfs nicht
>> hochbekommen lassen, insofern wäre Devuan schon ein besserer Ansatz, als
>> solche Systeme. Allerdings ist auch das auf ein initramfs ausgelegt, so
>> dass da recht tiefgreifende Basteleien nötig sein werden.
>
> Unsinn. Das mag bei systemd so sein, bei SysV mit Sicherheit nicht.

Einen Kernel zu bauen und die Bootkonfiguration entsprechend anzupassen, 
sehe ich als „recht tiefgreifende Bastelei“ – man verlässt bei einer 
absoluten Kernkomponente den Pfad seiner Distribution. Insofern weise 
ich das „Unsinn“ zurück.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Nun ist es nicht so, dass ich systemd grundsätzlich schlecht finde.
> Gerade am Anfang als er noch frisch war, (damals war ich noch auf
> ArchLinux) war ich davon geradezu begeistert.

Genau so ging es mir, die Ideen in "Rethinking PID 1" im 
0pointer.net/blog/ haben mir wirklich gut gefallen. Aber von da an 
ging's bergab.

Bauform B. schrieb:
> Inzwischen frage ich mich allerdings, wann die initrd überhaupt neu
> gebaut wird. Natürlich bei einem Kernel-Update, aber sonst? Kann es
> sein, dass es auch bei udev-Updates passiert (und schief gegangen) ist?

> (initramfs) Updates finden immer dann statt, wenn (...) irgend ein
> Programm installiert/aktualisiert wurde, welches ebenfalls
> Bestandteil der initrd ist

Also doch relativ häufig, das erklärt meine Probleme damit, danke.

> andi@bla:~$ sudo aptitude install task-gnome-desktop
> 0 Pakete aktualisiert, 342 zusätzlich installiert

dass das auch schon funktioniert hätte ich nicht gedacht, das ist ja der 
Wahnsinn. Ich sollte bannedpackages.txt nicht nur überfliegen...
Dankeschön!

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Einen Kernel zu bauen und die Bootkonfiguration entsprechend anzupassen,
> sehe ich als „recht tiefgreifende Bastelei“ – man verlässt bei einer
> absoluten Kernkomponente den Pfad seiner Distribution.

Die ersten Versuche sind wohl Bastelei, aber sobald es läuft, ist es 
viel überschaubarer und stabiler als ein initramfs. Der Eingriff in die 
Distribution ist nur formal tiefgreifend, technisch ändert sich fast 
garnichts. Man könnte sagen, die Distribution merkt das garnicht. Man 
darf ganz offiziell zusätzliche Kernel bei grub eintragen, das würde 
doch reichen?

Ich benutze allerdings sowieso eine Bootpartition und syslinux, weil ich 
immer mehrere Systeme auf einer Platte habe. Man kann auch ganz 
offiziell "ohne Bootloader" installieren. Dadurch bin ich sicher, dass 
syslinux und -config nicht überschrieben werden. /boot wird nicht 
benutzt, die Distribution kann da rein schreiben, was sie will, es stört 
nicht.

Diese Boot-Mimik funktioniert natürlich genauso gut mit wie ohne 
initramfs, das ist ja unabhängig, aber aus "tiefgreifend" wird "minimal" 
(oder so).

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Die ersten Versuche sind wohl Bastelei, aber sobald es läuft, ist es
> viel überschaubarer und stabiler als ein initramfs. Der Eingriff in die
> Distribution ist nur formal tiefgreifend, technisch ändert sich fast
> garnichts.

Gut, da bin ich halt anderer Meinung. Schon alleine der Punkt, dass man 
das Ding für jeden Patch und Fix neu bauen muss, statt einfach das 
Update der Distribution einzuspielen, wobei das initramfs ohne weiteres 
Zutun neu gebaut wird, ist in meinen Augen ’n tiefgreifender 
Unterschied. Letzteres dauert auf ’nem ältlichen Pentium Silver hier 
immerhin geschlagene 10 Sekunden, während ein Kernel mit einiger 
Sicherheit nicht in der Zeit zu bauen ist, allerdings nahezu genauso oft 
gebaut werden müsste.

Aber mach’s halt einfach, und berichte dann. Ich werd’ bestimmt kein 
Anhänger der Idee, Linux auf heutiger HW ohne initramfs starten zu 
wollen, dafür ist das initramfs einfach viel zu flexibel und einfach zu 
handhaben (und meinen PC würde ich ohne das nicht mal sinnvoll 
hochbekommen, weil das Modul für die Grafik via DKMS gebaut wird, und 
zur Bootzeit geladen werden sollte. Bei anderen Rechnern funktioniert’s 
nicht, weil die Systempartitionen vor dem Starten des Systems 
entschlüsselt werden müssen, LVM und sonstiger Kram gestartet muss, und 
einige andere Sachen ablaufen sollen), aber das heißt ja nicht, dass ich 
nicht auch gerne über den Tellerrand schaue um zu sehen, wie’s andere so 
machen, und wie’s dabei so läuft.

Das Schöne an den offenen Systemen ist und bleibt ja: „There’s always 
more then one way to do it“

: Bearbeitet durch User
von Karl Käfer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Jack V. schrieb:
> Meine Frage ist eigentlich "kann man Devuan empfehlen", "initrd" ist nur
> ein Aufhänger. Es ist aber ein interessantes Detail, inwieweit sich
> Devuan und Debian unterscheiden. Mir scheint, der Trend geht dahin, dass
> etwas wie initramfs zwingend nötig sein soll, genau wie manch andere
> Neuerungen.

Ein initramfs ist schlicht und ergreifend: sinnvoll, denn es verhindert, 
daß man nach jeder Änderung an etwas, das zum Mounten des 
Root-Dateisystems mit den Kernelmodulen benötigt wird, der Kernel neu 
kompiliert werden muß. Zudem bleibt der Kernel kleiner und man kann die 
Software in der initrd unabhängig vom Kernel aktualisieren. Im Grunde 
genommen ist das die logische Konsequenz aus der Modularisierung des 
Kernels mit dynamisch ladbaren Modulen.

>> weder mit DNS, noch mit NTP habe ich irgendwelche Probleme.
>
> Schön für dich, aber auch wenn 99.9% der Benutzer keine Probleme haben,
> hilft mir das garnichts. Mehrere Leute hatten Probleme. Es waren
> genug, dass es in der Zeitung stand und mir deshalb aufgefallen ist.

Also in meiner Zeitung stand nichts, aber das will ja nichts heißen. 
Meine Erfahrung ist, daß Probleme meistens dann auftreten, wenn die 
Anwender oder Admins abseits der Best Known Practices am System 
herumfummeln. Häufig ist es so, daß solch "abseitige" Fummeleien 
zunächst einmal funktionieren, es dann jedoch beim nächsten Update 
Probleme gibt, weil die neue Softwareversion andere Defaults nutzt, die 
Konfiguration nicht mehr lesen kann, oder die Konfiguration nicht mehr 
automatisch für die neue Softwareversion migriert oder konvertiert 
werden kann. Klar, so ein Linux bietet enorme Flexibilität, und das ist 
ja auch einer der wichtigsten Gründe für seine Beliebtheit. Aber je 
weiter man sich von den üblichen und getesteten Pfaden entfernt, desto 
fragiler wird die Sache, vor allem im Hinblick auf die 
Langzeitstabilität.

Das Traurige an solchen Problemen ist, daß die meisten Anwender, die 
diese Probleme höchstselbst verursacht haben, nicht erkennen, einsehen 
oder gar zugeben wollen, daß sie selbst die Ursache des Problems gewesen 
sind. Sowas erleben wir hier im Forum ja ziemlich häufig, daß sich 
jemand über Probleme mit einer Softwarekomponente X beschwert, und auf 
Nachfrage kommen dann oft zwei Szenarien: entweder, der Betreffende weiß 
gar nicht mehr, was er gemacht und wie genau sich der angebliche Fehler 
geäußert hat, oder er rastet schon deswegen prophylaktisch aus, weil man 
es wagt, nachzufragen und damit seine (natürlich unantastbare) Kompetenz 
in Frage zu stellen.

Die initrd gibt es im stabilen Linux-Kernel seit Version 2.6.13, also 
seit ziemlich genau 15 Jahren. Ich selbst nutze sie auf einigen hundert 
Rechnern, mir persönlich seit vielen Jahren gut bekannte, erfahrene 
Administratoren und Anwender von Linux-Systemen auf einigen weiteren 
tausend Maschinen jedweder Couleur. Von größeren Problemen mit dieser 
Technik habe ich bisher sehr, sehr selten gehört, viel seltener als von 
Problemen mit selbstgestelten Kernels.

Wie dem auch sei: jedes manuelle Herumfummeln am System außerhalb der 
dafür vorgesehenen Pfade und Lösungen birgt das Risiko, daß es einem 
früher oder später auf die Füße fällt. Und ich befürchte, genau das gilt 
auch für Dein Ansinnen, ein System ohne initrd betreiben. Letzten Endes 
erhöhst Du die Fehlerwahrscheinlichkeit, anstatt sie zu reduzieren.

Eine womöglich fehlertolerantere Möglichkeit wäre, die zum Mounten des 
RooFS nötigen Module in den Kernel zu kompilieren und trotzdem eine 
initrd zu verwenden. Die Module aus der initrd werden nur genutzt, wenn 
das benötigte Modul nicht fest einkompiliert ist. Habe ich aber nicht 
getestet, YMMV.

von Karl Käfer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Der Trend geht zum initramfs (bzw.: ist gegangen zu, vor vielen, vielen
> Jahren schon – Ausnahme ist der Embedded-Bereich), weil das nunmal
> einfach praktisch ist, und zudem die Folgen von Fehlern abfangen kann.

Im Embedded-Bereich ist es ja auch meistens so, daß die Hardware bei 
Weitem nicht so modular, flexibel und erweiterbar ist wie bei einem 
Computer. Daher macht es dort natürlich viel mehr Sinn, alle benötigten 
Module fest in den Kernel einzukompilieren und alles Überflüssige 
herauszulassen, so daß am Ende ein schlankerer und genau auf die 
Hardware abgestimmter Kernel herauskommt.

Auch bei besonders sicheren Systemen, beispielsweise für Firewalls, ist 
es häufig sinnvoll, einen passenden Kernel zu kompilieren und das 
dynamische Laden von Kernelmodulen zu deaktivieren -- und dann macht 
eine initrd mit ladbaren Kernelmodulen natürlich auch keinen Sinn.

von Karl Käfer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Für den Fall das man sich bei systemd dazu entscheidet das Teil zu
> entbündeln, zu modularisieren,
> [...]
> Genau aus dem Grunde gibt es ja den elogind im Devuan statt dem systemd.
> Dieser implementiert alle notwendigen Dinge bzgl. Login und Session
> Management. Und natürlich kann ich bei Devuan einfach einen USB Stick
> einstecken und als normaler Benutzer mounten.

Das ist ja interessant: man kann Teile von systemd also durch andere 
ersetzen? Und wenn das so ist: ist das nicht genau jene Modularisierung, 
deren Fehlen Du gerade noch beklagt hattest?

von Andreas M. (amesser)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Einen Kernel zu bauen und die Bootkonfiguration entsprechend anzupassen,
> sehe ich als „recht tiefgreifende Bastelei“ – man verlässt bei einer
> absoluten Kernkomponente den Pfad seiner Distribution. Insofern weise
> ich das „Unsinn“ zurück.

Zwischen Kernel und Distribution gibt es so gut wie keine einzige 
direkte Abhängigkeit, außer das der Kernel seine API anbieten muss, auf 
der dann alles andere aufsetzt. Was im Kernel passiert, welche Treiber 
eincompiliert sind, welche als Modul geladen werden müssen, und mit 
welchen Optinen die geladen werden interessiert kein einziges Program 
innerhalb der Distribution. Natürlich haben diese Einstellungen 
Auswirkungen auf Performance und verfügbarkeit der Hardware im 
Gesamtsystem, aber ein Gnome, KDE und selbst systemd interessiert sich 
herzlich wenig dafür ob die Festplatte nun über den Sata, Scsi, iScsi 
oder was auch immer angesprochen wird, pb diese Module hart im Kernel 
waren aus der initrd kamen oder sogar erst viel später geladen wurden, 
es bleibt ne Festplatte.

Was glaubst du denn, warum Docker, lxc, flatpak und Konsorten 
funktionieren? Denkst Du im Ernst, das die ganzen Leute und Projekte die 
solche Container anbieten sich irgendwelche Gedanken über den Kernel des 
Hostsystem, ja die Distribution machen? Genau das tun sie nämlich nicht, 
denn das ist der Sinn dieser Geschichten, das eben nicht für jede 
Distribution ind jeden Kernel ein eigenen Container bauen müssen.

Jack V. schrieb:
> Gut, da bin ich halt anderer Meinung. Schon alleine der Punkt, dass man
> das Ding für jeden Patch und Fix neu bauen muss, statt einfach das
> Update der Distribution einzuspielen, wobei das initramfs ohne weiteres

Es ist doch etwas völlig anderes zu sagen "ich möchte automatisch 
Updates bekommen" als "das ist Bastelei". Während das erste eine völlig 
legitimer Grund ist, zu sagen, dass man den vorcompilierten Kernel 
benutzen möchte zeugt das letztere in diesem Fall hier einfach nur 
davon, das man keine Ahnung hat.

Karl Käfer schrieb:
> Ein initramfs ist schlicht und ergreifend: sinnvoll, denn es verhindert,
> daß man nach jeder Änderung an etwas, das zum Mounten des
> Root-Dateisystems mit den Kernelmodulen benötigt wird, der Kernel neu
> kompiliert werden muß. Zudem bleibt der Kernel kleiner und man kann die
> Software in der initrd unabhängig vom Kernel aktualisieren.

Was ist den "etwas" was grundsätzlich zum Mounten benötigt werden soll? 
Wenn man gar keine initrd hat, dann braucht man auch keine zu 
aktualisieren? Nach deiner Logik also noch besser. Oder? Ob der Kernel 
zur Boot-Zeit kleiner ist, ist vollkommen irrelevant, da spätestens zur 
Laufzeit normalerweise eh alle Treiber geladen werden. Ein rein 
monolitischer Kernel der alle Module eincompiliert hat, die das 
Zielsystem braucht ist sogar noch kleiner. Und es soll sogar möglich 
sein, nur die zum Booten und mounten notwendigen Treiber in den Kernel 
zu compilieren und die restlichen Treiber vom gemounten root 
nachzuladen. Der Linux Distribution ist das herzliche egal, wie das 
konfiguriert ist.

Karl Käfer schrieb:
> Wie dem auch sei: jedes manuelle Herumfummeln am System außerhalb der
> dafür vorgesehenen Pfade und Lösungen birgt das Risiko, daß es einem
> früher oder später auf die Füße fällt. Und ich befürchte, genau das gi

Ja ich denke auch, es ist besser wenn Du lieber andere entscheiden 
lässt, was gut und richtig für Dich ist. Ich habe übrigens meine ersten 
Schritte mit Linux Kernel 2.0 gemacht nur mal so am Rande. Damals hat 
man auch mal über den Tellerrand geschaut und sich intensiver mit den 
Sachen beschäftigt.

Karl Käfer schrieb:
> Das ist ja interessant: man kann Teile von systemd also durch andere
> ersetzen? Und wenn das so ist: ist das nicht genau jene Modularisierung,
> deren Fehlen Du gerade noch beklagt hattest?

Nein kann man eben nicht. Du kannst entweder libelogind installieren 
oder systemd. Wenn systemd modular wäre, dann würde ein systemd-networkd 
z.B. mit libelogind funktionieren. Oder der elogind könnte mit der 
libsystemd laufen. Genau das ist aber nicht der Fall. Weil es beim 
systemd eben keine saubere Trennung der Schnittstellen gibt und jede 
Teilkomponente ein "Teilwissen" über den Rest der Komponenten hat, 
darüber was und wie sie es tun. z.B. Ist in jede systemd Komponente die 
cgroup Struktur von systemd hart einkompiliert, statt diese in der 
libsystemd zu abstrahieren. Da elogind jedoch eine komplett anderes 
cgroup Layout benutzt kann man also kein einziges systemd-* Program 
zusammen mit elogind benutzen, obwohl technisch eigentlich nichts 
dagegen sprechen würde. Diese Software wurde absichtlich so designt, 
dass man das nicht kann.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Zwischen Kernel und Distribution gibt es so gut wie keine einzige
> direkte Abhängigkeit, außer das der Kernel seine API anbieten muss, auf
> der dann alles andere aufsetzt. Was im Kernel passiert, welche Treiber
> eincompiliert sind, welche als Modul geladen werden müssen, und mit
> welchen Optinen die geladen werden interessiert kein einziges Program
> innerhalb der Distribution.

… bis auf die, die bestimmte Funktionalität voraussetzen, die beim 
Distributionskernel garantiert dabei ist, bei ’nem selbstgedrehten 
Kernel vielleicht nicht – sei’s aufgrund eines Fehlers, aus Unwissen, 
oder einfach, weil sich mal wieder ’ne Option geändert hat, und das beim 
Bauen übersehen wurde. Ist ja nicht so, als wäre TE der erste, dem sowas 
passieren würde …

Andreas M. schrieb:
> Es ist doch etwas völlig anderes zu sagen "ich möchte automatisch
> Updates bekommen" als "das ist Bastelei".

Ansichtssache. Etwas, das man für jedes Update selbst neu bauen muss, 
ist meiner Ansicht nach Bastelei, aber nicht die Basis für ein stabiles, 
wartungsarmes System, wie sie heutige Linuxdistributionen nunmal 
ermöglichen. Und wenn’s dann noch am Paketsystem vorbei installiert 
würde, wie’s die allermeisten Selbstbauer machen, die ich kenne, wär’s 
erst recht Bastelei.


Andreas M. schrieb:
> Ich habe übrigens meine ersten
> Schritte mit Linux Kernel 2.0 gemacht nur mal so am Rande. Damals hat
> man auch mal über den Tellerrand geschaut und sich intensiver mit den
> Sachen beschäftigt.

Ja gut … als ich ’99 bei 2.2 eingestiegen bin, war das schon völlig 
anders. Keiner hat irgendwohin geschaut, oder sich gar noch mit dem Kram 
beschäftigt. Vielleicht erklärt das die unterschiedlichen 
Wahrnehmungsweisen?
(ich hoffe, der Hauch von Ironie ist erkennbar?)

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Karl Käfer schrieb:
>> Wie dem auch sei: jedes manuelle Herumfummeln am System außerhalb der
>> dafür vorgesehenen Pfade und Lösungen birgt das Risiko, daß es einem
>> früher oder später auf die Füße fällt. Und ich befürchte, genau das gi
>
> Ja ich denke auch, es ist besser wenn Du lieber andere entscheiden
> lässt, was gut und richtig für Dich ist.

Ein guter und zutreffender Satz.
Es wäre schließlich vermessen zu glauben, man wäre schlauer als die 
Schwarmintelligenz aus Linux-Entwickler, -maintainer und -distributoren.

Als ambitionierter aber pragmatischer Privatanwender habe ich in 15 
Jahren Linuxerei (jaja, ich ahnungsloser Späteinsteiger) keinen Grund 
gefunden einen Kernel zu bauen oder irgendein grundlegendes Systemsetup 
gegenüber dem abzuändern was der Distributor als sinnvoll erachtet.
Ich möchte halt gerne mit dem System arbeiten als am System
(Da ich aber auch nerdige Hobbies betreibe kann ich mich in euch gut 
hineinversetzen und gönne jedem den Spaß, sich sein Systm nach Belieben 
zu Verbasteln und nach jedem mittelgroßen Update alles wieder flott zu 
kriegen).

von Andreas M. (amesser)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Ansichtssache. Etwas, das man für jedes Update selbst neu bauen muss,
> ist meiner Ansicht nach Bastelei, aber nicht die Basis für ein stabiles,
> wartungsarmes System, wie sie heutige Linuxdistributionen nunmal
> ermöglichen.

Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket 
zu bauen, dieses regelmäßig zu aktualisieren und per lokalem 
Paket-Repository (das es als Mirror und wegen spezifischer Software 
sowieso gibt) zu verteilen, dann hält sich der Aufwand in engen Grenzen. 
Dafür bekomme ich einen schlanken Kernel, der alles was man nicht 
braucht gar nicht erst enthält und somit generell eine kleine 
Angriffsfläche bietet.

Le X. schrieb:
> Als ambitionierter aber pragmatischer Privatanwender habe ich in 15
> Jahren Linuxerei (jaja, ich ahnungsloser Späteinsteiger) keinen Grund
> gefunden einen Kernel zu bauen oder irgendein grundlegendes Systemsetup
> gegenüber dem abzuändern was der Distributor als sinnvoll erachtet.

Du vielleicht nicht, andere aber schon. Ich hab ein Problem damit das 
einfach als "Gebastel" in die Ecke zustellen, weil das einfach nicht 
stimmt.

Le X. schrieb:
> hineinversetzen und gönne jedem den Spaß, sich sein Systm nach Belieben
> zu Verbasteln und nach jedem mittelgroßen Update alles wieder flott zu
> kriegen).

Ich benutze schon immer selbst kompilierte Kernel und stell Dir vor, ich 
habe mein System von Debian Jessie nach Devuan Ascii und zuletzt nach 
Beowulf per dist-upgrade aktualisiert, ohne irgend ein Problem. Als ob 
ein selbst kompilierter Kernel automatisch zu Upgrade Problemen führen 
würde. Der Kernel ist das kleinste Problem bei einem Upgrade.

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket
> zu bauen, dieses regelmäßig zu aktualisieren und per lokalem
> Paket-Repository (das es als Mirror und wegen spezifischer Software
> sowieso gibt) zu verteilen, dann hält sich der Aufwand in engen Grenzen.

Dann solltet ihr, im Sinne der Diskussion schleunigst mal klären wie der 
Kontext aussieht.

Gehts um den Privatanwender mit Email und Office?
"Poweruser" mit NAS, mehreren OSen und etwas mehr Ambition?
Konzern mit großer IT-Abteilung?

Also ich hab keinen MA abgestellt der mir zuhause den Kernel baut und 
die Pakete einspielt, deshalb versuche ich jeglichen Aufwand zu 
vermeiden der mir nicht wesentliche Vorteile einbringt (Rebellion gegen 
Pöttering zum reinen Selbstzweck ist für mich kein Vorteil).
Ich bin sehr zufrieden wenn sich mein Adminstrationsaufwand auf ein 
"pacman -Syu " beschränkt.

Von einem Privatanwender hier im Forum ist bekannt dass er sich im 
Keller auch Serverfarmen hält und die Devuan-Repos spiegelt (könnten ja 
morgen weg sein. Was es aber bringt sich Kopien einer nicht mehr 
existenten Distri vorzuhalten ist mir aber unklar).
Das läuft dann wohl unter Hobby, damit kann man natürlich jeden 
Mehraufwand rechtfertigen.

Beim TO hatte ich aber bisher eher den Eindruck er möchte sein System 
einfach nur nutzen.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Bauform B. schrieb:
>> Die ersten Versuche sind wohl Bastelei, aber sobald es läuft, ist es
>> viel überschaubarer und stabiler als ein initramfs. Der Eingriff in die
>> Distribution ist nur formal tiefgreifend, technisch ändert sich fast
>> garnichts.
>
> Gut, da bin ich halt anderer Meinung. Schon alleine der Punkt, dass man
> das Ding für jeden Patch und Fix neu bauen muss, statt einfach das
> Update der Distribution einzuspielen, wobei das initramfs ohne weiteres
> Zutun neu gebaut wird, ist in meinen Augen ’n tiefgreifender
> Unterschied.

Ein großer Unterschied ist es natürlich, ein Eingriff ist es eher 
nicht. "das Ding" besteht ja nur aus dem Kernel, also muss es nur bei 
einem Kernel-Update neu gebaut werden und meistens nicht einmal dann, 
weil z.B. ein Patch im Bluetooth-Stack für mich nicht relevant ist.


Karl Käfer schrieb:
> Von größeren Problemen mit dieser Technik (initramfs) habe ich
> bisher sehr, sehr selten gehört, viel seltener als von
> Problemen mit selbstgestelten Kernels.

Das glaube ich gerne, aber entscheidend ist doch, wann diese Probleme 
auftreten. Wenn ich gerade am Kernel bastel, muss ich mit Problemen 
rechnen, ich kann sie aber auch sofort beheben. Im anderen Fall 
passieren sie ohne mein Zutun, irgendwann, überraschend, irgendwo.

> Eine womöglich fehlertolerantere Möglichkeit wäre, die zum Mounten des
> RooFS nötigen Module in den Kernel zu kompilieren und trotzdem eine
> initrd zu verwenden. Die Module aus der initrd werden nur genutzt, wenn
> das benötigte Modul nicht fest einkompiliert ist.

Ein Beispiel wäre, wenn ich / von ext4 auf btrfs umstelle (oder so). 
Aber sonst? Welches Modul sollte plötzlich nötig werden, wenn es beim 
Kernelbau noch nicht nötig war? USB-Hardware kommt und geht, klar, aber 
die kommt später dran, wenn / gemountet ist.

Karl Käfer schrieb:
> Im Embedded-Bereich ist es ja auch meistens so, daß die Hardware bei
> Weitem nicht so modular, flexibel und erweiterbar ist wie bei einem
> Computer.

Trotz Modularität und Erweiterbarkeit braucht auch ein Desktop-PC die 
Module nicht bevor / gemountet ist. Apropos Embedded: die meiste Zeit 
habe ich mit PCs zu tun, die einfach ein- und ausgeschaltet werden wie 
eine Schreibtischlampe. Daher kommt meine Vorliebe für kurze Bootzeiten 
und tiefgreifende Eingriffe.
Edit: und die Idee, dass man den Kernel selbst bauen sollte, stammt aus 
der Zeit, als das devtmpfs im Kernel auftauchte und Debian das (noch) 
nicht genutzt hat.


Jack V. schrieb:
> Etwas, das man für jedes Update selbst neu bauen muss,
nur bei einem Kernel-Update, und nicht einmal bei jedem
> ist meiner Ansicht nach Bastelei, aber nicht die Basis für ein stabiles,
> wartungsarmes System, wie sie heutige Linuxdistributionen nunmal
> ermöglichen. Und wenn’s dann noch am Paketsystem vorbei installiert
> würde, wie’s die allermeisten Selbstbauer machen, die ich kenne, wär’s
> erst recht Bastelei.

Mein Kernel auf der extra Bootpartition ist natürlich am Paketsystem 
vorbei, das ist ja genau der Sinn der Sache. Ohne Bootpartition und ohne 
initramfs müsste ich eben ein Kernel-Paket bauen, das ist ja auch 
offiziell vorgesehen. Und mehr ändert sich doch nicht.

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich verwende auch manchmal selbstgebaute Kernels, meistens weil es 
einfach nicht anders geht.

Als ich z.B. mein Surface Pro 3 bekam, war der Debian Kernel einfach zu 
alt. Als ich später nochmal nachsah waren gewisse Treiber erstmal nicht 
aktiviert (wer nutzt den schon Linux auf nem Surface? Viel zu 
exotisch!). Ob es mittlerweile ootb geht, keine Ahnung.

Aber Problematisch ist es nicht. Man könnte eine minimale config 
generieren (make localyesconfig oder localmodconfig), und die dann 
nehmen (obwohl, die sind doch etwas gar minimal), aber man kann auch die 
alte Config vom debian Kernel nehmen (/boot/config-*), und die dann 
erweitern "make menuconfig". Wenn man das hat, einfach das kernel packet 
von Debian auf hold setzen (linux-image-amd64 glaub ich) (oder 
deinstallieren, falls möglich), "make deb-pkg" oder "make bindeb-pkg" 
nehmen, die relevanten Packete installieren, und fertig.

Updates sind kein Problem. Einfach .config kopieren, "make deb-pkg", mit 
dpkg installieren, fertig. Ich hab das in nem Script automatisiert, und 
muss jetzt nur noch "update-kernel" eintippen, und es lädt und 
kompiliert mir den aktuellen stable oder longstable Kernel, jenachdem, 
ob letzterer schon neu genug ist. Alles total schmerz und gefahrlos. Und 
notfalls kann man auf den vorherigen Kernel kann man immer noch zurück, 
ist ja in grub auswählbar.

Initramfs entfernen ist auch sehr unproblematisch. In grub den Eintrag 
temporär wegnehmen, und wenn es geht, einfach mit apt initramfs-tools 
deinistallieren & grub updaten.

Sobald das System mal sauber eingerichtet ist werden dann auch 
zukünftige Updates nichts kaputt machen. Nur dass der Kernel ständig 
neue fixes bekommt ist nervig, fast jede Woche wieder eins. Da muss man 
dann aufpassen, dass einem /boot nicht volläuft, und auch mal alte 
Kernels + quellen löschen...

Andere Orte, wo ich einen eigenen Kernel habe, ist mein Librem 5 (auch 
hier, debian kernel zu alt), und ein Server (dort hauptsächlich, um den 
selbst zu signieren, und ich glaube zu jessie Zeiten brauchte ich noch 
was für meine Container...).

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket
> zu bauen, dieses regelmäßig zu aktualisieren und per lokalem
> Paket-Repository (das es als Mirror und wegen spezifischer Software
> sowieso gibt) zu verteilen, dann hält sich der Aufwand in engen Grenzen.

Natürlich. Bestimmt wird der TE das genau so machen, oder?

Le X. schrieb:
> Es wäre schließlich vermessen zu glauben, man wäre schlauer als die
> Schwarmintelligenz aus Linux-Entwickler, -maintainer und -distributoren.

Da erhebe ich nun wieder Einspruch: es wäre vermessen, zu glauben, die 
Entwickler und Maintainer könnten jeden speziellen Fall gleichermaßen 
vorhersehen und abdecken. Schon alleine, weil das nicht geht. Es gibt 
triftige Gründe, es anders zu machen. Und wenn’s ein „aber ich will 
das Neue nich!!k“ ist – das ist zwar kein objektiver, aber ein valider 
subjektiver Grund.
Nur ist’s wichtig, das dann auch genau so zu sagen: technisch spricht 
bei einem herkömmlichen Setup und Einsatzzweck nichts gegen ein 
initramfs.

Bauform B. schrieb:
> Ein großer Unterschied ist es natürlich, ein Eingriff ist es eher
> nicht. "das Ding" besteht ja nur aus dem Kernel, also muss es nur bei
> einem Kernel-Update neu gebaut werden und meistens nicht einmal dann,
> weil z.B. ein Patch im Bluetooth-Stack für mich nicht relevant ist.

Die Frage ist ja: du hast die LKML abonniert und verfolgst die 
Entwicklung aufmerksam, und bist in der Lage, den Einfluss der einzelnen 
Sachen auf dich abzuschätzen und zeitnah einen neuen Kernel zu bauen? 
Zum Kernel gehört übrigens schon auch bisschen mehr, als das einzelne 
Binary.

🐧 DPA 🐧 schrieb:
> Updates sind kein Problem. Einfach .config kopieren, "make deb-pkg", mit
> dpkg installieren, fertig.

Damit sind schon Leute böse aufs Gesicht gefallen :D

🐧 DPA 🐧 schrieb:
> Initramfs entfernen ist auch sehr unproblematisch. In grub den Eintrag
> temporär wegnehmen

Das geht irgendwie bei keinem meiner Debiansysteme. Vielleicht braucht’s 
da ja tatsächlich Devuan für?

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Initramfs entfernen ist auch sehr unproblematisch. In grub den Eintrag
>> temporär wegnehmen
>
> Das geht irgendwie bei keinem meiner Debiansysteme. Vielleicht braucht’s
> da ja tatsächlich Devuan für?

Hast du grub, ist es bei Debian noch standard? Beim Grub Menu ist das 
glaub ich die E taste zum editieren, und dann F10 zum booten. Ist aber 
schon länger her, das ich das mal gebraucht habe.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Hast du grub, ist es bei Debian noch standard?

Nein. Und es bootet nicht ohne initramfs – der Bootloader ist da 
unerheblich. Kann’s auch gar nicht, weil da Module drin sind, die’s bei 
mir zum Booten braucht (verschlüsseltes Root-FS, LVM, etc.).

Das mag für den TE okay sein, wenn er eh ’nen eigenen Kernel baut, aber 
den Standardkernel von Debian bootet man wohl nicht ohne initramfs, auch 
ohne meine (eigentlich gar nicht mehr so exotischen) Sachen da.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.