Hi all,
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:
ext4-fs failed to convert unwritten extents
How can I fix this?
Thanks in advance.
Can you share following for both scenarios
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
cat /etc/fstab
As well the error log from the failing system
systemctl restart mariadb.service
journalctl -u mariadb
cat /var/log/mysql/error.log
readlink /var/lib/mysql
readlink -f /var/lib/mysql
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?
TIA
Klaus
You could boot your original configuration. Once up and running, connect your new HDD and use dd command to clone the whole drive.
1 Like
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.
Yes drives are mounted by the device ID.
Can you boot your device with original configuration. Once up, connect the new HDD. How does following looks like
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
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.
1 Like
That really sounds good.
Will try with dd
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.
Any ideas?
Could this be a weak power supply resp. power supply cabling?
1 Like
as well you can check for kernel error messages
dmesg -l 0,1,2,3
Does the drive return after reboot?
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…
1 Like
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.
1 Like
Ok, will consider this.
At least this time (with external PSU) the dd copy worked.
But the drive IDs are different again and now I have this layout:
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> sda 8:0 0 1,8T 0 disk
> └─sda3 8:3 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 /
Services are not started, so I have to find a way to change the assignments on the new system configuration.
Can you share following
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
cat /etc/fstab
> NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID
> sda 1,8T 0 disk
> +-sda3
> ext4 dietpi-media
> 931,5G 0 part /mnt/dietp 67e36afd-a699-6644-80ff-20eb9067c4a9 e7dc44e9-f081-44aa-a6da-4aa18e94443b
> sdb 238,5G 0 disk
> +-sdb1
> ¦ vfat 128M 0 part /boot 0140a7f0-01 E547-094A
> +-sdb2
> ext4 238,3G 0 part / 0140a7f0-02 196af0eb-3cdf-4d16-a819-6d064fbd60ff
This is the output of the cat/fstab command:
> # 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
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.
UUID is correct e7dc44e9-f081-44aa-a6da-4aa18e94443b both are fitting
Device
And /etc/fstab
The drive is mounted. Can you check
df -h
These are the results of
df -h
> #Running system:
> Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
> /dev/root 235G 1,7G 224G 1% /
> devtmpfs 3,9G 0 3,9G 0% /dev
> tmpfs 3,9G 0 3,9G 0% /dev/shm
> tmpfs 1,6G 2,4M 1,6G 1% /run
> tmpfs 5,0M 0 5,0M 0% /run/lock
> tmpfs 1,9G 0 1,9G 0% /tmp
> /dev/sda1 127M 33M 94M 26% /boot
> /dev/sdb3 916G 660G 211G 76% /mnt/dietpi-media
> tmpfs 50M 8,1M 42M 17% /var/log
>
> #System with new SSD
> Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
> /dev/root 235G 1,7G 224G 1% /
> devtmpfs 3,9G 0 3,9G 0% /dev
> tmpfs 3,9G 0 3,9G 0% /dev/shm
> tmpfs 1,6G 11M 1,6G 1% /run
> tmpfs 5,0M 0 5,0M 0% /run/lock
> tmpfs 1,9G 8,0K 1,9G 1% /tmp
> tmpfs 50M 16K 50M 1% /var/log
> /dev/sdb1 127M 33M 94M 26% /boot
> /dev/sda3 916G 659G 211G 76% /mnt/dietpi-media
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
What is the system doing here?
Rolling dices?