Ubuntu 11.04 - Boot-Partitionsgröße ändern

Das zeigt df -h auf einer meiner Maschinen an:

Dateisystem Size Used Avail Use% Eingehängt auf
/dev/sda7 9,4G 4,1G 4,9G 46% /
none 488M 660K 487M 1% /dev
none 497M 948K 496M 1% /dev/shm
none 497M 132K 497M 1% /var/run
none 497M 0 497M 0% /var/lock
/dev/sda8 15G 2,8G 11G 21% /home
/home/xxx/.Private
15G 2,8G 11G 21% /home/xxx
/dev/sda5 92M 81M 5,4M 94% /boot

Probleme macht mir hier die boot-Partition, für ein Boot-Loader-Update leider zu klein, dieses bricht mit einer Fehlermeldung ("Auf '/dev/sda5' sind 0 Bytes frei!") ab, sobald die Paketverwaltung versucht, das Image aufzuspielen. Partitionierung in Hinsicht auf Größe ändern (/home kann ruhig 200 MB frei machen) lautet die Devise, aber hier beginnt's ja schon, mit fdisk mache ich mir beim Schreiben der neuen Partitionstabelle garantiert irgendwas kaputt. Zumindest boot wird mir kaputtgehen, und ohne Loader - naja, ihr wisst schon.

Würde ein dd reichen, um einen Dump von boot zu machen, dann die Partitionsgröße zu ändern und den Dump wieder einzuspielen? Wenn das funktioniert, werde ich dann das Update noch mal starten.

Nehme eine Live-Version, benutze gparted und boote dann neu von der Live-Version wähle dann aber im Boot-Manager das System von der HDD aus und im richtigen System führst Du dann eine GRUB-Installation aus.

Anfänger. schrieb:

Nehme eine Live-Version, benutze gparted und boote dann neu von der Live-Version wähle dann aber im Boot-Manager das System von der HDD aus und im richtigen System führst Du dann eine GRUB-Installation aus.

Das ist nicht so einfach. Das CD-ROM-Laufwerk hat einen an der Rappel und funzt nicht, und ich habe derzeit keinen USB-Stick, wo ich die Live-Version draufspielen könnte. Eine Operation am offenen Herzen wäre, soweit ich denken kann (haha, wat ham wir jelacht) die schnellste und sauberste Lösung.

Live-System auf dem Computer herunterladen z.B. nach /TEMP und neu starten. Beim Bootlader das System unter /TEMP auswählen. Den Befehl bei einer iso mit Bootmagicode kenne ich jetzt auch nicht auswendig. Auf jeden Fall nach dem das System unter /TEMP geladen wurde z.B. direkt über den Kernel, falls das System unter /TEMP entpackt wurde, wie auch immer, deine /dev/sda1 bearbeiten usw. und dann aus dem /TEMP (wobei dann eher aus dem RAM) System heraus wieder den sda1 Kernel laden und GRUB-Installation ausführen eher du neu startest.

Anfänger. schrieb:

Live-System auf dem Computer herunterladen z.B. nach /TEMP und neu starten. Beim Bootlader das System unter /TEMP auswählen. Den Befehl bei einer iso mit Bootmagicode kenne ich jetzt auch nicht auswendig.

[url=http://www.linuxquestions.org/questions/linux-software-2/booting-of-raw-iso-from-grub-lilo-though-preferably-grub-367901/]Hier[/quote] habe ich was zu dem Thema gefunden. Das Problem ist hier allerdings: soweit ich die verstehe, braucht man ein bisschen unpartitionierten Speicher, um das Image auf die Festplatte zu "brennen", den ich aber nicht habe. Müsste ich erst mit fdisk freigeben - wenn ich das bei /home/ mache, bleiben dann meine Daten erhalten? Und wenn ja, warum dann nicht bei /boot/? Selbst ein Mini-Kernel-Image ist schon zu viel, ich habe keinen Platz für diese Partition.

Anfänger. schrieb:

Auf jeden Fall nach dem das System unter /TEMP geladen wurde z.B. direkt über den Kernel, falls das System unter /TEMP entpackt wurde, wie auch immer, deine /dev/sda1 bearbeiten usw. und dann aus dem /TEMP (wobei dann eher aus dem RAM) System heraus wieder den sda1 Kernel laden und GRUB-Installation ausführen eher du neu startest.

1. Wäre es wohl die sda5.
2. Sobald ich die /boot/-Partition bearbeite, war's das meines Wissens mit den Daten (bin mir allerdings nicht sicher, wenn ich hier einem Trugschluss erliege, sag das bitte). Wie soll ich den Kernel von sda5 laden, wenn das die geänderte Partition ist (aus dem RAM? Würdest du das eventuell weiter spezifizieren?)? Meine Idee war eher, /boot/ danach zu mounten und dann von Live-Image GRUB auf sda5 zu installieren.

Ich weiß jetzt auch nicht, wie man mit GRUB manuell eine weitere Partition mountet. Das einzige was mir jetzt noch einfällt, unter Berücksichtigung was Du nach deinen Angaben zu Hand hast ist, wenn Du dich in das vorhandene System eingeloggt hast, gehst Du über in das andere System. Das müsste dann aber in diesem Fall auf jeden Fall entpackt sein, weil Du dann nicht mehr das Bootfile starten würdest, sondern den Kernel. Suche mal nach "Aus einem gestarteten Linux ein anderen Linux-System wechseln". Wir müssten dabei ein System haben, was eine Live-Variante ist und sich mittels Übergabeparameter komplett in den Arbeitsspeicher laden lässt. Bei der Ubuntu-Version ist der Parameter im web ziemlich einfach zu finden.

Ob der Bootmagiccode und/oder Bootloader beim vergrößern der Partition, in der sich eben bezeichnetes befindet (also MBR), beschädigt wird, kann ich Dir auch nicht sagen. MBR ist glaube ich eine bestimmte Position auf der Festplatte unabhängig von der Partitionierung.

Das wäre eventuell möglich, einen zweiten Kernel in den Arbeitsspeicher zu laden und von dort aus die Partitionen zu manipulieren.

Ich frage mich allerdings, warum dann so umständlich. Ich meine, boot ist auch eine Partition, die man aushängen lassen kann. So oder so ist der erste Kernel bereits im Arbeitsspeicher und kann auf die Partitionen zugreifen oder auch nicht, dann kann ich doch auch sd8 (home) und sd5 (boot) aushängen, mit fdisk darauf zugreifen (/ und untergeordnete Programme/Module sind ja noch eingebunden) und repartitionieren. Das einzige Problem wäre ein Datenverlust auf den beiden Partitionen, den ich nicht kompensieren kann, daran harpert's ja.

Ich könnte also die beiden Partitionen, deren Größe ich verändern will, aushängen, verändern, einbinden und dann das Boot-Loader-Update machen (Verbindung zum Internet bleibt bestehen), wenn ich eine Sicherung von home hätte, oder? Da ich das System auf diesem Wege nicht neustarten muss und es keinen Unterschied macht, wenn boot verloren geht, solange ich noch die Möglichkeit habe, GRUB neu zu installieren, wäre dies eigentlich eine gute Lösung, oder?

Gibt doch auch Partitionierer die verkleinern/vergrößern können ohne den Inhalt zu löschen. Ansonsten kopiere doch die Daten einfach vorher auf eine nicht zu ändernde Partition (inkl. verstecktem) und dann änderst die Partition, kopierst die Daten wieder rein und das selbe mit der anderen dann. Und zum Schluss GRUB installieren.

nman

Warum ist da überhaupt so viel Platz belegt? Bist du sicher, dass du nicht einfach alte Kernel-Versionen löschen kannst?

Christoph

Was ist bei normalen Desktop-PCs (mit unverschlüsseltem root-Dateisystem) heute noch der Vorteil einer separaten Boot-Partition?

Anfänger. schrieb:

Gibt doch auch Partitionierer die verkleinern/vergrößern können ohne den Inhalt zu löschen. Ansonsten kopiere doch die Daten einfach vorher auf eine nicht zu ändernde Partition (inkl. verstecktem) und dann änderst die Partition, kopierst die Daten wieder rein und das selbe mit der anderen dann. Und zum Schluss GRUB installieren.

Und das sagst du mir jetzt ... das wäre die schnellste Lösung gewesen.

nman schrieb:

Warum ist da überhaupt so viel Platz belegt? Bist du sicher, dass du nicht einfach alte Kernel-Versionen löschen kannst?

Ne, kann ich nicht. Eigentlich bin ich froh, dass der Kernel noch so gut auf dieser Gurke funktioniert, betagt ist hier nämlich kein Ausdruck mehr. Und bevor ich hier anfange, /boot zu leeren, möchte ich den neuen Kernel samt Boot-Loader doch gerne erst ausprobieren.

Christoph schrieb:

Was ist bei normalen Desktop-PCs (mit unverschlüsseltem root-Dateisystem) heute noch der Vorteil einer separaten Boot-Partition?

Ich stelle mir gern vor, dass ich dann mehr Kontrolle über das System habe. Ein über mehrere Partitionierungen verteiltes System sichert die verschiedenen Bausteine in jeweils zusammengehörende Cluster - falls ein Hardware-Schaden entsteht, bilde ich mir gerne ein, dass ich, solange /boot noch in Ordnung ist, ich mit Sicherheit ohne Live-CD auf den Kernel zugreifen kann. Von dort habe ich eventuell noch die Chance, das kaputte Dateisystem einzubinden, zu retten oder zumindest noch einige Daten zu sichern. Verrückt, was?

Nun gut, ich werde mich erst einmal über ordentliche Partitionierungsprogramme informieren (bisher verwendete ich fdisk, eventuell lässt sich diese Wahl überdenken), und ansonsten sichere ich die Daten einfach.

Christoph

Der aus dem Westen .. schrieb:

Christoph schrieb:

Was ist bei normalen Desktop-PCs (mit unverschlüsseltem root-Dateisystem) heute noch der Vorteil einer separaten Boot-Partition?

Ich stelle mir gern vor, dass ich dann mehr Kontrolle über das System habe. Ein über mehrere Partitionierungen verteiltes System sichert die verschiedenen Bausteine in jeweils zusammengehörende Cluster - falls ein Hardware-Schaden entsteht, bilde ich mir gerne ein, dass ich, solange /boot noch in Ordnung ist, ich mit Sicherheit ohne Live-CD auf den Kernel zugreifen kann. Von dort habe ich eventuell noch die Chance, das kaputte Dateisystem einzubinden, zu retten oder zumindest noch einige Daten zu sichern. Verrückt, was?

Der war gut.

Auf der Boot-Partition liegt normalerweise weder fsck noch eine Shell, nur der Kernel. Damit lässt sich recht wenig anfangen.

Ich bin mittlerweile dazu übergegangen, keine separate /boot-Partition mehr anzulegen, außer wenn es unbedingt notwendig ist (z.B. wenn / mit dmcrypt verschlüsselt ist). Bisher hab ich davon keinen Nachteil gehabt, nur den Vorteil, dass /boot nicht mehr voll werden kann.

Eine meiner Vermutungen ist, dass das mit der separaten Boot-Partition aus einer Zeit kommt, zu der lilo bzw. grub mit den modernen Dateisystemen nichts anfangen konnte. grub2 kann aber problemlos von ext4 booten, insofern ist der Bootloader gar kein Grund mehr, eine /boot-Partition mit ext2 oder was ähnlich altem anzulegen.

Das ist eine Sache, die mich bei Linux manchmal stört: Es gibt so viele alte Howtos, die vor 10 Jahren vielleicht sinnvoll waren, aber heute einfach nur noch als Voodoo übernommen werden ohne darüber nachzudenken. Bestes Beispiel "swap sollte doppelt so groß wie der RAM sein". Bei heutigen RAM-Größen ist das ein ausgesprochen schlechter Ratschlag.

Christoph schrieb:

Auf der Boot-Partition liegt normalerweise weder fsck noch eine Shell, nur der Kernel. Damit lässt sich recht wenig anfangen.

Verdammt, jetzt, wo du's sagst ... sh und bash liegen bei mir doch unter /bin/, auf / gemountet, und sind gar nicht in sda5 enthalten, oder? Wat'n Plan ... Ich sag's ja, die Macht der Einbildung.

Hast du aktuellere HowTos, dich ich adaptieren kann? Die Swap-Größe habe ich nämlich genau wie du gesagt hast auf 2 GB gestellt (1 GB physikalischer Speicher vorhanden) ...

Christoph

Der aus dem Westen .. schrieb:

Hast du aktuellere HowTos, dich ich adaptieren kann? Die Swap-Größe habe ich nämlich genau wie du gesagt hast auf 2 GB gestellt (1 GB physikalischer Speicher vorhanden) ...

Ne, leider nicht. Ich bin mir ja selber nicht sicher, ob meine Ratschläge gut sind. Es sind nur meine persönlichen Erfahrungen, dass viel Swap und eine separate /boot-Partition bei Ubuntu eher schadet als nutzt.

nman

DadW: Ich verstehe noch immer nicht, warum dein /boot so verdammt voll ist. Da müssen einfach noch alte Kernelversionen en masse drauf sein, sonst bringst du es doch nicht auf 80MB (oder was auch immer du hattest). Mit Debian Squeeze ist /boot nach der Installation unter 20MB groß.

(Deine Gründe für ein extra /boot sind auch etwas eigen. Aber gut, als Anfänger macht man komische Sachen, weil man sich einbildet dass irgendwelche Cargo-Cult-Ratschläge eine ganz wichtige Basis haben und so alles besser ist.)

Christoph schrieb:

Eine meiner Vermutungen ist, dass das mit der separaten Boot-Partition aus einer Zeit kommt, zu der lilo bzw. grub mit den modernen Dateisystemen nichts anfangen konnte.

Gab immer wieder Bugs, die /boot nötig gemacht haben. Die 1024-Zylinder-Sache und so. Kaputte BIOSes, kaputte Boot-Loader, …

Bestes Beispiel "swap sollte doppelt so groß wie der RAM sein". Bei heutigen RAM-Größen ist das ein ausgesprochen schlechter Ratschlag.

Ack. Wozu überhaupt Swap-Partitionen. (edit: Außer vielleicht man benutzt Hibernation, das geht vmtl. mit Swapfile ja eher nicht.)

nman schrieb:

DadW: Ich verstehe noch immer nicht, warum dein /boot so verdammt voll ist. Da müssen einfach noch alte Kernelversionen en masse drauf sein, sonst bringst du es doch nicht auf 80MB (oder was auch immer du hattest). Mit Debian Squeeze ist /boot nach der Installation unter 20MB groß.

Mannometer, was ist denn bei mir in /boot/ los ... von abi, config, initrd.img, System.map, vmcoreinfo und vmlinuz habe ich von Version 2.6.38 jeweils die Revision 8, 11 und 13. Laut /proc/version ist derzeit Revision 13 geladen, und dabei habe ich doch die 8er Revision geladen 8o. Ich glaube, daran liegt es ...

nman schrieb:

(Deine Gründe für ein extra /boot sind auch etwas eigen. Aber gut, als Anfänger macht man komische Sachen, weil man sich einbildet dass irgendwelche Cargo-Cult-Ratschläge eine ganz wichtige Basis haben und so alles besser ist.)

Verschuldigung, das habe ich mir angelesen und erlaubt.

nman schrieb:

Gab immer wieder Bugs, die /boot nötig gemacht haben. Die 1024-Zylinder-Sache und so. Kaputte BIOSes, kaputte Boot-Loader, …

Vor allem bei älteren PCs, oder?

nman

Der aus dem Westen .. schrieb:

Ich glaube, daran liegt es ...

Das lässt sich ja dann zum Glück leicht beheben.

Verschuldigung, das habe ich mir angelesen und erlaubt.

Ist ja ok, Sachen zu machen, die nicht unbedingt rational perfekt begründbar sind. Ich habe auch fast überall noch eine /boot-Partition. Liegt in meinem Fall daran, dass ich schon einige lästige Bugs erlebt habe, wo es ohne eigene Boot-Partition Schwierigkeiten gab. (Nach einem versch…enkten Nachmittag irgendwann mal: "So, wenn das jetzt mit einer eigenen Bootpartition funktioniert, pfeif ich darauf und erstelle die nächsten zehn Jahre blind weiterhin Bootpartitionen." )

nman schrieb:

Vor allem bei älteren PCs, oder?

Die 1024-Zylinder-Sache war eine LiLo-Beschränkung. (Grub habe ich damals noch nicht verwendet, keine Ahnung, ob der das auch hatte.)

Komische Bugs mit bestimmter Hardware waren bei älteren PCs schon häufiger, aber jetzt mit verbuggter UEFI-Hardware könnten sich durchaus wieder lustige Eigenheiten beim Booten ergeben, mal schaun. Ich blieb bis dato aber verschont.

Der aus dem Westen ...

nman schrieb:

Das lässt sich ja dann zum Glück leicht beheben.

Schon lange behoben. Images gelöscht, apt-get upgrade die Sache machen lassen, und es funktionierte. Nur die Netzwerkkarte hat der Kernel danach kurze Zeit nicht mehr erkannt, aber auch das hat sich erledigt.

nman schrieb:

Ist ja ok, Sachen zu machen, die nicht unbedingt rational perfekt begründbar sind. Ich habe auch fast überall noch eine /boot-Partition. Liegt in meinem Fall daran, dass ich schon einige lästige Bugs erlebt habe, wo es ohne eigene Boot-Partition Schwierigkeiten gab. (Nach einem versch…enkten Nachmittag irgendwann mal: "So, wenn das jetzt mit einer eigenen Bootpartition funktioniert, pfeif ich darauf und erstelle die nächsten zehn Jahre blind weiterhin Bootpartitionen." )

Eben. Und als ich unsere Server aufgesetzt habe, haben wir für Debian 6.0 auch 100 MB-Partitionen für den Boot-Sektor erstellt.

nman schrieb:

Die 1024-Zylinder-Sache war eine LiLo-Beschränkung. (Grub habe ich damals noch nicht verwendet, keine Ahnung, ob der das auch hatte.)

Ich meine mal, darüber gelesen zu haben, dass es Probleme mit einem Boot-Loader gab, wenn die Partition 1024 Zylinder übersteigt oder so ...

nman schrieb:

Komische Bugs mit bestimmter Hardware waren bei älteren PCs schon häufiger, aber jetzt mit verbuggter UEFI-Hardware könnten sich durchaus wieder lustige Eigenheiten beim Booten ergeben, mal schaun. Ich blieb bis dato aber verschont.

Wird wohl auch in Zukunft so sein. Windows 8 soll nicht gerade das Ei des Columbus sein, da können wir auf UEFI verzichten.

nman

Der aus dem Westen ... schrieb:

Eben. Und als ich unsere Server aufgesetzt habe, haben wir für Debian 6.0 auch 100 MB-Partitionen für den Boot-Sektor erstellt.

100MB-Partitionen erstelle ich nicht mehr fuer /boot. Meistens eher 1 Gig sowas. Festplattenplatz ist mir ja gluecklicherweise egal. Auszer fuer virtuelle Maschinen. Und die bekommen idR. eh kein /boot.

Ich meine mal, darüber gelesen zu haben, dass es Probleme mit einem Boot-Loader gab, wenn die Partition 1024 Zylinder übersteigt oder so ...

Naja, nicht ganz. Es geht nicht darum, dass die /boot-Partition nicht mehr als 1024 Zylinder belegen durfte, sondern darum, dass sie nicht ueber den 1024. Zylinder deiner HDD hinausgehen durfte. Es sei denn, dein BIOS konnte Extended INT13. Und dein Bootloader unterstuetzte das... Dunkle Zeiten.

Wird wohl auch in Zukunft so sein. Windows 8 soll nicht gerade das Ei des Columbus sein, da können wir auf UEFI verzichten.

UEFI ist schon ziemlich cool und ueberfaellig. Dieser Secure-Boot-Bloedsinn ist halt... Bloedsinn eben.

DrGreenthumb

Wieso deinstalliert ubuntu die alten kernel-versionen nicht... Läuft mir auch alle Jahre wieder über.