Problem with moving rootFS to the new SSD drive

Creating a bug report/issue

Moving the rootFS to other drive always fails (at the end of coping files).

Background info:
Every couple of days my boot & RootFS that is located on the USB pendrive, is mounted in “read-only” mode. I know that its the good moment to move the RootFS to the new SSD drive.
However every time I’m using the dietpi-manager to move it to the new drive, after an hour of coping all files, its failed at the end (can’t copy it as it dissapear quite quickly, but its just “FAILED” status next to this rsync command that was displayed when the file were transfered from tmp/tmp_root to the new drive).

I have searched the existing open and closed issues

Required Information

  • DietPi version | G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=1 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng' G_LIVE_PATCH_STATUS[0]='not applicable'
  • Distro version | bookworm 0
  • Kernel version | Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
  • Architecture | arm64
  • SBC model | RPi 4 Model B (aarch64)
  • SD card used | USB Pendrive as a boot device/rootFS (128 GB)

Steps to reproduce

  1. execute dietpi-drivemanager
  2. selecting the “transfer RootFS” on target drive and (which is not mounted)
  3. formatting it into ext4 (the same FS as a current root drive)


After formatting and waiting around an hour I got error message.
Althought when I check the the disk usage I can spot that the all data is transfered to new device

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       118G   56G   57G  50% /
/dev/sdc1       110G   56G   54G  51% /mnt/f1e82f43-3eb9-4ff2-90d0-629a5281dd01

Expected behaviour

Successful transfer of rootFS, updated fstab

Actual behaviour

Transfer data fails, and rootFS is still located on original USB drive

Extra info

fdisk output(after restart)

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/loop0: 49.07 MiB, 51453952 bytes, 100496 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


Disk /dev/loop1: 49.12 MiB, 51503104 bytes, 100592 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


Disk /dev/loop2: 49.12 MiB, 51503104 bytes, 100592 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


Disk /dev/loop3: 14.7 MiB, 15413248 bytes, 30104 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


Disk /dev/loop4: 14.7 MiB, 15417344 bytes, 30112 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


Disk /dev/loop5: 236.26 MiB, 247734272 bytes, 483856 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


Disk /dev/loop6: 236.36 MiB, 247836672 bytes, 484056 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


Disk /dev/loop7: 35.52 MiB, 37240832 bytes, 72736 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


Disk /dev/sda: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: ASM225CM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D32E17C5-6635-4461-9D3D-E18524AD581D

Device     Start        End    Sectors  Size Type
/dev/sda1   2048 5860532223 5860530176  2.7T Linux filesystem


Disk /dev/sdb: 119.08 GiB, 127865192448 bytes, 249736704 sectors
Disk model: Flash Drive
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: 0xcb891ace

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sdb1  *      8192    270335    262144  128M  c W95 FAT32 (LBA)
/dev/sdb2       270336 249736703 249466368  119G 83 Linux


Disk /dev/sdc: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: DSC2BW120A4
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: A2C33B99-2DA7-4D19-B075-89956113277F

Device     Start       End   Sectors   Size Type
/dev/sdc1  65535 234418694 234353160 111.7G Linux filesystem


Disk /dev/loop8: 35.21 MiB, 36921344 bytes, 72112 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

fstab

#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=cb891ace-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=cb891ace-01 /boot vfat noatime,lazytime,rw 0 2
UUID=57cffb2b-d093-4373-93c6-9152e09f3ed5 /mnt/magazyn ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
UUID=f1e82f43-3eb9-4ff2-90d0-629a5281dd01 /mnt/f1e82f43-3eb9-4ff2-90d0-629a5281dd01 ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount

blkid

/dev/sdb2: UUID="1ff5b9f9-2abf-4937-b25c-d1f2fa3ca4b9" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cb891ace-02"
/dev/sdb1: UUID="B9AD-A61C" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="cb891ace-01"
/dev/sdc1: UUID="f1e82f43-3eb9-4ff2-90d0-629a5281dd01" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="85a58268-d5a4-47f9-95c3-1639aeed6be0"
/dev/sda1: UUID="57cffb2b-d093-4373-93c6-9152e09f3ed5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="9f5d55ff-d9b3-432e-9766-06b91ac3ab17"

why not moving the entire system to the new connected SSD instead of RootFS only? Moving a running DietPi system to a USB stick/disk or an onboard eMMC – DietPi Blog

can you share following

lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid

After the error you should try to capture the error so you can see what it says.
At the terminal of course,

sudo journalctl --since "today" | grep rsync

or if you know the date

sudo journalctl -since "2024-02-23" | grep rsync

Not sure what will actually report the error it may be dietpi-drivemanager but I would try rsync first.

1 Like

Hi, sorry for the delay in responding.
Thanks for the hints; I decided to move the entire system to new drive instead of the RootFS only as @Joulinar pointed to (many, many thanks for that!).
It works as a charm, and the system booted with the SSD.
And the story could end here, but from this point, it started to be a bit more interesting.

My issue with “read-only RootFS” was solved, and I thought that it would a reason of the problem that I had for a long time - namely my rpi after a couple of hours/days, without any particular reason started to be unresponsive, even with no noticeable jobs runnings. This makes establishing an SSH connection impossible, or even if the SSH was initialized already, it was so slow that I almost couldn’t type any commands.

As I said, I thought that a faulty USB drive was the reason. But to my surprise, the problem still occurred precisely as before. I tried to disable all unnecessary services, docker, but even on very “light” workload (with only cloudflare tunnel and one light docker) the problem persisted.

Then, after being in despair, I accidentally found a root cause. The problem lies with the kernel threads that started to make this system unresponsive.
Please see the attached picture.

So, I found that the problem is well known and occurs on some systems that are connected only via WIFI (my RPI was connected to the Internet that way)

The problem was related to two components (kworker/u2:0-brcmf_wq/mmc1:0001:1 - which is responsible for WIFI stack, and the second problem is related to very well known kswapd0 which is responsible for swap.)

Please see

https://forums.raspberrypi.com/viewtopic.php?t=317429

So, not to make this offtopic too long, after disabling wifi on rpi4 and connecting the system via ethernet, the system is perfectly stable and working as expected.

I hope that this will help anyone who faces unexpected sluggishness of RPI with troubleshooting if they are connected only via a WIFI channel,

1 Like

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