# Wie bescheuert muss man eigentlich sein ...

## fuchur

Hi

Nachdem ich vor Monaten Gentoo nach weit über 10 Jahren den rücken gekehrt habe dachte ich mir vor 3 oder 4 Tagen ich könnte ja mal meine Gentoo Installation

booten und update. Gesagt und getan, und hat auch problemlos funktioniert, weil war ja auch nicht das erste mal. Als ich heute die Gentoo Installation booten

wollte konnte ich dann auf einmal nicht meine verschlüsselte Partitionen mounten. Kurz überlegt, kann also nur an cryptsetup und/oder "/etc/init.d/dmcrypt"

oder "/etc/conf.d/dmcrypt" liegt. Dachte mir also da hast du wohl bei deinem update nicht aufgepasst. Also überprüft

```
genlop -t cryptsetup

 * sys-fs/cryptsetup

     Sun Aug 24 10:33:08 2014 >>> sys-fs/cryptsetup-1.6.2

       merge time: 1 minute and 47 seconds.

     Tue Oct 14 18:49:02 2014 >>> sys-fs/cryptsetup-1.6.5

       merge time: 1 minute and 9 seconds.

     Thu Nov 20 21:09:11 2014 >>> sys-fs/cryptsetup-1.6.5

       merge time: 47 seconds.

     Sun Nov 23 20:07:07 2014 >>> sys-fs/cryptsetup-1.6.5

       merge time: 54 seconds.

     Tue Nov 25 19:13:08 2014 >>> sys-fs/cryptsetup-1.6.5

       merge time: 53 seconds.

     Mon Apr 20 01:37:23 2015 >>> sys-fs/cryptsetup-1.6.5

       merge time: 49 seconds.
```

Nein denke ich das kann nicht sein cryptsetup ist noch das gleiche wie vor einem halben Jahr. Nach einigen Überlegungen und versuchen kam ich dann darauf 

das mir bei meinem update und als Abhängigkeit ein remerge von sys-fs/cryptsetup-1.6.5 ein abgeänderte Version von "/etc/init.d/dmcrypt" untergejubelt worden

ist. Wie dämlich muss man eigentlich sein um ein Programm das seit einem halben Jahr stable ist und so tiefgreifende "Verbesserungen" vorzunehmen das man

sein System nicht mehr entschlüsseln kann ohne die Versionsnummer zu ändern? Jetzt laufen die dafür verantwortlichen wohl komplett Amok, weil noch bekloppter

kann man eigentlich überhaupt nicht sein tiefgreifende Änderungen an eine Programm vorzunehmen ohne die Versionsnummer zu ändern und ein System

unbootbar zu mache geht überhaupt nicht. Hiermit geht es übrigens problemlos "/etc/init.d/dmcrypt"

```
#!/sbin/runscript

# Copyright 1999-2014 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/sys-fs/cryptsetup/files/1.5.1-dmcrypt.rc,v 1.2 2014/10/19 04:37:19 vapier Exp $
```

P.S. 

Bin dann mal wieder wech und boote ein vernünftiges Linux wo die Entwickler etwas mehr Hirn haben und komm nur noch gelegentlich zum meckern vorbei 

(oder auch nicht).

MfG

----------

## mv

Tja: vapier ... auch flameeyes ging wegen ihm, was m.E. ein herber Verlust für gentoo war.

In seinem letzten Gentoo Blog postete er den passenden Link.

Schade, dass Du Dich wegen eines einzelnen Entwicklers von Gentoo abwendest.

Mich hatte er ehrlich gesagt auch fast schon enimal so weit gehabt. Aber ich habe festgestellt, dass es keine vernünftige Alternative zu Gentoo gibt. Sie kommen alle wieder...  :Wink: 

Nur um es klar zu machen: Massive Änderungen an inits ohne Version Bump sind ein klarer Verstoß gegen die "Regeln". Neue Entwickler lernen das in den "Quizzies". Aber vapier ist halt ein Entwickler der ersten Stunde...

----------

## Klaus Meier

Was ist für dich denn ein "vernünftiges Linux"? ich habe ähnliches auch ein paarmal gesagt und war dann ziemlich bald wieder zurück. Und soweit mir bekannt ist, werden einem Änderungen an Dateien im Ordner /etc nicht untergejubelt sondern angeboten. Da kann man doch vorher sehen, was sich ändert und entscheiden, ob du es übernimmst. War das in diesem Fall nicht so?

Ändert aber nichts daran, dass es nicht optimal gelaufen ist.

----------

## toralf

 *fuchur wrote:*   

> P.S. Bin dann mal wieder wech
> 
> MfG

 Wenn Du dann wieder zurück willst/bist und Du so etwas abändern willst, dann bitte gentoo-dev@lists.gentoo.org bzw. IRC : ircs://irc.freenode.net:6697/#gentoo-dev-help, auf (gut) deutsch hier rumheulen ändert vapier nämlich nicht.

----------

## franzf

Mich würde interessieren welches bessere Linux das genau ist  :Wink: 

Ich habe das "beste Linux der Welt" - Suse - versucht, lief auch ganz gut - bis ich alte, unbenötigte Kernel entfernt habe. Der Paketmanager hat ja neue Versionen aufgespielt, interessanterweise aber immer den ältesten gebootet. Als dann ein Kernel-Update nicht wollte, weil ich knallarsch /boot auf ner eigenen (AFAIR 100MB) Partition hatte und die voll war, hab ich mir gedacht "räumste auf". Alte Kernel runtergehauen, sicherheitshalber noch in Bootmanager config gegangen und den neuesten auf Default gesetzt, gespeichert -> "Config updated successfully". Dann sogar sicherheitshalber (!! doppelt hält besser !!) Config Programm neu aufgemacht und gecheckt -> zeigte immer noch den neuesten Kernel an.

Ihr könnt euch denken was beim Reboot passiert ist - ging schief weil der Kernel nicht gefunden wurde  :Wink: 

Der Laptop ist noch immer in unbootbarem Zustand und wartet darauf, wieder mit dem "besten Linux der Welt" (diesmal Gentoo  :Wink: ) installiert zu werden. Glücklicherweise ist /home auf ner eigenen Partition, weshalb es hier keine Probleme geben sollte.

Yeah  :Wink:  Ich liebe Binär-"ich mach das schon richtig"-Distris  :Wink: 

----------

## Josef.95

 *toralf wrote:*   

>  *fuchur wrote:*   P.S. Bin dann mal wieder wech
> 
> MfG Wenn Du dann wieder zurück willst/bist und Du so etwas abändern willst, dann bitte gentoo-dev@lists.gentoo.org bzw. IRC : ircs://irc.freenode.net:6697/#gentoo-dev-help, auf (gut) deutsch hier rumheulen ändert vapier nämlich nicht.

 

Sorry nein. Der #gentoo-dev-help Channel ist nicht dafür vorgesehen Bugs zu reporten, oder Devs zu ändern.

Wenn es einen Bug gibt, dann sollte man den am besten ganz normal auf bugs.gentoo.org stellen.

----------

## Marlo

 *fuchur wrote:*   

> 
> 
> P.S. 
> 
> Bin dann mal wieder wech ...
> ...

 

Du bist hier immer willkommen fuchur   :Smile: 

Und in deinem Herzen weist du es ... Gentoooo ist ..  :Twisted Evil:  geil!

----------

## kernelOfTruth

 *Marlo wrote:*   

> 
> 
> Und in deinem Herzen weist du es ... Gentoooo ist ..  geil!

 

und wie   :Mr. Green: 

Dieses Problem hat mich auch schon mehrmals gestört

aktuelles Beispiel

sys-devel/gcc-4.9.2

pie-patches & patchset von 1.0 auf 1.4 geupdated - immer noch die gleiche version (kein bump auf z.B. -r2)

Entweder gehört in Portage eine Funktion hinein, in der dies auch berücksichtigt wird (toll, noch mehr variablen für diverse Pakete   :Embarassed:  ),

zusätzliche News-Einträge (juhuu ! News-Spam   :Rolling Eyes:  )

oder eben einfach pflichtgemäß ein Bump durchgeführt

----------

## schmidicom

Das eigentliche Problem liegt wohl weniger beim Maintainer sondern viel mehr in dieser Scripthölle von sysvinit, da ist es ja nur eine Frage der Zeit bis irgendwo irgendetwas gewaltig in die Hose geht.

----------

## mv

... und die Systemd-Fanboys hier benutzen jede Kritik, um ihre vollkommen deplazierten Propaganda-Sätze  und Falschinformationen abzuladen.

Was kümmern die  denn Fakten, solange sie nur behauputen können, dass die Nichtbenutzung von systemd an allen Problemen schuld seien.

BTW: Schaut Euch mal in Debian-Listen an, wie der schwachsinnige Umstieg auf systemd den Leuten ihr dm-setup kaputtgehauen hat - und dort kann das natürlich nicht durch Restaurieren eines verschlimmbesserten Initfiles beseitigt werden (so es denn bei Gentoo überhaupt daran lag und das Problem nicht wegen einer ev. hinzugefügten und nicht richtig konfigurierten Option auftrat - analysiert haben wird das Problem ja gar nicht): Unter Debian wäre der einzige Weg der Reparatur die Deinstallierung des Systemd-Schwachsinns, aber dieser Weg ist in Debian von den systemd-Fanboys ja exzellent boykottiert worden.

----------

## schmidicom

systemd hast du jetzt in den Raum geworfen nicht ich, es gibt auch andere (z.B.: epoch) die der Scripthölle den Kampf ansagen.

----------

## mv

 *schmidicom wrote:*   

> systemd hast du jetzt in den Raum geworfen nicht ich

 

Ja, denn Du wolltest Dein FUD nur ganz unterschwellig streuen, und wie alle Propagandisten magst Du es nicht, enttarnt zu werden.

Und Du besitzt sogar noch die Dreistigkeit das Wort "Skripthölle" zu wiederholen, im offensichtlich Versuch, den Eindruck zu erwecken, dass die Aufgabe von /etc/init.d/dmcrypt tief mit anderen Skripten gekoppelt sei und wegfallen würde, wenn man ein anderes Init-System benutzen würde.

Beides könnte fälscher nicht sein:

Die Nicht-Kopplung ist offensichtlich: 1. Das Skript ist nur ein wrapper-für cryptsetup.

2. In vernüftigen alternativen Init-Systemen hat man nach wie vor ein Skript in der Sprache seiner Wahl - ebenso wie bei openrc.

In schwachsinnigen init-Systemen a-la systemd hat man statt dessen eine Binary-Hölle - die in diesem Fall wirklich eine ist, weil sie die Aufgabe von dm-crypt vollkommen unnötig fest verdrahtet - dem Benutzer keine einfache Eingriffsmöglichkeit ohne Patchen von Systmd erlaubend - der entsprechende Code Dutzendfach länger ist und ganz bewusst mit Querverbindungen an 15MB Sourcecode: Hier ist der Begriff "Binary-Hölle" wirklich angebracht.

----------

## Yamakuzure

Leute, bitte. Könnten wir uns vielleicht darauf einigen, dass der Begriff "Scripthölle" leicht ungünstig gewählt war?

Meine Augenbrauen verschwanden auch oberhalb des Haaransatzes, aber eine neue systemd-Diskussion muss doch nicht sein. (Auch wenn mv mal wieder in allen Punkten recht hat.  :Wink: )

----------

## xtrace

Frickelhölle würde sowieso besser passen.

----------

## schmidicom

Auf eine pro/contra-systemd Diskussion lasse ich mich hier nicht mehr ein, das führt bekanntlich zu nix, doch an der Kritik von sysvinit und allem was darauf aufbaut hallte ich fest.

Mit Hilfe eines Scripts einen Hintergrunddienst zu starten ist mit Abstand eine der schlechtesten Ideen die es gibt. Von den vielen redundanten Abläufen welche vermieden werden könnten mal ganz abgesehen ist das Fehlerpotenzial schlicht inakzeptabel. Auch neigen Scripte gern dazu das sie nur noch von dem wirklich verstanden werden der sie geschrieben hat, und manchmal sogar nicht einmal mehr von diesem.

----------

## mv

 *schmidicom wrote:*   

> Mit Hilfe eines Scripts einen Hintergrunddienst zu starten ist mit Abstand eine der schlechtesten Ideen die es gibt.

 

Die alte systemd-Fanboy-Strategie der "moving targets":

Bem Aufruf von cryptsetup bist Du gerade widerlegt worden, und schon wird das Thema gewechselt und so getan, als wenn die Diskussion um etwas ganz anderes gegangen wäre, nämlich um das Starten von Hintergrunddiensten.

 *Quote:*   

> Von den vielen redundanten Abläufen welche vermieden werden könnten

 

Und wieder wird das Thema gewechselt und neuer FUD erlogen.

Butter bei de Fische: Welcher Teil des dmcrypt-Skripts hat redundante Abläufe, die vor allem plötzlich nicht mehr nötig wären, wenn man das Ganze in C implementiert und mit vollkommen überflüssigen Kopplungen an dbus und anderen Mechanismen übersäht wäre?

 *Quote:*   

> mal ganz abgesehen ist das Fehlerpotenzial schlicht inakzeptabel.

 

In einem der folgenden beiden Fälle gibt es ein schlicht inakzeptables Fehlerpotenzial und sogar ein vollkommen überflüssiges Sicherheisrisiko. Es bleibt dem Leser mit gesundem Menschenverstand als Übungsaufgabe überlassen, den richtigen Fall zuzuordnen.

1. openrc: Es wird ein 9K Skript gestartet, das seine Parameter aus /etc/conf.d/dmcrypt liest und entsprechender dieser Parameter genau eine Sache macht: cryptsetup mit geeigneten Parametern aufrufen und ggf. mounten. Wenn das Skript nicht tut, was es soll, kann man es problemlos fixen oder durch eigenen Code ersetzen, ggf. auch in C, wenn man dies bequemer finden sollte.

2. systemd: Es gibt zunächst 17K C-sourcode (wohlgemerkt: speziell und aussschließlich für cryptsetup), dessen zugehöriges Binary dann verschiedene Konfig-Dateien manuell (oder mit Hilfe anderer komplexer Bibliotheken - genau habe ich mir das nicht angeschaut) parst und daraus eine Unit erstellt, der dann mit Hilfe eines weiteren Binaries aus 24K C-sourcecode (auch wieder nur für cryptsetup) letztlich zu einem Aufruf von cryptsetup führt. Dazu braucht man natürlich etliche weitere Units, die die obigen Binaries an den richtigen Stellen ausführen. Das Mounten ist noch einmal eine eigene Komplexitätsgeschichte für sich. Für die vollkommen überflüssige "Kommunikation" zwischen diesen Units wird natürlich dbus benutzt, gekoppelt mit Policykit und einem entsprechenden Sack zugehöriger Regeln, weil natürlich verhindert werden muss, dass der zugehörige überflüssige cryptsetup-Daemon, der permanent läuft und jederzeit cryptsetup oder anderes aufrufen kann und ev. gar Zugriff auf die Passworte hat, von irgendeinem Benutzer missbraucht werden kann - was natürlich durch Hinzufügen des komplexen Policykit-Codes jetzt vollkommen ausgeschlossen ist.

 *Quote:*   

> Auch neigen Scripte gern dazu das sie nur noch von dem wirklich verstanden werden der sie geschrieben hat, und manchmal sogar nicht einmal mehr von diesem.

 

Das gilt für jeden Code in jeder Sprache. Bei C-Code ist das i.d.R. wesentlich schlimmer, vor allem, wenn er sehr komplex wird, mit anderen Programmen auf komplexe Art interagiert und massenhaft eigene und andere Bibliotheken benutzt.

Zugegeben: Init-Skripte in Distributionen werden häufig von Dilettanten geschrieben. Andererseits sind die systemd-Entwickler extreme Stümper. Bis jetzt habe sie noch nicht einmal ein vernünftiges Mounten in den Griff bekommen. Im Vergleich dazu ist der ev. hereingerutschte Bug in dmcrypt vernachlässigbar.

Und der wichtigste Unterschied: Im Fall von openrc kann man das Skript leich selbst reparieren oder durch ein eigenes viel Kürzeres ersetzen, das auf die eigenen Bedürfnisse viel besser zugeschnitten ist. Im Zweifelsfall lautet dieses: 

```
depend() {

  before ... # Je nach Bedarf (bräuchte man bei systemd auch ähnlich)

  needs ... # Je nach Bedarf

}

start() {

  cryptsetup [geeignete Parameter]

  mount [geeignete Parameter]

}
```

Um nochmal auf Dein FUD zu kommen: Zeig mir doch mal in obigem Skript das inakzeptable Fehlerpotenzial, den schwer verständlichen Code, die redundanten Abläufe, die Scripthölle. Oder von aus auch im tatsächlichen dmcrypt-Skript - obwohl man dem schon mit einem gewissen Recht vorwerfen kann, dass es zu allgemein ist und versucht, zu viele Fälle universell abzudecken (aber den Vergleich zu dem Sourcecode-Alptraum von systemd gewinnt es trotzdem noch allemal).

----------

## py-ro

@mv du solltest dich mit deinem FUD Vorwürfen etwas zurückhalten, nur mal als schnelles Beispiel, bei dem Init-Skript unterschlägst den gesamten OpenRC Code der dafür nebenbei geparst und ausgeführt wird.

Und wolltet Ihr den Thread eigentlich nicht in eine systemd Diskussion verwandeln?

----------

## mv

 *py-ro wrote:*   

> @mv du solltest dich mit deinem FUD Vorwürfen etwas zurückhalten

 

Hätte ich gerne gemacht, hätte schmidicom etwas anderes als unqualifiziertes FUD gepostet.

 *Quote:*   

> bei dem Init-Skript unterschlägst den gesamten OpenRC Code der dafür nebenbei geparst und ausgeführt wird.

 

Ebenso wie ich den gesamten systemd-Code unterschlagen habe, der Units startet und ausführt - die Infrastruktur zum Ausführen der Skripte bzw. Units betrachte ich in beiden Fällen als gegeben, denn sie war nicht der Gegenstand des geposteten FUD. Wenn man sie berücksichtigen und vergleichen will, kann man systemd gleich noch ein weiteres Armutszeugnis ausstellen.

Nebenbei:  "der gesamte OpenRC Code der dafür nebenbei geparst und ausgeführt wird" - geparst werden da tatsächlich nur die paar Zeilen Shell-Code von /bin/sh, nicht mehr. Der Code ist wirklich so einfach, wie er aussieht. Es gibt nur noch ein bisschen Infrastruktur drumrum, um die "depends()"-Funktion zu parsen, aber das passiert normalerweise nicht zum Startzeitpunkt.

----------

## ChrisJumper

Kann mir denn jetzt mal jemand erklären was genau das Problem von fuchur mit dem sys-fs/cryptsetup update war?

Hier wurde ja schon darauf hingewiesen das die /etc/init.d oder /etc/config.d zu dmcrypt eventuell verändert wurden.

Aber was war es denn jetzt genau? Ich meine ein verschlüsseltes Dateisystem verwendet vielleicht einen Passwort zu einem Randomstring um den verwendeten Key zu vergrößern. Aber kann es sein das dieser hin einen der Dateien lag und überschrieben wurde? oO

So etwas schreibt man sich doch auf oder hat es notfalls in einem anders verschlüsselten Backup?

----------

## l3u

Das würde mich auch interessieren ;-)

----------

## Josef.95

Hm nee, ist eher unwahrscheinlich. 

```
# portageq envvar CONFIG_PROTECT CONFIG_PROTECT_MASK

/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0

/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo
```

Wenn ich das richtig sehe liegen /etc/init.d/ und auch /etc/conf.d/

unter CONFIG_PROTECT

sprich, die sollte portage bei änderungen normal nicht ohne nachfrage überschreiben.

----------

## fuchur

Hi

Nun habe sie dmcrypt komplett zerlegt. Diese Post ist nur als Info gedacht, falls Leute auch Probleme habe neuerdings Ihr System zu entschlüsseln.

Da der Bug auch schon ewig besteht zeigt das vielleicht auch das gentoo so gut wie keine Nutzer mehr hat (weil wenn man an seine verschlüsselt

Daten nicht mehr drankommt sollte wohl auffallen  :Wink:  ). 

Da ich schon länger gentoo nicht mehr benutze sonder es nur noch gelegentlich boote um es upzudaten ist es mir auch ziemlich egal ....  

Über viele Jahre habe ich die Schlüssel zum entschlüsseln meiner Partitionen auf einer verschlüsselten Partition auf einem USB Stick.

/etc/conf.d/dmcrypt sieht seit vielen Jahren so aus:

```
# stick

# 

target=stick

source=' /dev/by-id/usbstick6'

gpg_options='--decrypt'

key='/keys/stick.gpg:gpg'

remdev='/dev/by-id/usbstick5'

# home

#

target=home

source='/dev/md6'

key='/keys-on-stick/home-key.txt'

remdev='/dev/mapper/stick'

post_mount='cryptsetup luksClose stick' 
```

Wie an der /etc/init.d/dmcrypt herum gespielt wurde konnte ich das relativ schnell durch die alte lösen wie in meine ersten Post beschrieben, nun

nach dem update auf openrc-0.22.4 ist komplett Feierabend. Verschlüsselte Partitionen lassen sich nicht mehr mounten weder mit der

alten noch mit der neuen /etc/init.d/dmcrypt, scheint wohl ein Problem mit "remdev" zu sein da /dev/by-id/usbstick5 und /dev/by-id/usbstick6

vorhanden sind (geprüft!). Habe aber keine Lust das weiter zu untersuchen da ich gentoo eh nicht mehr benutze und es fliegt jetzt von der Platte.

Jetzt ist openrc auf gentoo qualitativ da angekommen wo so ein modernes System wie systemd bei anderen Dist schon lange ist  :Smile: . 

MfG

Ps. Kann man eigentlich seine Benutzeraccount hier im Forum löschen?

----------

## ChrisJumper

Das Problem ist ja ähnlich wie ein Crypto-Trojaner. Mit einem ordentlichen Backup verliert man genau 0 Daten, selbst wenn sich die Platte nicht mehr einbinden lässt.

Zudem wechseln mit der Zeit wohl immer mehr von openrc hin zu systemd. Alle X Jahre kommt dann ja noch hinzu das man den Server/Laptop mal auf neuere Hardware migriert oder Überarbeitet und dann stellt sich so ein Problem ja auch nicht wirklich.

Ich muss aber gestehen das mich so etwas auch sehr geärgert hätte wenn ich davon betroffen gewesen wäre. Eine Vollverschlüsselung wollte ich auch öfters umsetzen, allerdings ist das a nur bei Labtops nötig oder wenn man den physikalischen Schutz der Server/Rechner nicht gewährleisten kann. Normale Sicherheitsprobleme wie Exploits für Root-Zugriffe, dagegen bietet dann auch eine verschlüsselte Platte keinen Schutz, weil das System zu dem Zeitpunkt ohnehin auf diese Partitionen schreiben oder lesen kann.

Von daher nutze ich wenn einfach nur verschlüsselte Dateien mit unterschiedlichen Containern und Passwörtern.

----------

## cryptosteve

Moin fuchur,

 *fuchur wrote:*   

> [ ... ]

 

die Eingangsfrage von Klaus Meier ist noch nicht beantwortet: welche ist denn jetzt Deine neue (aktuelle) Distribution?

----------

## fuchur

Hi

 *cryptosteve wrote:*   

> Moin fuchur,
> 
>  *fuchur wrote:*   [ ... ] 
> 
> die Eingangsfrage von Klaus Meier ist noch nicht beantwortet: welche ist denn jetzt Deine neue (aktuelle) Distribution?

 

Ich habe jetzt Debian Stable, Debian Testing und Mint 17.3 Rose LongTerm alle komplett eingerichtet. Das heißt jetzt nicht das ich damit zufrieden bin aber 

unter den ganzen verkorksten Linux Dists sind Debian und Ablegern die die bei mir am wenigsten Ärger machen. Hinzu kommt noch

das Software Angebot, bei Gentoo wird ja neuerdings alles entfernt obwohl die unterschiedlichen Dist/Quellen die Pakete noch pflegen, Patches

und fixes werden von andern Dist/Quellen in Gentoo nicht mehr übernommen sonder rücksichtslos entfernt.

MfG

----------

## cryptosteve

 *fuchur wrote:*   

> Ich habe jetzt Debian Stable, Debian Testing und Mint 17.3 Rose LongTerm alle komplett eingerichtet. 

 

Danke. Das wären auch meine Favoriten, wenn gleich ich bei Debian wohl gleich auf Stretch und bei Mint gleich auf 18.1 setzen würde. Viel Erfolg damit ...

----------

## ChrisJumper

Für mich ist der größte Vorteil von einem Gentoo eigentlich, das ich bequem jederzeit nachprüfen kann, welcher Code wirklich übersetzt wurde. Das bieten andere Distributionen so nicht. Da müsste man halt immer den Source-Code übersetzten und mit dem Binary vergleichen, wobei selbst das nicht so wirklich dienlich ist.

Letztlich ist Gentoo da sehr gut. Wem das Updaten zu lange dauert, der muss halt einfach seine Computer-Farm zusammen arbeiten lassen und zeitgleich die Pakete speichern. Das geht dann auch. Trotzdem ist es mehr Aufwand und ich kann jeden verstehen der das einsparen will. Zudem ist es ja auch eine größere Energieverschwendung.

Trotzdem, das ist es mir einfach Wert. Allein schon weil sich Patches dank Sourcecode sehr schnell und einfach installieren lassen. Natürlich ist das auch der Fall bei Debian und wenn es ein Problem gibt könnte man immer noch selbst auch dort die Packages selber bauen. Aber wie oft macht man das?

Eigentlich schaue ich immer öfter in den Sourcecode um bestimmte Dinge nachzuprüfen. Das geht halt nicht wenn man im ersten Schritt schon auf Binarys gesetzt hat, oder erst wenn man sich über reverse Engeneering nähert.

Alles in allem wird sehr eindringlich vermittelt wie das alles funktioniert. Allein schon deswegen finde ich es extrem Interessant. Wie viel ist es wohl Wert, wenn dir der Maschinenaufbau gleich logisch Fragen aufzeigt, die sonst in absolutem verborgenen liegen würden?

----------

## fuchur

Hi

Kleine Info wenn jemand sein gentoo nicht mehr entschlüsseln kann 

```

cryptsetup --key-file - ${options} ${arg1} ${arg2} ${arg3}
```

 in 

```

/etc/init.d/dmcrypt 
```

 suchen und abändern in

```

cryptsetup ${options} ${arg1} ${arg2} ${arg3}
```

(auf die Idee muss man erste einmal komme, dieses nach Jahren still und heimlich einfach zu ändern,

war bestimmt eine Arbeitsgruppe weil einer alleine kann überhaupt nicht so...)

Des weiteren ist mit der letzten stable openrc version das root Dateisystem beim booten per default nur readonly gemountet wenn 

```
/etc/init.d/dmcrypt
```

ausgeführt wird. Da hilft auch nicht bei den gpg optionen "--lock-never" oder

"--homedir" anzugeben, habe das aber nicht weiter untersucht. Als Hack/Workaround hilft dem bootloder

ein rw mitzugeben. In etwa so (grub 1)

```

kernel /gentoo/vmlinuz-47.11 rw  root=/dev/was-auch immer
```

MfG

----------

## Roman_Gruber

 *ChrisJumper wrote:*   

> allerdings ist das a nur bei Labtops nötig 

 

Wenn man seine FEstplatten sorglos entsorgen will, oder der Controller usw kaputt wird, ist man besser dran, wenn die Daten zumindest für den LAien nicht zugreifbar sind, sprich mit Luks verschlüsselt.

Bei mir liegt nur root in einem lvm / luks. Der rest ist laut handbuch. mit selbst angepassten init

--

Ich kann ja den Frust verstehen. Nur ist es leider üblich zuletzt, welches die Entwickler immer recht haben.

Zur Zeit beschwert sich eudev / openrc welches es unmöglich ist den FScheck durchzuführen. liegt an dem bescheidenen init usw.

 da ich so und so jetzt vorhabe immer neu das fs zu erstellen, die daten zu kopieren, ist ein fscheck im grunde nicht mehr von nöten. die daten sollten immer alle 2 monate oder kürzer auf eine neues file system kopiert werden.

--

luks ohne anpassung funktioniert seit jahren nicht in gentoo. auf zumindest 3-4 gentoo installationen in den letzten jahren seit 2009.

und nur home zu verschlüsseln ist gelinde gesagt eher unschlau.

gentoo hat so viel müll rumliegen in irgendwelchen ordern die nie und nimmer gelöscht werden obwohl sie temporaere dateien sind, dadurch kann man sehr viele rückschlüsse ziehen. da ich zumeist 99 prozent nur gentoo verwende rede ich jetzt nur von gentoo openrc + eudev + lvm + luks. ob das linux spezifisch ist kann ich nicht sagen

--

empfehlung

wie handbuch

initrd + anpassung von genkernel

root in lvm => dann luks => dann ext4

--

was mehr nervt bei gentoo. zu alte, nicht mehr aktualisierte pakete. ich finde regelmässig pakete welche schon seit 2+ jahren nicht mehr aktualisiert wurden. ob dies schlau ist...

Gentoo sollte irgendeinen prozess haben um pakete auf neue versonen zu prüfen und dies auch dann durchführen.

wenn auf projektseiten wirklich 1zu1 steht wie dies zu kompilieren ist, verstehe ich nicht, warum man nicht einfach ein neues paket , auch als rot markiert in das system gibt.

--

und ja das init ist zum vergessen seit ~6 monaten oder länger.

----------

## artbody

 :Crying or Very sad:  ja das Trauerspiel   :Shocked: 

liegt meines Erachtens in verschiedenen Punkten

1. Never touch a running system  :Wink: 

2. Platons Hölengleichnis 

mal etwas weitläufiger ausgelegt besagt u.a. dass ein jeder von uns in seiner ureigenen Höhle (geistiges Gefängnis) sitzt.

d.h. für einen Entwickler sind manche Dinge so selbstverständlich dass er überhaupt keinen Gedanken dafür aufbringen kann, wie es vieleicht einem einfachen USER damit ergeht. Anderst herrum natürlich genauso. 

So nun kommen tausende von Neuentwicklungen ... jede dieser Neuentwicklungen bringt neue Abhängigkeiten, ersetzt vieleicht altes, oftmals allerdings nicht zufriedenstellend. Die Entwicklung der Eier legenden WollmilchSau läßt auf sich warten.

3. Eitelkeit im Sinne von meine Idee ist die Beste .... 

4. nicht rückwärtskompatibel !!!   :Evil or Very Mad:   :Twisted Evil:   :Rolling Eyes:   :Question:   :Question:   :Question: 

actuelles Beispiel ncurses ... 5er 6er 

wer z.B. CPLD's oder FPGA's z.B. mit Quartus (Altera) programmiert bekommt seit diesem UPDATE mit umgekehrt proportionaler Knallerlogik das Problem, das der Simulator nicht mehr funktioniert ...

Bis das irgendwann dann bei Altera ( VIELEICHT ) geändert oder vieleicht ganz eingestellt wird ( siehe Beispiel Acroreader ) kann der USER schauen wie er mit dem MÜLL zurecht kommt.

JA klar Package mask etc UND DANN ?? meckern 100te programme sie brauchen aber dies oder jenes ..

 :Arrow:  WIESO kann man an der Stelle, wenn NICHT kompatibel , nicht einfach eine Neue parallel zu installierende Version erzeugen usw...

Fragen über Fragen .. also auch Probleme über Probleme.

5. Kleine Verschwörungskunde

Wenn ich, wie es , nennen wir ihn einfach mal: der Herr Billy.M$ , XXoft versucht habe ein Linux , sei es gerichtlich oder sonst wie , mir vom Hals zu halten, meine Marktanteile zu sichern  usw.. und das nicht so fruchtet, so müßte ich doch zu anderen Mitteln greifen ODER ?

Nun eines dieser Mittel dürfte mit Geld ganz einfach zu machen sein: Man sponsert einfach jeden Müll und die Guten etablierten läßt man leer ausgehen. Die welche sich kaufen lassen werden gekauft usw ..

Der Müll gedeiht . 

6. NACH UPDATE IMMER IN TEILEN UNBRAUCHBAR !!!   :Embarassed:   :Embarassed:   :Embarassed: 

bei mir derzeit Quartus und Freecad + noch ein paar

bei Quartus muß da praktisch eine altere instalation auf VM herhalten, welche noch ncurses5 hat.

Freecad hängt am QT4 .. usw

Zusammenfassung der obigen Punkte zeigt deutlich die Diskrepanz zwischen Benutzer , Entwickler sowie Dritter welche von dem Schlammassel profitieren.

und jeder sieht nur das Schattenspiel in seiner Höhle (Platon)

----------

## artbody

 :Laughing:  mal was zum schmunzeln   :Laughing: 

```
Missing power buttons in GTK greeter

The GTK greeter used to have a button to power off / restart the computer in the top right corner. This has been removed from the default configuration in newer versions of the upstream package (bug report). To get it back, adapt the following line in /etc/lightdm/lightdm-gtk-greeter.conf:

/etc/lightdm/lightdm-gtk-greeter.conf

indicators = ~host;~spacer;~clock;~spacer;~language;~session;~a11y;~power
```

gefunden auf https://wiki.archlinux.org/index.php/LightDM

 :Shocked: 

Das gleicht dem Entfernen des Lenkrades weil ja die Innenbeleuchtung defekt ist  :Wink: 

Die Kolbenrückholfedern flattern oder  es Nachts kälter ist als draußen, dies weil das Joghurt ja keine Kräten hat. 

 :Rolling Eyes: 

Und da soll noch einer behaupten da wird mit Hirn gearbeitet..

 :Laughing:  Entwickler ....

Ich hab gerade eine Archlinux VM aufgesetzt weil ich 

Quartus MultiSim (prop. Software in der  neuesten version vom Nov 2017 < = man staune) 

mit seiner Abhängigkeit zu ncurses5.x und ABI 32   :Embarassed: 

zum laufen bringen wollte ohne 100te Packete auf meinem Gentoo neu zu compilieren.

Das Aufsetzen war in kürzester Zeit erledigt, 

aber um diesen Beitrag " Zum Ausschalten des Rechners " im Netz zu finden 

hab ich jetzt 4 Stunden vergondelt

sowas wissen auch nur die Insider   :Mr. Green: 

----------

