I have now done some steps with the GParted Live medium. Unfortunately, I encountered some problems. I try to provide some information below.
I must say that I first realized that at the end of the disk there was some unused space, and I decided to include this into sda4, and to start to shrink from the situation after adding this space.
Growing sda4 within GParted seemed OK, the graphical windows shows that there is no unused space left. I have a screenshot after reboot, but I don't find a way to upload the image to the BB (although I can see the "Images" help).
Now, just after reboot into GParted Live, before I activate the LUKS encrypted LVM partitions, I get the following fdisk -l result (/dev/sdb is of course the USB stick with the Live medium):
Disk /dev/sdb: 7.27 GiB, 7801405440 bytes, 15237120 sectors
Disk model: STORE N GO
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x41c15519
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 64 714751 714688 349M 17 Hidden HPFS/NTFS
Disk /dev/sda: 149.5 GiB, 160041885696 bytes, 312581808 sectors
Disk model: WDC WD1600BEVT-2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000c12a9
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 321535 319488 156M 83 Linux
/dev/sda2 321536 46313471 45991936 22G 8e Linux LVM
/dev/sda4 46315395 312580095 266264701 127G 8e Linux LVM
Disk /dev/loop0: 303.31 MiB, 318033920 bytes, 621160 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
The number of sectors for /dev/sda4 has indeed increased, see the respective line in the fdisk report before growing:
/dev/sda4 46315395 312576704 266261310 127G 8e Linux LVM
If I now unlock both sda2 and sda4, both become also activated and fdisk -l lists more information, but the size of /dev/mapper/system-home has not changed and is still:
Disk /dev/mapper/system-home: 127 GiB, 136319074304 bytes, 266248192 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
No sectors have been added. So, I thought that the LV and the file system should be grown as well, and used in analogy to your suggestion with the added -r flag
lvm lvresize -r -l+100%FREE /dev/mapper/sda4_crypt
Please note, that I used "sda4_crypt" instead of the "cr_ata-WDC_WD1600BEVT-22ZCT0_WD-WXE708N10973-part4", because the latter was the name in my Leap 15.1 system (from where I created the lsblk output in my original post, but in the GParted Live system, sda4_crypt appears instead. In fact, I also tried the "cr_ata...", but of course that gave me an error.
This command gave the following result:
"/dev/mapper/sda4_crypt": Invalid path for Logical Volume.
Run `lvresize --help' for more information.
Well, indeed the command lvdisplay shows that
WARNING: PV /dev/mapper/sda2_crypt in VG system is using an old PV header, modify the VG to update.
WARNING: PV /dev/mapper/sda4_crypt in VG system is using an old PV header, modify the VG to update.
--- Logical volume ---
LV Path /dev/system/home
LV Name home
VG Name system
LV UUID XHMtO6-TFcg-mQea-qPI7-yCer-GlYP-tjgt1Z
LV Write Access read/write
LV Creation host, time linux, 2013-04-25 19:25:29 +0000
LV Status available
# open 0
LV Size <126.96 GiB
Current LE 32501
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:2
Apart from the warnings, this seems to tell me that the logical volume path were rather /dev/system/home, while the pvdisplay command shows /dev/mapper/sda4_crypt to be a physical volume:
WARNING: PV /dev/mapper/sda2_crypt in VG system is using an old PV header, modify the VG to update.
WARNING: PV /dev/mapper/sda4_crypt in VG system is using an old PV header, modify the VG to update.
--- Physical volume ---
PV Name /dev/mapper/sda2_crypt
VG Name system
PV Size <21.93 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 5613
Free PE 0
Allocated PE 5613
PV UUID 4ZpFcU-CsmK-9JsR-O1eG-RDlI-8aTa-FB97Et
--- Physical volume ---
PV Name /dev/mapper/sda4_crypt
VG Name system
PV Size 126.96 GiB / not usable <4.41 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 32501
Free PE 0
Allocated PE 32501
PV UUID 2XDQmQ-WR8a-3bKR-AdjE-dVVa-yael-xJN3Qj
Finally, I tried to apply lvresize to /dev/system/home:
WARNING: PV /dev/mapper/sda2_crypt in VG system is using an old PV header, modify the VG to update.
WARNING: PV /dev/mapper/sda4_crypt in VG system is using an old PV header, modify the VG to update.
fsck from util-linux 2.35.2
/dev/mapper/system-home: Inode 3410128 extent tree (at level 1) could be shorter. IGNORED.
/dev/mapper/system-home: 175972/8323072 files (1.6% non-contiguous), 13931353/33281024 blocks
Size of logical volume system/home unchanged from <126.96 GiB (32501 extents).
Logical volume system/home successfully resized.
resize2fs 1.45.6 (20-Mar-2020)
The filesystem is already 33281024 (4k) blocks long. Nothing to do!
The filesystem block count times 4k is exactly what fdisk -l shows me to be the number of bytes of /dev/mapper/system-home: 136319074304 bytes. And this is the same before and after adding the previously unused space by growing.
What do I have to do to include the additional space?
And: is it OK that I have to use lvresize on /dev/system/home rather than on sda4_crypt (or cr_ata_...) to get any action (as opposed to your suggestion)?
Can I now proceed to shrink sda4 by 1024 (or rather 512)M by applying lvresize to /dev/system/home ?