Migrate Encrypted Tubleweed Install to smaller disk

I want to migrate from my current ssd to a smaller one (the current is slower)
The system currently has a ssd and a hdd, and I’m planning to keep the hdd
Current setup

  • 2 partitions on current ssd luks encrypted (/ and swap)
  • 3 partitions on current hdd luks encrypted /mnt/Data (data partition) and unencrypted /boot /boot/efi
  • The system boots with a single password entered at plymouth boot splash

output of lsblk:

sda           8:0    0   1.8T  0 disk  
├─sda1        8:1    0   500M  0 part  /boot/efi
├─sda2        8:2    0   128M  0 part  
├─sda3        8:3    0 197.6G  0 part  
├─sda4        8:4    0   450M  0 part  
├─sda5        8:5    0  10.4G  0 part  
├─sda6        8:6    0   1.1G  0 part  
├─sda7        8:7    0  1000M  0 part  /boot
└─sda8        8:8    0   1.6T  0 part  
  └─cr_sda8 254:2    0   1.6T  0 crypt /mnt/Data
sdb           8:16   0 223.6G  0 disk  
├─sdb1        8:17   0 215.9G  0 part  
│ └─cr_sdb1 254:0    0 215.9G  0 crypt /
└─sdb2        8:18   0   7.7G  0 part  
  └─cr_sdb2 254:1    0   7.7G  0 crypt [SWAP]

Device Graph Yast :slight_smile:

The current ssd is 240 GB and target is 120 GB
Is this possible without a full reinstall?

See if this helps at all:


Yes. It is a matter of backup everything, create new partitions, restore from backup, then do lots of tweaking to fix references to the old file systems.

In all honesty, it is probably easier to reinstall, then restore only “/home” from backups.

The setup is ext4 & fat:
output of blkid:

/dev/sda1: LABEL="ESP" UUID="32F2-69D9" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="49fedc3b-30a8-45dd-bd4d-747ead3537cc"
/dev/sda3: LABEL="OS" UUID="6EFE65EDFE65AE51" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="b2e11e5a-49db-41b8-af75-cd52f9fe89b6"
/dev/sda4: LABEL="WINRETOOLS" UUID="8652A45F52A455A9" TYPE="ntfs" PARTUUID="b36964d7-4b9b-469a-b4b5-e4099a0272b2"
/dev/sda5: LABEL="Image" UUID="6C86A51D86A4E932" TYPE="ntfs" PARTUUID="1d52fec4-a9b6-40ad-ba3a-7b407644ac19"
/dev/sda6: LABEL="DELLSUPPORT" UUID="F4FC9C33FC9BEDDC" TYPE="ntfs" PARTUUID="7ae38639-e226-450b-880e-3c5a91c46292"
/dev/sda7: UUID="171e4982-0e75-4904-bf2a-19ecb1f2437f" TYPE="ext4" PARTUUID="986bcada-7a95-4030-a86f-38e7f4f127bc"
/dev/sda8: UUID="f1085e3c-624f-4b0c-8ecb-2b3a610ebe6d" TYPE="crypto_LUKS" PARTUUID="f533be39-eae6-46dc-b451-c44956e41835"
/dev/sdb1: UUID="1c497ed9-2139-4498-a383-ec4969e11d8d" TYPE="crypto_LUKS" PARTUUID="8ae7b001-b1ef-4486-8f0e-abf299c6e689"
/dev/sdb2: UUID="95be3439-a7b2-46cc-b336-ed159d321c84" TYPE="crypto_LUKS" PARTUUID="86d1d091-95cf-46c5-8f21-109674adab5e"
/dev/mapper/cr_sdb1: UUID="ff5737e7-e9cc-44e2-82d6-0bdb5d6faadb" TYPE="ext4"
/dev/mapper/cr_sdb2: UUID="767b29c4-fc3d-4b6e-bea4-7fd9fb670869" TYPE="swap"
/dev/mapper/cr_sda8: UUID="307bde86-2633-48d4-9623-4d3f7c58a60c" TYPE="ext4"
/dev/sda2: PARTLABEL="Microsoft reserved partition" PARTUUID="0996afdc-1cdb-49f1-8d72-1f511a699f19"

I thought that, but if I shrink the partitions then dd them to the new drive, will the uuids change?

That will probably preserve uuids. But you will have to be careful with the encrypted partitions. And they might be mounted by virtual device name (such as “/dev/mapper/cr_sdb2”).

I’ve thought of the following:
Nuke encrypted swap and make sure system works (to prevent errors of not finding swap in new system)
Attach ssd , dd / to it using a live iso (after resizing / to fit new disk)
Recreate encrypted swap on new disk

The root partition is /dev/mapper/cr_sdb1
output of mount:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4021220k,nr_inodes=1005305,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
/dev/mapper/cr_sdb1 on / type ext4 (rw,relatime,data=ordered)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17698)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/sda7 on /boot type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mapper/cr_sda8 on /mnt/Data type ext4 (rw,relatime,data=ordered)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=806596k,mode=700,uid=1000,gid=100)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)

output of cat /etc/fstab:

UUID=ff5737e7-e9cc-44e2-82d6-0bdb5d6faadb  /           ext4  defaults  0  0
/dev/sda7                                  /boot       ext4  defaults  0  0
UUID=32F2-69D9                             /boot/efi   vfat  defaults  0  0
UUID=767b29c4-fc3d-4b6e-bea4-7fd9fb670869  swap        swap  defaults  0  0
UUID=307bde86-2633-48d4-9623-4d3f7c58a60c  /mnt/Data/  ext4  defaults  0  0

Should I dd the whole disk or the partition only?
i.e. dd if=/dev/sdb1 of=/dev/sdc or dd if=/dev/sdb of=/dev/sdc

If you are resizing partitions, then you should do the replication by partitions.

dd if=/dev/sdb1 of=/dev/sdc

That would copy a partition to the whole disk. But perhaps that was just a typo.

I did what I mentioned in the previous post, after resizing, copied / with dd to a cleared partition on the new drive
It worked! the uuids were same and even my running programs reopened; kde :slight_smile:

But I reverted as the new disk gave an improvement of 100MB/s read speed only vs expected 300 MB/s gain, and also brought
back those old read errors:

Both disks lose half of their speed due to encryption (confirmed by hdparm on locked drive)

Just realized I made one in the thread title …
I think this issue is resolved for now, thanks for your help.