# FAQ Tips > Tipps und Tricks >  Wir bauen uns ein Testsystem UND MEHR in 20 Minuten - am Beispiel Suse8.x mit grub

## LX-Ben

Die Beschreibung ist hier in voller Länge abgedruckt, damit der
eine oder andere mit Schlussfolgerung 'Ach, so einfach ist das?'
Appetit bekommt, die neuen Möglichkeiten zu nutzen. Der Gesamt-
text ist außerdem als *.ZIP angehängt.
======================
Die Profis werden es eleganter realisieren, ich wollte es
durchsichtig und narrensicher Schritt für Schritt lösen.
Um den Umsteigern die Scheu vor Kommandozeilenbefehlen zu
nehmen, sind die Kommandos jeweils ausführlich erläutert.
Die Nutzung dieser Beschreibung für andere Distributionen
und Dateisysteme dürfte meist unproblematisch sein.

Sicherheit ist nicht alles, aber ohne Sicherheit
ist alles NICHTS.

1. Zielsetzung und Methoden
2. Durchführung
3. Die zwei Anpassungen - und viele Nutzmöglichkeiten
-----

zu 1. Zielsetzung und Methoden
Linux per CD-Start startet immer per Ramdisk - damit ist die totale
Flexibilität gegeben, welche Linuxpartition genutzt wird. Und
zeigt die Leichtigkeit und Eleganz, mit der eine weitere Partition
als Testsystem genutzt werden kann oder Linux mit einfachsten
Maßnahmen 'auf eine Partition umzieht.' Ferner kann - bevor die
Linux-Datensicherungsmöglichkeiten erprobt sind - diese Methode
benutzt werden, um 'das Erreichte' zu sichern und im Katastrofen-
fall einen Rückweg zu haben. Auch zum Beispiel nach verunglückten
Updates von Anwendungen oder der gesamten Distribution. Oder auch,
um im Vergleich zu entscheiden, ob man/frau lieber auf das nächste
fehlerfreiere Linux-Update wartet: Ideen habt ihr selbst genug.

Das Tool 'dd' ist ein mächtiges Werkzeug zum spuren-/blockweisen
Kopieren, aber bei Fehlbedienung mit fatalen Folgen, außerdem
dauert dd bei nur teilweise belegten Partitionen deutlich
länger als Kopieren. Win98-DriveImage2002 war meine zweite Lösungs-
variante, aber wie an den nachfolgenden Durchsatzzeiten ablesbar,
kann es zeitlich mit Linux-Lösungen nicht konkurrieren. Als DER
Lösungsweg hat sich für mich daher 'cp (Kopieren) unter geeigneten
Bedingungen' erwiesen.

Das zweite Problem sind die beim Plattenstart in Benutzung befind-
lichen 'Offenen Dateien.' Zwar kann man als root mit 'init 1' auf
einen solchen Status 'herunterfahren', dass lsof (list open files)
keine offenen Dateien mehr feststellt, aber da auch die Möglichkeiten
des CD-Rescue-Starts ausgelotet werden sollen, habe ich mich zu
der Rescrue-CD-Methode entschlossen.

Meine Sachangaben: Linux-PROduktionssystem ist hda10 mit 8 GB
Kapazität und 2,1 GB used. Ziel des Testsystems ist hda11
mit 9 GB Kapazität. Da das Duplizieren der Testpartition
per cp erfolgt, wäre auch eine Zielpartition mit 3 GB
völlig ausreichend.

zu 2. Durchführung
Zuerst wird das grub-Startmenü erweitert: Das hat den Sinn,
dass die hinzugenommene Linux-Startpartition auch bereits
durch den Kopiervorgang im Testsystem berücksichtigt ist.

kwrite /boot/grub/menu.lst (HIER: Vom root Fertig geändert)
==========================



> # Modified! Last modification Jul 25 CEST 2005
> -siehe auch untenstehenden Beitrag vom 25.07.2005!
> gfxmenu (hd0,9)/boot/message
> color white/blue black/light-gray
> default 0
> timeout 8
> bootp
> 
> ###Don't change this comment - YaST2 identifier: Original name: Suse9.1-TEST(hda11-Test)###
> ...


----------------
REM Wie unschwer zu erkennen ist, wurde lediglich der Block
'title Suse8.x-PRO(hda10)' davor gedoppelt und der title sowie die Einträge von hd0,9 auf hd0,10 sowie von hda10 auf hda11 geändert.
*Bitte hierzu auch den Beitrag vom 25.07.2005 beachten - man lernt nie aus. 
PS: Der Anhang ist noch nicht geändert, aber die zwei kleinen Anpassungen sind ja kein Problem..* 

Nun wird die bootbare Suse-CD1 eingelegt und der PC neu gestartet.
Als Startoption wird Rescue ausgewählt. Bei 'Rescue login:' wird
root eingegeben.
REM Damit sind wir ohne Passwordeingabe 'im System' - wie bei ALLEN
Betriebssystemen (auch Win2k,XP) hat derjenige (bzw. diejenige) Zugang
zu allen Einzeldateien, der physikalischen Rechnerzugang hat. Das löst
die Anregung aus, ob nicht ggf. BIOS-Kennwörter oder das Verschlüsseln
(Crypten) wichtiger Dateien genutzt werden sollte.

fdisk -l  zeigt die Partitionsübersicht, mit df -m ersieht man, dass
noch keine Plattenpartition gemountet (eingehängt) wurde. Daher
werden mit 'md /mnt/res10' und 'md /mnt/res11' die mount-Ziele
für das Einspiegeln der physikalischen Partitionen hda10 und hda11
erstellt (Namenswahl beliebig) und per
'mount -t ext3 /dev/hda10 /mnt/res10' sowie
'mount -t ext3 /dev/hda11 /mnt/res11'
in unser per CD gestartetes Linux-System eingespiegelt.

df -m bestätigt das erfolgreiche mounten - aber damit ein aktuell voll
identisches System erzeugt wird, putzen wir vorher die Testpartition mit
'rm -rf /mnt/res11' - endlich kann der berüchtigte Removebefehl mal
nützlich eingesetzt werden (bis zu zwei Minuten). Die Anzeige '/mnt/res11
not removed - busy' ist logisch und nicht zu beachten, da der Mountpunkt
ja noch aktiv ist. df -m zur Anzeige des neuen Standes eingeben.

'cd /mnt/res10'  ist ein wichtiger Zwischenschritt !
REM 'cp -a /mnt/res10 /mnt/res11' würde auf hda11 ein unbrauchbares
Haupt-Unterverzeichnis res10 entstehen lassen!
dir zeigt an, dass wir auf dem richtigen Produktionslaufwerk sind.
cp -a * /mnt/res11 - jetzt ist zehn Minuten Kaffeepause angesagt
REM Die cp-Option -a schließt automatisch etliche Unterfunktionen ein.

df -m sollte anschließend zeigen, dass hda10 und hda11 identische used-
Größenangaben aufweisen.

DAS WAR'S - jedenfalls schon fast. Die Boot-CD wird entnommen, und
nach Eingabe von reboot wird das Platten-Linux gestartet.

zu 3. Die zwei Anpassungen - und viele Nutzmöglichkeiten
Im Startmenü erstmal die PROduktionsPartition (hda10) auswählen -
per 'default 0' würde ja das Testsystem auf hda11 gestartet, welches
durch cp der fstab aber noch auf hda10 verweist (funktioniert aber).

Anpassung 1: Die Einfügung der Startpartition Testsystem in das Platten-
Bootmenü wurde bereits unter Ziffer 2 erledigt.

Anpassung 2: Bleibt also nur noch die Notwendigkeit, der hda11-Partition
'mitzuteilen', dass hda11 als / genutzt wird. Da die Testpartition im
PROduktionssystem nicht automatisch gemountet werden soll (strikte Funk-
tionstrennung!), ist nach Anmeldung als root 'md /mnt/res11' sowie
'mount -t ext3 /dev/hda11 /mnt/res11' einzugeben.

df -m bestätigt, dass wir uns auf hda10 als  "/" befinden.
kwrite /mnt/res11/etc/fstab  erledigt den Rest, die erste Zeile ist nur
VON '/dev/hda10 / ext3 defaults 1 1'
AUF '/dev/hda11 / ext3 defaults 1 1'
ZU ÄNDERN - DAS WAR JETZT WIRKLICH ALLES! In zwanzig Minuten alles erledigt.

Nutzmöglichkeiten: Test- und Reservesystem; Linux-Umzug auf eine andere
Partition; Gastystem - auch hinsichtlich weiterer Beschränkungen auf
Laufwerke/Gerätefunktionen; vorläufige Datensicherung, bis die Linux-
Erfahrung besere Lösungen ermöglicht (dann physikalisch unabhängiger
Datenträger!).

DAZU NOCH ZWEI PROBLEMLÖSUNGEN:
a) Linux zieht auf eine andere Partition um - grub im MBR muss es auch
erfahren: Per Menü das Testsystem/neue System starten. Yast2 - System ..
den grub-Loader neu in den MBR schreiben. Nach erfolgreichem Test
kann die /boot/grub/menu.lst angepasst und die alte Partition neuen
Verwendungszwecken 'zugeführt werden.'
b) grub per MBR startet nicht mehr, außerdem ist die PROduktions-
Partition 'zerschossen': Suse-CD1 booten.

./. Boot Installed OS -  klingt verführerisch, benutzt aber den
unbrauchbaren grub-MBR.

Installation - deutsch - Installiertes System starten - und nun bietet
Yast per Mausklick die Option, /dev/hda10 oder /dev/hda11 zu starten.
Der geänderte/defekte grub-Bootloader kann (durch root) nun per
Kontrollzentrum -Yast2 - System erneut in den MBR geschrieben
werden.

Die Nutzung der Beschreibung geschieht auf eigene Gefahr - wegen der
Streubreite der in Natura vorkommenden Linuxvarianten ist jegliche
Gewährleistung ausgeschlossen.

LINUX-Flexibilität - das ist die Zukunft.

PS: Da einige den lilo-Bootloader benutzen, wären sie sicher dankbar,
wenn jemand hier die Änderungseinträge für das zusätzliche Testsystem
ins lilo-Menü bescheiben könnte.

----------


## HirschHeisseIch

Hier noch eine angepasste lilo.conf



```
boot	= /dev/hda
change-rules
reset
read-only
menu-scheme = Wg:kw:Wg:Wg
lba32
prompt
timeout	= 80
message	= /boot/message

  image  = /boot/vmlinuz
  label  = Suse8.x-TEST(hda11)
  root   = /dev/hda11
  vga    = 791
  initrd = /boot/initrd
  append = "hdc=ide-scsi"

  image  = /boot/vmlinuz
  label  = Suse8.x-PRO(hda10)
  root   = /dev/hda10
  vga    = 791
  initrd = /boot/initrd
  append = "hdc=ide-scsi"

  image  = /boot/vmlinuz.suse
  label  = failsafe
  root   = /dev/hda5
  vga    = 791
  initrd = /boot/initrd.suse
  append = "ide=nodma apm=off acpi=off  idebus=133 hdd=ide-scsi"
  optional

  image  = /boot/memtest.bin
  label  = memtest86

# Wie man sieht ist auch hier lediglich das label (Der angezeigte Name) und der root-Eintrag geändert.
```

Auch diese ist als zip-File angehängt. Wir wollen ja den Stil waren  :Wink:

----------


## LX-Ben

Nach über vier Monaten Erfahrung - es ist einfach herrlich (oder neudeutsch
goil), nach Lust und Laune aber praktisch ohne jedes Risiko Neues zu testen
und dann das eventuell zermüllte Testsystem aus dem Produktionssystem
wieder herzustellen oder die Änderungen auch in die Produktionspartition
zu übernehmen. Gäste zuhause erhalten nur Zugang auf mein Testsystem
als stark eingeschränkter Normaluser - diesen User gibt es zwar auch in der
Produktionspartition -so dass er per cp automatisch auf dem Testsystem
vorhanden ist- aber auf der Produktions-Partition wird dieser spezielle user 
nicht angerührt. Z.B. kann ich damit risikolos diese bekannte Gäste-Bitte 
erfüllen "Darf ich mal schnell nachsehen, ob neue Mails für mich bei web.de 
angekommen sind?" 

Aktuell hatte ich nacheinander fünf verschiedenen mplayer-binary-RPMS    
getestet, die aber alle entweder nicht sauber oder gar nicht liefen - jetzt
ist der Testrechner wieder sauber.

----------


## linuxhanz

auch_seMf_add:  :Big Grin: 

früher war man auch gut beraten die erste Partition für BSD/M$ etc. zu nutzen.
Zumindest BSD ging ne Zeit lang nicht auf logische Partitonen zu installen.
(deshalb auf ne primary)

Gemein ist auch, wenn der lilo im mbr sitzt und man mal von hda mal von
hdb (Wobei ich hier von 2 Platten spreche)
(usr)/sbin/lilo ausführt das kann böse überraschungen mit-sich-bringen.
Es dauert einige Zeit (fand ich) per Rettungssystem dem lilo alles 
benutzerdefiniert zu übergeben.

EDIT: hat mal jemand lilo -r ausprobiert?

Meisst habe ich dann Kernel/initrd nochmal in die Partition kopiert von der ich lilo 
ausgeführt habe.

Übrigens ist das BSD-Kernel kompilieren auch nicht so schwer.

Und noch ein Tip: Immer auf dem 2. Rechner eine Doku/Intern{a|e}t
Anschluss und/oder Bücher und nicht Bier.

Besser ist ein extra Test Rechner.

----------


## LX-Ben

Neben meinen einjährigen Praxiserfahrungen (Testsystem wegen Unzufriedenheit mit Installationen aus Produktionspartition in 20 Minuten wieder hergestellt) gibt es eine weitere Anwendererfahrung: http://www.linuxforen.de/forums/show...hreadid=111478

----------


## LX-Ben

SuSE-Update9.0-geprägter Nachtrag!

Der Startbeitrag war beflügelt von der Begeisterung, fast risikolos wie unser Firmen-Rechenzentrum testen und ggf. den Rückweg anzutreten zu können, nachdem das  Testsystem-SuSE8.1 auch nach Update des Produktionssystems auf 8.2 problemlos weiterfunktionierte. Doch mit dem SuSE9.0-Update "kommt die Stunde der Wahrheit" - hält mein aus Erfahrungen anderer zusammengesetzter Lösungsvorschlag?  [SuSE9.0-Neuinstallationsfragen sind damit ausgeklammert!].

Und selbstkritisch stelle ich fest, dass nach 9.0-Update die hda11-Testpartition-8.2 sich zwar noch starten lässt und die meisten Anwendungen funktionieren, aber eben nicht mehr alle, zum Beispiel kein Sound mehr, mount-Fehler bei Windows-Partitionen u.ä.: Nach den Linux-Start-Fehlermeldungen [F2 für verboose] ist zu erkennen, dass einige lib's der /boot-Partition auch upgedated wurden, weswegen sich diese Ausfälle erklären - neue lib-Versionen haben evtl. abweichende Funktionen und werden nicht akzeptiert/nicht geladen. Naja bei funktionierender Datensicherung kein Problem, und umso stärker ist der Druck, das Update 9.0 gründlich auszutesten sowie letzte Feinheiten zu beheben und dann die Testpartition auch auf SuSE9.0 umzukopieren.

1. Um maximal vorbereitet zu sein, wurde auf Linuxforen.de alles gesammelt, was sich mit Suchen nach "9.0" finden liess. Das bedeutete, fünf Wochen voller Ungeduld die Füße still zu halten, doch es hat sich gelohnt: Nach Update incl. sofortiger Umsetzung der Erfahrungen etlicher Test-Installierer bin ich ziemlich zufrieden, denn trotz aller hiesigen Lustschreie "SuSE9.0 - klappt dies nicht - klappt das nicht" stelle ich nüchtern fest: Beim  Update wurden bei meinem PC 526! zu aktualisierende bzw. neue Pakete in der Vorschau genannt - da ist die Zahl der Hautabschürfungen durch die zu unterstützende schier unübersichtliche Hardwarewelt recht gut gelungen.

2.
a) Zum Updaten wurde die CD-Version anstatt DVD gebootet, so dass das evtl. Löschen von DVD-installierten SourceDateien nicht erforderlich wurde.
b) Mein Produktionssystem ist hda10 und mein Testsystem ist hda11. Der naheliegende Erstversuch, das Update auf dem Testsystem hda11 durchzuführen, brachte SuSEs CD-Update völlig ins Schleudern und machte hda11 fast unbrauchbar.

b) Also hda11 aus hda10 gemäß diesem Beitrag wieder hergestellt und neuer Update-Start. Das Update auf hda10 läuft nun klaglos durch und bootet neu. Das wichtigste Ärgernis beseitige ich als root sofort, nämlich das Problem der übereilten SuSE9.0-Firewallregel zu ipv6, nachzulesen bei Linuxforen unter http://www.linuxforen.de/forums/show...hreadid=103022 Seite 3, Beitrag Luke_S98 (mozilla, ..firebird, ..netscape laufen nach Update soo langsam). Auch verzerrter/knisternder Sound wie unter http://www.linuxforen.de/forums/show...hreadid=101120 beschrieben, trat bei mir unter SuSE9.0 auf - über xmms, links oben anklicken - Optionen - Einstellungen - Ausgabe-Plugin habe ich vom voreingestellten 'OSS-Treiber 1.2.8' auf ALSA 1.2.8 umgestellt; eSound-Plugin ist einen Hauch weniger originalgetreu (nach meinen Ohren  :Smilie:  ), dafür funktioniert aber dann der Lautstärke-Schieberegler in xmms. Ferner hat das SuSE9.0-Update 'vergessen', dass ich *.txt generell der Anwendung kwrite zugeordnet hatte und noch so ein paar Kleinigkeiten - das übt mal wieder  Auch cups (Common UNIX Printing System) verhielt sich anfangs unberechenbar - unter kde3 und user blieb der Druck einfach im Druckerspool stehen. Nachdem einmal unter kde3 und root gedruckt wurde, war das user-Druckproblem "verschwunden."

c) Mein Produktionssystem(SuSE9.0,hda10) werde ich wohl noch mindestens zwei Wochen konkurrierend nutzen, bevor ich hda11 aus hda10-anpasster Kopie überschreibe, aber Schockerlebnisse erwarte ich (derzeit) nicht mehr.

d) Was mir zum SuSE9.0-Update positiv aufgefallen ist, mal abgesehen vom Schließen von Sicherheitslücken
-Meine Fein-Einstellungen des Desktops, der Browser usw. wurden praktisch hundertprozentig übernommen, lediglich die kwrite-Schriftgröße musste ich neu einstellen, und mein Scriptpfad ging auch irgendwie verloren, aber das ist weniger Arbeit als MS-Sober.A..C (..Z soon coming).
-Die kde3-Schriften sind nach Update generell viel schärfer geworden.
-Subjektiv scheint mir auch mein Desktop-Linux als auch die (Modem-)Internetverbindung nochmal bemerkbar schneller geworden zu sein.
-Im Systemtray findet sich unter root ein neuer (grüner) "SuSE-Plugger" - scheint zumindest teilweise ein Ersatz für die bei mir entfernte Funktion SuSE-Watcher (.._Online-Updatefunktion) zu sein: Dort habe ich alles nicht Notwendige per rechter Maustaste deaktiviert, und automatische Internetverbindung schon gar nicht erlaubt.
-Zum Abschluss des SuSE9.0-CD-Updatelaufes erschien u.a. eine (zu diesem Zeitpunkt nicht druckbare) Bildschirmnachricht, dass beim Drucker-Dienst cupsd ein root-PW einzurichten sei und die ich deshalb händisch mühsam abgeschrieben habe. Doch auf meinem Einzelplatz-PC kann ich 'trotz Update' problemlos wie bisher per cupsd  drucken. *)

PS: Die vor Update gezogene hda10-Langzeitsicherung(SuSE8.2) auf CDRW wird vorsichtshalber noch ca. drei Monate aufgehoben.

*) Siehe auch Ziffer 2.b) letzte drei Zeilen. Die SuSE9.0-Update-Information hier im Originalwortlaut:



> Änderungen beim CUPS Druckdienst (cupsd) - SuSE 9.0
> Der cupsd wechselt nach dem Start vom Benutzer root zum Benutzer lp. Vorteil ist die deutlich höhere Sicherheit. Konsequenzen:
> - Es muss die cups-Authentisierung verwendet werden. Dazu muss der Benutzer root mit dem Befehl 'lppasswd -g sys -a root' ein CUPS-Passwort setzen.
> - Der cupsd verwendet /etc/cups/printcap und /etc/printcap ist ein symbolischer Link auf /etc/cup/printcap.
> - Der cupsd kann nicht mehr mit 'rccups reload' neu geladen werden. Statt dessen ist 'rccups restart' zu verwenden.
> 
> Die bei BrowseAllow/BrowseDeny gesetzten Zugriffsbedingungen beziehen sich jetzt auf jeglichen Zugriff auf den cupsd. Zugriffe von unberechtigten Rechnern werden hiermit sofort zurückgewiesen. Siehe auch detaillierte Informationen unter  http://portal.suse.com/sdb/de/2003/0...ichten-90.html

----------


## LX-Ben

Beiträge sollen ja anwendungs-sicher sein. Vor kurzem gab es auf Linuxforen eine lebhafte Diskussion, wie auch hidden-Dateien kopiert werden können. Dort wurde bezweifelt, dass der Befehl 'cp -a * ...' alles kopieren würde. Mein aktuell neu durchgeführter Test zu 'cp -a * ..' mit Knoppix-CD3.2 und Startbefehl 'knoppix 2 = runlevel 2 = echte console) bestätigt, dass dieser Befehl für das Erstellen des Testsystems problemlos funktioniert. Bei gestartetem Desktop scheint 'cp -a * ..' aber nicht "vollkommen zu sein", was zu beachten ist. Die kompletten Beiträge finden sich hier --> http://www.linuxforen.de/forums/show...890#post717890

----------


## LX-Ben

In meinem Beitrag vom  '27th December 2003, 14:30' schrieb ich: 


> Und selbstkritisch stelle ich fest, dass nach 9.0-Update die hda11-Testpartition-8.2 sich zwar noch starten lässt und die meisten Anwendungen funktionieren, aber eben nicht mehr alle, zum Beispiel kein Sound mehr, mount-Fehler bei Windows-Partitionen u.ä.: Nach den Linux-Start-Fehlermeldungen [F2 für verboose] ist zu erkennen, dass einige lib's der /boot-Partition auch upgedated wurden, weswegen sich diese Ausfälle erklären - neue lib-Versionen haben evtl. abweichende Funktionen und werden nicht akzeptiert/nicht geladen..


Damals kam ich zu dem Schluss, man könne keine zwei unterschiedlichen Linux-SuSE-Versionen (wegen unterschiedlicher lib-Versionen) problemlos nebeneinander nutzen: Das war leider nicht zu Ende gedacht, und keiner hat es gemerkt. Denn es geht doch - hier die Korrektur.

Ein Produktivsystem und ein baugleiches Testsystem (per obigem Konzept) auf dem gleichen PC sind sehr angenehme Linux-Errungenschaften. Das geht so lange gut, bis das Produktivsystem upgedated wird, am aktuell getesteten Beispiel:

Das hda10-Produktivsystem wird von SuSE9.0 auf 9.1 upgedated. Wird nun der PC per grub aus dem MBR neu gestartet, wird gemäß dem grub-Eintrag zunächst auf das hda10-Produktivsystem verzweigt, einige (neueste) libs geladen und dann die Auswahl aus hda10-/boot/grup/menu.lst angeboten, u.a. das hda11-Testsystem. Wird das hda11-Testsystem (mit Version 9.0) nun als "/" gestartet, können die bereits von hda10 geladenen neuesten libs in Konflikt mit Nutzungen der alten Version 9.0 von der hda11 kommen und nicht mehr korrekt ausführbar sein.

Die ausgetestete Lösung: Die SuSE-CDs 1 bzw. 2 sind bootbar, benutzen grub und bieten unter Auswahl 'Installation' die Möglichkeit, eine vorhandene Installation zu starten: Dann dort einfach hda11 auswählen! Bei abweichenden Versionen darf die zweite Linux-SuSE-Installation also nur direkt per CD-Boot gestartet werden.

Damit leben Version 9.1 (per MBR-grub gestartet) bzw. 9.0 (per CD-grub gestartet) in friedlicher fehlerfreier Koexistenz. Wem das Starten per CD zu aufwändig ist, der kann über hda11-yast2 (Testsystem) auch den grub-Start für Version9.0 auf Diskette schreiben lassen. Sobald die neue Version9.1 auf dem Produktivsystem problemlos funktioniert, wird sinnvollerweise auch das Testsystem auf die neueste Version gebracht - wie gehabt mit knoppix-Start .. und 'Sonne@ /mnt/hda10# cp -a * /mnt/hda11'.

----------


## LX-Ben

Nochmal zum Erstellen des grub-loaders, wenn unterschiedlich SuSE-Versionen genutzt werden
-Von CD-ROM wurde im vorigen Beitrag schon beschrieben
-Und nun 'grub-loader von disk booten:

1. Der wirklich einfachste Weg ist root-konsole und 'grub-install /dev/fd0'. Wenn das BIOS auf 'Erstes Bootmedium Diskette' umgestellt ist und der grub-loader von Disk gestartet wird, meldet der Bildschirm 'grub loading stage 1.5', während sich der mit yast erzeugte  grub-loader mit 'stage 2' meldet.

2. Es geht tatsächlich auch mit yast, wenn auch mehr als umständlich und mit falschen Info-Anzeigen
yast  System  Konfiguration des Bootloaders  Ort des Bootloaders markieren  Bearbeiten  Diskette /dev/fd0  BEENDEN  dann wird Diskschreiben angeboten. Bei evtl. Auswahl der Lowlevel-Formatierung ist Angabe eines Dateisystems zwingend (wird per yast NICHT überprüft).

	- Fälschlicherweise bleibt nach dem nächsten Booten in yast die Anzeige 'Ort des Bootloaders /dev/fd0' erhalten, obwohl bei entsprechend eingestelltem BIOS und nicht eingelegter grub-loader-Diskette sehr wohl der (per yast NICHT GELÖSCHTE) Festplatten-grub gestartet wird! Erst nach dem dritten grub-Neustart hatte yast wieder auf '1. IDE Maxtor..' selbsttätig umgestellt.

	Die 1. Lösung per root-konsole ist daher eindeutig durchsichtiger und praktikabler.

	Die Lösung zweimal durchführen  Disketten sind schneller sterblich als CDs!

----------


## LX-Ben

Widerspruch ist immer gut, wenn er weiterführt. So schrieb uns -nämlich den Lesern- alterpinguin am 22./23.07.2005 unter der Überschrift Hallo, grub-Eintrag  ist das so gewollt? sinngemäß:




> Ich benutze schon lange mehrere Linux-Distributionen (SuSE, Knoppix, Debian) auf meinem Rechner. Platten sind ja groß genug. In deinem Beispiel zu grub:
> ---------------------------- hier ---
> title Suse8.x-TEST(hda11)
> kernel (hd0,9)/boot/vmlinuz root=/dev/hda11 hdc=ide-scsi vga=791
> initrd (hd0,9)/boot/initrd
> 
> title Suse8.x-PRO(hda10)
> kernel (hd0,9)/boot/vmlinuz root=/dev/hda10 hdc=ide-scsi vga=791
> initrd (hd0,9)/boot/initrd
> ...


1.	alterpinguin hat Recht, so tief war ich gar nicht eingestiegen, weil die bisherige Lösung ja bis auf Release-Wechsel fehlerfrei funktionierte. Also mal schnell in den Kofler geschaut, und tatsächlich verwendet grub die Syntax hd0 statt hda/sda und zählt die Partitionen schon ab 0!, daher hd0,10 für das Nachladen von Kernel und initrd aus hda11 bei Starten des Testsystems!

[Laut Kofler kann die Datei je nach Distribution den Namen /boot/grub/grub.conf, ..menu.lst oder einen ähnliche Dateinamen haben. Beim Blättern im Platten-Masterbootbereich habe ich jedoch gesehen, dass der bei SuSE verwandte Name menu.lst dort in einem Folgesektor gespeichert ist, also nicht wahllos ändern! Und in /etc gibt es auch noch eine grub.conf, die aber offensichtlich anderen Zwecken dient.]

2.	Diese Anpassung in der /boot/grub/menu.lst auf die korrekte Lade-Partition ist nicht nur Korrektur eines Schönheitsfehlers, sondern bringt handfeste Vorteile, was sich aus meinen Nachtests ergab!

3.	a) Dazu habe ich mich zunächst per Plattenmonitor davon überzeugt, dass grub tatsächlich in den MBR geschrieben wurde, hier der ascii-Auszug aus Head 0, Track 0 und Sector 1 (Sektoren werden ab 1 gezählt) --> .....¥É}Þ0.¥ò}Þ*.Ù_GRUB.Geom.Hard Disk.Read. Error.+.¦.-¼<.u¶+.......

b) Dann wurden die 14 hda10-Hauptverzeichnis-Namen (ausgenommen /boot) durch Anfügen eines Bindestriches renamed zB. /bin- .. und das Testsystem konnte problemlos neu gestartet werden. Fazit: Da somit keine libs usw. von hda10 geladen wurden, ist durch die Anpassungen in der menu.lst eine wirklich selbständige Kopie entstanden  dh. beim nächsten Releasewechsel können tatsächlich eine alte und eine neue SuSE-Version problemlos nebeneinander genutzt werden. 

c)	Als radikalen Abschlusstest habe ich dann sogar noch auf hd10 /boot in /boot- renamed. Beim Neustart kam die Meldung
ci)	gGRUB loading, please wait...
cii)	graphics file '(hd0,9) /boot/message' missing, press a key to continue...'
ciii)	Logisch, da der erste Kommandoaufruf in menu.lst zum Start der grafischen Menüoberfläche auf das nicht gefundene hda10-Verzeichnis /boot verweist.

Danach wurde das vollständige Bootmenü der menu.lst mit blauem Text angezeigt, und das Testsystem startete wie gewohnt. Wie kann das denn sein, wenn hda10/boot/menu.lst durch rename nicht gefunden werden konnte? 

d)	Das Suchen im MBR-Bereich Head 0, Track 0 und Sector 2 ff. war erfolglos, dort ist keine menu.lst 'versteckt'. Also mal eine Textausgabezeile in hda11/boot/menu.lst geändert, neu gestartet  und tatsächlich erscheint der geänderte Menütext beim nächsten Booten. Da die hda10-Verzeichnisse durch renamen vollkommen unbrauchbar gemacht wurden, somit von dort keinerlei files mehr geladen werden konnten, ergibt sich daraus zweierlei:
-  Der grub-Loader im MBR, der ja eigentlich auf hda10 zeigt, findet 'selbständig' eine geeignete menu.lst auf der folgenden Partition
-  Das Testsystem auf hda11 ist somit nachweislich eine selbständige Kopie. 

Danke, alterpinguin. Deine Ausführungen gehen aber noch weiter, nämlich du führst aus, dass mit entsprechenden Anpassungen in der menu.lst ganz unterschiedliche Distributionen eingebunden werden können. Das war jedoch nicht Ziel meines Beitrags, und deswegen zitiere ich hier deine Messages kommentarlos, sozusagen als Anregung für den jeweiligen weitergehenden Bedarf. Auf jeden Fall klingt es ziemlich einfach und logisch.
=============================




> hallo, grub-Eintrag ist das so gewollt? 
> 
> Hallo LX-Ben,
> ich benutze schon lange mehrere Linux (SuSE, Knoppix, Debian) auf meinem Rechner. Platten sind ja groß genug. In deinem Beispiel zu grub:
> ---------------------------- hier ---
> title Suse8.x-TEST(hda11)
> kernel (hd0,9)/boot/vmlinuz root=/dev/hda11 hdc=ide-scsi vga=791
> initrd (hd0,9)/boot/initrd
> 
> ...





> dann als Beispiel noch die Einträge aus meiner grub menu.lst 
> 
> ---- snip ------
> title SUSE LINUX 9.2
> kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 vga=0x31a selinux=0 splash=0 resume=/dev/hda1 desktop elevator=as showopts
> initrd (hd0,4)/boot/initrd
> 
> title LINUX Kernel 2.6.11.7
> kernel (hd0,4)/boot/vmlinuz-2.6.11.7 root=/dev/hda5 vga=0x31a selinux=0 splash=0 resume=/dev/hda1 desktop elevator=as showopts
> ...

----------


## LX-Ben

... und die Lösung funktioniert noch immer (seit sechs Jahren) – jetzt mit openSUSE11.0, allerdings war diesmal bei grub eine Anpassung notwendig:



```
# Modified by YaST2. Last modification on Fr Jun 27 19:56:40 CEST 2008
# Modified by LX-Ben. Last modification on June 28 10:36 MESZ 2008
default 0
timeout 8
gfxmenu (hd0,9)/boot/message

title openSUSE 11.0 (sda11, Work)
    root (hd0,10)
    kernel /boot/vmlinuz-2.6.25.5-1.1-pae root=/dev/disk/by-id/scsi-SATA_Maxtor_6Y080L0_Y2ARNY1C-part11 resume=/dev/sda9 splash=silent  showopts vga=0x317
    initrd /boot/initrd-2.6.25.5-1.1-pae

#------ALT=grub-KEIN-STARTEN-------------------
# openSUSE10.3-grub-Syntax
# kernel (hd0,10)/boot/vmlinuz-2.6.22.5-31-default root=/dev/sda11 resume=/dev/sda9 splash=silent  showopts vga=0x317
#   initrd (hd0,10)/boot/initrd-2.6.22.5-31-default

###Don't change this comment - YaST2 identifier: Original name: vista-Loader (vista-WinXP)###
title Windows-Loader (Fruehere Windows'e, vista)
    rootnoverify (hd0,0)
    makeactive
    chainloader (hd0,0)+1

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.0 (sda10, Org)
    root (hd0,9)
    kernel /boot/vmlinuz-2.6.25.5-1.1-pae root=/dev/disk/by-id/scsi-SATA_Maxtor_6Y080L0_Y2ARNY1C-part10 resume=/dev/sda9 splash=silent  showopts vga=0x317
    initrd /boot/initrd-2.6.25.5-1.1-pae
...
```

----------

