staging.inyokaproject.org

noisefloor schrieb:

• der Backup-Teil ist viel zu lang - es reicht der Hinweis, dass man sicher sollte. Wie und womit bleibt dem Nutzer überlassen

Gut den Text kann man grundsätzlich kürzen, aber da - zumindest bisher - Anfänger auch häufig mal über GRUB-Probleme stolpern, finde ich es grundsätzlich gut, dass da auch direkt eine Alternative innerhalb des Artikels aufgezeigt wird. Über Nautilus geht es z.B. nicht so ohne weiteres.

• manuelle Zeilenmbürche im Wiki sind böse → entfernt

Ja, dachte ich mir schon. Aber manchmal sind die Abstände bescheiden (siehe vor symlink).

• im Terminal braucht man kein gksudo für einen Shellbefehl 😉 → korrigiert

Das "gedit" hättest Du aber drin lassen dürfen. Gefixt. 😉

• zu viel fett, zu wenig Monospace → korrigiert

Danke, dafür, hatte ich vergessen!

Es wäre schöner, wenn die Überschriften-Ebene nur bis drei gehen würde, als alles eins hoch. Ist aber Geschmackssache. ☺

Kommt halt auch auf die Gliederung drauf an. So ergibt es zumindest erst mal einen Sinn. Wer einen besseren Gliederungsvorschlag hat, kann den hier ja loswerden. Sehe da grundsätzlich kein Problem.

Hatte übrigens grub.cfg updaten vergessen und noch angefügt.

Danke, schon mal für's Feedbback und die Korrekturen!

Gruß, Martin

Hallo,

Aber manchmal sind die Abstände bescheiden

Na ja, kann man so sehen. Das muss aber wenn über's Stylesheet dauerhaft korrigiert werden. Als entweder in "Rund um Inyoka" Vorschlagen oder direkt ein Ticket erstellen.

Gruß, noisefloor

So... hab' den Backuptext ein wenig gekürzt.

Werde heute mal Dein Thema-Artikel praktisch in allen Schritten zum Test nachvollziehen.

Gruß, Martin

So ich habe Deinen Artikel nun mal unter Karmic und Jaunty in Virtualbox getestet:

1. Hatte ich ja schon geschrieben: Der Grafikmodus muss nicht aktiviert werden und auch nicht das Hintergrundbild. Eigentlich ist schon ein Hintergrundbild aktiviert (moreblue-orbit-grub.png bzw. .tga). Nur existiert das Bild nicht. Für den Fall, dass ein Bild nicht existiert, bietet 05_debian_theme ein Fallback auf das Standardmenü. Es muss also nur ein gültiger Bildname gewählt und die Auflösung der Bildauflösung entsprechend angepasst werden.

2. Das Deaktivieren des Hintergrundbildes funktioniert auf die beschriebene Art nur für den Fall, dass eine andere Auflösung gewählt wird, als die Standardauflösung. Bei einer Auflösung von 640x480 wird das Bild trotz #GRUB_GFXMODE weiter angezeigt, was auch logisch ist (siehe Anmerkung zuvor).

3. Dann wollte ich mal noch anregen anstatt

   for i in {/boot/grub,/usr/share/images/desktop-base}/moreblue-orbit-grub.{png,tga} ; do

   durch

   for i in /boot/grub/bildname.png ; do

   zu ersetzen, es lieber so zu machen

   for i in {/boot/grub,/usr/share/images/desktop-base}/bildname.{png,tga} ; do

   Noch besser wäre sogar:

   for i in {/home/benutzername/Bilder,/boot/grub,/usr/share/images/desktop-base}/bildname.{png,tga,jpg} ; do

   Das hat den Vorteil, dass man die Bilder im eigenen Home-Verzeichnis bearbeiten kann. Was die Sache vereinfacht, da man beim Abspeichern mit Gimp in den anderen beiden Verzeichnissen keine Schreibrechte hat. Ob das allerdings auch geht, wenn /home verschlüsselt ist, habe ich noch nicht getestet, wahrscheinlich dann aber nicht. Trotzdem würde ich grundsätzlich mal erwähnen, dass das Verzeichnis eigentlich beliebig wählbar ist.

Getestet habe ich das alles wie gesagt mit Jaunty und Karmic.

Hintergrundbild deaktivieren habe ich Dir berichtigt, in den anderen Bereichen wollte ich nicht einfach rumpfuschen. Ansonsten habe ich noch ein paar kleine Fehler korrigiert.

Gruß, Martin

Hallo,

nee, korrigiert den Rest auch. Macht ja alles Sinn. Habe es auch aus einer anderen Schritt-für-Schritt Anleitung nachvollzogen und dabei nicht weiter darüber nachgedacht, dass z.B. ein Bild in /home durchaus sinnig ist.

Gruß, noisefloor

Newubunti schrieb:

Noch besser wäre sogar:

for i in {/home/benutzername/Bilder,/boot/grub,/usr/share/images/desktop-base}/bildname.{png,tga,jpg} ; do

Diese Lösung ist wohl auch noch nicht optimal. Grundsätzlich besteht bei Änderungen an 05_debian_theme das Problem, dass sie bei einem Update von GRUB selbst, also aus den Paketquellen, überschrieben wird.

Siehe auch hier.

Jetzt könnte man, wie in dem verlinkten Post vorgeschlagen, einen Symlink für die Bilddatei moreblue-orbit-grub. in einem der beiden vorgegebenen Verzeichnisse erstellen, der dann ins home verweist.

Damit hätte man aber nur die Bildänderung "geschützt".

Oder man muss halt einfach damit leben. Sicherung von der eigenen 05_debian_theme anlegen und bei Bedarf zurückspielen oder die wichtigen Teile davon.

Auf der anderen Seite besteht das Problem wahrscheinlich aber auch nur, solange GRUB 2 noch im Testing Status ist. Später wird das GRUB-Paket dann hoffentlich nicht so häufig aktualisiert.

Gruß, Martin

Hallo,

na ja, so schlimmt ist /boot/grub ja auch nicht. Kann man sich jedenfalls merken. 😉

Versucht, später auch was zu LVM und RAID zu schreiben...

Gruß, noisefloor

So habe die angekündigten Änderungen in der Themen-Baustelle eingefügt.

Ansonsten noch ein paar Kleinigkeiten in Konfigruation geändert.

Gruß, Martin

Könnt ihr bei der Gelegenheit noch Gfxboot darüber schaun und evtl ausmisten ? Insbesondere der Hinweis bzgl. ext4 meine ich.

Hallo,

habe in Konfig-Artikel einen Beispiel-Menüeintrag zu LVM und RAID eingebaut. Wie oben bereits erwähnt, dass ist pure Theorie, testen kann ich es nicht... Außerdem habe ich ein paar Syntax-Sachen korrigiert.

Gruß, noisefloor

Zu Raid und LVM kann ich auch praktisch (noch) nichts sagen - deshalb hätte ich es persönlich auch noch nicht ins Wiki aufgenommen.

Die Verkürzung von Backup und Erstellen eines eigenen Skriptes finde ich eher - wie auch schon mal weiter oben angedeutet - kontraproduktiv; und zwar deshalb, weil sich eventuell auch blutige Linux-Anfänger damit herumschlagen müssen. Da sehe ich das ausdrückliche Aufführen von Befehlen, als Ausstrecken einer helfenden Hand an. Wenn das System nicht bootet bricht bei Unwissenden ohnehin schon eine gewisse Panik aus.

Im übrigen zeigt z.B. auch die Befehlszeile in "Eigenes Skript erstellen" an einem praktischen Beispiel, dass das Terminal eine echte Arbeitserleichterung sein kann.

Klar wird keiner umkommen, wenn die Befehle nicht mehr aufgeführt sind, aber ich verstehe hier auch nicht, warum die so überflüssig sein sollen, dass man sie unbedingt herausnehmen muss.

Gruß, Martin

Hallo,

warum die so überflüssig sein sollen, dass man sie unbedingt herausnehmen muss.

1. Weil es mit dem Artikel nichts zu tun hat

2. Backups so wie so Standard sein sollten ...

3. Wir schreiben grundsätzlich keinen festen Weg vor, wenn es mehrere Möglichkeiten gibt. Der beschriebene war halt nur EINER von vielen. Das muss man nicht zwingend genau so auf der Kommandoziele machen (jetzt aber bitte nicht noch eine Meta-Diskussion GUI vs. Terminal 😉 )

Gruß, noisefloor

Hallo,

verschoben: GRUB 2 (und GRUB 2/Thema).

Da das Thema ja jetzt "erst" richtig aktuell wird sind Ergänzungen und Verbesserungen willkommen!

Gruß, noisefloor

ist die manuelle konfiguration nicht hinfällig bei verwendung von Startup Manager ?

http://web.telia.com/~u88005282/sum/index.html Grub2 soll ja auch unterstützt werden.

Hallo,

hm? Welche manuelle Konfiguration? Wenn du keine Sonderwünsche hast sollte alles automatisch laufen...

Gruß, noisefloor