staging.inyokaproject.org

Normalerweise befindet sich diese Datei im Stammverzeichnis der Kernelquellen. Mit dem obigen Einführungsbeispiel also im Pfad: /usr/src/linux-source*/.config

Das Einführungsbeispiel ist ein toter Link, die genannte Datei ebenso, weil nun wohl /usr/src/linux-source-*/debian.master/config/amd64/config.flavour.generic gemeint ist? Allerdings widerspricht sich sowohl der Umfang der Datei als auch der Ort der Datei mit der obigen Angabe, dass die .config aus /boot kopiert werden soll, was dann wohl die Ubuntu-spezifische Kernel-Konfiguration sein dürfte?

Und die Aussage

make xconfig - Qt-Oberfläche, komfortabler als gconfig, da es sich um eine vollwertige GUI-Oberfläche handelt

kann ich so nicht bestätigen - es ist wohl eher genau dasselbe bis auf ein zusätzliches find-Menü sowie bereits die Dreifensteransicht aktiviert, was gconfig aber auch kann. Die zusätzliche Suchfunktion ist allerdings ein echtes Plus und könnte man im Artikel erwähnen. Die GtK-Suche kann das auch, ist aber nur umständlich zu erklären: Alle Menüs aufklappen lassen, dann erst STRG + F und Suchbegriff tippen, mit Pfeil-nach-unten zum nächsten Treffer.

Nebenbei, lustige Fehler gibt es bei der Installation der libs für beide GUIs im Wiki auch noch:

Entpacken von libgles1:amd64 (1.0.0-2ubuntu2.2) ...
dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-CXR1dr/073-libgles1_1.0.0-2ubuntu2.2_amd64.deb (--unpack):
 Versuch, »/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1« zu überschreiben, welches auch in Paket nvidia-340 340.106-0ubuntu3 ist
Vormals nicht ausgewähltes Paket mesa-common-dev:amd64 wird gewählt.
[...]
Entpacken von libglvnd-dev:amd64 (1.0.0-2ubuntu2.2) ...
dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-CXR1dr/077-libglvnd-dev_1.0.0-2ubuntu2.2_amd64.deb (--unpack):
 Versuch, »/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so« zu überschreiben, welches auch in Paket nvidia-340 340.106-0ubuntu3 ist
Vormals nicht ausgewähltes Paket libx11-xcb-dev:amd64 wird gewählt.
[...]
Fehler traten auf beim Bearbeiten von:
 /tmp/apt-dpkg-install-CXR1dr/073-libgles1_1.0.0-2ubuntu2.2_amd64.deb
 /tmp/apt-dpkg-install-CXR1dr/077-libglvnd-dev_1.0.0-2ubuntu2.2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Es funktioniert aber wegen vorhandener Nvidia-Treiber. Sollte also jemand die Nvidia-Treiber nutzen, sie deinstallieren und es dann nicht mehr funktionieren, müssen sicherlich diese beiden Pakete installiert werden, worüber sicherlich ein Fehler über fehlende Dateien unterrichtet. Selbes könnte passieren, wenn man ein mobiles System an einem anderen Rechner/ Hybridgrafikkarten/ nach Wechsel andere Grafikkarten benutzt. Nur so als Hinweis, wenn mal jemand in die Diskussion schaut und auch das Problem hat.

Edit (für's Log): Fehler wurde vor 14h via Updates behoben (zuvor musste man nvidia mit dpkg kicken, wenn Updates nicht durchliefen).

Würde ich soweit bestätigen, ohne die Quellen zu sichten:

• make-kpkg brauchte um die 26 GB und schien noch nicht so weit gekommen zu sein - nach vielen Stunden (so 8?) brach ich ab, aber zu früh, siehe unten

• die neue Variante brauche auf externer USB 2.0 Platte zwar auch 12-18h, lief dann aber durch und es brauchte mit 22 GB 4 GB weniger

• Kernel lies sich installieren und läuft

Die neue Variante ist vielleicht doch nicht besser oder schneller, aber sie schluckte schon mal weniger Speicher. Das sind ja enorme Mengen, die 5 GB im Wiki scheinen auch nicht mehr aktuell zu sein?

Pancalia schrieb:

Auch bei mir funktioniert die Angabe "make-kpkg --initrd buildpackage" nicht (es wird absurd viel Plattenplatz belegt und kommt zu keinem Ende).

Dagegen habe ich

"make

make deb-pkg"

erfolgreich getestet.

Weitere Hinweise, dass "make-kpkg" veraltet ist: https://debian-handbook.info/browse/de-DE/stable/sect.kernel-compilation.html

http://debianforum.de/forum/viewtopic.php?f=33&t=143461&start=15

https://scalability.org/2015/01/parallel-building-debian-kernels-and-why-its-not-working-and-how-to-make-it-work/

https://github.com/coldhakca/coldkernel/issues/24

http://unix.stackexchange.com/questions/115961/debian-ubuntuhow-to-compile-a-linux-kernel-on-one-machine-and-use-on-other-mach

https://www.reddit.com/r/debian/comments/4889ar/how_to_upgrade_to_44_kernel_on_debian_8/

Also Leute, bitte überprüft das doch mal, sei es per Recherche oder durch eigenen Test. Ansonsten - da ich kaum der einzige mit diesem Problem sein werde - werde ich zumindest einen Hinweis in den Artikel setzen.

Danke

Ab 2020 wird es neu mit Win ja nur noch Secure Boot Geräte geben, wo sich das nicht abstellen lässt. Die selbstgebratenen Kernel muss man dann signieren. Dieses ubuntu.com-Blog beschreibt das und die zukünftigen Aussichten für DKMS ganz gut:

https://blog.ubuntu.com/2017/08/11/how-to-sign-things-for-secure-boot

Vielleicht könnte man den Link mit in den Artikel einfügen oder steht in den vielen Links schon was versteckt dazu? Im ersten jedenfalls nicht. Falls doch, könnte man hinter den Link noch ergänzen, dass er auch "sign things for Secure Boot" enthält.

Mal 4 Wochen warten und dann könnte es der nächste, der es hier sieht, einfach selbst ergänzen, wenn bis dahin noch kein Feedback hier gekommen ist.

Hallo,

Update: Da ich erst im Nachhinein gemerkt habe, dass ich im "falschen Thread" gelandet bin...

Meine Anfrage befindet sich jetzt unter: https://forum.ubuntuusers.de/topic/mainline-kernel-signieren-uefi/

Bezüglich Wiki: Es wäre super, wenn im Wiki die Beschreibung der Kernelsignierung (UEFI) ergänzt werden könnte! Vielen Dank.

Wenn jemand dazu etwas schreiben möchte, gerne. Ggf. macht es aber Sinn, das in einen eigenen Artikel zu packen. Ist vermutlich einfacher zu testen.

Hallo,

Xenial ist aus dem Getestet-Block raus. Der Artikel ist somit ungetestet.

LG
tuxifreund

Seit längerem ungetestet → archiviert.

Gruß, noisefloor