staging.inyokaproject.org

Das Thema zieht seine Kreise und führt mich hierhin zurück.

Ich habe keine initrd.img* in /boot.

Scheinbar wird diese mit make-kpkg nicht erzeugt und/oder nicht in das deb gepackt.

Es gibt wohl einen extra --initrd Parameter für make-kpkg. Diesen werde ich ausprobieren.

Die Frage ist allerdings, warum geschieht das nicht automatisch? Warum sollte man einen Kernel bauen, mit debs und allen drum und dran, aber keine initrd? Das läuft doch ohne initrd gar nicht. Warum wird das alles ohne Fehlermeldung installiert und lässt mich (und ne Menge anderer Leute) tagelang damit beschäftigen, warum das root-fs nicht gemounted werden kann?

MoonKid schrieb:

Die Frage ist allerdings, warum geschieht das nicht automatisch? Warum sollte man einen Kernel bauen, mit debs und allen drum und dran, aber keine initrd? Das läuft doch ohne initrd gar nicht.

Man kann durchaus Kernel bauen, die keine initrd benötigen. Hab ich z.B. auf meinem Desktop-PC so. Warum soll dann automatisch eine initrd gebaut weden, wenn ich gar keine brauche? Steht übrigens auch im Artikel: ab Kernel/Kompilierung (Abschnitt „Kernel-kompilieren“) bzw. ab Baustelle/Kernel/Kompilierung (Abschnitt „Kernel-kompilieren“)

Ah, langsam wirds helle. 😀

Dickes Danke für die Erklärung.

Kernel läuft - ohne Bauen mit root oder fakeroot.

Kurze Wiki-Frage:

Wann benutze ich die Vorlage "befehl" und wann "code Bash"?

Komme da etwas durcheinander. 😉

z.B. Ich möchte die Ausgabe von "ls" (also den Verzeichnisinhalt) in einem Wiki-Artikel zeigen.

z.B. Ich möchte einen simplen Befehl zeigen, den der Leser selbst ausführen soll/kann, ohne die Ausgabe des Befehls zu zeigen.

Hallo,

Wann benutze ich die Vorlage "befehl" und wann "code Bash"?

Befehl halt Shell-Befehle, "Code Bash" für Code-Listings (wie z.B Skripte).

Ausgabe von Shell-Befehlen kommen in eine

{{{#!code
foo
bar
}}}
Box

Gruß, noisefloor

So, wie jetzt aktuell im ersten Abschnitt des Artikels?

Hallo,

nicht ganz. Die Code-Box ist so nicht richtig. Korrekt:

ls -ld /usr/src/linux-source* 

drwxr-xr-x 4 root root 4096 Mär 22 13:54 /usr/src/linux-source-3.5.0
lrwxrwxrwx 1 root root   45 Mär 20 01:07 /usr/src/linux-source-3.5.0.tar.bz2 -> linux-source-3.5.0/linux-source-3.5.0.tar.bz2

Gruß, noisefloor

noisefloor schrieb:

nicht ganz. Die Code-Box ist so nicht richtig. Korrekt:

Hättest du es gleich im Artikel geändert, müsste ich jetzt nicht nochmal fragen. 😉

Ist es jetzt korrekt?

Hallo,

Ist es jetzt korrekt?

Nee, falsch. Es fehlten alle Befehls-Boxen...?!? Ist korrigiert.

Hättest du es gleich im Artikel geändert, müsste ich jetzt nicht nochmal fragen.

Learning by doing. Es ist ja mittelfristig nicht Sinn der Sache, dass du als User den Inhalt besteuerst und wir als Wikiteam die komplette Syntax korrigieren. Deshalb gibt's bevorzugt Hilfestellung und kein "All in" Paket ☺

Gruß, noisefloor

noisefloor

Es fehlten alle Befehls-Boxen...?!?

So hab ich dein etwas unkonkret formuliertes Posting aber interpretiert. 😉 Konkreter Code (also Versionsvergleich im Wiki) ist da einfacher zu interpretieren.

Deshalb gibt's bevorzugt Hilfestellung und kein "All in" Paket ☺

THX!

Der Ursprung meiner Frage bezieht sich auf diesen Thread http://forum.ubuntuusers.de/topic/nach-dist-upgrade-grub-witzig-ueberladen/

Ich habe hier Kubuntu. Dieses läuft allerdings mit einem selbstgebauten Kernel. Scheinbar weiß dieser nicht, dass er Kubuntu ist. 😉

Wenn per apt-get ein neuer Kernel (bzw. Header) installiert und daher update-grub ausgeführt wird, entsteht im Grub-Menu neben dem Kubuntu-Eintrag noch ein Ubuntu-Eintrag. Bereinigt werden kann dies, wenn ich unter dem laufenden generic-Kernel ein update-grub ausführe.

An welcher Stelle, muss man beim Kernel-Bauen ansetzen, damit dieser weiß, dass er zu einem speziellen Ubuntu-Derivat gehört und wiederum grub-update die Einträge korrekt behandelt?

Hi MoonKid,

du schriebst:

[...] An welcher Stelle, muss man beim Kernel-Bauen ansetzen, damit dieser weiß, dass er zu einem speziellen Ubuntu-Derivat gehört und wiederum grub-update die Einträge korrekt behandelt?

Garnicht, da musst du dir die GRUB-Skripte (vermutlich 10_linux) anschauen wie das gemacht wird.

Gruss Lasall

Das hilft nicht wirklich weiter. Es gibt die Variable $GRUB_DISTRIBUTOR welche in dem Script selbst aber nie gesetzt wird. Dies wird in /etc/default/grub mit lsb_release -i -s gesetzt.

Haut aber nicht ganz hin.

Im Eigenbau-Kernel gibt es ein Symbol

Symbol: VERSION_SIGNATURE [=Ubuntu 3.8.0-19.29-generic 3.8.8] 

lsb_release -a spuckt aber das hier aus

user@pc-kubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 13.04
Release:        13.04
Codename:       raring

Woher bezieht lsb_release seine Info?

Theorie zurück!

Auch mit dem generic-Kernel wird "Ubuntu" und nicht "Kubuntu" zurückgeliefert.

Linux pc-kubuntu 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:36:13 UTC 2013 i686 athlon i686 GNU/Linux
raring
Ubuntu 13.04 \n \l

user@pc-kubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 13.04
Release:        13.04
Codename:       raring

Scheinbar hab ich die GRUB2-Skripte doch noch nicht verstanden. 😉

Also ich hab mir das Skript nochmal angeschaut, aber ich verstehe überhaupt nicht wie in meinem GRUB2-Menü ein Kubuntu-Eintrag zustande kommt.

Hi MoonKid,

das gehört dann eher in den Supportbereich. Auf Anhieb kann ich dir nicht sagen, wie die Variablen dort gesetzt werden, ich würde mich mit grep und "set -x" durchhangeln.

Gruss Lasall