[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed documentation, please comment! [was Re: Bug#838919: debian-installer: please calculate swap parition according to max RAM...]



Nicholas D Steeves schreef op 30-09-2016 0:18:

Page title or section heading of "I've upgraded my RAM and my
swap partition/LV is no longer big enough to hibernate".

I don't think Debian is for lay users, but yeah.

7. There would also need to be a section on reinitialising encrypted
   swap.  Consideration of this is why I went with the delete, resize
   create method rather than attempting to resize, because I'm not
   sure if resizing encrypted swap is supported...and I have no
   experience with encrypting disks/partitions/LVs.

Encrypted swap is normally initialized on every boot. That is to say if you have a "cryptswap" partition/LVM then a new key will be generated at every boot and mkswap executed on the newly mapped device. Typical for me is shrinking the largest partition/LVM (at the end) removing the initial swap (that is positioned right after root) and then adding the new swap in the space at the end. Then I would grow the root partition to cover the new space.

This is why swaps are handy to begin with: they are free root growing space.

Also, if someone with
experience with LUKS would like to write this documentation (or the
LUKS section), please let me know! :-)

More than willing but it's very easy: you don't have to change anything unless you reference swap by UUID.

Which is fairly typical I think, but still it only involves replacing the UUID in /etc/crypttab. I am fairly sure swap needs to be contigious

"Note that a swap file must not contain any holes (so, using cp(1) to create the file is not acceptable)."

but LVM is a mapped space and only presents a contigious space to the user. So in principle it doesn't matter if you have non-contigious LVM but personally I do not like it and would always recommend to just consume the old swap space and create a new one at the end. Regardless it is a possibility, I am fairly certain. More troublesome is growing and deleting live partitions (you can grow a root fs runtime, and you can resize an LV runtime. You can shrink a data partition runtime. You cannot shrink a root partition runtime. I mean in a live system.

You cannot shrink XFS runtime. Or at all. Shrinking XFS requires backup and restore. I don't know what Debian's recommended choices are and I do not know about BTRFS. Hence the recommendation (by me) to not have a single filesystem (root). And to not use XFS unless absolutely required.

The recipe for shrinking some data LV is fairly simple:

- lvresize -r vg/lv -L -4G
- swapoff -a
- (cryptsetup close cryptswap)
- lvresize vg/swap -L +4G --- if you don't care about non-contigious - (cryptdisks_start cryptswap // systemctl restart systemd-cryptsetup@cryptswap.service // not sure)

And that should normally be it.

- mkswap /dev/vg/swap // the crypt services automatically do this
- swapon -a           // the crypt services automatically do this

If you would delete and add anew:

- lvresize -r vg/lv -L -8G
- swapoff -a
- ...
- lvremove vg/swap
- lvresize -r vg/root

You'll have to know the space, e.g. +4G if the swap was 4G and you want root to grow by the same. That should normally work fine and not skip into the new area. You can check with pvdisplay --map after resize/creation.

So : - lvresize -r vg/root -L +4G

- lvcreate vg -n swap -l 100%free (or -L 8G)

- now change /etc/crypttab for the new UUID

Regards.


Reply to: