Installation vom grub customizer

[owl102]

Code: Alles auswählen

"/usr/share/polkit-1/actions/net.launchpad.danielrichter2007.pkexec.grub-customizer.policy".

Hmm, stimmt, die Policy Kit Datei (und das Anwendungssymbol) landen nicht in /usr/local. Damit könnte ich aber leben, und damit wird die manuelle Installation für mich auch nicht "böse". Was soll das Tool auch machen, unter /usr/local gibt es AFAIK kein Verzeichnis, welches von Policy Kit eingelesen wird. (Das könnte man zwar so konfigurieren, aber dafür müsste man wieder außerhalb /usr/local herumpfuschen.)

Dem Readme nach schreibt es u.A. direkt in die grub.cfg, und damit ist’s für Debian eigentlich sowieso schon disqualifiziert.

Das hätte immerhin den Vorteil, daß man zur anschließenden Reparatur lediglich ein "update-grub" benötigt.

[DeletedUserReAsG]

Wie auch immer: wer weiß, was er tut, kann gerne auf die Art am Paketsystem vorbei installieren. Der kann nämlich im Fehlerfall die Fehler auch selbst beheben – er weiß ja, was er getan hat, und mit welchen Problemen zu rechnen war.

Mir ging’s in erster Linie darum, dass ’nem offensichtlichen Einsteiger unreflektiert empfohlen wird, Fremdrepos einzubinden oder am Paketmanagement vorbeizuinstallieren – das finde ich nicht gut und hielt’s daher für wichtig, meine Bedenken zu äußern. Das beugt immerhin schon mal „aber aber aber … das hat mir keiner gesagt! Debian ist scheiße!!k“-Threads vor, bzw. es kann drauf verwiesen werden, wenn es trotzdem zu einem solchen Thread kommt. Siehe auch die ganzen Problemthreads, an denen etwa dmo, oracle, parallels, php.net, etc. ursächlich beteiligt waren – es kann immerhin keiner sagen, dass nicht gewarnt worden wäre.

[owl102]

es kann immerhin keiner sagen, dass nicht gewarnt worden wäre.

Ich sehe hier folgende Probleme: Erstens hat dann das ganze was von "Ich habe es dir ja gleich gesagt!". Und zweitens können Anfänger weder das Handeln noch die Warnungen einschätzen. Sehr hilfreich finde ich daher das reine Warnen nicht, genauso wenig, wenn (wie in diesem Falle) im Blogeintrag eine schlechte Variante des (guten) README des Projektes steht, ohne Hinweis, was wo landet und wie gut oder schlecht das ist.

Über das Ubuntu-PPA in Debian brauchen wir nicht zu diskutieren, ich hoffe wir sind wir uns da alle einig. Aber was die Variante des Selberbauens und Installierens angeht, hätte ich mir differenziertere Aussagen gewünscht. Zumal in diesem Falle "make install" alles, was außerhalb /usr/local landet, minimiert, es außerhalb von /usr/local lediglich zusätzliche Dateien anlegt (und keine bestehenden modifiziert), und "make uninstall" alles sauber wieder wegräumt.

Davon ab gibt es eine alternative Möglichkeit, den "Grub Customizer" einzusetzen: In einer Debian-VM kann man damit herumspielen, und wenn das Ergebnis dem entspricht, was man haben will, kann man sich die grub.cfg der VM anschauen und die mit der lokalen grub.cfg vergleichen. Dann bekommt man eine Idee, was man bei seinen händischen Versuchen falsch gemacht hat.

[DeletedUserReAsG]

Erstens hat dann das ganze was von "Ich habe es dir ja gleich gesagt!".

… genau das werde ich schreiben, wenn einer der Beteiligten mit einem hieraus resultierenden Problem aufschlägt. Oder wenn geiers System sich aufgrund seines Sparky-Repos zerlegt hat. Oder wolfns System nicht mehr hochkommt, weil ’n unreflektiert am Paketmanagement vorbeiinstalliertes Programm diverse Files überschrieben hat, oder ’n Update nicht mehr geht, weil Files im System sind, die da nicht hingehören

Und zweitens können Anfänger weder das Handeln noch die Warnungen einschätzen.

… weswegen es für Einsteiger die sicherste Variante ist, ohne Fremdquellen/hingepfuschte Installationen auszukommen, bis sie eben keine Anfänger mehr sind und die Tragweite ihres Abweichens vom „Debian way” abschätzen können.

Wenn man sich a) darauf verlassen könnte, dass es ein make uninstall gibt und sich b) weiterhin darauf verlassen könnte, dass es prüft, ob die wegzuräumenden Files nicht zwischenzeitlich modifiziert, oder gar von einem regulär installierten Paket neu geschrieben wurden, könnte ich zustimmen, dass es harmlos ist. Die Erfahrung zeigt jedoch, dass man sich eben nicht darauf verlassen kann. Und selbst, wenn es in diesem Fall funktioniert – beim Einsteiger bleibt hängen: „Kann man generell so machen“ – und ich kenne einige richtig böse Makefiles ….

In einer Debian-VM kann man damit herumspielen, und wenn das Ergebnis dem entspricht, was man haben will, kann man sich die grub.cfg der VM anschauen und die mit der lokalen grub.cfg vergleichen.

Ja.

[owl102]

… genau das werde ich schreiben, wenn einer der Beteiligten mit einem hieraus resultierenden Problem aufschlägt.

Und wozu?

… weswegen es für Einsteiger die sicherste Variante ist, ohne Fremdquellen/hingepfuschte Installationen auszukommen, bis sie eben keine Anfänger mehr sind und die Tragweite ihres Abweichens vom „Debian way” abschätzen können.

Ja, die sicherste, aber nicht immer die praktikabelste. Angenommen es gibt Programm xyz, welches ich gerne einsetzen möchte, welches aber nicht im Repository liegt. "Vergiss es, zumindest solange du noch ein Anfänger bist!" halte ich für keine konstruktive Hilfestellung. Es sollten Alternativen aufgezeigt werden, und wenn es die nicht gibt, wenigstens eine differenzierte Auseinandersetzung mit den bestehenden Methoden, welche ist die am wenigsten üble Methode, was genau sind warum die Schwachpunkte dieser Methode usw.

Wenn man sich a) darauf verlassen könnte, dass es ein make uninstall gibt und sich b) weiterhin darauf verlassen könnte, dass es prüft, ob die wegzuräumenden Files nicht zwischenzeitlich modifiziert, oder gar von einem regulär installierten Paket neu geschrieben wurden, könnte ich zustimmen, dass es harmlos ist.

In diesem Falle gibt es aber ein "make uninstall" und "make install" legt lediglich eine Policy Kit Datei und Anwendungssymbole außerhalb /usr/local ab, und in allen diesen Dateien kommt der Anwendungsname vor. Solange es kein regulär installiertes Paket namens "grub-customizer" gibt, sehe ich kein Konfliktpotential zu regulär installierten Paketen.

„Kann man generell so machen“ – und ich kenne einige richtig böse Makefiles ….

"Kann man generell so machen" unterschreibe ich aber. Ja, es gibt auch böse Makefiles. Und die Möglichkeit, die Installation erst einmal in einer VM zu machen, wo man entweder einfach zum letzten Snapshot zurückkehren kann oder sie ganz in die Tonne drücken kann. Wenn man dann sieht, daß was außerhalb /usr/local installiert wird, kann man sich das anschauen, oder im Forum nachfragen. Oder aber man betreibt die Anwendung sicherheitshalber in der VM, zumindest solange, bis man die Änderungen am System angeschaut und verstanden hat. BTW: So wird man auch vom Anfänger zum Nicht-mehr-Anfänger.

[DeletedUserReAsG]

Und wozu?

Zur Erinnerung. Ich werd angegangen, wenn ich davor warne, vom vorgesehenen Weg abzuweichen, also werde ich drauf hinweisen, wenn genau das zu Konsequenzen geführt hat. Ist was Psychologisches, ich halt’s für wichtig. Verstärkt den Lerneffekt aus Fehlern.

Angenommen es gibt Programm xyz, welches ich gerne einsetzen möchte, welches aber nicht im Repository liegt.

In dem Fall gibt es mehrere Möglichkeiten: man könnte sich ein Paket draus bauen. Das wäre die beste Variante, wenngleich gerade für Anfänger aufwändig. Aber lehrreich – dann sieht er gleich mal, was das Paketmanagement alles so macht, das man nicht hätte, wenn man es umginge. Weiterhin könnte man es in einen Container oder in eine VM packen. Dann ist’s kein großes Problem, wenn das betreffende System dabei kaputtgeht, und das Programm ist zudem gut vom eigentlichen System isoliert. Nicht zuletzt gibt’s die Möglichkeit, es mit --prefix=~/programm/… zu bauen und als User zu installieren – dann kann man immerhin schon mal sicher sicher sein, dass zumindest das Bauen und die Installation das System nicht beeinträchtigen.

In diesem Falle gibt es aber ein "make uninstall" und "make install" legt lediglich eine Policy Kit Datei und Anwendungssymbole außerhalb /usr/local ab, und in allen diesen Dateien kommt der Anwendungsname vor. Solange es kein regulär installiertes Paket namens "grub-customizer" gibt, sehe ich kein Konfliktpotential zu regulär installierten Paketen.

Solange nicht genau evaluiert wurde, was da geschrieben und beim Uninstall gelöscht wurde, unterschreibe ich die Aussage nicht. Zudem ist mir die Quelle des Codes suspekt – das ist aber subjektiv.

Um’s aber nicht weiter ausufern zu lassen, möchte ich es hierbei mit einem „Ach, macht doch, was ihr wollt!“ belassen. Aber wenn geier mit Probs aufgrund Fremdquellen, oder wolfn mit Probs aufgrund am Paketsystem vorbeigepfuschter Installationen ankommt, werde ich wieder da sein – und „Told you so!“ hinschreiben

[owl102]

Zur Erinnerung. Ich werd angegangen, wenn ich davor warne, vom vorgesehenen Weg abzuweichen

? Wer ist dich hier dafür angegangen? Ich halte die Warnungen für richtig und wichtig! Aber ich halte es eben auch für wichtig, den Anwendern weder mit "mach doch einfach das" ins Verderben rennen zu lassen noch mit "mach das nicht" im Regen stehen zu lassen.

In dem Fall gibt es mehrere Möglichkeiten: man könnte sich ein Paket draus bauen. Das wäre die beste Variante, wenngleich gerade für Anfänger aufwändig. Aber lehrreich – dann sieht er gleich mal, was das Paketmanagement alles so macht, das man nicht hätte, wenn man es umginge. Weiterhin könnte man es in einen Container oder in eine VM packen. Dann ist’s kein großes Problem, wenn das betreffende System dabei kaputtgeht, und das Programm ist zudem gut vom eigentlichen System isoliert. Nicht zuletzt gibt’s die Möglichkeit, es mit --prefix=~/programm/… zu bauen und als User zu installieren – dann kann man immerhin schon mal sicher sicher sein, dass zumindest das Bauen und die Installation das System nicht beeinträchtigen.

Dieser Absatz von dir gefällt mir viel viel besser als "Wenn du Software baust, solltest du’s draufhaben, auch ein ordnungsgemäßes Paket draus zu bauen." Warum nicht gleich so?

Um’s aber nicht weiter ausufern zu lassen, möchte ich es hierbei mit einem „Ach, macht doch, was ihr wollt!“ belassen.

Da gefällt mir aber der obrige Absatz von dir viel besser.

[DeletedUserReAsG]

Dieser Absatz von dir gefällt mir viel viel besser als "Wenn du Software baust, solltest du’s draufhaben, auch ein ordnungsgemäßes Paket draus zu bauen." Warum nicht gleich so?

Weil die bemängelte Aussage eine direkte, stilgerechte Antwort auf

Dann sollte das Paketsystem bitteschön sowas draufhaben!

war.

[geier22]

… genau das werde ich schreiben, wenn einer der Beteiligten mit einem hieraus resultierenden Problem aufschlägt. Oder wenn geiers System sich aufgrund seines Sparky-Repos zerlegt hat. Oder wolfns System nicht mehr hochkommt, weil ’n unreflektiert am Paketmanagement vorbeiinstalliertes Programm diverse Files überschrieben hat, oder ’n Update nicht mehr geht, weil Files im System sind, die da nicht hingehören

Geiers System läuft als "Rolling Distro" seit nunmehr 2 Jahren. Und ich denke mal, das es innerhalb des "debian way" auch eiige Propleme gibt.
Und

und ich werd’ mich meinerseits schwer hüten, es als Root zu installieren oder /usr/share/…/ für den bauenden User freizugeben um zu gucken, was sonst noch so passiert.
Dem Readme nach schreibt es u.A. direkt in die grub.cfg, und damit ist’s für Debian eigentlich sowieso schon disqualifiziert.

Kann ich dir sagen, wobei ich das /usr/share/locale und usr/share/icons/hicolor gekützt habe:

Code: Alles auswählen

dpkg -L grub-customizer
/.
/usr
/usr/bin
/usr/bin/grub-customizer
/usr/lib
/usr/lib/grub-customizer
/usr/lib/grub-customizer/grubcfg-proxy
/usr/share
/usr/share/locale
/usr/share/locale/de
/usr/share/locale/de/LC_MESSAGES
/usr/share/locale/de/LC_MESSAGES/grub-customizer.mo
/usr/share/locale/hr/LC_MESSAGES/grub-customizer.mo
/usr/share/locale/bs/LC_MESSAGES/grub-customizer.mo
/usr/share/locale/cs/LC_MESSAGES/grub-customizer.mo
/usr/share/applications
/usr/share/applications/grub-customizer.desktop
/usr/share/polkit-1
/usr/share/polkit-1/actions
/usr/share/polkit-1/actions/net.launchpad.danielrichter2007.pkexec.grub-customizer.policy
/usr/share/doc
/usr/share/doc/grub-customizer
/usr/share/doc/grub-customizer/copyright
/usr/share/doc/grub-customizer/changelog.Debian.gz
/usr/share/icons
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/grub-customizer.1.gz

Ich empfehle hier auch mal in diesem Zusammhang einen Thread über das debian way os-prober -Paket, das man ja wohl braucht, wenn man mehere System am laufen hat, und man kein in der Grub-Syntax geübter Profi ist?:
viewtopic.php?f=12&t=160631&hilit=os+prober#p1089212

[DeletedUserReAsG]

Geiers System läuft als "Rolling Distro" seit nunmehr 2 Jahren. Und ich denke mal, das es innerhalb des "debian way" auch eiige Propleme gibt.

Geier geht halt nicht den Debian Way – der ist nämlich das genaue Gegenteil eines Rolling Releases. Kann man tun, nur kann man dann nicht für sich reklamieren, es auf Debian-Art zu machen.

Kann ich dir sagen

Kannst du nicht, weil du’s als Paket, von deinem Maintainer angepasst, installiert hast, und es hier um die dubiose Anleitung für die Installation aus dubiosen Quellen ging, die wolfn ins Spiel gebracht hat.

Ich empfehle hier auch mal in diesem Zusammhang einen Thread über das debian way os-prober -Paket, das man ja wohl braucht, wenn man mehere System am laufen hat, und man kein in der Grub-Syntax geübter Profi ist?

a) braucht man weder das Paket, noch muss man ein in der grub-Syntax geübter Profi sein, um mehrere Systeme laufen zu lassen, ein kurzer Blick in die entsprechende Doku tut den Job (tatsächlich halte ich os-prober für gruselig: was das an Logeinträgen generiert, wenn man es laufen lässt – da bekomme ich Angst ^^), und b) was hat os-prober mit diesem Thread zu tun?

[geier22]

was hat os-prober mit diesem Thread zu tun?

Weil der Grub-customizer den Mist, den os-prober erzeugt auch für einen Laien wie mich übersichtlich darstellt. und man die Einträge in der /boot/grub/grub.cfg auf relativ einfache Art und Weise bearbeiten kann, ohne in die Grub-Syntax tief einzusteigen, was übrigens sehr gut funktioniert.
Und weil os-prober halt bei einer normal Installation mitinstalliert wird.

Code: Alles auswählen

$ apt-cache depends grub-common
grub-common
  Hängt ab von: libc6
  Hängt ab von: libdevmapper1.02.1
  Hängt ab von: libfreetype6
  Hängt ab von: libfuse2
  Hängt ab von: liblzma5
  Hängt ab von: gettext-base
    gettext-base:i386
  Beschädigt: <apport>
  Beschädigt: friendly-recovery
  Beschädigt: <lupin-support>
  Beschädigt: mdadm
  Empfiehlt: os-prober
  Schlägt vor: multiboot-doc
  Schlägt vor: grub-emu
    grub-emu:i386
  Schlägt vor: xorriso
  Schlägt vor: desktop-base
  Schlägt vor: console-setup
  Ersetzt: grub-coreboot
  Ersetzt: grub-efi
  Ersetzt: grub-efi-amd64
  Ersetzt: grub-efi-ia32
  Ersetzt: <grub-efi-ia64>
  Ersetzt: grub-ieee1275
  Ersetzt: grub-linuxbios
  Ersetzt: grub-pc
  Ersetzt: <grub-yeeloong>

Hatte erst kürzlich wieder das Problem, dass nach einem Kernel-Update der falsche Kernel gestartet wurde. Und so geht das - wenn es weiss - zuverlässig und problemlos.

[DeletedUserReAsG]

Weil der Grub-customizer den Mist, den os-prober erzeugt auch für einen Laien wie mich übersichtlich darstellt.

Für mich sieht dein Bildchen erheblich unübersichtlicher aus, als die grub.cfg.

Und weil os-prober halt bei einer normal Installation mitinstalliert wird.

Also ich würde --without-recommends (bzw. das Äquivalent in der Config) als geringere Abweichung vom Debianweg ansehen, als Testing mit Fremdquellen zu fahren (wodurch das „Testing“ ad absurdum geführt wird, nebenbei erwähnt – Bugreports für Bugs, die unter Beteiligung von Fremdquellen entstanden sind, sind wertlos. Egal, ob man selbst glaubt, dass das nichts miteinander zu tun hätte).

[wolfn]

Ich habe gerade mal nachgelesen, was Ihr Euch da weiter oben so um die Ohren haut.
Ein Stück weit hat wohl jeder Recht, aus seiner Sicht sowieso.
Was mir aber fehlt in der Diskussion ist die Richtung nach vorne, hier geht es immer darum, was könnte schief gehen und dem OP um die Ohren fliegen.
Ich finde es einfach grottenschlecht, daß im Debian so ein essentielles Teil immer noch fehlt. Den Anfängern hilft es über die bösesten Hürden und denen, die sich halbwegs auskennen spart es das immer wieder neu Suchen oder dient einfach der Bequemlichkeit und schützt vor Schusseligkeit.

Um mein System müßt Ihr Euch übrigens keine Sorgen machen, habe immer ein paar dd-Abzüge rumliegen für den Weg zurück.
Und wenn ein neues Release rauskommt, wird das in einer alternativen Partition frisch aufgesetzt und nach und nach alles rübergezogen.
Aber das ist sicher Geschmackssache...

[DeletedUserReAsG]

Ich finde es einfach grottenschlecht, daß im Debian so ein essentielles Teil immer noch fehlt.

Ja, dann geh hin und melde dich als Maintainer, wenn du meinst, dass es essenziell wäre (was ich zwar nicht im Ansatz nachvollziehen kann, aber was weiß ich schon?) und unbedingt zur Verfügung stehen müsste. Du scheinst ja unheimlich kluk zu sein und enorm viel drauf zu haben, da sollte das doch ’ne Kleinigkeit sein?

[maledora4]

Weil der Grub-customizer den Mist, den os-prober erzeugt auch für einen Laien wie mich übersichtlich darstellt.

Für mich sieht dein Bildchen erheblich unübersichtlicher aus, als die grub.cfg.

+1

Vor allen Dingen vergißt er bei dieser "Breitseite", die er seit Jahren gegen os-prober fährt, zu erwähnen, seine Probleme
entstanden durch die gleichzeitige Verwendung von dem grub-customizer und update-grub in seinen Multibootsytem(en).

[geier22]

Vor allen Dingen vergißt er bei dieser "Breitseite", die er seit Jahren gegen Debianos-prober fährt, zu erwähnen, seine Probleme
entstanden durch die gleichzeitige Verwendung von dem grub-customizer und update-grub in seinen Multibootsytem(en).

Wollen Herr mal bitte den von mir oben angegegebnen Thread vollständug lesen, bevor er ier solche Bemerkungen loslässt?
Ist ja wohl nicht meine Schuld, wenn Bugs jahrelang nicht ausgemerzt werden.
Ansonsten geht mir die Diskussion hier langsan auf die Nerven. Wenn ich den Thread nochmal lese, war ich bisher der einzige, der versucht hat, zu dem eigentlichen Problem was beizutragen

Was mir aber fehlt in der Diskussion ist die Richtung nach vorne, hier geht es immer darum, was könnte schief gehen und dem OP um die Ohren fliegen.

.
Vielleicht sollten das die anderen, die viel erfahrender als ich sind, auch mal tun, anstatt sich über den "Debian Way" und die Abweichler auszulassen.

[DeletedUserReAsG]

Vor allen Dingen vergißt er bei dieser "Breitseite", die er seit Jahren gegen os-prober fährt, zu erwähnen, seine Probleme
entstanden durch die gleichzeitige Verwendung von dem grub-customizer und update-grub

Hmm … und grub-customizer kommt von der Fremdquelle. q.e.d. Told you so.

scnr

[owl102]

Weil die bemängelte Aussage eine direkte, stilgerechte Antwort auf ...war.

Kann ich nachvollziehen, ein Punkt für dich.

Ich find's halt nur schade, daß sowas immer auch auf Kosten des Themenerstellers geht, dem mit solchen Antworten nicht geholfen ist.

[DeletedUserReAsG]

Stimmt auch wieder. Wäre also schön, wenn der Threadstarter sich melden und schreiben könnte, was er versucht hat, um das Hintergrundbild zu bekommen, damit man gucken kann, was schiefgelaufen ist, und wie man’s ohne Pfusch richtig machen könnte.

[KP97]

Mal unabhängig davon, ob ein grub-customizer hilfreich ist oder nicht, aber wer das Tool einsetzen will, soll es doch machen.
Aber dann selbst bauen aus den sourcen, und vor allen Dingen kein make install ausführen.
Das uninstall ist nicht immer sauber programmiert und hinterläßt u.U. Leichen, vom Paketmanager ganz zu schweigen. Sowas benutzt man bei Debian besser nicht.
Stattdessen gibt es das Paket checkinstall.
Damit wird ein Paket erstellt, läßt sich mit dpkg -i installieren und über den Paketmanager auch sauber wieder entfernen.
Damit ist jeder zufrieden...auch der Paketmanager...
...und man hat keine Fremdquellen, denn da gebe ich @niemand recht. Wer die einbindet, sollte wissen, was man tut und sich bei Fehlern nicht wundern.

[geier22]

Stattdessen gibt es das Paket checkinstall.

Danke für den Tipp. Wenns mal wieder über mich kommt, werde ich das mal testen

[maledora4]

Wollen Herr mal bitte den von mir oben angegegebnen Thread vollständug lesen, bevor er ier solche Bemerkungen loslässt?
Ist ja wohl nicht meine Schuld, wenn Bugs jahrelang nicht ausgemerzt werden.

Nee warum?
Du empfiehlst doch bereits auf der ersten Seite dem TE einerseits wie er die Installation des customizer durchführen kann und "schiebst" ein update-grub zur Änderung des Hintergrundbildes nach.

Das ist doch der Irrsinn, den du einfach nicht begreifen willst!

[geier22]

Du empfiehlst doch bereits auf der ersten Seite dem TE einerseits wie er die Installation des customizer durchführen kann und "schiebst" ein update-grub zur Änderung des Hintergrundbildes nach.

Vielleicht solltest du auch hier den von dir zitieren Beitrag ganz lesen und verstehen, anstatt etwas rein zu interpretieren, was gar nicht da steht.
Ich bin es leid hier in diesem Ton weiter zu diskutieren. Was ist bloß im Augenblick mit dem Debian Forum los
Bin gespannt, wann jemand auf die Idee kommt, mal was zum Thema zu sagen

[geier22]

So - hab das gerade mal in einer VM durchgeführt.

Anleitung:
Zuerst mal das Verzeichnis anlegen:

Code: Alles auswählen

 # mkdir /boot/grub/themes

Habe zwei Themen runter geladen, die mir gefallen - Das ist einfacher, weil damit auch
gleich die Schriften, Position auf dem Bildschirm usw. definiert werden. Du kannst
auch nachträglich die Datei /boot/grub/themes/Themen-Name/theme.txt bearbeiten, wenn es denn Spaß macht.

Ich hab mir erst mal 2 Themen heruntergeladen:

Grub Thema elementary OS GRUB 2 theme
https://www.gnome-look.org/p/1180195
und Standby
https://www.gnome-look.org/p/1172610/
Dann die entpackten Datei - Verzeichnisse ins richtige Verzeichniss transportieren:

Code: Alles auswählen

 # mv /home/hans/Downloads/elementary-OS-Grub /boot/grub/themes/

und

Code: Alles auswählen

 # mv /home/hans/Downloads/Standby /boot/grub/themes/

..ergibt:

Code: Alles auswählen

 /boot/grub/themes# ls -al
insgesamt 16
drwxr-xr-x 4 root root 4096 Aug 25 18:33 .
drwxr-xr-x 6 root root 4096 Aug 25 18:02 ..
drwxr-x--- 3 hans hans 4096 Jun  7 15:28 elementary-OS-Grub
drwxr-xr-x 3 hans hans 4096 Aug 25 18:20 Standby

Dann:
Da das die grub aus der Virtuellen Maschine ist, und beim Starten der VM nur ein kleines Fensterchen da ist,
hab ich da keine Anpassungen vorgenommen.
Um das anzupassen kannst du im Grub-Menü die Taste "c" drücken
mit

Code: Alles auswählen

videoinfo 

die gültigen Auflösungen ansehen
und die Zeile

Code: Alles auswählen

#GRUB_GFXMODE=640x480

entsprechend anpassen und natürlich auskommentieren

Das Ist die Origial /etc/default/grub aus der VM, bei der ich nur die letzte Zeile
GRUB_THEME="/boot/grub/themes/Standby/theme.txt" eingefügt habe:

Code: Alles auswählen

 # nano /etc/default/grub

Code: Alles auswählen

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR='Sparky'
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

GRUB_THEME="/boot/grub/themes/Standby/theme.txt"

Dann:

Code: Alles auswählen

root@hans-pc:/home/hans# update-grub
GRUB-Konfigurationsdatei wird erstellt …
Thema gefunden: /boot/grub/themes/Standby/theme.txt
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found background image: /opt/artwork/sparky-grub.png
Linux-Abbild gefunden: /boot/vmlinuz-4.12.0-1-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.12.0-1-amd64
erledigt
root@hans-pc:/home/hans#reboot

Schon ist es erledigt.
Wenn du dann noch das Hintergrundbild ändern willst, musst du einfach die Datei /boot/grub/themes/DEIN THEMEN NAME/background.png
gegen eine andere austauschen. ein update-grub brauchst du dabei nicht ausführen.

Original:

[
Viel Spass

Edit
ch hab die Bilder mal von Pic Upload raus genommen, da da jetzt aggressiv Werbung gemacht wird. Soweit, dass der Browser blockiert wird..

[geier22]

Nachtrag:
Hab dann zum Spass den grub-customizer installiert, um dann "bequem" die Themen zu wechseln.
Ergebnis für die vorher installierten Themen:
Die Möglichkeit, die einzelnen Menüeinträge zu bearbeiten, ohne sich durch die 232 Zeilen lange (Minimum) grub.cfg wühlen zu müssen, und da eventuell eine Zeile oder auch nur einen Buchstaben zu viel zu löschen, finde ich hervorragend und sehr übersichtlich gemacht.
Außerdem ist es so bequem möglich Schriften Logos usw. auszutauschen.

Edit
ch hab die Bilder mal von Pic Upload raus genommen, da da jetzt aggressiv Werbung gemacht wird. Soweit, dass der Browser blockiert wird..