(glöst) jessie Standard-Kern, initrd und Quellen

[guennid]

Wie kriegt man es bewerkstelligt, sich das aktuelle kernel-image für jessie und die entsprechenden Sourcen (für Eigenbau) herunterzuladen. Ich komme mit Debians-Bezeichnerei nicht zurecht. Der Rechner ist ein TP T42.
Ein apt-get -s install linux-image-3.16.* listet mir:

Code: Alles auswählen

Inst linux-image-3.16.0-4-586 [3.16.7-ckt9-3~deb8u1] (3.16.7-ckt11-1 Debian:8.1/stable [i386])
Inst linux-image-3.16.0-4-686-pae (3.16.7-ckt11-1 Debian:8.1/stable [i386])
Inst linux-image-3.16.0-4-amd64 (3.16.7-ckt11-1 Debian:8.1/stable [i386])
Inst linux-image-3.16.7-ckt9 (1.std localhost [i386])
Inst linux-image-3.16.0-4-686-pae-dbg (3.16.7-ckt11-1 Debian:8.1/stable [i386])

Da das thinkpad lediglich über 1GB RAM verfügt und auch keine Mehr-Kern-Maschine ist, sollte 3.16.0-4-586 das passende sein.

Soweit richtig?

Ein apt-get -s install linux-source-3.16.* listet lediglich:

Code: Alles auswählen

Inst linux-source-3.16 (3.16.7-ckt11-1 Debian:8.1/stable [all])

Mit

Code: Alles auswählen

apt-get install linux-source-3.16 linux-image-3.16.0-4-586

hätte ich also das image und die genau dazu gehörenden Sourcen auf der Maschine. Stimmt das so?

Grüße, Günther

[smutbert]

Ja, das müsste passen. Um sicher zu sein, dass es sich um die richtigen Versionen handelt, könntest du dir auch die Abhängigkeiten der Metapakete ansehen, in diesem Fall also, der Pakete linux-image-586 und linux-source:

Code: Alles auswählen

$ apt-cache depends linux-image-586
$ apt-cache depends linux-source

[guennid]

Danke sehr!
Zu vermuten war es ja und sonst hätte ich's auch nicht vermutet. Und dir glaube ich das auch. Was anderes bleibt mir bis zum Gegenbeweis durch Scheitern auch nicht übrig, denn die Beschreibungen der verlinkten Pakete bringen alles andere als Sicherheit - für mich jedenfalls.

Grüße, Günther

[hikaru]

Ich würde dir zum i686-Kernel als Basis raten. Der hat gegenüber dem i586-Kern ein paar nette Features mehr, die v.a. für Multimedia interessant sind.
Einiges davon funktioniert mit dem i586-Kern auf deiner Machine nur, weil Debians i586-Userland teils kaputt ist und in Wahrheit i686 braucht, was deine CPU zum Glück kann.

[guennid]

Danke für den Hinweis! Aber mir geht es hier in erster Linie um die Kongruenz von Standard-Image und Sourcen. Nach deinem Hinweis, werde ich den Nachbau dann mal mit i686 versuchen. Bei der Auswahl der Sourcen stehe ich dann vor dem gleichen "Problem": Welche sourcen brauche ich für den Nachbau des i686-images? Nach dem o.a. sollten es dieselben (

Code: Alles auswählen

linux-source-3.16 (3.16.7-ckt11-1 Debian:8.1/stable [all]

) sein - richtig?

Hintergrund des Ganzen: viewtopic.php?f=12&t=155615. rendegasts Vorschlag überfordert mich zur Zeit. Ich will mal versuchen, einen Standard-Kern lediglich um die Option

Code: Alles auswählen

devtmpfs_mount

zu erweitern. An sich benötige ich keine Standard-Kerne, aber zum Testen der Mängel meiner eigenen in Verbindung mit neuer Hardware sind sie mitunter ganz brauchbar.

Grüße, Günther

[smutbert]

Welche sourcen brauche ich für den Nachbau des i686-images?

Ja, dieselben. Der i686-Kernel unterscheidet sich vom i586er ja nur durch die Konfiguration. Hier
https://packages.debian.org/source/jessie/linux
siehst du welche Pakete alle aus ein und demselben Quellpaket gebaut werden (da ist der amd64-Kernel genauso dabei wie i586 und i686) — ganz unten gibt es das Quellpaket zum Download (ließe sich natürlich auch mit apt-src holen und damit könntest du das Paket für den Debiankernel natürlich auch nachbauen — ist imho aber etwas komplizierter als der normale Weg ein Kernelpaket zu bauen).

Was du auf derselben Seite auf jeden Fall an den Dateinamen des Quellpakets siehst - und darauf wollte ich hinaus

Code: Alles auswählen

File	                               Size (in kB)  MD5 checksum
linux_3.16.7-ckt11-1.dsc              137.3 kB   	04e29ec5087465e45880d565e8e9d75a
linux_3.16.7-ckt11.orig.tar.xz     79,799.7 kB   	dc35fbc127a4f6cd9098c8bf9c7d60a4
linux_3.16.7-ckt11-1.debian.tar.xz  3,023.7 kB   	de585e71d18eef5f392896765f119202

ist, dass linux-source die richtige Version der Quellen installiert:

Code: Alles auswählen

$ apt-cache depends linux-source
linux-source
  Depends: linux-source-3.16
$ apt show linux-source-3.16
Package: linux-source-3.16
Source: linux
Version: 3.16.7-ckt11-1
[…]

[guennid]

Hmmm,
eine Frage hätte ich noch: das i686-image gibt's nur als pae. Dass das per se auf diesem T42 nicht laufen wird ist klar. Und eigentlich will ich auch nur die config (kann man die extrahieren - ohne das image zu installieren?). Dass man mehr als 4GB RAM in die Maschine einbauen KÖNNTE, habe ich zwar nicht geprüft, erscheint mir aber unwahrscheinlich.Kann ich dann die config trotzdem ohne größere Konfigurationsorgien wegen PAE beim Nachbau des images aus den Sourcen verwenden? Ich will z.Z. wie gesagt, lediglich deftmpfs_mount einkompilieren. Wenn dabei doch noch was bedacht werden muss: was?

Grüße, Günther

[hikaru]

das i686-image gibt's nur als pae. Dass das per se auf diesem T42 nicht laufen wird ist klar.

Ich bin ja alles andere als ein Kernelspezialist, aber was diese beiden Aussagen miteinander zu tun haben sollen verstehe ich nicht.
PAE [1] macht es möglich unter x86_32 mehr als 4GB RAM zu nutzen, 4GB sind aber keine Voraussetzung dafür.

Auf ganz ähnlicher Hardware habe ich schon Jessie mit i686-Kernel erfolgreich und problemlos installiert und betrieben.


[1] http://de.wikipedia.org/wiki/Physical_Address_Extension

[KBDCALLS]

Dann versuch mal in einer Virtualbox einen 686 Kernel zu starten wenn PAE nicht aktiviert ist. Das geht in die Hose. Dürfte auf einer echten CPU nicht anders aussehen.

[hikaru]

Die im T42 verbauten CPUs können aber alle PAE. Die Banias' teilen das nur nicht mit.

[guennid]

das i686-image gibt's nur als pae. Dass das per se auf diesem T42 nicht laufen wird ist klar.

Ich bin ja alles andere als ein Kernelspezialist, aber was diese beiden Aussagen miteinander zu tun haben sollen verstehe ich nicht.

Guckst du im anderen Thread. Meine Behauptung bezog sich nicht speziell auf i686-pae, sondern auf Standard-Kernel-Image. Ich hätte besser formulieren sollen: "Dass das per se auf diesem T42 genauso wenig laufen wird, wie das i586 Standard-Image ohne pae ist klar". Aber wenn du weißt, dass das pae beim T42 keine Zicken macht, ist ja gut.

Ich hatte einen Internet-Artikel gelesen, in dem genau das, was KBDCALLS anspricht, passiert war: Die (alte) Maschine vertrug keinen pae-Kernel. Ich hoffe du ersparst mir die neuerliche Suche.

Grüße, Günther

[guennid]

Au Mann!

Ich habe bisher nur mit Vanilla-Sourcen gearbeitet. Da muss man sich ja an einiges umgewöhnen!

Also: ich habe die sourcen heruntergeladen (mit apt-get -d). Da ich mir nicht sicher war, was er eigentlich macht, wenn ich das jetzt "installiere", habe ich das deb aus /var/cache/apt/archives nach /usr/src kopiert und entpackt. Dabei erhielt ich - möglicherweise - zwei neue "Dinge":

einmal eine Datei namens linux-source-3.16.tar.xz. Wenn ich das wieder auspacke, dann erhalte ich eine Verzeichnisstruktur, die dem entspricht, was ich beim Auspacken der Sourcen von kernel.org gewohnt bin. Soweit richtig?

zum anderen ein Verzeichnis namens linux-config-3.16. Wenn ich mir den Inhalt anschaue, dann sieht das verdächtig nach einer Sammlung von gepackten .configs für die verschiedenen Architekturen aus - also genau das, was ich suche, um an eine Standard-config OHNE den Umweg über die Installation des kompletten Images zu kommen.
ABER: für i686 finde ich NUR den merkwürdigen Bezeichner

Code: Alles auswählen

config.i386_none_686-pae.xz

Ist das die Standard-Config für i686-PAE?

Grüße, Günther

[smutbert]

Ja, davon würde ich ausgehen. Der erste Teil des Anhängsels dürfte die Rechnerarchitektur sein (i386), beim zweiten (none) habe ich keine Idee und der dritte dürfte für die CPU (686-pae) stehen.

[guennid]

Na, dann will ich mal. Und wollen wir hoffen, dass wir beide richtig spekuliert haben.

Grüße, Günther

[guennid]

Wenn ich devtmpfs_mount einkompilieren will, sagt mir die Hilfe von make-menuconfig:

Code: Alles auswählen

This option does not affect initramfs based booting, here the devtmpfs filesystem always needs to be mounted manually after the rootfs is mounted.

Heißt ja wohl: Einkompilieren nutzt nix, wenn initramfs, also initrd benutzt wird. Dumm ist sie nicht, die gnome-udev-systemd-Mafia. Sie weiß, wie sie einem Apostaten das Leben schwer machen kann. (devtmpfs:mount=1 hatte ich dem bootloader schon erfolglos mitgegeben, bevor ich mich im Kernel-Bauen versuchte). Mal schauen, ob ich einen "Standard-Kern" ohne initrd gebacken kriege. Das mache ich automatisch schon so lange, dass ich mir die config-Optionen jetzt erst mal wieder zusammensuchen darf.

Grüße, Günther

[smutbert]

Hast du es ausprobiert?

Ich könnte mir vorstellen, dass damit gemeint ist, dass nach dem Abarbeiten der initrd und dem Mounten des echten /-Dateisystems devtmpfs nicht mehr automatisch gemountet wird und dass die Kernelentwickler davon ausgegangen sind, dass eine initrd auf jeden Fall ein eigenes /dev mountet, egal ob statisch oder dynamisch in Form eines udev-ähnlichen Dienstes und allein aus diesem Grund das vorherige automatische Mounten des devtmpfs keine Wirkung zeigt.

edit
hm andererseits hätte dann wohl devtmpfs.mount=1 Wirkung zeigen müssen

[KBDCALLS]

Wenn dann sollte man auch alles lesen.

Das ist der komplette Text.

Code: Alles auswählen

This will instruct the kernel to automatically mount the devtmpfs filesystem at /dev, directly after the kernel has mounted the root filesystem. The behavior can be overridden with the commandline parameter: devtmpfs.mount=0|1. This option does not affect initramfs based booting, here the devtmpfs filesystem always needs to be mounted manually after the rootfs is mounted. With this option enabled, it allows to bring up a system in rescue mode with init=/bin/sh, even when the /dev directory on the rootfs is completely empty.

Das funktioniert ja auch so wie gedacht. Macht bei einer initramfs keinen Sinn weil hier das /dev/ komplett leer sein kann.

[smutbert]

Naja, wäre /dev nicht auch auf einem /-Dateisystem möglicherweise erst einmal leer, wenn man devtmpfs verwenden will? Bei dem alten devfs (das es nicht mehr gibt, das ich aber gerne verwendet habe und das ja denselben Zweck erfüllt hat) habe ich jedenfalls /dev auf der /-Partition immer leer gelassen.

Irgendwie will sich mir in diesem Zusammenhang der Unterschied zwischen initrd und /-Dateisystem auf einem normalen Massenspeicher nicht so recht erschließen. Ich habe mir das so vorgestellt, dass im Falle des Bootens der Reihe nach

• der Bootloader Kernel (und gegebenenfalls die initrd) lädt
• der Kernel startet
  • Das /-Dateisystem mountet, entweder die initrd oder von einem Massenspeicher
  • devtmpfs automatisch einbindet
• es danach normal mit dem Systemstart weitergeht, entweder indem das init auf der initrd oder das auf dem Massenspeicher ausgeführt wird

Mir ist klar, dass das jetzt stark vereinfacht wird und es liegt mir auch fern den Thread entern zu wollen, aber irgendwo im Unterschied zwischen mit und ohne initrd muss doch guennids Problem begründet sein und diesen Unterschied vermag ich nicht zu erkennen.

[guennid]

@KBDCALLS

Ich hatte schon alles gelesen, aber verstanden habe ich es nicht.

Nachdem der 1. Eigenbau-Kern mit initrd nicht wollte (war aber möglicherweise auch Fehler meinerseits), habe ich jetzt kurzerhand auch die noch wegkompiliert. Aber das Kompilat läuft noch: ca vier Stunden auf der alten Maschine.

Grüße, Günther

[KBDCALLS]

Wenn man sich den Inhalt einer Initrd listen läßt, dann gibt es noch nicht mal ein /dev . Und da dürfte es auch keinen Sinn machen das devtmpfs automatisch mount zu lassen.

[guennid]

Und da dürfte es auch keinen Sinn machen das devtmpfs automatisch mount zu lassen.

Ich weiß nicht, was du jetzt mit "da" meinst, aber meine Eigenbaukerne funktionieren ausnahmslos ohne initrd und mit devtmpfs, was gebraucht wird, wenn man keine initrd nutzen will. Kann es sein, dass du das nicht benutzt (ein debian ohne initrd)?

Ich kriegs nicht gebacken. Ich schaffe es nicht, diesen Kern ohne initrd zu bauen
Ich denke, hier hängt's:
lspci:

Code: Alles auswählen

00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)

Ich vermute, ich kriege es nicht geregelt, das fest einzukompilieren. Ich schreibe die configs meiner Kerne seit Jahren fort und jetzt habe ich nicht mehr im Kopf, wie ich sie zur Umgehung der initrd konfiguriert habe und dummerweise habe ich es mir nicht aufgeschrieben, vielleicht auch nur vergessen, wohin . Dass das /-Dateisystem fest drin sein muss, ist alles, was ich erinnere.

Grüße, Günther

[KBDCALLS]

Es gibt ja mittlerweile einen ganzen Zoo an Optitonen mit denen man den Kernel konfigurieren kann.

Code: Alles auswählen

localyesconfig  - Update current config converting local mods to core

Weitere Optionen

Code: Alles auswählen

make help

Achtung ohne -- Ansonsten erhält die Hilfe von /usr/bin/make selbst , anstatt die des Make der Kernelsourcen.

[guennid]

Code: Alles auswählen

localyesconfig

diese Option werde ich nicht mehr benutzen. Ich verstehe die nicht ohne eine gute deutsche Beschreibung, die ich bisher nicht kenne/erinnere.

[KBDCALLS]

Ne Deutsche Beschreibung kann auch nicht klarer sein. Es wird die Konfig eines laufendenden Kernels genommen und die dann so abgeändert das die Module fest in den Kernel kompiliert werden. Wie Sinnvoll das ist, das sei mal dahingestellt. Da halte ich localmodconfig für Sinnvoller

[guennid]

Es wird die Konfig eines laufendenden Kernels genommen und die dann so abgeändert das die Module fest in den Kernel kompiliert werden.

Abgesehen davon, dass sich mir der Sinn einer sochen aktion nicht recht erschließt, ist das nicht das, was ich hier benötige: Ich möchte einen jessie-Standard-Kern nur soweit modifizieren, dass er ohne initrd durchbootet. Das von Debian geliefert Kernel-Image bootet aber dank udev nicht durch. Ergo habe ich keinen laufenden Standard-Kernel. Ich wiederhole mich: Es sind wenige Optionen (3-6, habe ich mal gesagt), die man der config als fest einzukompilieren mitgeben muss. Man muss halt nur wissen, welche. Eine ist das root-Dateisystem.