Installation vom grub customizer

[Pix]

Hallo,

da ich es nicht schaffe auch nach 3 Tagen mein Hintergrundbild von grub mittels Konfigurationsdatei /etc/default/grub zu ändern, wollte ich mir den "grub customizer " installieren.

Dazu habe ich den Befehl im Terminal eingefügt: sudo add-apt-repository ppa:danielrichter2007/grub-customizer

Die Fehlermeldung:

Code: Alles auswählen

  
sudo add-apt-repository ppa:danielrichter2007/grub-customizer
sudo apt-get update
sudo apt-get install grub-customizer
More info: https://launchpad.net/~danielrichter2007/+archive/ubuntu/grub-customizer
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keybox '/tmp/tmp_drf7npd/pubring.gpg' created
gpg: failed to start the dirmngr '/usr/bin/dirmngr': Datei oder Verzeichnis nicht gefunden
gpg: connecting dirmngr at '/tmp/tmp_drf7npd/S.dirmngr' failed: Datei oder Verzeichnis nicht gefunden
gpg: keyserver receive failed: Kein Dirmngr
 

konnte ich mit einem "apt-get install dirmngr" beseitigen.

Komme aber der folgenden Fehlermeldung nicht weiter:

Code: Alles auswählen

gpg: keybox '/tmp/tmps9eo9b4y/pubring.gpg' created
gpg: /tmp/tmps9eo9b4y/trustdb.gpg: trustdb created
gpg: key A8AA1FAA3F055C03: public key "Launchpad PPA for Daniel Richter" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no valid OpenPGP data found.

Ein sudo apt-get update aktualisiert zwar die Paketlisten aber am Ende kommt eine neue Fehlermeldung:

Code: Alles auswählen

W: The repository 'http://ppa.launchpad.net/danielrichter2007/grub-customizer/ubuntu artful Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: Fehlschlag beim Holen von https://deb.opera.com/opera-stable/dists/stable/InRelease  Operation too slow. Less than 10 bytes/sec transferred the last 120 seconds
E: Fehlschlag beim Holen von http://ppa.launchpad.net/danielrichter2007/grub-customizer/ubuntu/dists/artful/main/binary-amd64/Packages  404  Not Found
W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

Frage:
Kann bitte jemand einem Anfänger hier weiterhelfen?

Vielen Dank für eure Mühe

[owl102]

da ich es nicht schaffe auch nach 3 Tagen mein Hintergrundbild von grub mittels Konfigurationsdatei /etc/default/grub zu ändern

Hast du danach ein "update-grub" (als root) getätigt?

[towo]

Herzlichen Glückwunsch zum Zerstören Deines Systems.
Ubuntu PPA's haben in einem Debian nichts verloren!

[geier22]

Da du es ja offensichtlich (noch) nicht geschafft hast, das Repo zu etablieren (siehe Fehlermeldungen) löschen es am Besten wieder.
Ubuntu würde ich auch nicht gerade nehmen, aber immer gleich zu sagen: System kaputt gemacht ist auch gewagt.
Wer kein Fremdrepo sein eigen nennt werfe den ersten Stein
Was aber nicht heißen soll, das man ohne ein bischen nachzudenken alles von überall einbinden sollte.

Ich benutze seit Jahren SparkyLinux. Sparky ist absolut stabil.Der Installer hat mich noch nie im Stich gelassen, im Gegensatz zu den vielen Versuchen, ein "normales" Debian zu installieren
Die Repos von Sparky kann man bedenkenlos zu den Debian Repos zufügen.
Da gibt es auch dem Customizer.
Inhalt der Repos, die auch aus vielen anderen Gründen interessant sind:
https://sparkylinux.org/repo/

Anleitung zum hinzufügen der Repos aufpassen, das Richtige wählen (Testing oder Stable):
https://sparkylinux.org/wiki/doku.php/repository

Aber das Einfügen eines Themas für Grub ist so schwer nicht
Meine Konfiguration:
In der etc/default/grub folgende Zeilen am Ende Einfügen

Code: Alles auswählen

export GRUB_COLOR_NORMAL="white/black"
export GRUB_COLOR_HIGHLIGHT="light-cyan/black"
GRUB_THEME="/boot/grub/themes/Vimix/theme.txt"
export GRUB_MENU_PICTURE="/boot/grub/themes/Vimix/background.png"
GRUB_FONT="/boot/grub/unicode.pf2"

Dann das Thema (in meinem Fall eben Vimix
nach /boot/grub/themes/Vimix/ kopieren, falls das nicht durch irgend einen Installer gemacht wurde.
danach ein

Code: Alles auswählen

update-grub

und es sollte funktionieren.

Weitere Einzelheiten und Möglichkeiten in der Ubuntu_Wiki:
https://wiki.ubuntuusers.de/GRUB%202/

Mein, wie ich finde, sehr schönes Thema gibt es hier:
https://www.gnome-look.org/p/1009236/
oder hier
https://github.com/Se7endAY/grub2-theme-vimix

[DeletedUserReAsG]

Wer kein Fremdrepo sein eigen nennt werfe den ersten Stein

Erster.

Die Repos von Sparky kann man bedenkenlos zu den Debian Repos zufügen.

Aber dann hier halt nicht jammern, wenn sie’s doch mal versauen. Wenn man eine Fremdquelle einbindet, gibt man dem Betreiber faktisch Rootrechte auf seinem System. Den Leuten vom Debianprojekt traue ich zu, ihren Kram im Griff zu haben und auch nicht böswillig zu agieren. Bei kleineren Projekten und gar weitgehend unbekannten PPAs mit einer Person dahinter würde ich das nicht als gegeben ansehen.

[Pix]

Ubuntu PPA's haben in einem Debian nichts verloren!

Sorry, ihr habt Recht. Aus Unwissenheit ist mir dieser Fehler unterlaufen.

@ geier22
Vielen Dank für deinen Vorschlag. Werde versuchen mich daran zu halten.
Über Grub2 habe ich das Ubuntu_Wiki rauf und runter gelesen und mich an diese http://www.chip.de/bildergalerie/Grub-2 ... 63964.html Anleitung gehalten.

Habe immer versucht das Skript /etc/grub.d/05_debian_theme irgendwie zu bearbeiten.
Geholfen hat es alles nicht.

Wenn ich nicht weiterkomme, werde ich dazu nochmal extra Thread aufmachen.

[wolfn]

Falls Du noch Interesse hast:

Nach diesem Kochrezept habe ich neulich den Grub-Customizer in meinem Stretch installiert, absolut schmerzfrei. YMMV!

https://www.linuxsecrets.com/en/entry/6 ... ?showall=1

Viel Glück!

[DeletedUserReAsG]

Es ist generell keine gute Idee, Sachen am Paketsystem vorbeizuinstallieren.

[wolfn]

Dann sollte das Paketsystem bitteschön sowas draufhaben!
Sonst steig ich gleich um auf Slackware und mach alles zu Fuss

[DeletedUserReAsG]

Wenn du Software baust, solltest du’s draufhaben, auch ein ordnungsgemäßes Paket draus zu bauen.

Versteh’ mich nicht falsch: wenn’s für dich funktioniert – dein Ding, alles prima. Aber anderen Einsteigern sowas zu empfehlen, ist unhöflich. Spätestens mit dem nächsten Release wird’s nämlich Probleme machen, und dann knallt’s in der Regel richtig.

[geier22]

Fügt das Sparky- Repo bei euch ein und habt Freude. Da gibt es auch noch div. Browser, die man sonst mühselig separat installieren muß. Ich weiss nicht warum jedesmal, wenn jemand sudo oder Fremdrepo sagt (bzw. schreibt) alle sich auf den armen Kerl stürzen und schon hat man wieder ien Grundsatzdiskussion grrrrrrrrrrrrrrrrrrrrrr.

[owl102]

Es ist generell keine gute Idee, Sachen am Paketsystem vorbeizuinstallieren.

Genau dafür ist /usr/local aber da: "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr." [1]

Wenn du Software baust, solltest du’s draufhaben, auch ein ordnungsgemäßes Paket draus zu bauen.

Meinst du damit den Ersteller der Software oder den Anwender, der es übersetzt? Wie auch immer, bei beidem mag ich widersprechen.

Spätestens mit dem nächsten Release wird’s nämlich Probleme machen, und dann knallt’s in der Regel richtig.

Was knallt denn richtig, wenn ein Binary in /usr/local herumliegt? Schlimmstenfalls funktioniert es nach dem Upgrade auf das nächste Release nicht mehr.

[1] http://refspecs.linuxfoundation.org/FHS ... 04s09.html

[DeletedUserReAsG]

Was knallt denn richtig, wenn ein Binary in /usr/local herumliegt? Schlimmstenfalls funktioniert es nach dem Upgrade auf das nächste Release nicht mehr.

Wenn es denn unter /usr/local/ landen würde. Tut es aber nicht, wenn man der von wolfn verlinkten Anleitung folgt. Und ich würd’s schon als „knallt richtig“ bezeichnen, wenn das Upgrade auf‘s nächste Release aufgrund von Files, die da nicht hingehören, mittendrin aussteigt und ein unbenutzbares System hinterlässt. Die genannte Software scheint gar noch Files aus Paketen, bzw. von Paketen erstellte Dateien, zu überschreiben und übergeht die Mechanismen von Debian […].

Meinst du damit den Ersteller der Software oder den Anwender, der es übersetzt?

Ich meine damit jeden, der selbstgebaute Software auf einem Debiansystem installiert und nicht irgendwann unliebsam überrascht werden möchte, oder der auch nur Wert auf ein sauberes, wartbares System legt.

[…] alle sich auf den armen Kerl stürzen und schon hat man wieder ien Grundsatzdiskussion grrrrrrrrrrrrrrrrrrrrrr.

Besser so herum, als später irgendwann im Thread „Hilfe!!k Nix geht mehr, alles kaputt!“-Thread schreiben zu müssen.

[owl102]

Was knallt denn richtig, wenn ein Binary in /usr/local herumliegt? Schlimmstenfalls funktioniert es nach dem Upgrade auf das nächste Release nicht mehr.

Wenn es denn unter /usr/local/ landen würde. Tut es aber nicht, wenn man der von wolfn verlinkten Anleitung folgt.

Das habe ich gerade gemacht (wenn auch unter Fedora und nicht unter Debian), und es ist unter /usr/local gelandet.

(Was der Anleitung aber anzulasten ist, ist, daß das Bauen als root geschieht, insbesondere, da es in dem Projekt beiliegendem README richtig steht.)

Die genannte Software scheint gar noch Files aus Paketen, bzw. von Paketen erstellte Dateien, zu überschreiben und übergeht die Mechanismen von Debian […].

Was die Software selber macht, weiß ich nicht, ich werde mich auch hüten, das auszuprobieren, indem ich sowas auch noch starte. Ich habe besseres zu tun, als hinterher mein Grub zu reparieren.

Ich denke wir stimmen beide in dem Punkt überein, daß es immer besser ist, zu wissen, was man tut, anstatt blindlings das Editieren von systemrelevanten Dateien einem GUI-Tool zu überlassen. Leider haben wir nur "ich schaffe das nicht" und "Geholfen hat es alles nicht" als Fehlerbeschreibung. Die nach update-grub resultierende /boot/grub/grub.cfg kennen wir auch nicht.

[DeletedUserReAsG]

Das habe ich gerade gemacht (wenn auch unter Fedora und nicht unter Debian), und es ist unter /usr/local gelandet.

Ich hab‘s auch gerade gemacht (wenn auch unter Arch, nicht unter Debian), und /usr/local/ (ansonsten leer) schreibend für den bauenden User freigegeben. Ausgestiegen ist es mit

Code: Alles auswählen

Make Error at cmake_install.cmake:44 (file):                                                                                                                                                
  file INSTALL cannot copy file                                                                                                                                                              
  "/home/niemand/gcust_delme/grub-customizer-5.0.6/net.launchpad.danielrichter2007.pkexec.grub-customizer.policy"                                                                            
  to                                                                                                                                                                                         
  "/usr/share/polkit-1/actions/net.launchpad.danielrichter2007.pkexec.grub-customizer.policy".

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.

[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?