Hello, I had dietpi latest running on x86 machine ASrock Deskmini 310 for couple of month and switched now to new ASrock Deskmini B660. On 310 the root drive was Kingston 3.0 NVME and on B660 it’s a Kingston 4.0 NVME.
I used the clonezilla option from dietpi installer / usb stick to clone the old 3.0 NVME to the new 4.0 NVME. 4.0 is installed to internal mainboard slot and 3.0 was attached to usb with external NVME drive.
Recovery works well and I now use the whole dietpi installation on the new system like it was before but with something annoying.
I work on the machine only headless over ssh / kitty and Filezilla. Randomly from time to time I have something like a system freeze. As example when I want to do some file operation with filezilla the task will not start instead the system halts for couple of seconds and then successfully finishes it. What I would expect is that this is done immediately as usual. Same happens when working in terminal. Lets say I exec a script, sometimes it takes couple of seconds delay before the script will start.
This behaviour exists only since changing the hardware.
But this is not the first time having this. Before the Deskmini 310 I used a Raspberry Pi 4 and also cloned the sdcard to the nvme. Later I had to build the whole system from scratch because of another problem and the delay on the fresh install was gone.
Can someone imagine what could cause this problem? Is there maybe a fix other than building the whole system fresh?
maybe you can use the option describe on our blog post to clone/move your system Moving a running DietPi system to a USB stick/disk or an onboard eMMC – DietPi Blog Just as an idea.
The problem still persists. SSH connection drops randomly in some cases.
Before the backup restore I had no problems with SSH drops.
It’s same behaviour as with my previous rpi devices. Before restore no SSH issue after restore SSH drops in kitty on win10 or in juice ssh on android.
As example everytime when using dietpi backup connection gets lost with dietpi backup output gets stuck and only way getting back to progress is using screen to enter session again. During SSH some delay or pause happens between command input or command execute. In Filezilla SFTP commands often gets paused during file transfers but after reconnect the transfer gets finished.
Nothing in configs was changed server side nor client side.
Maybe I have to get to the server and reinstall SSH locally…
After reconnecting, any error messages within logs?
dmesg -l err,crit,alert,emerg
journalctl
Started dietpi backup and as expected after minute or so ssh droped.
The output below is what happened after backup was started I think.
Jun 28 14:14:23 xxx systemd[1]: docker.service: Succeeded.
Jun 28 14:14:23 xxx systemd[1]: Stopped Docker Application Container Engine.
Jun 28 14:14:23 xxx systemd[1]: docker.service: Consumed 17.639s CPU time.
Jun 28 14:14:38 xxx sshd[1659380]: Accepted password for root from 192.168.xxx.xxx port xxxxx ssh2
Jun 28 14:14:38 xxx sshd[1659380]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Jun 28 14:14:38 xxx systemd-logind[413]: New session 660 of user root.
Jun 28 14:14:38 xxx systemd[1]: Started Session 660 of user root.
Jun 28 14:18:21 xxx sshd[1658880]: pam_unix(sshd:session): session closed for user root
Jun 28 14:18:21 xxx systemd-logind[413]: Session 659 logged out. Waiting for processes to exit.
Jun 28 14:18:21 xxx systemd[1]: session-659.scope: Succeeded.
Jun 28 14:18:21 xxx systemd[1]: session-659.scope: Consumed 37.078s CPU time.
Jun 28 14:18:21 xxx systemd-logind[413]: Removed session 659.
The other problem with paused / delayed / interrupted console output during ssh session is hard to capture because its very random. Also the sftp transactions. In that cases the connection will not get lost. I think it auto reconnects in background…? But why doesnt it continue automatic during dietpi backup?
Hope you can use the output to maybe figure out something. 
As one of the first task dietpi-backup will stop most of services. On a default system, this will include Docker or FTP server. But it should not interrupt any SSH sessions or SSH server.
Yes I thought so but how can I debug this further?
just for clarification, the issue occurs during backup, after backup or after restoring?
before switching system the problem didnt exists.
to clearify i bought new x86 system. switched from asrock desk mini a310 to desk mini b660. cloned the 310 gen3 nvme with clonezilla (built in with dietpi) to the new gen4 nvme. after that I got these ssh drop outs.
as mentioned i had similar problem in the past when i switched from rpi4 to deskmini 310. after cloning sdcard to nvme the ssh connection had drops.
after making fresh dietpi install on 310 the ssh drops were gone.
now on b660 they are back.
something has to go wrong when cloning dietpi to another drive my guess.
when i have time i will go locally reinstall openssh and see if this solves the problem.
the dietpi-backup thing was just an example to demonstrate the problem because i know it fails every time. but the main problem for me are these randomly ssh delays that really disturb the workflow. also on such powerful machine compared to rpi it feels disappointing with these ssh hiccups
Just to avoid any misunderstanding. DietPi is not an operating system. It is a set of bash scripts built on top of a Debian base system. Depending on the device, we use different base images of Armbian, Raspbian or Debian.
This should not be possible at all, as RPI is based on ARM and the Deskmini seems to have an Intel architecture. This means that an RPI image cannot boot on this Deskmini device.
If changing the device, it is recommended to perform a new, fresh installation.
Yes you are totally right my fault. I got things mixed up a bit
On rpi i switched to bigger sdcard and had same behaviour.
On Deskmini 310 I had a fresh install and now switched to Deskmini b660 and after cloning samsung gen3 nvme to samsung gen4 nvme it started again with ssh delays and connection losts like I had it after switching to bigger sdcard.
Until now I can only reproduce the complete ssh connection lost with dietpi-backup and only happens there. Only way back is manual reconnect and reattaching with screen.
Rest of the time when working in console or sftp files the workflow gets randomly interrupted for couple of seconds until the tasks continue. Really driving me nuts but thankful no complete connection losts in this cases.
Edit: Today I got hands on the server. Reinstalled openssh but seems it makes no difference. ssh still looses connection during Dietpi-backup. Im sure the hiccups arent gone also. I have to test it further.
Maybe the filesystem gets currupted when cloning? or could it be a permission issue?
Really want to avoid a frsh install 
Well, that’s exactly the idea of cloning. Source and target should be exactly the same and should not differ. 
yes I think so but why do these sympthoms start after cloning a disk? And I wonder if Im the only one having these issues.
As expected since ssh reinstall nothing changed.
The ssh delays in normal workflow are not that major problem in fact that it’s kind of an automation when it reconnects and continues the task it self after couple of seconds. But on dietpi-backup for example its really pain in the arse everytime when backing up, ssh drops randomly and the task is nowhere in Nirvana. Only workaround still is opening a screen session before starting a backup task.
On top I did a script that starts from a selector the command “dietpi-backup 1” for kind a auto backup with last settings and without gui and afterwards the script utilizes tar to build me one archive to copy over to another machine with ease. But without screen I wouldnt even be able to quit the dietpi-backup process so my backup script can go on.
Something has to be the root of this failure…