LUKS Partition auf LVM vergrößern ... [solved]

[Stefan U. Hegner]

Hi Frank, Alexander & Pierre,

Pierre Bernhardt schrieb:
> Also ich finde, dass Dein Vorschlag doch ganz gut aussieht.
> Warum sollte das cryptsetup Probleme während des Betriebs machen?
... keine Ahnung.  War mir halt nicht sicher, ob das im lfd. Betrieb geht.
> Es werden doch nur die zus. hinzu gekommenen Blöcke dazu verschlüsselt.
Ach so!

> Wenn das System produktiv ist, solltest Du es vielleicht besser vorher
> einmal testen. 
Klar. Aber Fragen, bevor man was zerschießt und das Backup wieder
einspielen muss ist auch nicht dumm, gell?

So, habe mal mit dem /tmp Volume angefangen. Hat prima geklappt.

Fürs Archiv habe ich hier mal meine Lösung dokumentiert:

1. Wir schauen uns mal an wie groß /tmp Filesystem ist ...

    # df
    Filesystem           1K-blocks      Used Available Use% Mounted on
    [...]
    /dev/mapper/crypt-areca1-tmp
                           6192188    273304   5604340   5% /tmp

2. ... dazu sehen wir uns das LVM Volume an ...

    # lvdisplay
      [...]
      --- Logical volume ---
      LV Name                /dev/vg-areca1/tmp
      [...]
      LV Size                6,00 GB
      [...]


3. ... wir blasen das LVM Volume auf ...

    # lvresize -L +1G /dev/vg-areca1/tmp
      Extending logical volume tmp to 7,00 GB
      Logical volume tmp successfully resized


... und bekommen die Bestätigung, dass es nun 1 Gig größer ist.

4. Nun schauen wir uns das Crypto-Device an ....

    # cryptsetup status crypt-areca1-tmp
    /dev/mapper/crypt-areca1-tmp is active:
      cipher:  aes-cbc-essiv:sha256
      keysize: 128 bits
      device:  /dev/dm-6
      offset:  1032 sectors
      size:    12581880 sectors
      mode:    read/write


5. ... vergrößern es ...

    # cryptsetup resize crypt-areca1-tmp


6. ... und prüfen die neue Größe.

    # cryptsetup status crypt-areca1-tmp
    /dev/mapper/crypt-areca1-tmp is active:
      cipher:  aes-cbc-essiv:sha256
      keysize: 128 bits
      device:  /dev/dm-6
      offset:  1032 sectors
      size:    14679032 sectors
      mode:    read/write


7. Zuletzt passen wir das Ext3-FS an die neue Größe an ...

    # resize2fs -p /dev/mapper/crypt-areca1-tmp
    resize2fs 1.41.3 (12-Oct-2008)
    Filesystem at /dev/mapper/crypt-areca1-tmp is mounted on /tmp;
    on-line resizing required
    old desc_blocks = 1, new_desc_blocks = 1
    Performing an on-line resize of /dev/mapper/crypt-areca1-tmp to
    1834879 (4k) blocks.
    The filesystem on /dev/mapper/crypt-areca1-tmp is now 1834879 blocks
    long.


8. ... prüfen die neue Größe ...

    # df
    Filesystem           1K-blocks      Used Available Use% Mounted on
    [...]
    /dev/mapper/crypt-areca1-tmp
                           7224308    274836   6582540   5% /tmp


9. <FREU> ... und freuen uns, dass alles problemlos gefunzt hat. </FREU>

> Wenn das System produktiv ist, solltest Du es vielleicht besser vorher
> einmal testen. Und immer schön an ein Backup denken ;-)
Wenn das nächst Backup gelaufen ist, werde ich dann der Reihe nach
    /
    /usr
    /var   und
    /home

anpacken. Und dann ist alles wieder gut ;-)

LG

Stefan.

-- 
Stefan U. Hegner 
         <stefan at hegner-online.de>
              * * *
D-32584 Löhne --- good ole Germany
internet: http://www.hegner-web.de
              * * *
GPG-Key | D9DB 51BD 2DA6 9B3A 41CB
F-Print | 0287 05A1 8D11 38BA CE91


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20100216/cb277e36/attachment.sig>