Am 01.03.2015 um 10:36 schrieb Heinz Mezera: > Hallo Thore, > > das klingt weder trivial noch optimistisch. Die gewünschte und weitere > Informationen, die hilfreich sein könnten inline oder unten. Allerdings > >> Am 28.02.2015 um 23:08 schrieb Heinz Mezera: >>> Guten Tag, >>> >>> ich bin neu auf dieser Liste und hoffe, für mein nachstehendes Problem >>> die richtige Lösung zu finden. >>> >>> Auf einem Ubuntu 14.10 host betreibe ich in einer VM Debian 7 als >>> Server. Bei der Debian Installation habe ich ein RAID 1 definiert, das >>> die Partitionen /dev/sda1 und /dev/sdb1 umfasst. Das Verzeichnis / liegt >>> auf /dev/sda1, swap auf /dev/sda2 und /boot auf /dev/sda3. >>> >>> Die beiden Laufwerke der VM wurden als dynamische Laufwerke erstellt und >>> sind mit ca. 2.3GB belegt, die Laufwerksgröße wurde mit 8GB definiert. >>> Obwohl theoretisch reichlich platz sein müsste, kann ich Debian nicht >>> aktualisieren, da nicht dynamisch vergrößert wird. Ich gehe davon aus, >>> dass die RAID 1 Konstruktion hinderlich ist und möchte sie für begrenzte >>> Zeit entfernen, das Debian update durchführen und dann wieder RAID 1 >>> kreieren. >>> >>> Wie geht das? Worauf muss ich achten? Ist mein Problem überhaupt lösbar? >>> >>> Besten Dank für Hilfe, >>> Heinz >>> >> Hmm >> Ich kann mir momentan zwar keine Gründe für ein solches Szenario vorstellen. >> Ich hoffe mal, dass die VM Images auf unterschiedlichen Platten lagern. >> Warum das RAID aber nicht schon auf dieser Ebene gelöst wird erschließt >> sich mir nicht. >> Nun zu deinem Problem: >> >> Vorweg: Ich befürchte, dass du nur ein Image damit dynamisch vergrößern >> wirst und damit daran scheitern wirst das RAID wieder zusammen zu bauen. >> >> Eigentlich sollte für ein Update unter diesen Bedingungen mehr als genug >> Speicher zur Verfügung stehen. Was sagt df -h ? sind unter Umständen >> weitere Partitionen erstellt worden vom Installer und diese nun voll? > > df -h liefert > > Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf > rootfs 2,3G 2,2G 29M 99% / > udev 10M 0 10M 0% /dev > tmpfs 76M 272K 76M 1% /run > /dev/disk/by-uuid/6a8e4113-5288-489c-b338-ac424168d633 2,3G 2,2G 29M 99% / > tmpfs 5,0M 0 5,0M 0% /run/lock > tmpfs 343M 0 343M 0% /run/shm > /dev/sda3 277M 29M 235M 11% /boot > Die Laufwerksgröße ist viel zu klein. / ist nur 2,3GB groß und damit randvoll. Die Frage ist nur, wo der restliche Speicher hingewandert ist. sda1 und sdb1 sind schonmal gleich groß. Nur wie groß sind die Partitionen reell. Ich habe zurzeit deinen Swap im verdacht, dass dieser zu groß ist und den Großteil von sda gefressen hat. Der übrige Platz wurde für das Raid verwendet und ist nun nicht weiter verfügbar. Ein Lösungsansatz wäre es den Swap auf beide Platten zu verteilen. Entweder einfach auf beiden eine Partition anlegen und mit mkswap und swapon aktivieren. Damit solltest du Speicherplatz gewinnen können. Theoretisch ginge auch ein RAID 0. Warum aber das Laufwerk nicht dynamisch vergrößert wird kann ich dir leider nicht erzählen. Möglich wäre es, dass die Belegung auf sdb dazwischen funkt und sich die Platten durch das Raid dabei selber stören. > fdisk -l /dev/sda /dev/sdb liefert > > > Disk /dev/sda: 8589 MB, 8589934592 bytes > 255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x000ace62 > > Device Boot Start End Blocks Id System > /dev/sda1 2048 4882431 2440192 fd Linux raid autodetect > /dev/sda2 4882432 6836223 976896 82 Linux swap / Solaris > /dev/sda3 * 6836224 7421951 292864 83 Linux > > Disk /dev/sdb: 8589 MB, 8589934592 bytes > 234 heads, 58 sectors/track, 1236 cylinders, total 16777216 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x000c476a > > Device Boot Start End Blocks Id System > /dev/sdb1 2048 4882431 2440192 fd Linux raid autodetect > > swap und /boot sind unmittelbar nach / > >> Solltest du den Skizzierten weg wirklich gehen wollen wird das ungemütlich. >> Zunächst müsstest du eine Platte aus dem Raid nehmen, komplett neu >> Formatieren und dein laufendes System darauf klonen. Anschließend >> chrooten und updaten. >> Nun die Platte zu dem Zeitpunkt noch das (aktuell halbe) RAID 1 >> darstellt mit dem Update überschreiben. >> Chroot mit exit verlassen und die aktuell unabhängige Platte wieder ins >> RAID einbinden lassen. >> 1: Sicher unbedingt deine Daten vorher >> 2: Ich zweifle bei diesem Szenario, dass alles heil bleibt. >> 3: Habe ein Backup >> >> Viele Grüße >> Thore > > Siehst du eine Möglichkeit die VM von einer Live-CD (Gparted oder Knoppix) zu booten, > oder die Netinstall Debian CD hilfreich zu verwenden? > Das sollte gehen. Welche Virtualisierungsumgebung verwendest du? Es dürfte kein Problem darstellen ein iso Image von Gparted beim Start als Boot Priorität 1 mitzugeben. Nur bereitet es wenig Freude Partitionsgrößen innerhalb eines raids zu verschieben. Erkennen sollte Gparted das raid. Die Frage ist, ob dieses in der Lage ist darin auch zu arbeiten. Wenn ja würde dir das viel Arbeit ersparen. Wenn das nicht funktioniert würde ich dazu tendieren die komplette Vm mit Hilfe von rsync einmal komplett zu sichern eine neue VM anzulegen mit einem Image für /boot und Swap (ca 500mb für Boot, Swap = RAM der VM) und zwei Images für das Raid sofern du das wirklich in der VM realisieren möchtest. Anschließend debian neu zu installieren und das raid als / anlegen. Ich gehe aber weiterhin davon aus, dass das Dynamisch Erweitern scheitern wird. Ich hoffe für dich, dass Gparted in der Lage ist im RAID herumzuschrauben. Ansonsten wird es gefrickel. Ich habe irgendwann LVM für soetwas lieben gelernt. Ich kann damit die Größe der Volumes auf dem Host verwalten und relativ problemlos vergrößern und verkleinern (vorausgesetzt die VM ist ausgeschaltet). Einen schönen Sonntag, Thore > Liebe Grüße aus Wien, > Heinz >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature