Changing partitions for swap

Hi all!
When I installed manjaro in my new laptop, I wasn’t aware of one question: to be able to properly hibernate, a partition (or file) is needed with space enough for RAM and GPU. I’ve not used a system with dedicated GPU sonce many years, so I just dind’t thought of this.
So, when installing, I used the default options, includng swap partition, but this is 16 Gb, which is my RAM, but not 20 as I would need (16 RAM + 4 GPU).
To be honest, there’s no big rpoblem, I can choose to close my RAW photo editor (darktable) before hibernating (or, as I use to do, suspend-then-hibernate), and there has been no problems by now. But it wuold be just more comfortable no to have to do so.
And I also set my system with encryption (LUKS, as default by Manjaro), so the partitions for / and swap are inside the LUKS container.
So, my question is: would be safe to resize partitions to acomodate my swap to 20 GB inside a LUKS container? And how should be done, I’ve never tried to operate with partitions inside LUKS.
Or wuold it be more convenient to use a swap file, more easy to create. The not-so-big problem, of course, is to let this 16 GB unused, for SSD are limited nowadays (512 GB in my case, so nearly 4% of real space). Or perhaps would be easy to add this swap partition to the main one after doing so… once again, I’m not used to work inside LUKS, so I don’t know if that woukd be easier fo doing the first option, which would mean to change sine of / partition, deleting the swap one, and dreate another one in the new position, to access space enough),
Or I could just stay as I’m now, and simply close my GPU dependent applications before hibernating (or stopping for a time that could become enough for the suspend-then-hibernate option to do the change).

What would you do, and how to be done if recommended to chage partitions?

Thanks for your help!

Edit: I forgot to add my system info:

System:
  Kernel: 6.1.12-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 12.2.1
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1-x86_64
    root=UUID=4d2d0e11-44f4-4f14-a6dc-d1f83f358998 rw quiet
    cryptdevice=UUID=95fc649b-53b3-4137-813b-69f906456198:luks-95fc649b-53b3-4137-813b-69f906456198
    root=/dev/mapper/luks-95fc649b-53b3-4137-813b-69f906456198 apparmor=1
    security=apparmor
    resume=/dev/mapper/luks-e4419e8b-5200-43f2-9f1f-8f886ee1616a
    udev.log_priority=3 ibt=off mem_sleep_default=deep
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel, cairo-dock
    wm: xfwm v: 4.18.0 vt: 7 dm: LightDM v: 1.32.0 Distro: Manjaro Linux
    base: Arch Linux
Machine:
  Type: Laptop System: LENOVO product: 82K1 v: IdeaPad Gaming 3 15IHU6
    serial: <superuser required> Chassis: type: 10 v: IdeaPad Gaming 3 15IHU6
    serial: <superuser required>
  Mobo: LENOVO model: LNVNB161216 v: No DPK serial: <superuser required>
    UEFI: LENOVO v: H4CN23WW(V1.08) date: 02/11/2022
CPU:
  Info: model: 11th Gen Intel Core i5-11320H bits: 64 type: MT MCP
    arch: Tiger Lake gen: core 11 level: v4 note: check built: 2020
    process: Intel 10nm family: 6 model-id: 0x8C (140) stepping: 2
    microcode: 0x28
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
    L1: 320 KiB desc: d-4x48 KiB; i-4x32 KiB L2: 5 MiB desc: 4x1.2 MiB L3: 8 MiB
    desc: 1x8 MiB
  Speed (MHz): avg: 2395 high: 3200 min/max: 400/4500 scaling:
    driver: intel_pstate governor: powersave cores: 1: 3200 2: 3200 3: 3200
    4: 3200 5: 3200 6: 1032 7: 1052 8: 1076 bogomips: 51008
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: retbleed status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
    prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
    sanitization
  Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB
    filling, PBRSB-eIBRS: SW sequence
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] vendor: Lenovo
    driver: i915 v: kernel arch: Gen-12.1 process: Intel 10nm built: 2020-21
    ports: active: eDP-1 empty: DP-1, DP-2, DP-3, HDMI-A-1
    bus-ID: 0000:00:02.0 chip-ID: 8086:9a49 class-ID: 0300
  Device-2: NVIDIA TU117M [GeForce GTX 1650 Mobile / Max-Q] vendor: Lenovo
    driver: nvidia v: 525.89.02 alternate: nouveau,nvidia_drm non-free: 525.xx+
    status: current (as of 2023-02) arch: Turing code: TUxxx
    process: TSMC 12nm FF built: 2018-22 bus-ID: 0000:01:00.0
    chip-ID: 10de:1f9d class-ID: 0302
  Device-3: Syntek Integrated Camera type: USB driver: uvcvideo
    bus-ID: 1-6:2 chip-ID: 174f:244c class-ID: 0e02 serial: <filter>
  Display: x11 server: X.Org v: 21.1.7 compositor: xfwm v: 4.18.0 driver: X:
    loaded: modesetting,nvidia alternate: fbdev,nouveau,nv,vesa dri: iris
    gpu: i915 display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93")
  Monitor-1: eDP-1 model: BOE Display 0x09d2 built: 2020 res: 1920x1080
    hz: 60 dpi: 142 gamma: 1.2 size: 344x194mm (13.54x7.64") diag: 395mm (15.5")
    ratio: 16:9 modes: 1920x1080
  API: OpenGL v: 4.6 Mesa 22.3.5 renderer: Mesa Intel Xe Graphics (TGL GT2)
    direct-render: Yes
RAID:
  Hardware-1: Intel Volume Management Device NVMe RAID Controller driver: vmd
    v: 0.6 port: N/A bus-ID: 0000:00:0e.0 chip-ID: 8086:9a0b rev: class-ID: 0104
Drives:
  Local Storage: total: 476.94 GiB used: 116.39 GiB (24.4%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Intel model: SSDPEKNW512GZL
    size: 476.94 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
    lanes: 4 type: SSD serial: <filter> rev: C01C temp: 31.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 459.68 GiB size: 451.4 GiB (98.20%)
    used: 113.92 GiB (25.2%) fs: ext4 dev: /dev/dm-0 maj-min: 254:0
    mapped: luks-95fc649b-53b3-4137-813b-69f906456198
  ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
    used: 14.5 MiB (4.8%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
Swap:
  Kernel: swappiness: 60 (default) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 16.95 GiB used: 2.46 GiB (14.5%)
    priority: -2 dev: /dev/dm-1 maj-min: 254:1
    mapped: luks-e4419e8b-5200-43f2-9f1f-8f886ee1616a

And my SSD structure is:
/dev/nvme0n1p1 /boot/efi fat32 330 Mb
And the luks container with:
/dev/nvme0n1p2 / etx4 459’69 GB
/dev/nvme0n1p3 linux-swap 16’96 Gb

Unless you specifically and definitely know that you do have a problem (with not enough swap)
you don’t have a problem.

This is/seems to be an assumption on your part - or have you tested this?

Yes, I’ve had some problems with hibernate at first times using the laptop, when not closing darktable, for example. And after some research, seems to be because fo that…

You should view a LUKS container like any other RAW device.
Linux does so also, hence why you need to create a filesystem inside.
The only difference is that the data is encrypted/decrypted before it is written to/read from the underlying hardware device.

The resizing depends on what type of filesystem you used inside your LUKS container.
From what i can tell you are using ext4 inside one LUKS container, and a separate swap partion in another LUKS container…

On top of that all you are using a hardware RAID…

This could possibly make things hard/difficult/impossible…

Could you also provide the output of:

sudo lsblk --fs --all
1 Like

Are you 100% sure that GPU memory is actually saved to disk when hibernating? A short and shallow search on my side, disproved this, however, I guess you have your reason to assume so.

Instead of resizing partitions and the danger of killing your files, I would recommend to remove the swap partition and use a swap file instead.

Perhaps it’s because you’re already using swap, and you haven’t got enough space for that and the contents of your RAM.

Either way I’d use 1.5-2x RAM, so 24-32GB for swap. I like swap partitions but it would be easier to put a swap file on /.

It should work by just resizing partitions. But of course it is a drastic operation and something could go wrong.

That could be also a reason, you’re right. Should have been a larger swap partition, anycase.

It’s probably less risky to just delete the swap partition and extend your / partition to use that space.

With gparted, after you booted the live system from USB and have opened the encrypted container.

Then create a swap file inside the / partition.

But this then involves a few adjustments to /etc/fstab and to /etc/default/grub
in order to use the swap file for hibernation.

… not too difficult, but could be challenging when you are not familiar with the command line and with the underlying procedure
(understanding what is happening and why is done what needs to be done …)

just FYI:
I have 8 GB RAM - and 8 GB swap (not double the RAM …)
and I never had a problem to hibernate …

I was reading and finding references to GPU sending it’s memory to the hibernate file. And so that it failed when using the GPU, and not otherwise, it seems to be this. But I cannot say for sure, I found no way to make a proper diagnosis…
One way or another, it seems that a bigger swap file/partition would make problems dissapear.
But so that it is usable without this (just closing GPU apps), I’m not sure if the damage probability, if it’s bigger or more complex because of LUKS, makes more logical to opt for repair.
Thank for comments!

No problem about changes for the swap file in fstab, grub, and so, I’ve done this mores times before.
That was one of the options I was thinking: just to use a swap file, and add the swap partition space to /
I was not sure if that was a possibility being inside of LUKS, but after reading answers, it seems it not difficult at all. So, probably will be the option for me.

And this could even give a possibility of trying first the swap file, to see if it works properly, and only then do the partition modification. And if not, just keep everyting as it is now.

Thanks!

That’s right.
Only comment out the line in /etc/fstab and the GRUB_CMDLINE_LINUX_DEFAULT= in /etc/default/grub
(or back up those two files so you can easily restore them)
and then go ahead and configure and test your swap file …

It’s really just like Lego - you swap out one thing for another
and you can’t go catastrophically wrong when you have backups of the stuff you changed and know how to get back to that state.

It seems you’re right. There are two different LUKS containers. Manjaro sets encryptions this way by default (don’t know if that makes any improvement, for my intuition seems the opposite).

NAME                                          FSTYPE      FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0                                                                                                                        
nvme0n1                                                                                                                      
├─nvme0n1p1                                   vfat        FAT32 NO_LABEL 932A-C731                             284,9M     5% /boot/efi
├─nvme0n1p2                                   crypto_LUKS 1              95fc649b-53b3-4137-813b-69f906456198                
│ └─luks-95fc649b-53b3-4137-813b-69f906456198 ext4        1.0            4d2d0e11-44f4-4f14-a6dc-d1f83f358998  312,3G    26% /
└─nvme0n1p3                                   crypto_LUKS 1              e4419e8b-5200-43f2-9f1f-8f886ee1616a                
  └─luks-e4419e8b-5200-43f2-9f1f-8f886ee1616a swap        1     swap     7cc37bde-631a-4e3b-8949-05e856d1a0e5                [SWAP]

Then it seems impossible to change partitions as I was proposing. Unless reinstalling completely, which is something I don’t want to do, neither seems proportional to the improvement (if any).

So, the only comfortable option would be make and use a swap file bigger than present partition, and loose the space from this partition (or better, make a new one in this container and use it as another store space).

Most probably will keep thing as they are now, which is not a bad state, anyway.

Thanks a lot, most helpful!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.