Custom-Kernel bei Debian 7 - Sehr viele Bugs

[Misterzde]

Hallo zusammen,

ich hatte mir bei Debian 6 zur Performanceoptimierung und zur Verbesserung der Sicherheit einen eigenen Kernel gebaut. Das funktioniert sehr gut mit den Standardwerkzeugen (make menuconfig, make, make install, etc.)

Debian 7 hat damit leider ein Problem bzw.die Routinen enthalten diverse Bugs.

1. Bei make install wird seit Version 7 der Eintrag in grub.cfg immer mit der uuid für die Disk vorgenommen (anstatt z.B.mit /dev/sda1). Das ist schön und gut und wäre theoretisch auch besser, wenn die Disks öfter mal wechseln - Problem ist nur, dass die UUID falsch generiert wird und das System dann mit dem eigenen Kernel nicht startet. Um das zu beheben, musste ich die Einträge in grub.cfg manuell anpassen.

2. Bei einem kompakten, selbst gebauten Kernel benötigt man keine Initial-Ramdisk (es startet dann schneller ohne). "make install" baut aber immer eine initial-ramdisk, unabhängig davon, ob im Kernel überhaupt eine initial-ramdisk aktiviert ist. Ausserdem wird dann immer diese initial-ramdisk in grub.cfg eingetragen und "gebootet", obwohl sie gar nicht benötigt wird.

3. Der Kernel 3.2 bzw. die Tools von Debian 7 benötigen im Netzwerkbereich jetzt zwangsläufig das "Transformation User Interface".

Insgesamt finde ich diese Entwicklungen bei Linux Kernel 3.2 / Debian 7 sehr unschön. Wird sich ja auch in Distrubutionen wie Ubuntu, etc. fortsetzen, da diese auf Debian basieren.

Ist das ein Thema für den Debian-Support oder ein generelles Kernel-Thema?

VG

Felix

[catdog2]

Das funktioniert sehr gut mit den Standardwerkzeugen (make menuconfig, make, make install, etc.)

Würde dann doch eher.

Code: Alles auswählen

make deb-pkg

empfehlen, bzw. bei dieser alten Version vmtl noch make-kpkg aus kernel-package

1. Bei make install wird seit Version 7 der Eintrag in grub.cfg immer mit der uuid für die Disk vorgenommen (anstatt z.B.mit /dev/sda1). Das ist schön und gut und wäre theoretisch auch besser, wenn die Disks öfter mal wechseln - Problem ist nur, dass die UUID falsch generiert wird und das System dann mit dem eigenen Kernel nicht startet. Um das zu beheben, musste ich die Einträge in grub.cfg manuell anpassen.

Ich weiss nicht was make install da macht aber, wenn das normale update-grub verwendet wird: in /etc/default/grub GRUB_DISABLE_LINUX_UUID (wobei ich kein wheezy mehr hab deswegen nicht 100% sicher obs das da gibt)

2. Bei einem kompakten, selbst gebauten Kernel benötigt man keine Initial-Ramdisk (es startet dann schneller ohne). "make install" baut aber immer eine initial-ramdisk, unabhängig davon, ob im Kernel überhaupt eine initial-ramdisk aktiviert ist. Ausserdem wird dann immer diese initial-ramdisk in grub.cfg eingetragen und "gebootet", obwohl sie gar nicht benötigt wird.

Meiner Erfahrung nach macht das nicht wirklich einen Unterschied.

[Misterzde]

Selbst wenn Du das alles nicht schlimm findest: Es hat sich gegenüber der Version 6 verschlechtert.

Bei Debian 6 war es so:

- Ich konnte den Kernel mit make bauen und mit make install installieren (ggf. dazu noch make modules / make modules install).
- Eine initial-ramdisk wurde nicht angelegt
- Die Einträge in Grub mussten mit update-grub manuell gemacht werden.

Bei Debian 7 hat man es "verschlimmbessert"

- make install erzeugt immer eine Initial-Ramdisk, zumindest dann, wenn es schon mal irgendwann Module gab, die in den entsprechenden Verzeichnissen liegen. Wenn es schlau programmiert wäre, würde nur dann eine Initital-Ramdisk gebaut werden, wenn der Kernel dies auch aktiviert hat....

- make install aktualisiert zudem immer automatisch grub (was ggf. in meinemFall gar nicht gewünscht ist)
- make install erzeugt zudem die Einträge in /boot/grub/grub.cfg "falsch" - "falsch" in dem Sinne, dass eine UUID erzeugt wird, die gar nicht gültig ist (das System bootet so nicht).

Das Problem dabei ist, dass man ggf. zunächst gar nicht merkt, dass es an den Einträgen in grub.cfg liegt, der Fehler im Kernel lautet nämlich sinngemäss "Kann Bootdisk nicht finden", was auch an einem fehlenden Treiber liegen kann, wenn man den Kernel nicht richtig gebaut hat.Dürfte also insbesondere für einen Anfänger sehr verwirrend sein.

Von daher halte ich von der Verschlimmbesserung in Debian 7 gar nichts - es fehlt meiner Meinung nach hier an der nötigen Qualität!

[DeletedUserReAsG]

Ẁeil das Nutzen von selbstzusammengeklöppelter Fremdsoftware (hier Kernel) in Debian nicht exakt so funktioniert, wie du’s gerade gerne hättest, wobei du offensichtlich weder die debianeigenen Werkzeuge zum Bau, noch das Paketsystem zur Installation verwendest, so dass da nicht mal die gröbsten Fehler abgefangen werden könnten – kurz: weil du an Debians System vorbeipfuschst und es dann nicht ganz rund läuft, beschwerst du dich über das Fehlen von Qualität in Debian? Das ergibt keinen Sinn.

Ist das ein Thema für den Debian-Support oder ein generelles Kernel-Thema?

Ich befürchte, es wäre die dritte, fehlende, Option: ein Thema, mit dem du dich mal beschäftigen solltest.

Insgesamt finde ich diese Entwicklungen bei Linux Kernel 3.2 / Debian 7 sehr unschön. Wird sich ja auch in Distrubutionen wie Ubuntu, etc. fortsetzen, da diese auf Debian basieren.

… dann guck’ dir erstmal ein aktuelles Debian oder Buntu an – das wird dich umhauen. Auf die eine oder andere Art

[scnr]

[guennid]

make oldconfig, make menuconfig, make-kpkg und dpkg -i sind meine Werkzeuge. Deine Probleme hatte ich in ca. 10 Jahren nicht. Und was die initrd angeht: das /-Dateisystem darf nicht als Modul gebaut werden, sondern muss fest in den Kern. Habe ich ebenfalls noch nie erlebt, dass eine initrd gebaut wurde, die ich nicht wollte. Und falls ich niemand dahingehend richtig verstehe, dass er empfiehlt, sich mit dem Thema "Kernel bauen" intensiver zu beschäftigen, dann sehe ich das auch so.

Und was den bootloader (hier lilo) angeht, den möchte ich gar nicht eingerichtet haben, den richte ich selber ein.

Grüße, Günther

[Misterzde]

Ẁeil das Nutzen von selbstzusammengeklöppelter Fremdsoftware (hier Kernel) in Debian nicht exakt so funktioniert, wie du’s gerade gerne hättest, wobei du offensichtlich weder die debianeigenen Werkzeuge zum Bau, noch das Paketsystem zur Installation verwendest, so dass da nicht mal die gröbsten Fehler abgefangen werden könnten – kurz: weil du an Debians System vorbeipfuschst und es dann nicht ganz rund läuft, beschwerst du dich über das Fehlen von Qualität in Debian? Das ergibt keinen Sinn.

Man kann immer ein anderes Tool nehmen, das Problem ist einfach, dass etwas daran gemacht wurde und das in schlechter Qualität. Wenn gar nichts dran gemacht worden wäre, wäre es ja O.K.

Aber so ist das einfach Mist, kann man jetzt probieren wegzudiskutieren, die Qualität bleibt aber so oder so Mist...

Wie findest man denn raus, wer die Make-Skripte vom Custom-Kernel verwaltet?

[Misterzde]

make oldconfig, make menuconfig, make-kpkg und dpkg -i sind meine Werkzeuge. Deine Probleme hatte ich in ca. 10 Jahren nicht. Und was die initrd angeht: das /-Dateisystem darf nicht als Modul gebaut werden, sondern muss fest in den Kern. Habe ich ebenfalls noch nie erlebt, dass eine initrd gebaut wurde, die ich nicht wollte. Und falls ich niemand dahingehend richtig verstehe, dass er empfiehlt, sich mit dem Thema "Kernel bauen" intensiver zu beschäftigen, dann sehe ich das auch so.

Und was den bootloader (hier lilo) angeht, den möchte ich gar nicht eingerichtet haben, den richte ich selber ein.

Grüße, Günther

Um das mal auf den Automobilsektor zu übertragen:

Du schreibst im Mercedes-Forum:

"Ich fahre keine Mercedes E-Klasse sondern einen VW Golf, der hat das Problem, dass der V8-Benziner nach 200.000 Kilometern eine durchgebrannte Zylinderkopfdichtung hat in 10 Jahren nicht gehabt, und wenn da Mercedes ein Problem hat, liegt das vermutlich an der schlechten Entgratung des Zylinderkopfs ab Werk (den habe ich bei Mercedes zwar noch nie gesehen, aber bei VW ist das auch so).

Und generell solltest Du dich intensiver mit dem Thema Motoren bei Autos beschäftigen, ich habe neulich den Motorölwechsel selbst gemacht...."

[DeletedUserReAsG]

Wenn du ’nen Autoforenvergleich haben willst:

Du schreibst in dein Benzforum etwa „Ich hab mir einen neuen Motor zusammengebaut, die Werkzeuge hab’ ich von VW genommen. Die Inbussschlüssel passten nicht in die Torxbolzen, da hab’ ich solange draufgekloppt, bis es irgendwie ging – nun ist nix fest und alles klappert, aber raus bekomme ich die Bolzen auch nicht mehr, um’s nochmal ordentlich zu machen – die Qualität von Mercedes ist ziemlicher Mist …“. Das entspricht so ziemlich genau deiner Vorgehensweise mit dem Kernel (incl. der Folgerung bezüglich der Qualität).

[Misterzde]

Wenn du ’nen Autoforenvergleich haben willst:

Du schreibst in dein Benzforum etwa „Ich hab mir einen neuen Motor zusammengebaut, die Werkzeuge hab’ ich von VW genommen. Die Inbussschlüssel passten nicht in die Torxbolzen, da hab’ ich solange draufgekloppt, bis es irgendwie ging – nun ist nix fest und alles klappert, aber raus bekomme ich die Bolzen auch nicht mehr, um’s nochmal ordentlich zu machen – die Qualität von Mercedes ist ziemlicher Mist …“. Das entspricht so ziemlich genau deiner Vorgehensweise mit dem Kernel (incl. der Folgerung bezüglich der Qualität).

Eben nicht, es stimmt eher:

"Ich habe Standardwerkzeuge und Standardschrauben (DIN oder ISO, Torx oder Inbus) bestellt, ein paar Spinner von Volkswagen waren aber der Meinung, dass man unbedingt ein Spezialwerkzeug bräuchte mit passenden Spezialschrauben , das aber aus billigem, weichen Stahl gefertigt, zudem schlecht designed ist deshalb ganz schlecht Drehmoment übertragen kann (schlechter als ein Standardwerkzeug)".

Am Schluss werden wegen diesen Werkzeugen und entsprechenden Schrauben die Zylinderköpfe nur mit dem halben Drehmoment angezogen, in der Folge wird das ganze Zeug dann noch ca. 50.000 Kilometern undicht....

[Misterzde]

Der Ursache für den Mist mit der Initial-Ramfs liegt wohl hier:

root@Debian7:/etc/kernel/postinst.d# more initramfs-tools
#!/bin/sh -e

version="$1"
bootopt=""

[ -x /usr/sbin/update-initramfs ] || exit 0

# passing the kernel version is required
if [ -z "${version}" ]; then
echo >&2 "W: initramfs-tools: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package
} did not pass a version number"
exit 2
fi

# exit if kernel does not need an initramfs
if [ "$INITRD" = 'No' ]; then
exit 0
fi

# absolute file name of kernel image may be passed as a second argument;
# create the initrd in the same directory
if [ -n "$2" ]; then
bootdir=$(dirname "$2")
bootopt="-b ${bootdir}"
fi

# avoid running multiple times
if [ -n "$DEB_MAINT_PARAMS" ]; then
eval set -- "$DEB_MAINT_PARAMS"
if [ -z "$1" ] || [ "$1" != "configure" ]; then
exit 0
fi
fi

# we're good - create initramfs. update runs do_bootloader
INITRAMFS_TOOLS_KERNEL_HOOK=1 update-initramfs -c -t -k "${version}" ${bootopt}
>&2

Man hat hier zwar ein Post-Installation-Script geschrieben, das die initramfs baut, man hat sogar eine Überprüfung vorgesehen, ob $INITRD gesetzt ist und würde dann abbrechen, Problem scheint aber zu sein dass entweder diese Variable nicht sauber gesetzt wird - oder falsch, die Konfigurationsoption in .config ist auf jeden Fall auf nicht aktiv gesetzt:

# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

Von daher ist das Script von Debian sicherlich gut gemeint - in dieser Form ist es jedoch unbrauchbar - da fehlerhaft programmiert...

P.S.

Die Umgebungsvariable scheint gar nicht gesetzt zu sein, zumindest liefert ein echo dieser Variable nichts zurück....

[DeletedUserReAsG]

"Ich habe Standardwerkzeuge und Standardschrauben (DIN oder ISO, Torx oder Inbus) bestellt, ein paar Spinner […]

Dann für den Fall, dass es dir bislang entgangen ist: Wenn du deine Software vom Upstream und ohne Paketmanagement nutzen willst, bist du bei Debian schlicht falsch. Dort ist das Paketmanagement der zentrale Punkt, zusammen mit den knapp 43000 Paketen pro Architektur, welche die Spinner von Debian pflegen und aufeinander abstimmen – damit das richtig zusammen funktionieren kann, sollte man wenigstens die vorgesehenen Werkzeuge hernehmen, und die Software auf Debianart bauen und installieren, wenn man denn schon mit seinen mangelhaften Kenntnissen dran rumfingern muss.

Und wenn jemand meint es besser zu wissen und eben nicht den dokumentierten Weg nimmt, sondern seinen Kram am System vorbeibaut und manuell auf die Platte klatscht, weil „das haben wir immer so gemacht“ (obwohl’s noch nie der richtige Weg war, anschließend ist die Paketdatenbank quasi hinfällig und die Wahrscheinlichkeit groß, dass es früher oder später knallt), dann muss er sich nicht wundern, wenn’s nicht hinhaut. Es ist seine eigene Schuld, und mir erscheint alleine der Gedanke „Wenn ich’s falsch mache, und es geht nicht, ist die Qualität des Systems mies“ geradezu absurd. Such’ oder bau’ dir ein System, was darauf ausgelegt ist und gut.

Kleiner Tipp am Rande: wenn du Codetags für deinen Code verwendest, liest’s vielleicht sogar jemand.

[towo]

Nuja, wenn ich mir die anderen Threads vom TE so ansehe, ist das Alles doch nur konsequent

[Misterzde]

Die Leute wollen das hier wohl nicht verstehen. Der Fehler liegt bei Debian. Die Scripts sind von Debian geschrieben worden und unvollständig und schlecht implementiert worden. Per Default (kernel.org) gibt es nämlich gar keine Routine, die automatisch eine Initial-Ramdisk erzeugt.

Ich teste ja gerade Debian 7 - und umso mehr ich davon sehe, desto weniger will ich es eigentlich einsetzen - dafür ist mir dann doch die Qualität zu schlecht.

Es gibt ja auch noch andere Distribution, die nicht auf Debian basieren....

[schwedenmann]

Halo


Kann es sein, das für die initramfs die Datei zuständig ist ?

/etc/kernel-img.conf

# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = no

Ich denke mal ein "do initrd =no" löst dein Problem.

mfg
schwedenman

[Misterzde]

Halo


Kann es sein, das für die initramfs die Datei zuständig ist ?

/etc/kernel-img.conf

# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = no

Ich denke mal ein "do initrd =no" löst dein Problem.

mfg
schwedenman

Danke für den Tipp

Gerade getestet, das löst das Problem leider auch nicht, das scheint nicht zu "ziehen".

Eine Lösung habe ich ja bereits. Ich kann das Script, das das Update durchführt ja einfach entfernen. Ist halt "unsauber"....

[towo]

Ist halt "unsauber"..

Der war gut, bei komplett unsauberen Vorgehen macht das das Kraut auch nich mehr fett.

[Misterzde]

Das mit der nicht funktionierenden UUID beim Boot scheint mit der "Initital-Ramdisk" zusammenzuhängen:

http://www.linuxquestions.org/questions ... 5D-903023/

UUIDs scheinen nur mit "Initital-Ramdisk" zu funktonieren.

Es war offensichtlich eine poltische Entscheidung bei einem Custom-Kernel auf intitial-Ramdisk zu gehen, UUID kommt dann da wohl automatisch mit.

Schöner wäre es natürlich, wenn dies alles einfach konfiguriert werden könnte (also z.B. einfache Logik --> Keine initial Ramdisk = keine UUID in grub und vice versa....

[DeletedUserReAsG]

Die Leute wollen das hier wohl nicht verstehen. Der Fehler liegt bei Debian. Die Scripts sind von Debian geschrieben worden und unvollständig und schlecht implementiert worden.

Der Leut will‘s wohl auch nicht verstehen: wenn man es richtig macht, gibt es damit keinerlei Probleme. Wenn man davon abweichen möchte, sollte man wissen, was man tut – dann halten sich die Probleme auch in Grenzen. An allem anderen ist man selbst schuld. Wie’s halt überall ist. Mal MacOS in Erwägung gezogen? Das hält einen recht effizient von Systeminterna ab – da ist viel Qualität drin.

[Misterzde]

Die Leute wollen das hier wohl nicht verstehen. Der Fehler liegt bei Debian. Die Scripts sind von Debian geschrieben worden und unvollständig und schlecht implementiert worden.

Der Leut will‘s wohl auch nicht verstehen: wenn man es richtig macht, gibt es damit keinerlei Probleme. Wenn man davon abweichen möchte, sollte man wissen, was man tut – dann halten sich die Probleme auch in Grenzen. An allem anderen ist man selbst schuld. Wie’s halt überall ist. Mal MacOS in Erwägung gezogen? Das hält einen recht effizient von Systeminterna ab – da ist viel Qualität drin.

Gähn, Habe genug von Debian 7 (und gesehen. Teste jetzt mal Slackware....

[Misterzde]

Die Leute wollen das hier wohl nicht verstehen. Der Fehler liegt bei Debian. Die Scripts sind von Debian geschrieben worden und unvollständig und schlecht implementiert worden.

Der Leut will‘s wohl auch nicht verstehen: wenn man es richtig macht, gibt es damit keinerlei Probleme. Wenn man davon abweichen möchte, sollte man wissen, was man tut – dann halten sich die Probleme auch in Grenzen. An allem anderen ist man selbst schuld. Wie’s halt überall ist. Mal MacOS in Erwägung gezogen? Das hält einen recht effizient von Systeminterna ab – da ist viel Qualität drin.

Gähn, Habe genug von Debian 7 (und gesehen. Teste jetzt mal Slackware....

Habe jetzt Slackware drauf. Finde ich besser, da schlanker...

Debian 7 und 8 sind für mich zu fett, geht alles in die falsche Richtung meiner Meinung nach.

Mag Leute geben, die das gut finden und wollen, ich gehöre nicht dazu. Verabschiede mich daher wohl mit der Version 6 von Debian....

[rendegast]

Kann es sein, das für die initramfs die Datei zuständig ist ?
/etc/kernel-img.conf
...
do_initrd = yes
...
Ich denke mal ein "do initrd =no" löst dein Problem.

Das scheint eine mittlerweile (jessie?) obsolete Option zu sein,
ich finde es in noch herumliegenden postinst von 2.6.x-Kernelpaketen.
Im postinst des aktuellen 4.3-Kernelpakets:

Code: Alles auswählen

if (-r "$CONF_LOC" && -f "$CONF_LOC"  ) {
  if (open(CONF, "$CONF_LOC")) {
    while (<CONF>) {
      chomp;
      s/\#.*$//g;
      next if /^\s*$/;

      $do_symlink      = "" if /do_symlinks\s*=\s*(no|false|0)\s*$/i;
      $no_symlink      = "" if /no_symlinks\s*=\s*(no|false|0)\s*$/i;
      $link_in_boot    = "" if /link_in_boot\s*=\s*(no|false|0)\s*$/i;
      $use_hard_links  = '' if /use_hard_links\s*=\s*(no|false|0)\s*$/i;
      $minimal_swap    = '' if /minimal_swap\s*=\s*(no|false|0)\s*$/i;
      $ignore_depmod_err = '' if /ignore_depmod_err\s*=\s*(no|false|0)\s*$/i;

      $do_symlink      = "Yes" if /do_symlinks\s*=\s*(yes|true|1)\s*$/i;
      $no_symlink      = "Yes" if /no_symlinks\s*=\s*(yes|true|1)\s*$/i;
      $link_in_boot    = "Yes" if /link_in_boot\s*=\s*(yes|true|1)\s*$/i;
      $use_hard_links  = "Yes" if /use_hard_links\s*=\s*(yes|true|1)\s*$/i;
      $minimal_swap    = 'Yes' if /minimal_swap\s*=\s*(yes|true|1)\s*$/i;
      $ignore_depmod_err = 'Yes' if /ignore_depmod_err\s*=\s*(yes|true|1)\s*$/i;

      $image_dest      = "$1"  if /image_dest\s*=\s*(\S+)/i;
      $postinst_hook   = "$1"  if /postinst_hook\s*=\s*(\S+)/i;
      $mkimage         = "$1"  if /mkimage\s*=\s*(.+)$/i;
    }
    close CONF;
    $have_conffile = "Yes";
  }
}

'mkimage' scheint nach der Beschreibung darüber das entsprechende

Code: Alles auswählen

my $mkimage           = "";     # command to generate the initrd image

jedoch finde ich bis auf dieses Auslesen weder im Kernelpaket noch in initramfs-tools einen Bezug auf 'mkimage'.
Und '$1' wäre wohl die Option des postinst (imo zBsp. 'configure'),
wohin das aber führen soll?
Nach einer Suche in den kernel-Sourcen, scripts/mkuboot.sh, ist die Rede von einem "Tool mkimage", vielleicht/wohl dem aus u-boot-tools.



Im Falle de TE,
INITRD finde ich in der postinst eines per 'make deb-pkg' erstellten Kernels/Kernelpaketes

Code: Alles auswählen

#!/bin/sh

set -e

# Pass maintainer script parameters to hook scripts
export DEB_MAINT_PARAMS="$*"

# Tell initramfs builder whether it's wanted
export INITRD=Yes

test -d /etc/kernel/postinst.d && run-parts --arg="3.19-custom" --arg="/boot/vmlinuz-3.19-custom" /etc/kernel/postinst.d
exit 0

Eine Paket ohne initrd-Unterstützung (CONFIG_BLK_DEV_INITRD) würde ein INITRD=No mitbekommen, siehe scripts/package/builddeb.

Wie das bei einem 'make install' aussieht?
Das Install-Skript install.sh der linux-Source ruft 'installkernel' (debianutils) auf,
dieses dann /etc/kernel/postinst.d/.
debianutils als Abhängigkeit von bash/dash/cron/initscripts dürfte auf den meisten debian-Systemen vorhanden sein, also auch auf dem des TE.
Ein Skript vor kernel/postinst.d/initramfs-tools könnte auf den kernel testen und entsprechend INITRD=no setzen.
Ob das aber so ginge, daß auch das folgende Skript die Variable benutzen kann?
Alternativ

Code: Alles auswählen

INITRD=No make install
oder
INITRD=No; export INITRD; make install

Von "Sehr viele Bugs" kann keine Rede sein,
ich würde mich wundern, wenn sich slackware mit weniger Lesen als obigem konfigurieren ließe.

3. Der Kernel 3.2 bzw. die Tools von Debian 7 benötigen im Netzwerkbereich jetzt zwangsläufig das "Transformation User Interface".

google: ' linux "Transformation-User-Interface" '
bringt mir da jetzt nicht gerade Schlüssiges.
google: ' linux Transformation-User-Interface '
soll mehrdeutig sein, eventuell was mit ipsec?
Was ist damit gemeint? XFRM_USER "Transformation user configuration interface"?
Scheint aber tiefergehend zu sein sich damit zu beschäftigen,
mit solchen Fähigkeiten hätte TE obige Zusammenhänge auch selbst klären können.