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.