staging.inyokaproject.org

Newubunti schrieb:

letzteres wäre cool 😉

Aber nicht für den, der dadurch die Funktionalität verliert, seine Windows-Recovery-Partition über F-Taste aufzurufen. Sehr ärgerlich, wenn man keine Windows-CD hat.

Das eigentliche Problem hieran ist aber, dass eine Recovery-Funktion gar nichts auf der Platte zu suchen hat. Ein Recovery sollte schießlich auch dann funktionieren, wenn mit der Platte etwas passiert ist. Dieses Problem wäre ja auf Rechnern unumgänglich, die nur eine Platte besitzen, denn irgendwo muss Grub ja hin. Wie gesagt: Ich spreche von MBR, nicht PBR. Deshalb ist es bei MBR "cool". 😉

P.S: Bei meinem Rechner kann ich die Recovery Partition über einen "Vista"-Eintrag in Grub starten 😉

DrScott schrieb:

Newubunti schrieb:

letzteres wäre cool 😉

Aber nicht für den, der dadurch die Funktionalität verliert, seine Windows-Recovery-Partition über F-Taste aufzurufen. Sehr ärgerlich, wenn man keine Windows-CD hat.

Das eigentliche Problem hieran ist aber, dass eine Recovery-Funktion gar nichts auf der Platte zu suchen hat. Ein Recovery sollte schießlich auch dann funktionieren, wenn mit der Platte etwas passiert ist.

Ja, mag sein. Die Realität ist nun aber mal so wie sie ist und vor allem der Nutzer hat sie nicht verschuldet.

Dieses Problem wäre ja auf Rechnern unumgänglich, die nur eine Platte besitzen, denn irgendwo muss Grub ja hin. Wie gesagt: Ich spreche von MBR, nicht PBR. Deshalb ist es bei MBR "cool". 😉

Das Überschreiben des Codes im MBR ist umgänglich, indem man in dem Fall GRUB in den PBR installieren würde und MBR samt verborgenen Bereich so lässt wie er ist und GRUB dann über Windows-Bootmanager chainloaded.

Und vor allem: Es wäre für das GRUB-Setup ein leichtes, ein Backup von allen MBRs, PBRs und verborgenen Bereichen anzulegen und zwar ganz automatisch ungefragt. Ich bin der Meinung, dass sollte für eine Software wie einen Bootmanager selbstverständlich sein. Dann wäre es auch nicht schlimm, wenn sich das GRUB Setup, der Nutzer, das Wiki oder der am Ende der Kette helfende Supporter mal vertut.

P.S: Bei meinem Rechner kann ich die Recovery Partition über einen "Vista"-Eintrag in Grub starten 😉

Geht aber je nach Aufbau der Recovery-Partition aber auch mal nicht, oder nur mit erheblichem Forschungsaufwand. Vor allem ist es extrem schwer diese Funktionalität im Nachhinein ohne Windos-DVD in den Griff zu bekommen.

Gruß, Martin

Die geänderte chroot-Methode sehe ich sehr problematisch.

1. "sudo su" ist nach sudo nicht empfehlenswert, sondern z.b. sudo -i
2. ist das prozedere für Anfänger nicht nachvollziehbar
somit verleitet der Artikel zu einem "blinden abtippen" von Befehlen und zum aneignen falscher Verhaltensmuster.

Hallo,

"sudo su" ist nach sudo nicht empfehlenswert, sondern z.b. sudo -i

??? - heißt was? Warum soll man denn nicht in eine Root-Shell (sudo su) nach vorherigen sudo wechseln?

ist das prozedere für Anfänger nicht nachvollziehbar somit verleitet der Artikel zu einem "blinden abtippen" von Befehlen und zum aneignen falscher Verhaltensmuster.

Prinzipiell richtig. Nur: Wenn dein System nicht läuft, dann willst du es zum Laufen bekommen. Im Zweifelsfall auch mit C&P. Natürlich ist ein tieferes Verständnis besser. Nur kann das bei Details zu Grub, chroot etc. für Anfänger schon mal ein paar Monate dauern, ehe man das alles versteht. So lange will wohl kaum jemand warten, dass sein System wieder läuft.

Bzw. Gegenfrage: Wie würdest du das denn (im Artikel) ändern wollen.

Gruß, noisefloor

Die Verlinkung über "an das System anpassen" bringt einem Anfänger überhaupt nichts, weil dort so viele Abfragemöglichkeiten auftauchen, dass er überhaupt keinen Durchblick mehr hat. Leider findet sich unter den verlinkten Abfagen nicht die Abfrage, mit der das Problem gelöst werden kann, nämlich

sudo fdisk -l

Wäre da die direkt Angabe des Abfragebefehls mit einem Beispiel nicht besser, weil verständlicher?

So was, wie das hier versteht auch ein Änfänger.

Soll hier Wissen vermittelt oder verschleiert werden, das ist hier die Frage? 😈

Hej bowman,

bowman schrieb:

...nämlich

sudo fdisk -l

Wäre da die direkt Angabe des Abfragebefehls mit einem Beispiel nicht besser, weil verständlicher?

noch besser wäre imho

df -h

daraus erhält man ganz sicher das Device, auf dem "/" liegt; von da aus kann jeder (Wissende) auf das richtige X aus

sudo grub-setup /dev/sdX

schließen, aus dem o.g. Befehl geht das u. U. nicht mal so eben (s. Anhang). Bei 'gut' gelabelten Partitionen zeigt auch

blkid

bessere Informationen.

Gruß black tencate

bowman schrieb:

Soll hier Wissen vermittelt oder verschleiert werden, das ist hier die Frage? 😈

Im ursprünglichen Artikel "GRUB Umgebung analysieren", war an der Stelle, wo jetzt nur die Links sitzen, direkt der Befehl aufgeführt (siehe der dortige Verlauf).

Solche Kürzungen entstehen durch das Ansinnen Redundanz zu vermeiden. Was hier natürlich jetzt in diesem Artikel ungünstig ist, dass es einen Link auf einen Link gibt. Das hat derjenige, der die Änderung in GRUB Umgebung analysieren vorgenommen hat, wohl nicht beachtet bzw. übersehen.

Lange Rede kurzer Sinn: Im hiesigen Artikel sollte nun direkt auf den Artikel "Systeminformationen ermitteln" verlinkt werden. Diesen Artikel gab es bei der Erstellung der GRUB 2 Artikel noch nicht. Deswegen jetzt ein wenig das Durcheinander. Oder wahrscheinlich wäre es noch besser, auf die Redundanz zu pfeifen und es GRUB-sepzifisch in "GRUB Umgebung analysieren" teilweise redundant zu thematisieren.

Ich kümmere mich darum.

black tencate schrieb:

noch besser wäre imho

df -h

Grundsätzlich ist das die bessere Idee, wenn man davon ausgehen kann, dass die Partitionen gemountet sind - was hier in den meisten Fällen wo der Link auftaucht - der Fall sein dürfte.

BTW, was sagt Ihr zu der kürzlich eingefügten Tabelle bei der chroot-Methode. Ich blicke da gerade noch so durch - aber ich weiß auch, worauf es ankommt. Ich befürchte, dass die für einen Anfänger zu unübersichtlich ist.

Meinungen?

Gruß, Martin

Hi Newubunti,

du schriebst:

BTW, was sagt Ihr zu der kürzlich eingefügten Tabelle bei der chroot-Methode. Ich blicke da gerade noch so durch - aber ich weiß auch, worauf es ankommt. Ich befürchte, dass die für einen Anfänger zu unübersichtlich ist.

Mir geht es ähnlich. Ich finde die Idee zwar sehr gut zusätzlich noch RAID zu behandeln, allerdings hat die Übersichtlichkeit imho stark eingebüßt. Soll die chroot-Methode in einen eigenen Artikel ausgelagert werden, wo dann beide Beispiele (normal/RAID) jeweils einen eigenen Abschnitt bekommen?

Gruss Lasall

Bei der Tabelle versteht ein Anfänger nur noch Bahnhof. Hab das erst kürzlich in einem Thread erlebt. Eine übersichtlichere Darstellung wäre vorteilhaft.

Ich würde Lasall zustimmen, dass eine Auslagerung und Aufteilung in zwei unterschiedliche Fallbeispiele besser wäre.

Hej Newubunti,

Newubunti schrieb:

... BTW, was sagt Ihr zu der kürzlich eingefügten Tabelle bei der chroot-Methode. Ich blicke da gerade noch so durch - aber ich weiß auch, worauf es ankommt. Ich befürchte, dass die für einen Anfänger zu unübersichtlich ist.

Meinungen?

sieht gut aus (das übt, sich mit der (Wiki)Tabellendarstellung auseinanderzusetzen, aber, hast recht, daran könnte ein Anfänger schon verzweifeln, egal, welche Darstellung er dazu sieht), wobei ich zu dem RAID-Teil nichts beitragen kann, außer die 💡 plötzlich auftauchende Verständnisfrage:

grub-install /dev/sdX 

werden dabei auch mit dem anschließenden update-grub auf jeder Platte grub.cfg Dateien erzeugt?

Und weiter dann

...Abschließend verlässt man die chroot-Umgebung wieder, entweder mit Strg + D oder

exit 

hier könne imho ein entsprechender umount-Befehl angefügt werden.

Gruß black tencate

EDIT.:

bowman schrieb:

Bei der Tabelle versteht ein Anfänger nur noch Bahnhof. Hab das erst kürzlich in einem Thread erlebt. Eine übersichtlichere Darstellung wäre vorteilhaft.

nimm doch die Kurzfassung von (?) redknight (?) fürs Forum:

sudo mount /dev/sdxy /mnt

sudo mount -o bind /dev /mnt/dev

sudo mount -o bind /sys /mnt/sys

sudo mount -t proc /proc /mnt/proc

sudo chroot /mnt /bin/bash

grub-install --force /dev/sdXY

(evt. noch ein update-grub)

exit

sudo umount /mnt/dev /mnt/proc /mnt/sys /mnt

Lasall schrieb:

Soll die chroot-Methode in einen eigenen Artikel ausgelagert werden, wo dann beide Beispiele (normal/RAID) jeweils einen eigenen Abschnitt bekommen?

Also einen eigenen Artikel fände ich nicht so toll. Die meisten Supporter und auch Nutzer dürften sich jetzt endlich darauf eingeschossen haben, dass man das im Reparatur-Artikel findet. Zahlreiche Threads dürften auch darauf verlinken, wenn man das jetzt verschiebt, fände ich das ungünstig. So lang ist der Artikel ja auch noch nicht.

Ich würde es einfach hintereinander stellen, also:

Hi Newubunti,

ok und +1.

Gruss Lasall

black tencate schrieb:

bowman schrieb: Bei der Tabelle versteht ein Anfänger nur noch Bahnhof. Hab das erst kürzlich in einem Thread erlebt. Eine übersichtlichere Darstellung wäre vorteilhaft.

nimm doch die Kurzfassung von (?) redknight (?) fürs Forum:

Das mache ich nur in Notfällen, wenn der User Schwierigkeiten mit der Umsetzung hat. Wenn man die Prozedur auf einen Wikiartikel verlinken kann, der sie schön übersichtlich und nachvollziehbar darstellt, dann muss man das nicht in jedem Thread aufs neu eintippen. Dazu ist ja das Wiki da, oder? 😉

Der Vorschlag von Newubunti ist klasse. 👍

Newubunti schrieb:

Wenn das ok ist, dann setze ich das die Tage mal um.

Erledigt!

Außerdem erste Anpassungen hinsichtlich EFI vorgenommen.

Gruß, Martin

Hi Newubunti,

du schriebst:

Erledigt!

Klasse, sieht jetzt wieder richtig übersichtlich aus 👍 !

Gruss Lasall