I figured it out. I need to run resize2fs afterwards. I ran sudo resize2fs /dev/mapper/luks-5e5f911c... and that solved the issue.
this post was submitted on 02 Oct 2023
45 points (97.9% liked)
Linux
48229 readers
845 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Yup. This applies to filesystems regardless of whether they're in an encrypted partition it not.. You need to grow the FS size to fill the partition.
For other FS types it's:
xfs_resize /path/to/device
btrfs filesystem resize max /path/to/mountpoint
For LVM you may also need to first pvresize and then lvresize
Not sure about JFS or others
🎉 what Linux at home is all about
Well, not really. Someone on Reddit told me the solution.
Still counts 😹 software is all made by people after all, sometimes you just have to learn from others
Did you expand the filesystem itself?
You go from physical (your dd) to encrypted (luks) to lvm(if used) to your filesytem itself.
You probably have btrfs so check out Resizing btrfs
Edit: I can read, you have ext4 :)
Check out resize2fs, IIRC it can do it live on a mounted partition
KDE’s partition manager can resize LUKS partitions and the file systems inside of them. Be sure to have a back up (which it sounds like your old SSD is already).
Edit: Oh, nm, you already figured it out. :)
Why not encrypting the new SSD and rsync'ing the content from one drive to the other? Would be easier and safer.
I wasn't aware that rsync also copied system files. I'm curious to know why my method is unsafe. The only potential problem I see with what I did is mixing up if and of in dd.
Your method is safer imo as long as you get the dd command right. Because afterwards you'll have two bootable copies of your system. If you mess up resizing the filesystem on the new drive, just dd again from the old one.
Glad you figured it out.
rsync also gives you two bootable copies of your system. Even better, it gives you a checksum based copy of your files including permissions.
Safe/unsafe might be the wrong word, but rsync is resumable and also copies permissions for example. dd is more like the brute force method of data transfer.
Pause and resume are nice but dd also gives you the permissions. It copies everything, byte for byte, hence why it's a "low-level copy"
What does lsblk show? You might have to resize the ext4 filesystem as well as the luks volume.
Resizing the filesystem with resize2fs solved the issue.