Hallo, Leute!
Heute Abend (meine Frau hasst mich bestimmt!) habe ich ein Verfahren getestet, wie man die Festplatte eines bestehenden Linuxsystem ersetzen kann und gleichzeitig alles (bis auf /boot) auf LVM umstellt. WICHTIG: ich habe es nur auf einer minimalen VM getestet!! Sobald ich die neue Platte kaufen werde, werde ich auch probieren, ob es auch in der Realität funktioniert (sollte, aber). Bis dahin, freue ich mich auf eure Kommentare.
Also:
ANGENOMMEN: /dev/sda ist die ALTE Platte und /dev/sdb ist die NEUE Platte:
- HEILIGE BACKUP DURCHFÜHREN!!!! - Paket lvm2 installieren - Mit grml booten - Partition /dev/sdb1 für /boot anlegen (Typ Linux, Bootable) - Partition /dev/sdb2 für LVM anlegen (Typ FD) - LVM Partitionierung: - pvcreate /dev/sdb2 - vgcreate system /dev/sdb2 - lvcreate -L 3400M -n root system (Beispiele...) - lvcreate -L 200M -n home system - lvcreate -L 300M -n tmp system - lvcreate -L 100M -n swap system - mkfs für die neue Partitionen (LVM, sowie /dev/sdb1) - mkswap /dev/mapper/system-swap - Directories /mnt/old/ und /mnt/new anlegen - Für jede Partition (df -h | grep sda): - mount /dev/sdaX /mnt/old - mount /dev/sdbX /mnt/new bzw. mount /dev/system/<label> /mnt/new - rsync -aSHxv /mnt/old/ /mnt/new/ - umount /mnt/old - umount /mnt/new - /dev/system/root mounten und etc/fstab anpassen (überall, bis auf /boot werden die LVM-Partitionen benutzt) - GRUB installieren (Reboot mit der Ubuntu Hardy Alternate CD, ansonsten will grml GRUB2 installieren und geht GAR NICHTS MEHR): - mount /dev/mapper/system-root /mnt/new - mount /dev/sdb1 /mnt/new/boot - Anpassungen an grub.cfg (root = /dev/mapper/system-root) - grub-install --no-floppy --root-directory=/mnt/new /dev/sdb - umount /mnt/new/boot - umount /mnt/new - Reboot, beten, fluchen, eventuell Rescatux oder ähnliche nutzen, wenn GRUB nicht will - KAMILLENTEE TRINKEN! In Industriemenge!!!! :)
Grüße Luca Bertoncello (lucabert@lucabert.de)
Am 22.04.2012 20:56, schrieb Luca Bertoncello:
Hallo, Leute!
Hallo Luca,
- GRUB installieren (Reboot mit der Ubuntu Hardy Alternate CD, ansonsten will grml GRUB2 installieren und geht GAR NICHTS MEHR):
Was hast du gegen GRUB2? Ich vermute mal, du hast vergessen einige IDs umzustellen, deshalb ging das nicht mehr.
Betroffen sind /boot/grub/grub.cfg und ggf. /boot/grub/device.map
In der grub.cfg wird, zumindest bei separater /usr-Partition auch auf die UUID derselben verwiesen. Nicht alle UUIDs zeigen auf die Root-Partition.
Bei der device.map hab ich es schon erlebt, daß das Rettungssystem teilweise andere IDs zeigt als das Live-System. Du solltest also vor der Umstellung im Live-System nachschauen, welche dort vorhanden sind:
ls -l /dev/disk/by-id
und im Rettungssystem dann eine übereinstimmende Variante eintragen.
- KAMILLENTEE TRINKEN! In Industriemenge!!!! :)
Hmm, kann das in der Dosis auch unerwünschte Nebenwirkungen haben?
Gruß Rico
Rico Koerner rico@netbreaker.de schrieb:
Hallo, Rico!
Was hast du gegen GRUB2? Ich vermute mal, du hast vergessen einige IDs umzustellen, deshalb ging das nicht mehr.
Was ich gegen GRUB2 habe, habe ich heute schon gesagt...
Betroffen sind /boot/grub/grub.cfg und ggf. /boot/grub/device.map
Ja, ich habe auch geschrieben, daß menu.lst angepasst werden soll, ansonsten kann GRUB nicht mehr wissen, wo die / ist... Aber eine bunte Mischung mit GRUB1 und GRUB2 wird kaum laufen... Und, da Ubuntu Hardy mit GRUB1 arbeiten, sehe ich keinen Grund Grml zu erlauben, GRUB2 zu installieren... :)
In der grub.cfg wird, zumindest bei separater /usr-Partition auch auf die UUID derselben verwiesen. Nicht alle UUIDs zeigen auf die Root-Partition.
Ich habe einfach den Pfad (/dev/mapper/system-...) eingetragen. Mir gefällt besser als UUID... Aber prinzipiell ist es egal.
Wegen device.map. Ich habe, vor dem Reboot mit der Alternate-CD die alte Festplatte von der VM entfernt, also device.map ist GLEICH geblieben. Wahrscheinlich das ist die einfachste Variante...
- KAMILLENTEE TRINKEN! In Industriemenge!!!! :)
Hmm, kann das in der Dosis auch unerwünschte Nebenwirkungen haben?
Ja, daß du weniger fluchst... :D
Grüße Luca Bertoncello (lucabert@lucabert.de)
On 22.04.12 Luca Bertoncello (lucabert@lucabert.de) wrote:
Moin,
ANGENOMMEN: /dev/sda ist die ALTE Platte und /dev/sdb ist die NEUE Platte:
- Mit grml booten
- Partition /dev/sdb1 für /boot anlegen (Typ Linux, Bootable)
- Partition /dev/sdb2 für LVM anlegen (Typ FD)
- LVM Partitionierung:
- pvcreate /dev/sdb2
- vgcreate system /dev/sdb2
- lvcreate -L 3400M -n root system (Beispiele...)
- lvcreate -L 200M -n home system
- lvcreate -L 300M -n tmp system
- lvcreate -L 100M -n swap system
- mkfs für die neue Partitionen (LVM, sowie /dev/sdb1)
Mir will nicht ganz rein, wieso ich das nicht schon in alten gebooteten System machen kann. Dann würde ich unter /mnt/new das komplette neue FS aufbauen und könnte dann alles mit einem cp -a (oder cp -pr) (Exclude für /mnt/new nicht vergessen) rüberziehen.
Oder ist das nur eine Variante Deiner Mehthode?
- mkswap /dev/mapper/system-swap
Wenn ich das im gebooteten grml ausführe, wird auf welchem Device eine Swap-Partition angelegt?
- mount /dev/mapper/system-root /mnt/new
- mount /dev/sdb1 /mnt/new/boot
- Anpassungen an grub.cfg (root = /dev/mapper/system-root)
- grub-install --no-floppy --root-directory=/mnt/new /dev/sdb
Könnnte mir noch jemand die passenden Beschwörungsformeln für GRUB2 nennen? Bei mir steht demnächst Plattenumzug an und ich habe letztens von LILO auf grub2 geschwenkt.
Danke!
H.
Hilmar Preuße hille42@web.de schrieb:
Hallo, Hilmar!
Mir will nicht ganz rein, wieso ich das nicht schon in alten gebooteten System machen kann. Dann würde ich unter /mnt/new das komplette neue FS aufbauen und könnte dann alles mit einem cp -a (oder cp -pr) (Exclude für /mnt/new nicht vergessen) rüberziehen.
Klar! Du kannst alles von dem gebooteten System machen, allerdings musst du daran denken, daß die / zu kopieren nicht ohne weiteres geht... Du musst vorher sie in einer Art und Weise mounten, daß du sie kopieren kannst:
mount --bind / /somemountpoint/
Danach, kannst du mit:
rsync -aSHxv /mountpoint/ /mnt/new/mountpoint/
alles übertragen!
Aber ich würde wirklich jede Partition einzeln übertragen... Vielleicht ist es nur weil ich dumm bin, aber ich befürchte, daß alles auf einmal kopieren Probleme macht...
- mkswap /dev/mapper/system-swap
Wenn ich das im gebooteten grml ausführe, wird auf welchem Device eine Swap-Partition angelegt?
Na, das sollte auf der neuen Platte machen...
Grüße Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Mo 23 Apr 2012 07:34:44 CEST):
Hilmar Preuße hille42@web.de schrieb:
Hallo, Hilmar!
Mir will nicht ganz rein, wieso ich das nicht schon in alten gebooteten System machen kann. Dann würde ich unter /mnt/new das komplette neue FS aufbauen und könnte dann alles mit einem cp -a (oder cp -pr) (Exclude für /mnt/new nicht vergessen) rüberziehen.
Klar! Du kannst alles von dem gebooteten System machen, allerdings musst du daran denken, daß die / zu kopieren nicht ohne weiteres geht...
?? Warum?
Du musst vorher sie in einer Art und Weise mounten, daß du sie kopieren kannst:
mount --bind / /somemountpoint/Danach, kannst du mit:
rsync -aSHxv /mountpoint/ /mnt/new/mountpoint/
Was macht das anders, als
rsync -aSHxv / /mnt/new/mountpoint/
?
On 23.04.12 Luca Bertoncello (lucabert@lucabert.de) wrote:
Hilmar Preuße hille42@web.de schrieb:
Hallo, Luca!
- mkswap /dev/mapper/system-swap
Wenn ich das im gebooteten grml ausführe, wird auf welchem Device eine Swap-Partition angelegt?
Na, das sollte auf der neuen Platte machen...
Sicher? Im gebooteten grml hätte ich vermutet, daß das in der RAM-Disc von grml angelegt wird, also beim ersten Reboot verschwindet. Außerdem dürfte das neue System auch ohne Swap-Partition booten, ich würde die Einrichtung selbiger auf die Zeit nach dem ersten Reboot verschieben.
H.
Hilmar Preusse hille42@web.de schrieb:
Sicher? Im gebooteten grml hätte ich vermutet, daß das in der RAM-Disc von grml angelegt wird, also beim ersten Reboot verschwindet. Außerdem dürfte das neue System auch ohne Swap-Partition booten, ich würde die Einrichtung selbiger auf die Zeit nach dem ersten Reboot verschieben.
Naja, laut man ist mkswap so eine Art mkfs... Es bereitet die Partition vor.
swapon wird die Swaps in Betrieb nehmen...
Also, ich sehe keinen Grund, warum mkswap die Swap auf dem Live-System arbeiten soll.
Und, nach dem Boot mit der neuen Platte (auf der Test-VM), war auch die Swap da. Wäre die Partition nicht initialisiert, hätte ich sicher ein Fehler bekommen, oder?
Grüße Luca Bertoncello (lucabert@lucabert.de)
On 24.04.12 Luca Bertoncello (lucabert@lucabert.de) wrote:
Hilmar Preusse hille42@web.de schrieb:
Moin,
Sicher? Im gebooteten grml hätte ich vermutet, daß das in der RAM-Disc von grml angelegt wird, also beim ersten Reboot verschwindet. Außerdem dürfte das neue System auch ohne Swap-Partition booten, ich würde die Einrichtung selbiger auf die Zeit nach dem ersten Reboot verschieben.
Naja, laut man ist mkswap so eine Art mkfs... Es bereitet die Partition vor. swapon wird die Swaps in Betrieb nehmen...
Also, ich sehe keinen Grund, warum mkswap die Swap auf dem Live-System arbeiten soll.
OK, OK, mein Fehler. Entschuldigung! /dev/mapper/system-swap bezeichnet im konkreten Fall tatsächlich die swap-Partition auf der neuen Platte. Namensschema ist: /dev/mapper/<name-der-vg>-<name-des-lv> und da Deine vg "system" heißt und Dein lv "swap" haut das dann hin.
H.
Hilmar Preuße hille42@web.de (Di 24 Apr 2012 22:27:24 CEST):
On 24.04.12 Luca Bertoncello (lucabert@lucabert.de) wrote:
Hilmar Preusse hille42@web.de schrieb:
Moin,
Sicher? Im gebooteten grml hätte ich vermutet, daß das in der RAM-Disc von grml angelegt wird, also beim ersten Reboot verschwindet. Außerdem dürfte das neue System auch ohne Swap-Partition booten, ich würde die Einrichtung selbiger auf die Zeit nach dem ersten Reboot verschieben.
Naja, laut man ist mkswap so eine Art mkfs... Es bereitet die Partition vor. swapon wird die Swaps in Betrieb nehmen...
Also, ich sehe keinen Grund, warum mkswap die Swap auf dem Live-System arbeiten soll.
OK, OK, mein Fehler. Entschuldigung! /dev/mapper/system-swap bezeichnet im konkreten Fall tatsächlich die swap-Partition auf der neuen Platte. Namensschema ist: /dev/mapper/<name-der-vg>-<name-des-lv> und da Deine vg "system" heißt und Dein lv "swap" haut das dann hin.
Bemerkung am Rande: ein VG-Name wie „system“ ist nicht sehr geschickt. Spätestens, wenn Du die Platten der VG „system“ in ein System stecken möchtest, in dem es auch schon eine VG „system“ gibt. Das gibt Ärger. Nicht unlösbaren, aber halt häßlichen.
Heiko Schlittermann hs@schlittermann.de schrieb:
Hallo, Heiko!
Bemerkung am Rande: ein VG-Name wie „system“ ist nicht sehr geschickt. Spätestens, wenn Du die Platten der VG „system“ in ein System stecken möchtest, in dem es auch schon eine VG „system“ gibt. Das gibt Ärger. Nicht unlösbaren, aber halt häßlichen.
Naja, das Problem habe ich mit jedem Namen, oder?
Grüße Luca Bertoncello (lucabert@lucabert.de)
Moin Luca,
On Wed, Apr 25, 2012 at 07:33:03AM +0200, Luca Bertoncello wrote:
Heiko Schlittermann hs@schlittermann.de schrieb:
Hallo, Heiko!
Bemerkung am Rande: ein VG-Name wie „system“ ist nicht sehr geschickt. Spätestens, wenn Du die Platten der VG „system“ in ein System stecken möchtest, in dem es auch schon eine VG „system“ gibt. Das gibt Ärger. Nicht unlösbaren, aber halt häßlichen.
Naja, das Problem habe ich mit jedem Namen, oder?
Jop, aber die Lösung ist brachial simpel: vg_`hostname`_sys oder einfach den Hostnamen direkt als VG-Namen für die System-Platten.
Aber in deinem Fall als LVM-Starter ist die Kollisionswahrscheinlichkeit noch recht gering.
Gruß, Andre
Andre Klärner kandre@ak-online.be schrieb:
Naja, das Problem habe ich mit jedem Namen, oder?
Jop, aber die Lösung ist brachial simpel: vg_`hostname`_sys oder einfach den Hostnamen direkt als VG-Namen für die System-Platten.
Naja, wenn ich dann den Hostname wechseln? :)
Aber in deinem Fall als LVM-Starter ist die Kollisionswahrscheinlichkeit noch recht gering.
Ehrlich gesagt, wenn ich die Festplatte(n) mit einem Rechner nutze, warum soll ich sie auf einem anderen Rechner umziehen wollen? Außer der Fall, natürlich, daß der erste Rechner ins Grab geht, aber in dem Fall WILL ich daß alles so gleich wie möglich bleibt, oder?
Egal, wie du selber sagst, in meinem Fall ist Kollisionswahrscheinlichkeit ist sehr klein (ich hätte gesagt, Null).
Ich werde in der nähe Zukunft die Festplatte kaufen und demnächst die Daten umziehen. Ich melde mich bestimmt, wenn alles durchgelaufen ist.
Grüße Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Mi 25 Apr 2012 14:57:49 CEST):
Andre Klärner kandre@ak-online.be schrieb:
Naja, das Problem habe ich mit jedem Namen, oder?
Jop, aber die Lösung ist brachial simpel: vg_`hostname`_sys oder einfach den Hostnamen direkt als VG-Namen für die System-Platten.
Naja, wenn ich dann den Hostname wechseln? :)
Kommt doch eher selten vor, wenn man die Namen nicht nach der Funktion aussucht, sondern eher neutrale Namen hat.
Aber in deinem Fall als LVM-Starter ist die Kollisionswahrscheinlichkeit noch recht gering.
Ehrlich gesagt, wenn ich die Festplatte(n) mit einem Rechner nutze, warum soll ich sie auf einem anderen Rechner umziehen wollen? Außer der Fall, natürlich, daß der erste Rechner ins Grab geht, aber in dem Fall WILL ich daß alles so gleich wie möglich bleibt, oder?
Ja, wenn Du die Platten woanders reinsteckst und dort nichts anderes drin ist, ist das ok. Dann ist es ja immer noch Dein System, nur eben auf anderer Hardware. Wenn Du aber aus Recoverygründen Deine Platten zusätzlich zu anderen irgendwo reinhängst, dann hast Du ein Problem mit der eventuellen VG-Namenskollision.
Andre Klärner kandre@ak-online.be (Mi 25 Apr 2012 14:52:03 CEST):
Moin Luca,
On Wed, Apr 25, 2012 at 07:33:03AM +0200, Luca Bertoncello wrote:
Heiko Schlittermann hs@schlittermann.de schrieb:
Hallo, Heiko!
Bemerkung am Rande: ein VG-Name wie „system“ ist nicht sehr geschickt. Spätestens, wenn Du die Platten der VG „system“ in ein System stecken möchtest, in dem es auch schon eine VG „system“ gibt. Das gibt Ärger. Nicht unlösbaren, aber halt häßlichen.
Naja, das Problem habe ich mit jedem Namen, oder?
Jop, aber die Lösung ist brachial simpel: vg_`hostname`_sys oder einfach den Hostnamen direkt als VG-Namen für die System-Platten.
Den Prefix würde ich mir verkneifen, es ist überall aus dem Kontext ersichtlich, daß es sich um eine Volumegroup handelt. :)
Mich erinnert das ein wenig an
int iCounter;
wobei mir der Prefix anzeigen soll, daß Counter ein Integer ist. Ich denke, das war ungarische Notation. Und ist hier off-topic.
Moin Heiko,
On Wed, Apr 25, 2012 at 04:13:17PM +0200, Heiko Schlittermann wrote:
Andre Klärner kandre@ak-online.be (Mi 25 Apr 2012 14:52:03 CEST):
On Wed, Apr 25, 2012 at 07:33:03AM +0200, Luca Bertoncello wrote: Jop, aber die Lösung ist brachial simpel: vg_`hostname`_sys oder einfach den Hostnamen direkt als VG-Namen für die System-Platten.
Den Prefix würde ich mir verkneifen, es ist überall aus dem Kontext ersichtlich, daß es sich um eine Volumegroup handelt. :)
Mich erinnert das ein wenig an
int iCounter;wobei mir der Prefix anzeigen soll, daß Counter ein Integer ist. Ich denke, das war ungarische Notation. Und ist hier off-topic.
Ich denke da bin ich ein wenig von Arbeit beeinflusst - meine Lieblingsinder haben eher häufig das Problem, dass die das Konzept PV-VG-LV nicht so wirklich verstehen oder einfach sich nicht im Klaren sind, dass $(HOSTNAME) dann die System-VG bezeichnet.
Ehrlich gesagt: aus reiner Faulheit hab ich das Konzept auch zuhause angewand, weil nämlich dann die Tab-Completion für /dev/vg_<tab> sehr gut ist. Da ich aber inzwischen auf die zsh umgeschwenkt bin, sollte ich vllt auch mal schauen, dass ich ne gute LVM-Completion dafür finde. Dann ist der Vorteil nämlich sowieso weg. ;)
Gruß, Andre
Luca Bertoncello lucabert@lucabert.de (Mi 25 Apr 2012 07:33:03 CEST):
Heiko Schlittermann hs@schlittermann.de schrieb:
Hallo, Heiko!
Bemerkung am Rande: ein VG-Name wie „system“ ist nicht sehr geschickt. Spätestens, wenn Du die Platten der VG „system“ in ein System stecken möchtest, in dem es auch schon eine VG „system“ gibt. Das gibt Ärger. Nicht unlösbaren, aber halt häßlichen.
Naja, das Problem habe ich mit jedem Namen, oder?
Ja, wenn er so generisch ist. Ich verwende die $(hostname) als Name für die VG. Da bin ich mir zumindest in einem bestimmten Umfeld einigermaßen sicher, daß es keine Kollision gibt.
Hilmar Preusse hille42@web.de (Mo 23 Apr 2012 21:49:19 CEST):
On 23.04.12 Luca Bertoncello (lucabert@lucabert.de) wrote:
Hilmar Preuße hille42@web.de schrieb:
Hallo, Luca!
- mkswap /dev/mapper/system-swap
Wenn ich das im gebooteten grml ausführe, wird auf welchem Device eine Swap-Partition angelegt?
Na, das sollte auf der neuen Platte machen...
Sicher? Im gebooteten grml hätte ich vermutet, daß das in der RAM-Disc von grml angelegt wird, also beim ersten Reboot
SWAP in der RAM-Disk? Wozu ist das gut?
verschwindet. Außerdem dürfte das neue System auch ohne Swap-Partition booten, ich würde die Einrichtung selbiger auf die Zeit nach dem ersten Reboot verschieben.
Das schon eher.
Am Tue, 24 Apr 2012 09:19:47 +0200 schrieb Heiko Schlittermann hs@schlittermann.de:
SWAP in der RAM-Disk? Wozu ist das gut?
Das ist, wenn man einen zu schnellen Computer hat, dann kann man so dieses Problem lösen, ohne Java installieren zu müssen, denn seit Oracle ist das ja noch böser als davor schon ;)
Hallo Hilmar,
On Sun, Apr 22, 2012 at 22:51:54 +0200, Hilmar Preuße wrote:
Könnnte mir noch jemand die passenden Beschwörungsformeln für GRUB2 nennen? Bei mir steht demnächst Plattenumzug an und ich habe letztens von LILO auf grub2 geschwenkt.
Angenommen, Du hast ein Livesystem laufen und das rootfs des kopierten/installierten Systems auf /mnt gemountet:
cd /mnt mount --bind /dev/ dev mount --bind /proc/ proc mount --bind /sys/ sys chroot . /bin/bash grub-install /dev/sda <==== Ziel ist hier MBR von sda update-grub2 exit umount sys umount proc umount dev
Gruss, Chris
On 23.04.12 Christian Perle (chris@linuxinfotag.de) wrote:
On Sun, Apr 22, 2012 at 22:51:54 +0200, Hilmar Preuße wrote:
Hallo,
Könnnte mir noch jemand die passenden Beschwörungsformeln für GRUB2 nennen? Bei mir steht demnächst Plattenumzug an und ich habe letztens von LILO auf grub2 geschwenkt.
Angenommen, Du hast ein Livesystem laufen und das rootfs des kopierten/installierten Systems auf /mnt gemountet:
OK, danke; hat geklappt.
Eine Hürde war noch, daß die neue Platte eine SATA-Platte war und der sata_nv Treiber benötigt wurde. Also neue initrd bauen, in der Alten war der noch nicht drin.
Weiterhin gabs ein Problem beim fsck:
[/sbin/fsck.ext2 (1) -- /boot] fsck.ext2 -a -C0 /dev/sdc5 fsck.ext2: Device or resource busy while trying to open /dev/sdc5 Filesystem mounted or opened exclusively by another program?
Ich hatte den Eintrag
/dev/sdc5 /boot ext2 defaults 0 2
in der fstab drin... Braucht man den eigentlich? Ich habe den in der Rescue-Shell erstmal auskommentiert, damit konnte weiter gebootet werden. In /boot herrscht derzeit aber gähnende Leere.
H.
On 15.05.12 Hilmar Preuße (hille42@web.de) wrote:
On 23.04.12 Christian Perle (chris@linuxinfotag.de) wrote:
On Sun, Apr 22, 2012 at 22:51:54 +0200, Hilmar Preuße wrote:
Hallo,
Weiterhin gabs ein Problem beim fsck:
[/sbin/fsck.ext2 (1) -- /boot] fsck.ext2 -a -C0 /dev/sdc5 fsck.ext2: Device or resource busy while trying to open /dev/sdc5 Filesystem mounted or opened exclusively by another program?
Ich hatte den Eintrag
/dev/sdc5 /boot ext2 defaults 0 2
in der fstab drin... Braucht man den eigentlich? Ich habe den in der Rescue-Shell erstmal auskommentiert, damit konnte weiter gebootet werden. In /boot herrscht derzeit aber gähnende Leere.
Andere Idee: das Teil ganz unten in die fstab zu stecken und vom fsck auszuschließen. Wie macht Ihr das?
H.
Am Dienstag, den 15.05.2012, 22:47 +0200 schrieb Hilmar Preuße:
On 15.05.12 Hilmar Preuße (hille42@web.de) wrote:
On 23.04.12 Christian Perle (chris@linuxinfotag.de) wrote:
On Sun, Apr 22, 2012 at 22:51:54 +0200, Hilmar Preuße wrote:
Hallo,
Hallo Hilmar,
Weiterhin gabs ein Problem beim fsck:
[/sbin/fsck.ext2 (1) -- /boot] fsck.ext2 -a -C0 /dev/sdc5 fsck.ext2: Device or resource busy while trying to open /dev/sdc5 Filesystem mounted or opened exclusively by another program?
Ich hatte den Eintrag
/dev/sdc5 /boot ext2 defaults 0 2
Ändere mal die letzte 2 hinten in eine 0, damit wird das Filesystem beim booten nicht überprüft.
in der fstab drin... Braucht man den eigentlich? Ich habe den in der Rescue-Shell erstmal auskommentiert, damit konnte weiter gebootet werden. In /boot herrscht derzeit aber gähnende Leere.
na klar, ist ja auch nicht eingehängt, hast du ja auskommentiert
Andere Idee: das Teil ganz unten in die fstab zu stecken und vom fsck auszuschließen. Wie macht Ihr das?
Gruss Gerd
On 16.05.12 Gerd Göhler (gerdg-dd@gmx.de) wrote:
Am Dienstag, den 15.05.2012, 22:47 +0200 schrieb Hilmar Preuße:
On 15.05.12 Hilmar Preuße (hille42@web.de) wrote:
Hallo,
Weiterhin gabs ein Problem beim fsck:
[/sbin/fsck.ext2 (1) -- /boot] fsck.ext2 -a -C0 /dev/sdc5 fsck.ext2: Device or resource busy while trying to open /dev/sdc5 Filesystem mounted or opened exclusively by another program?
Ich hatte den Eintrag
/dev/sdc5 /boot ext2 defaults 0 2
Ändere mal die letzte 2 hinten in eine 0, damit wird das Filesystem beim booten nicht überprüft.
Ja, das ist mir schon klar. Ich weiß nur nicht, ob das so gut ist. Wie schon gesagt, scheint momentan alles i.O. zu sein, ich vermute /dev/sdc5 war beim fraglichen Boot nicht das fs mit /boot drauf, sondern eines von einer falschen Platte, welches dort als swap diente.
EOD, Hilmar
Hallo Hilmar,
On Tue, May 15, 2012 at 21:51:44 +0200, Hilmar Preuße wrote:
Weiterhin gabs ein Problem beim fsck:
[/sbin/fsck.ext2 (1) -- /boot] fsck.ext2 -a -C0 /dev/sdc5 fsck.ext2: Device or resource busy while trying to open /dev/sdc5 Filesystem mounted or opened exclusively by another program?
Ich hatte den Eintrag
/dev/sdc5 /boot ext2 defaults 0 2
in der fstab drin... Braucht man den eigentlich? Ich habe den in der Rescue-Shell erstmal auskommentiert, damit konnte weiter gebootet werden. In /boot herrscht derzeit aber gähnende Leere.
/boot muss nicht zwingend eingehaengt werden. Allerdings muss es spaetestens dann vorhanden sein, wenn ein Paket-Update das initramfs neu bauen will oder ein neues Kernelimage nach /boot geschrieben werden soll.
Was die Fehlermeldung von fsck angeht, fehlt mir hier etwas Kontext. Ist das Filesystem fuer /boot wirklich auf /dev/sdc5? Ist es zu diesem Zeitpunkt wirklich eingehaengt oder ist /dev/sdc5 vielleicht Teil eines LVM?
Eingehaengt darf /boot zum Ausfuehrungzeitpunkt von checkfs.sh nicht sein. Das einzige Filesystem, das ueblicherweise bei der Pruefung bereits (read-only) eingehaengt ist, ist das Rootfilesystem. Es wird danach read-write remounted.
Gruss, Chris
On 16.05.12 Christian Perle (chris@linuxinfotag.de) wrote:
On Tue, May 15, 2012 at 21:51:44 +0200, Hilmar Preuße wrote:
Moin,
Weiterhin gabs ein Problem beim fsck:
[/sbin/fsck.ext2 (1) -- /boot] fsck.ext2 -a -C0 /dev/sdc5 fsck.ext2: Device or resource busy while trying to open /dev/sdc5 Filesystem mounted or opened exclusively by another program?
Ich hatte den Eintrag
/dev/sdc5 /boot ext2 defaults 0 2
in der fstab drin... Braucht man den eigentlich? Ich habe den in der Rescue-Shell erstmal auskommentiert, damit konnte weiter gebootet werden. In /boot herrscht derzeit aber gähnende Leere.
/boot muss nicht zwingend eingehaengt werden. Allerdings muss es spaetestens dann vorhanden sein, wenn ein Paket-Update das initramfs neu bauen will oder ein neues Kernelimage nach /boot geschrieben werden soll.
OK. Da sowas aber ab und zu vorkommt, sollte man das Teil haben, weil man sicher nicht daran denkt, wenn man einen Kernel-Upgrade macht.
Was die Fehlermeldung von fsck angeht, fehlt mir hier etwas Kontext. Ist das Filesystem fuer /boot wirklich auf /dev/sdc5?
Ja..... oder besser: irgendein Mechanismus führt derzeit lustiges Plattenumbenamsen aus. Mal heißt die neue Platte /dev/sda, jetzt heißt sie gerade /dev/sdc. Ich referenziere die Partition derzeit über ihre UUID, mal sehn ob sich das Problem damit erledigt. Beim Boot eben war es nicht sichtbar, ich warte auf Reproduktion.
Ist es zu diesem Zeitpunkt wirklich eingehaengt oder ist /dev/sdc5 vielleicht Teil eines LVM?
Kann eigentlich nicht. Nein.
Eingehaengt darf /boot zum Ausfuehrungzeitpunkt von checkfs.sh nicht sein.
Nein, natürlich nicht. Aber grub hat sicher darauf schon zugegriffen, um die initrd zu lesen.
H.
Hallo Hilmar,
On Wed, May 16, 2012 at 11:09:54 +0200, Hilmar Preuße wrote:
Was die Fehlermeldung von fsck angeht, fehlt mir hier etwas Kontext. Ist das Filesystem fuer /boot wirklich auf /dev/sdc5?
Ja..... oder besser: irgendein Mechanismus führt derzeit lustiges Plattenumbenamsen aus. Mal heißt die neue Platte /dev/sda, jetzt heißt sie gerade /dev/sdc.
Ich denke dass dieser Effekt dadurch auftritt, dass die sd*-Devices zwar nicht umbenannt werden, sich aber nicht immer in der gleichen Reihefolge am SCSI/SATA/Sonstwas-Bus melden. Dazu koennen natuerlich noch zufaellig angesteckte USB-Sticks etc. kommen, die sich auch auf dem sd-Layer breit machen.
Ich referenziere die Partition derzeit über ihre UUID, mal sehn ob sich das Problem damit erledigt. Beim Boot eben war es nicht sichtbar, ich warte auf Reproduktion.
Obiges Problem ist genau der Grund fuer UUID-basiertes Mounten.
Gruss, Chris
lug-dd@mailman.schlittermann.de
-
Andre Klärner -
Carsten Weber -
Christian Perle -
Gerd Göhler -
Heiko Schlittermann -
Hilmar Preusse -
Hilmar Preuße
-
Luca Bertoncello -
Rico Koerner