I have a Raspi 4 running Owncloud with MariaDB, Apache 2 etc. and it’s running stable since more than a year.
Attached drives are a 256 GB M.2 device containing the system and some data.
The OwnlCloud and MariaDB data reside on a 1 TB Samsung EVO 870 SSD which is running out of space.
I bought a Samsung 2 TB EVO 870 and cloned the hard disk partition to the new drive.
Did that under Windows with AOMEI Partition Manager which took about 1.5 hours without resizing the partition to the full HDD size yet.
When I attach the new SSD to the Raspi and boot something’s going wrong, MariaDB, Owncloud etc. aren’t starting up.
The partition on the new SSD is recognized but with different device assignments. When issuing the
lstblk
command, the old, working configuration looks like this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 238,5G 0 disk
+-sda1 8:1 0 128M 0 part /boot
+-sda2 8:2 0 238,3G 0 part /
sdb 8:16 0 931,5G 0 disk
+-sdb3 8:19 0 931,5G 0 part /mnt/dietpi-media
When the new SSD is attached the result after booting looks like this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1,8T 0 disk
+-sda1 8:1 0 931,5G 0 part /mnt/dietpi-media
sdb 8:16 0 238,5G 0 disk
+-sdb1 8:17 0 128M 0 part /boot
+-sdb2 8:18 0 238,3G 0 part /
Starting dietpi-drive_manager immediately results in an error like:
These are the results from the working configuration.
> NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID
> sda 238,5G 0 disk
> +-sda1 vfat 128M 0 part /boot 0140a7f0-01 E547-094A
> +-sda2 ext4 238,3G 0 part / 0140a7f0-02 196af0eb-3cdf-4d16-a819-6d064fbd60ff
> sdb 931,5G 0 disk
> +-sdb3 ext4 dietpi-media 931,5G 0 part /mnt/dietpi-media 67e36afd-a699-6644-80ff-20eb9067c4a9 e7dc44e9-f081-44aa-a6da-4aa18e94443b
>
> # You can use "dietpi-drive_manager" to setup mounts.
> # NB: It overwrites and re-creates physical drive mount entries on use.
> #----------------------------------------------------------------
> # NETWORK
> #----------------------------------------------------------------
>
>
> #----------------------------------------------------------------
> # TMPFS
> #----------------------------------------------------------------
> tmpfs /tmp tmpfs size=1922M,noatime,lazytime,nodev,nosuid,mode=1777
>
> #----------------------------------------------------------------
> # MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
> #----------------------------------------------------------------
>
>
> #----------------------------------------------------------------
> # SWAP SPACE
> #----------------------------------------------------------------
>
>
> #----------------------------------------------------------------
> # PHYSICAL DRIVES
> #----------------------------------------------------------------
> PARTUUID=0140a7f0-02 / ext4 noatime,lazytime,rw 0 1
> PARTUUID=0140a7f0-01 /boot vfat noatime,lazytime,rw 0 2
> UUID=e7dc44e9-f081-44aa-a6da-4aa18e94443b /mnt/dietpi-media ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
But unfortunately now the Raspi even doesn’t allow me to connect with the new SSD atrached.
I get an:
“Device unexpectedly closed the network connection” error.
So I cannot provide the information with the new SSD attached.
But maybe you know, if there is a better or more successful way cloning an EXT4 harddrive?
But what would be the difference? Cloning the drive works, when I connect it to another machine all data is there.
The problem obviously is, that the Raspi configuration is stored in a way, that it’s pointing to a certain hard drive with IDs or whatever. Just replacing it with another one, same data and larger size doesn’t work.
It might be that the cloning process via AOMEI Partition Manager cloned the disk with a different disk UUID to have different UUIDs when having both disks (the old 1TB and the nes 2TB) in a system.
The dd command keeps this UUID identical, i.e. on long term you should only use one of them or chenge the UUID of the old disk at the end.
I think, this is what MichaIng tries to figure out.
Strange things happen…
Today I tried cloning the SSD with DD.
Everything started well and copying started quite fast.
But after some minutes and > 90 GBytes copied, dd quit with an error message stating that he target disk is full and it cannot write anymore.
lsblk
didn’t show the 2 TB disk anymore.
The SSD is brand new.
Will try again today and also check the log, if the error returns.
Weak power supply might be a possible reason. In the “copy configuration” there are two SSDs connected to the two USB 3.0 slots: The old 1 TB and the new 2 TB drive.
In the productive config it’s a 256 GB M.2 SSD and the Samsung SSD.
The maximum current for each USB device is limited to 600 mA (and 1.2 A for all four ports combined) which means 3 Watts at 5 Volts.
In the web I found power consumption values of the Samsung SSDs between 2,5 (average power consumption) and 4 Watts (0.8 A, peak) which exceeds the maximum.
So for the second try I use an active USB 3.0 Hub that supplies the the 2 TB drive and doesn’t use the Pi’s power line.
Let’s see…
USB ports of RPI4 are not designed to power external drives. We have seen it multiple times where this was causing issues and data corruption. Especially during peak situations. Our recommendation is to use external PSU to power HDD/SSD.
For some reason I don’t know, just exchanging the SSDs is not an option.
How about a “soft” migration?
Means, I would attach the newly cloned SSD to the running system and transfer whatever is necessary to the new drive, or better said change the configuration to point to the new drive where everything already exists?
Can you show the blkid output from the original setup and the state direct after the dd operation?
I assume that the UUIDs and PartUUIDs are identical.
Is also only can issue one command after logging in. When I enter the next command, I get
> -bash: /usr/bin/df: Eingabe-/Ausgabefehler
Means: Input/output error
As far as I can see, the dev assignments are different.
boot device is
/dev/sda1
on the running system and
/dev/sdb1
on the system with the new SSD
Also the SSD first is /dev/sdb3 versus /dev/sda3