Festplatte platzt aus allen Naehten... :-(
Bernhard Thoben
Meine Festplatte reicht vorne und hinten nicht mehr aus; ich bin nur am
schauen, was ich noch brauche, und am l�schen. So geht es nicht mehr weiter!
Eine gr��ere Platte mu� her!
Bis dahin ist alles klar, aber: Ich habe ja ein in l�ngerer Zeit gut abge-
hangenes System, da� ich nicht unbedingt neu aufsetzen m�chte.
Szenario: Vier Partitionen, alle als prim�re Partion angelegt:
- Eine FAT32 mit einem Windows XP
- Eine ext3 als *reine* Daten-Partition
- Eine Swap-Partition
- Eine ext3 mit meinem Debian Lenny
Boot-Manager grub im MBR.
Wie kann ich m�glichst elegant alle Daten und die BS'e auf die neue Platte
bekommen? Es sollten *unbedingt* alle Rechte unter Linux erhalten bleiben;
unter XP auf FAT32 ist das ja wohl latte... (NTFS m�chte ich *nicht*!)
Alles in drei Archive (Swap lege ich neu an) zip'en, Zip's auf die Parti-
tionen der neuen Platte r�ber und ent-zip'en?
Die "neue" ext3 kann ich ja mittels eines Rettungs-Systems starten und dann
mittels grub-install den MBR auf der neuen Platte schreiben lassen, damit
die BS'e bootf�hig werden.
Evtl. noch zu beachten: Die "alte" Platte ist P-ATA, die "neue" wird eine
S-ATA. Wird das dann auch noch /dev/hd(x) sein, oder /dev/sd(x)?
Bin echt f�r jeden Tip dankbar....
Und weg... Bernhard
Helmut Hullen
Du meintest am 25.01.10:
> Meine Festplatte reicht vorne und hinten nicht mehr aus; ich bin nur
> am schauen, was ich noch brauche, und am l�schen. So geht es nicht
> mehr weiter! Eine gr��ere Platte mu� her!
> Bis dahin ist alles klar, aber: Ich habe ja ein in l�ngerer Zeit gut
> abge- hangenes System, da� ich nicht unbedingt neu aufsetzen m�chte.
> Szenario: Vier Partitionen, alle als prim�re Partion angelegt:
> - Eine FAT32 mit einem Windows XP
> - Eine ext3 als *reine* Daten-Partition
> - Eine Swap-Partition
> - Eine ext3 mit meinem Debian Lenny
> Boot-Manager grub im MBR.
�bliches Verfahren:
2. Platte einbauen,
nach Wunsch partitionieren
Dateisystem aufbringen
mit "cp" o.�. (am sichersten von einer bootf�higen CD wie Knoppix)
kopieren.
Wenn Du neurotisch bist: �ndere nur die Mountpunkte in "/etc/fstab" und
lass (wenigstens eine Weile) die alte Platte mitlaufen; sie dient dann
vor allem zum Booten.
--------------------------------------
die klassische Antwort dazu ist im Hard-Disk-Upgrade-Howto des
"The Linux Documentation Project" http://www.tldp.org/ zu finden:
http://www.tldp.org/HOWTO/HOWTO-INDEX/categories.html
http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/copy.html
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Juri Grabowski
>
Du kannst auch Norton Ghost oder �hnliches benutzen, um alle Daten, byte
zu byte auf die neu Platte zu kopieren, dann kannst du mit dem Paragon
Partition die Partitionen erweitern. Allerdings, du sollst dann unter
Linux (von der Alte Platte) die cfg-Dateien auf der neue Festplatte zu
korregieren um das System ohne Problem zu starten fstab, grub ...
Michael Kramer
Am 25.01.2010 um 17:18:54 schriebst Du in LINUX.ger an All:
BT> Moin All!
BT> Meine Festplatte reicht vorne und hinten nicht mehr aus; ich bin nur
BT> am schauen, was ich noch brauche, und am l�schen. So geht es nicht
BT> mehr weiter!
BT> Eine gr��ere Platte mu� her!
[...]
BT> - Eine FAT32 mit einem Windows XP
BT> - Eine ext3 als *reine* Daten-Partition
BT> - Eine Swap-Partition
BT> - Eine ext3 mit meinem Debian Lenny
Der neuen Platte die Aufgabe der Datenpartition zu �bergeben, steht nicht
zur Debatte? Die freiwerdende k�nnte man unter einen anderen Mountpoint
unter Linux weiterbenutzen, oder mit $TOOL der XP Partition zukommen
lassen.
BT> Alles in drei Archive (Swap lege ich neu an) zip'en, Zip's auf die
BT> Parti- tionen der neuen Platte r�ber und ent-zip'en?
Unter Linux ist Zip nicht das passende Mittel, entweder cp -a oder tar.
Falls beide Platten gleichzeitig m�glich sind, ist cp vom Rettungssystem
erste Wahl.
BT> Die "neue" ext3 kann ich ja mittels eines Rettungs-Systems starten
BT> und dann mittels grub-install den MBR auf der neuen Platte schreiben
BT> lassen, damit die BS'e bootf�hig werden.
BT> Evtl. noch zu beachten: Die "alte" Platte ist P-ATA, die "neue" wird
BT> eine S-ATA. Wird das dann auch noch /dev/hd(x) sein, oder
BT> /dev/sd(x)?
Zur Info: Falls das wirklich passiert, brauchst Du auch eine neue initrd
und Du wirst bei jedem Update des Kernels Probleme bekommen. Du darfst Dir
dann jedesmal(!) VOR dem Reboot wieder eine neue initrd bauen und
/boot/grub/menu.lst anpassen. Solange man daran denkt, ist es aber kein
Problem.
Bis dann
Michael
Heiko Ruckdeschel
BT> Meine Festplatte reicht vorne und hinten nicht mehr aus;
Das Problem kannte ich. Ich habe es folgenderma�en gel�st:
Ich habe die Festplatte (2,5 Zoll IDE 80 GB) aus meimen Laptop ausgebaut
und die neue (leere) Festplatte (2,5 Zoll IDE 120 GB) eingebaut. Die alte
Festplatte habe ich mit einem USB-Adapter (ein einfacher Adapter, ohne
Geh�use) extern angeschlossen.
Aus dem Internet habe ich eine Live-CD mit dem GNU-Partition Editor
runtergeladen (Google Suche -> gparted)
Mit diesem Programm habe ich die Partitionen von meiner alten auf meine
neue Festplatte r�berkopiert. Danach noch Startpartition markiert usw. Das
Programm GParted ist zwar nicht das komfortabelste aber immerhin kann alles
im Grafikmodus mit der Maus gesteuert werden.
Der restliche freie Speicherplatz habe ich in eine neue Partition
verwendet. Allerdings kann man mit dem Gparted auch bestehende Partitionen
vergr��ern.
Bei mir hat dann alles einfach genauso funktioniert wie vorher, da ich
vorher eine IDE-Platte und danach auch wieder eine IDE-Platte verwende.
Genau da wird es bei Dir aber wahrscheinlich Probleme geben, da die neue
Platte keine P-ATA sondern eine S-ATA ist. Ich habe mit S-ATA leider keine
Erfahrung. Vielleicht kann da aber jemand anderer weiterhelfen.
Gruss,
Heiko
Bernhard Thoben
Am 27.01.2010 um 04:20 schrieb Michael Kramer an Bernhard Thoben folgendes:
BT>> Meine Festplatte reicht vorne und hinten nicht mehr aus; ich bin
BT>> nur am schauen, was ich noch brauche, und am l�schen. So geht es
BT>> nicht mehr weiter! Eine gr��ere Platte mu� her!
MK> [...]
BT>> - Eine FAT32 mit einem Windows XP
BT>> - Eine ext3 als *reine* Daten-Partition
BT>> - Eine Swap-Partition
BT>> - Eine ext3 mit meinem Debian Lenny
MK> Der neuen Platte die Aufgabe der Datenpartition zu �bergeben, steht
MK> nicht zur Debatte?
Ich la� meine Rechner ungerne mehr Energie als n�tig verbrauchen...
BT>> Alles in drei Archive (Swap lege ich neu an) zip'en, Zip's auf
BT>> die Parti- tionen der neuen Platte r�ber und ent-zip'en?
MK> Unter Linux ist Zip nicht das passende Mittel, entweder cp -a oder
MK> tar. Falls beide Platten gleichzeitig m�glich sind, ist cp vom
MK> Rettungssystem erste Wahl.
Ja, beide Platten sind parallel lauff�hig; also nehme ich "cp"! Booten kann
ich ja Knoppix...
BT>> Die "neue" ext3 kann ich ja mittels eines Rettungs-Systems
BT>> starten und dann mittels grub-install den MBR auf der neuen
BT>> Platte schreiben lassen, damit die BS'e bootf�hig werden.
BT>> Evtl. noch zu beachten: Die "alte" Platte ist P-ATA, die "neue"
BT>> wird eine S-ATA. Wird das dann auch noch /dev/hd(x) sein,
BT>> oder /dev/sd(x)?
MK> Zur Info: Falls das wirklich passiert, brauchst Du auch eine neue
MK> initrd und Du wirst bei jedem Update des Kernels Probleme bekommen. Du
MK> darfst Dir dann jedesmal(!) VOR dem Reboot wieder eine neue initrd
MK> bauen und /boot/grub/menu.lst anpassen. Solange man daran denkt, ist
MK> es aber kein Problem.
Das habe ich jetzt, ehrlich gesagt, nicht verstanden. Das mag aber daran
liegen, da� ich die Aufgabe der initrd nicht kenne.
Hat das mit P-ATA vs. S-ATA zu tun? S-ATA Platten sind derzeit wesentlich
billiger als eine P-ATA. Wenn aber eine P-ATA mehr Sinn macht, habe ich
damit auch kein Problem, an den paar EUR f�r eine neue P-ATA soll es auch
nicht scheitern..
Und weg... Bernhard
Bernhard Thoben
Am 25.01.2010 um 20:27 schrieb Helmut Hullen an All folgendes:
>> Meine Festplatte reicht vorne und hinten nicht mehr aus; ich bin nur
>> am schauen, was ich noch brauche, und am l�schen. So geht es nicht
>> mehr weiter! Eine gr��ere Platte mu� her!
>> Bis dahin ist alles klar, aber: Ich habe ja ein in l�ngerer Zeit gut
>> abge- hangenes System, da� ich nicht unbedingt neu aufsetzen m�chte.
>> Szenario: Vier Partitionen, alle als prim�re Partion angelegt:
>> - Eine FAT32 mit einem Windows XP
>> - Eine ext3 als *reine* Daten-Partition
>> - Eine Swap-Partition
>> - Eine ext3 mit meinem Debian Lenny
>> Boot-Manager grub im MBR.
HH> �bliches Verfahren:
HH> 2. Platte einbauen,
HH> nach Wunsch partitionieren
HH> Dateisystem aufbringen
HH> mit "cp" o.�. (am sichersten von einer bootf�higen CD wie Knoppix)
HH> kopieren.
Ok, alles klar.
HH> Wenn Du neurotisch bist: �ndere nur die Mountpunkte in "/etc/fstab"
HH> und lass (wenigstens eine Weile) die alte Platte mitlaufen; sie dient
HH> dann vor allem zum Booten.
Wie ich in einem anderen Beitrag schrieb, ich la� meine Rechner nur sehr
ungerne mehr Energie verbrauchen, also n�tig.
HH> die klassische Antwort dazu ist im Hard-Disk-Upgrade-Howto des
HH> "The Linux Documentation Project" http://www.tldp.org/ zu finden:
HH> http://www.tldp.org/HOWTO/HOWTO-INDEX/categories.html
HH> http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/copy.html
Das sehe ich mir mal an, danke.
Und weg... Bernhard
Helmut Hullen
Du meintest am 27.01.10:
MK>> Zur Info: Falls das wirklich passiert, brauchst Du auch eine neue
MK>> initrd und Du wirst bei jedem Update des Kernels Probleme
MK>> bekommen. Du darfst Dir dann jedesmal(!) VOR dem Reboot wieder
MK>> eine neue initrd bauen und /boot/grub/menu.lst anpassen. Solange
MK>> man daran denkt, ist es aber kein Problem.
> Das habe ich jetzt, ehrlich gesagt, nicht verstanden. Das mag aber
> daran liegen, da� ich die Aufgabe der initrd nicht kenne.
Die "initrd" muss nicht unbedingt ge�ndert werden, aber "/boot/grub/
menu.lst" (oder die entsprechende Datei bei GRUB 2) muss ge�ndert
werden. Einerseits wegen des Wechsels von P-ATA zu S-ATA, andererseits
wahrscheinlich, weil Dein Grub die Platten nach ihrer UUID sortiert, und
die hat sich beim Wechsel der Platten auch ge�ndert.
Aber die Installations-CD Deiner Distribution sollte das auch fast ohne
Deine Mithilfe hinbekommen.
> Hat das mit P-ATA vs. S-ATA zu tun? S-ATA Platten sind derzeit
> wesentlich billiger als eine P-ATA. Wenn aber eine P-ATA mehr Sinn
> macht, habe ich damit auch kein Problem, an den paar EUR f�r eine
> neue P-ATA soll es auch nicht scheitern..
Wenn per UUID sortiert und zugewiesen wird, dann ist der Wechsel von P-
ATA zu S-ATA unwichtig - nimm also S-ATA.
Michael Kramer
Am 27.01.2010 um 14:28:58 schriebst Du in LINUX.ger an mich:
BT>>> Evtl. noch zu beachten: Die "alte" Platte ist P-ATA, die "neue"
BT>>> wird eine S-ATA. Wird das dann auch noch /dev/hd(x) sein,
BT>>> oder /dev/sd(x)?
MK>> Zur Info: Falls das wirklich passiert, brauchst Du auch eine neue
MK>> initrd und Du wirst bei jedem Update des Kernels Probleme bekommen. Du
MK>> darfst Dir dann jedesmal(!) VOR dem Reboot wieder eine neue initrd
MK>> bauen und /boot/grub/menu.lst anpassen. Solange man daran denkt, ist
MK>> es aber kein Problem.
BT> Das habe ich jetzt, ehrlich gesagt, nicht verstanden. Das mag aber
BT> daran liegen, da� ich die Aufgabe der initrd nicht kenne.
BT> Hat das mit P-ATA vs. S-ATA zu tun? S-ATA Platten sind derzeit
BT> wesentlich billiger als eine P-ATA.
Falls sich durch die SATA-Platte der Devicename von /dev/hda in /dev/sda
�ndert, mu� /boot/grub/menu.lst angepa�t werden. Da der Devicename auch in
der Initrd verankert ist, mu� diese auch neu gebaut werden, "mkinitramfs"
ist daf�r das passende Tool.
Die initrd ist eine komprimierte Verzeichnisstruktur eines ganz minimalen
Systems, die beim Systemstart in den RAM geladen wird. Fr�her(tm) kam man
ohne initrd aus, dazu mu�te man "nur" einen Kernel bauen, der alle zum
Booten notwendigen Module fest einkompiliert hatte. Das war ein riesen
Spa�: Mit dem von der Distribution intallierten modularisierten Kernel und
Initrd booten, 20 Minuten Kernel kompilieren, diesen booten - Kernelpanic,
Distri-Kernel wieder geladen, Kernel umkonfiguriert, 20 Minuten kompiliert,
wieder gebootet - Kernelpanic, ... drei Leben sp�ter ging es dann, bis
lebenswichtige Hardware umgebaut wurde - Kernelpanic. Das will man heute
nicht mehr.
;-))
Kopiere zum Spa� mal eine initrd.img aus /boot in ein Verzeichnis Deiner
Wahl und packe sie mit:
unzip -c initrd.img | cpio -i -d -H newc --no-absolute-filenames
aus. Mit "grep -r "/dev/hda2" findest Du dann auch den Verweis auf das Root.
BT> Wenn aber eine P-ATA mehr Sinn macht, habe ich damit auch kein Problem,
BT> an den paar EUR f�r eine neue P-ATA soll es auch nicht scheitern..
SATA ist schon in Ordnung und sowieso vorzuziehen, man mu� sich nur des
Problems bewust sein. Evtl. gibt es auch eine Debian-Methode das zu l�sen,
da m��te man VORHER mal googlen.
PS: Ich w��te jetzt ehrlich gesagt nicht, wie man von einem Rettungssystem
eine passende initrd baut, denn die mu� zum sp�teren Kernel passen. Ich
habe das schon gemacht, nur wei� ich nicht mehr wie.
Bis dann
Michael
Bernhard Thoben
Am 27.01.2010 um 16:07 schrieb Helmut Hullen an All folgendes:
HH> Die "initrd" muss nicht unbedingt ge�ndert werden, aber "/boot/grub/
HH> menu.lst" (oder die entsprechende Datei bei GRUB 2) muss ge�ndert
HH> werden.
Das war mir schon klar.
HH> Einerseits wegen des Wechsels von P-ATA zu S-ATA, andererseits
HH> wahrscheinlich, weil Dein Grub die Platten nach ihrer UUID sortiert,
HH> und die hat sich beim Wechsel der Platten auch ge�ndert.
Hier ein Auszug meiner menu.lst:
=== Anfang des Imports der Datei <menu.lst> ===
title Debian GNU/Linux, kernel 2.6.26-2-686
root (hd0,1)
kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/hda2 ro vga=0x031a
initrd /boot/initrd.img-2.6.26-2-686
title Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)
root (hd0,1)
kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/hda2 ro single vga=0x031a
initrd /boot/initrd.img-2.6.26-2-686
root
# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/hda3
title Microsoft Windows XP Professional
root (hd0,2)
savedefault
makeactive
chainloader +1
=== Ende des Imports der Datei <menu.lst> ===
Wenn ich die Infos aus Wikipedia richtig deute, ist das obige *nicht* nach
UUID sortiert, richtig? Also m��te ein simples Anpassen der menu.lst (und
ggf. neu erzeugen der initrd) reichen.
Oder?
HH> Aber die Installations-CD Deiner Distribution sollte das auch fast
HH> ohne Deine Mithilfe hinbekommen.
Du w�rdest also das Basis-System *neu* aufbringen? (Installation)
Und weg... Bernhard
Bernhard Thoben
Am 28.01.2010 um 04:21 schrieb Michael Kramer an Bernhard Thoben folgendes:
MK> Falls sich durch die SATA-Platte der Devicename von /dev/hda in
MK> /dev/sda �ndert, mu� /boot/grub/menu.lst angepa�t werden.
Das war mit schon klar.
MK> Da der Devicename auch in der Initrd verankert ist, mu� diese auch neu
MK> gebaut werden,
Das nicht...
MK> "mkinitramfs" ist daf�r das passende Tool.
Wenn durch ein Update (Debian bringt ab und zu auch einen neuen Kernel raus)
der Kernel gewechselt wird, wird IMHO eh die initrd neu gebaut. Die menu.lst
*mu�* ich eh immer anpassen, da der Wert bei "vga=" *immer* gel�scht wird!
Und weg... Bernhard
Helmut Hullen
Du meintest am 28.01.10:
> Hier ein Auszug meiner menu.lst:
> === Anfang des Imports der Datei <menu.lst> ===
> title Debian GNU/Linux, kernel 2.6.26-2-686
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/hda2 ro vga=0x031a
> initrd /boot/initrd.img-2.6.26-2-686
> title Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/hda2 ro single
> vga=0x031a initrd /boot/initrd.img-2.6.26-2-686
> root
> Wenn ich die Infos aus Wikipedia richtig deute, ist das obige *nicht*
> nach UUID sortiert, richtig? Also m��te ein simples Anpassen der
> menu.lst (und ggf. neu erzeugen der initrd) reichen.
> Oder?
Korrekt. Purer Wechsel von hda2 nach sda2 sollte reichen.
HH>> Aber die Installations-CD Deiner Distribution sollte das auch fast
HH>> ohne Deine Mithilfe hinbekommen.
> Du w�rdest also das Basis-System *neu* aufbringen? (Installation)
Nein - Reparatur (o.�.); irgendwo sollte etwas mit Booten angeboten
werden.
Michael Kramer
MK>> Da der Devicename auch in der Initrd verankert ist, mu� diese auch neu
MK>> gebaut werden,
BT> Das nicht...
MK>> "mkinitramfs" ist daf�r das passende Tool.
BT> Wenn durch ein Update (Debian bringt ab und zu auch einen neuen
BT> Kernel raus) der Kernel gewechselt wird, wird IMHO eh die initrd neu
BT> gebaut.
Ja, nur hat das bei mir nie funktioniert. In der erstellten initrd (und
auch in der menu.lst) wurden immer wieder die alten Devicenamen
eingetragen.
Bis dann
Michael
Vitus Jensen
On Thu, 28 Jan 2010, Bernhard Thoben wrote:
> Am 28.01.2010 um 04:21 schrieb Michael Kramer an Bernhard Thoben folgendes:
>
> MK> "mkinitramfs" ist dafür das passende Tool.
>
> Wenn durch ein Update (Debian bringt ab und zu auch einen neuen Kernel raus)
> der Kernel gewechselt wird, wird IMHO eh die initrd neu gebaut. Die menu.lst
> *muß* ich eh immer anpassen, da der Wert bei "vga=" *immer* gelöscht wird!
Soweit ich mich erinnere, kannst Du den Wert für "vga=" auch so eintragen,
daß er immer für neue Kernel übernommen wird. Suche in der menu.lst nach
"Start Default Options" und trage "vga=" bei defoptions= ein. Evtl noch
bei altoptions=
Ungetestet mangelns Debian, aber es steht so noch ein einer alten Version
der Datei drin.
Tschüß,
Vitus
--
Vitus Jensen, Hannover, Germany, Earth, Universe (current)
Michael Kramer
Am 30.01.2010 um 10:00:50 schriebst Du in LINUX.ger an All:
>> MK> "mkinitramfs" ist daf�r das passende Tool.
>> Wenn durch ein Update (Debian bringt ab und zu auch einen neuen Kernel
raus)
>> der Kernel gewechselt wird, wird IMHO eh die initrd neu gebaut. Die
menu.lst
>> *mu�* ich eh immer anpassen, da der Wert bei "vga=" *immer* gel�scht
>> wird!
VJ> Soweit ich mich erinnere, kannst Du den Wert f�r "vga=" auch so
VJ> eintragen, da� er immer f�r neue Kernel �bernommen wird. Suche in
VJ> der menu.lst nach
VJ> "Start Default Options" und trage "vga=" bei defoptions= ein. Evtl
VJ> noch bei altoptions=
Dazu m��te Debian beim Update die alte menu.lst als Muster f�r die Neue
nehmen, aber grade das tut es nicht. Es scheint bei der Installation ein
Muster, oder auch nur ein paar passend gesetzte Variablen zu hinterlassen,
um aus diesen Informationen bei jedem Update eine neue menu.lst (und
initrd) zu generieren.
Aus Bequemlichkeit habe ich mich allerdings nie auf die Suche nach diesem
Muster gemacht.
Bis dann
Michael
Bernhard Thoben
Am 30.01.2010 um 10:00 schrieb Vitus Jensen an All folgendes:
>> Die menu.lst *muAf* ich eh immer anpassen, da der Wert bei
>> "vga=" *immer* gelA^Tscht wird!
VJ> Soweit ich mich erinnere, kannst Du den Wert fA�r "vga=" auch so
VJ> eintragen, daAf er immer fA�r neue Kernel A�bernommen wird. Suche in
VJ> der menu.lst nach "Start Default Options" und trage "vga=" bei
VJ> defoptions= ein. Evtl noch bei altoptions=
Das war ein Klasse Tip! Die Zeile, welche das macht, hei�t jetzt
# kopt=root=/dev/hda2 ro vga=0x31a
(Das Kommentarzeichen '#' MUSS drin bleiben!)
Danach noch ein beherztes update-grub und schon steht der Wert �berall
drin!
Danke!
Und weg... Bernhard
Michael Kramer
Am 31.01.2010 um 16:58:10 schriebst Du in LINUX.ger an Vitus Jensen:
BT> Das war ein Klasse Tip! Die Zeile, welche das macht, hei�t jetzt #
BT> kopt=root=/dev/hda2 ro vga=0x31a
BT> (Das Kommentarzeichen '#' MUSS drin bleiben!)
[klatsch vor die Stirn]
Arrrgg, Wald vs. B�ume!
Bis dann
Michael
Christoph 'Mehdorn' Weber
* Michael Kramer <Michael...@p13.monis.fido.de>:
> Dazu mￜￜte Debian beim Update die alte menu.lst als Muster fￜr die Neue
> nehmen, aber grade das tut es nicht.
Also bei Etch und Lenny hat es das bei mir immer gemacht. ï¿œltere
Versionen habe ich nie mit Grub betrieben.
> Aus Bequemlichkeit habe ich mich allerdings nie auf die Suche nach diesem
> Muster gemacht.
Bei der letzten Umstellung von IDE zu SATA(-N) habe ich nur die
eine Zeile in der menu.list geï¿œndert:
# kopt=root=/dev/sda1 ro
Nach update-grub hat es dann gepaï¿œt. Kann mich nicht erinnern,
die initrd neugebaut zu haben. Eventuell lief das automatisch.
Die Anpassungen von /etc/fstab und /etc/mtab sollte man nicht
vergessen, aber das hat mit grub wenig zu tun.
Christoph
--
On the other hand, poor Samara -- transcoded to FLV. No one deserves that.
Bernhard Thoben
Am 03.02.2010 um 04:20 schrieb Michael Kramer an Bernhard Thoben folgendes:
BT>> Das war ein Klasse Tip! Die Zeile, welche das macht, hei�t jetzt
BT>> # kopt=root=/dev/hda2 ro vga=0x31a (Das Kommentarzeichen '#' MUSS
BT>> drin bleiben!)
MK> [klatsch vor die Stirn]
MK> Arrrgg, Wald vs. B�ume!
Was ist mit neueren Versionen von grub? Ich hatte testweise Kubuntu 9.10
installiert, dort gibt es keine menu.lst, sondern nur eine grub.cfg und
die sieht so ganz und gar nicht so aus wie die menu.lst.
Das ist Script-Sprache mit "if" und so.
Kann mir jemand erz�hlen, wo ich bei diesen Versionen drehen mu�?
Es geht immer noch darum, bestimmte Werte beim Systemstart an grub zu
�bergeben, die auch *nach* einem Kernel-Update und dem daraus ergebenden
Neu-Erstellen (�ndern) der grub-Konfiguration genauso drin stehen wie
vorher. (vga= root= etc. pp.)
Und weg... Bernhard
Patrick Schueller
Falls es noch interessiert:
http://wiki.ubuntuusers.de/GRUB_2
Gru�, Patrick
--
OS: Ubuntu lucid (dev) � Kernel: 2.6.32-15-generic � KDE: 4.4.1 (KDE 4.4.1)
CPU: AMD Turion(tm) Dual-Core Mobile ZM-82 � RAM: 2906936kB/3799688kB
VGA: ATI RS780M/RS780MN [Radeon HD 3200] / ATI Mobility Radeon HD 3400
Patrick Schueller
> http://wiki.ubuntuusers.de/GRUB_2
bzw. http://wiki.ubuntuusers.de/GRUB_2/Konfiguration
Bernhard Thoben
Am 08.03.2010 um 00:18 schrieb Patrick Schueller an All folgendes:
>> Was ist mit neueren Versionen von grub? Ich hatte testweise Kubuntu
>> 9.10 installiert, dort gibt es keine menu.lst, sondern nur eine
>> grub.cfg und die sieht so ganz und gar nicht so aus wie die menu.lst.
>> Das ist Script-Sprache mit "if" und so. Kann mir jemand erz�hlen, wo
>> ich bei diesen Versionen drehen mu�?
>> Es geht immer noch darum, bestimmte Werte beim Systemstart an grub zu
>> �bergeben, die auch *nach* einem Kernel-Update und dem daraus
>> ergebenden Neu-Erstellen (�ndern) der grub-Konfiguration genauso drin
>> stehen wie vorher. (vga= root= etc. pp.)
PS> Falls es noch interessiert:
PS> http://wiki.ubuntuusers.de/GRUB_2
Aber ja doch! Das wird doch �ber kurz oder lang auch Debian-User betreffen!
Vielen Dank...
Und weg... Bernhard