Siduction Forum
Siduction Forum => Ideas & Improvements => Topic started by: bluelupo on 2013/06/16, 14:34:35
-
Hallo zusammen,
hier mal von mir ein Verbesserungsvorschlag der die Bezeichnung unserer Distri schon im Grubmenü anzeigt (/etc/default/grub).
So ist z.zt. Standard:
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
...das zeigt "Debian" an, wenn "lsb_release" installiert ansonsten "Debian"
So siehts etwas schicker auf unsere Distri bezogen aus:
GRUB_DISTRIBUTOR=`cut -d'-' -f1 /etc/siduction-version 2> /dev/null || echo Debian`
...das zeigt "siduction 12.1.1 Desperado Reloaded" als Standard an, ansonsten "Debian"
-
Klasse Tipp!
Das sieht doch viel "gefälliger" aus und in einem Multibootsystem
vereinfacht es die Bootauswahl merklich.
Danke @bluelupo! :D
-
....und das wäre auch noch schön, wenn dies im nächsten Release mit eingepflegt werden könnte :-)
-
Kleiner Tipp, schreibs ins Chili als Whishlist-Bug, dann gehts nicht unter.
-
@towo: mache ich
Hier unter http://chili.siduction.org/issues/1257
-
Danke für den Tipp, sieht gut aus so bei Multiboot.
Mich hatte das auch schon öfter gestört, ich bin irgendwie daran hängengeblieben dass ich statt der /etc/default/grub eher was mit dem verwendeten lsb-release machen wollte. man lsb_release spricht irgendwo davon, dass man den Distributor selbst nennen könnte, dass siduction also "sich da rein schreiben könnte". Habe das dann aber nicht weiter verfolgt.
-
Kann man auch und wäre der richtige Weg
-
Also ich hatte bislang
GRUB_DISTRIBUTOR=`awk -F '(' '{ print $1 }' /etc/siduction-version`
in der /etc/default/grub stehen, weiß nicht mehr wo ich das her hatte.
-
iss wahrscheinlich von hier:
http://forum.siduction.org/index.php?msg=27319#27319
Aber was auch noch nervt an den neuen "übersichtlicheren" Grubeinträgen ist daß weder Kernelversion noch Festplattenpartition angezeigt werden. Meiner bescheidenen Meinung nach ist diese neue Übersicht alles andere als ein Fortschritt.
Meine bootliste sieht nun -gekürzt- in etwa so aus:
siduction 12.1.1 Desperado Reloaded - kde -
Debian (jessy/sid)
Debian (jessy/sid)
Debian (wheezy/sid)
Wobei eins tatsächlich ein oldstable, eins mein "oldsiduction" Rettungssystem und eins meine Testpartition ist -Super, ich weiß nur nie was ich gerade boote.
Gruß
ayla
-
Ich habe mal statt /etc/default/grub zu verändern an der ausgelesenen "Quelle" geschraubt und eine Datei /etc/lsb-release mit folgendem Inhalt angelegt:
DISTRIB_ID=siduction
DISTRIB_RELEASE=2013.1
DISTRIB_CODENAME=Firestarter
DISTRIB_DESCRIPTION="siduction 2013.1 FS"
Das gibt mit siduction-eigenem grub den Wert "siduction GNU/Linux" an die Menüzeile weiter, bei Multiboot von anderen Systemen holt os-prober die Zeile "siduction 2013.1 FS"
-
Hi der_bud,
kann man machen mit der /etc/lsb-release, aber die Bezeichnung "siduction GNU/Linux' ist mir nicht aussagekräftig genug. Die Configdateien unter /etc/default sind ja genau zu diesem Zweck eingerichtet, das man Defaults setzen kann und wieso sollte ich die nicht ändern.
-
@bluelupo: Unglücklicherweise siehst Du das mit den defaults zwar prinzipiell richtig, die Realität sieht aber anders aus. Die Defaults werden von der Distribution gesetzt. Das ist bei uns meist Debian. Die Datei "lsb-release" wird in debian normalerweise nicht verwendet. Durch das "oder" wird dann bei Nichtvorhandensein einfach Debian in Grub gemalt.
Generell würde ich davon abraten, in den defaults zu ändern, wenn es nicht wirklich sein muss, das macht einem mehr oder weniger den Update-Pfad ohne Eingriffe kaputt.
-
Generell würde ich davon abraten, in den defaults zu ändern, wenn es nicht wirklich sein muss, das macht einem mehr oder weniger den Update-Pfad ohne Eingriffe kaputt.
Verstehe ich das richtig, bei Aktualisierungen des Grub2 auf die nächste Version wird also durch meinen Eingriff in die /etc/default/grub das dann nicht gemacht bzw. die "Veränderung" wieder überschrieben?
Ich habe auch die Lösung von @der_bud ausgetestet.
Daran imponiert mir, im Gegensatz zu @bluelupo, der os-prober
anderer Systeme liest tatsächlich die letzte Zeile aus.
Ich nehme an, der Anwender muß sich auch hier selbst um Aktualisierungen kümmern.
Vielen Dank euch 'dreien für die hier "in Gang" gebrachte
Diskussion. :wink:
-
@all
eine mögliche Lösung könnte mit dem Paket liblinux-distribution-perl, einem Patch dazu, und einer neu anzulegenden /etc/siduction-release generiert werden.
siehe auch Chili (http://chili.siduction.org/issues/1257)
Der Output eines Scripts wie distro.pl könnte anstatt lsb_release in Grub eingebaut werden.
gruss ab
-
Es gibt auch die Möglichkeit, einfach die Standards zu nutzen, die in grub2-mkconfig seit Jahren verbaut sind und von debian nicht genutzt werden. Diese Lösung ist momentan mein Favorit, da wir a) keine zusätzliche Software benötigen und b) debian nicht in die Quere kommen.
-
Es gibt auch die Möglichkeit, einfach die Standards zu nutzen, die in grub2-mkconfig seit Jahren verbaut sind und von debian nicht genutzt werden. Diese Lösung ist momentan mein Favorit, da wir a) keine zusätzliche Software benötigen und b) debian nicht in die Quere kommen.
Das kann ich nur unterstützen. siduction sollte wo immer möglich 100% Debinan konform bleiben.
Vielleicht OT?
Weil ich mich frage ob folgende fehlermeldung beim grub reinstall (wg. ReadERROR beim booten) irgendetwas mit dem hier diskutieren problem zu tun hat füge ich dies hier an. Wenn nicht bitte ignorieren (oder dennoch beantworten ;-) )
Undefined subroutine &conffile::abs_path called at /usr/bin/ucfq line 529, <HASH> line 61.
???
-
@agaida: Was sind die Standards von grub2-mkconfig? Ich hab jetzt auf die Schnelle nichts gefunden.
-
cat `which grub-mkconfig`
...
if test -f ${sysconfdir}/default/grub ; then
. ${sysconfdir}/default/grub
fi
for x in ${sysconfdir}/default/grub.d/*.cfg ; do
if [ -e "${x}" ]; then
. "${x}"
fi
done
...
Also schöner gehts in meinen Augen nicht.
-
@agaida: d.h. alle *.cfg Dateien in /etc/default/grub.d werden eingelesen. Jetzt aber muss ich dir schon eine Frage stellen.
Wieso wird das Feature von siduction einfach so links liegen gelassen? ;-)
-
Wer sagt, dass dieses Feature links liegen gelassen wird? :twisted: Im Gegentum, ich hab einen kleinen Freudentanz aufgeführt, als ich das gefunden habe. Ich bin heilefroh, dass debian das nicht benutzt und dass wir eine saubere, von debian unabhängige Möglichkeit haben, missliebige Debian-Konfigurationen einfach und schmerzlos zu überschreiben.
EDITH sagt: Implementiert muss das aber trotzdem werden und da bin ich grade dabei :)