DietPi Restore from metal to VM

eyduh · February 2, 2021, 6:06pm

Hiya,

I installed DietPi on the metal for a UEFI x64 media-server setup then realised I wanted to have some separation between functions of this little server. So I did a backup, installed Proxmox VE and setup a DietPi VM on proxmox. I thought I could just restore the backup to the VM but, alas, no.

When I do restore it fails after quite some time, but I find it hard to interpret where the error lies.

The bare-metal backup had lidarr/radarr/sonarr/bazarr/jellyfin as well some some bits and bobs like vim/git/pip and docker/portainer for flaresolverr. After the “failed” restore I checked what was on there and most things seemed there & ‘working’ (according to dietpi-services) except PHP was failing to start.

I tried to reboot thinking maybe php would come online but instead it failed to boot.

So I tried again, this time I moved /boot out of the backup so keep the one there intact but instead dietpi-backup deleted the existing /boot.

Any suggestions where to start troubleshooting?

edit:
I tried again, this time excluding /boot using the settings in dietpi-backup and I ended up with a sucessful restore according to dietpi-backup. After I rebooted I checked dietpi-services with everything failing to start because root has been mounted in r/o…

eyduh · February 11, 2021, 3:44pm

Ok so here we go again:

After the last restore with

/etc/fstab
/boot

in the backup/restore filters It seemed to work, no error messages etc. I manged to reboot but ofc all the services didn’t work. Many of them threw an error about a missing /var/log/application folder but I also noticed that they weren’t in the “uninstall” list in DietPi-Software so tried again from scratch. But not before getting the list of programs from dietpi-services!

This time I installed DietPi, then installed all the programs, after which I added the backup/restore drive from drive, added the exclusions and…

Now I’m getting a bunch of exec-format errors which is strange because the backup and restore are both on an x64 system… back to te drawing board.

Joulinar · February 11, 2021, 8:19pm

Hi,

just a side note. DietPi is keeping information about installed program inside following file /boot/dietpi/.installed. It’s a plain txt file that can be adjusted manually.

eyduh · February 12, 2021, 6:00pm

a side note. DietPi is keeping information about installed program inside following file /boot/dietpi/.installed. It’s a plain txt file that can be adjusted manually.

Cool! Did not know this.

Turns out the exec format errors was from accidentally overwriting the dietpi-backup folder with another system’s backup. I had a dietpi-sync of the backup I wanted to restore so just swapped the data folders and it worked fine.

The problem I’m having now is that all the webservices that require nginx fail because nginx fail with the errors:

┌─────────────────────────────────────┤ DietPi-Services | File viewer ├──────────────────────────────────────┐
│                                                                                                            │
│ ● nginx.service - A high performance web server and a reverse proxy server                                 │
│    Loaded: loaded (/lib/systemd/system/nginx.service; disabled; vendor preset: enabled)                    │
│    Active: failed (Result: exit-code) since Fri 2021-02-12 18:43:53 CET; 2min 20s ago                      │
│      Docs: man:nginx(8)                                                                                    │
│   Process: 3236 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited,          │
│ status=1/FAILURE)                                                                                          │
│                                                                                                            │
│ Feb 12 18:43:53 OlDiet systemd[1]: Starting A high performance web server and a reverse proxy server...    │
│ Feb 12 18:43:53 OlDiet nginx[3236]: nginx: [alert] could not open error log file: open()                   │
│ "/var/log/nginx/error.log" failed (2: No such file or directory)                                           │
│ Feb 12 18:43:53 OlDiet nginx[3236]: 2021/02/12 18:43:53 [emerg] 3236#3236: open()                          │
│ "/var/log/nginx/error.log" failed (2: No such file or directory)                                           │
│ Feb 12 18:43:53 OlDiet nginx[3236]: nginx: configuration file /etc/nginx/nginx.conf test failed            │
│ Feb 12 18:43:53 OlDiet systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE    │
│ Feb 12 18:43:53 OlDiet systemd[1]: nginx.service: Failed with result 'exit-code'.                          │
│ Feb 12 18:43:53 OlDiet systemd[1]: Failed to start A high performance web server and a reverse proxy       │
│ server.                                                                                                    │
│                                                                                                            │
│                                                   <Ok>                                                     │
│                                                                                                            │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

I tried just making an empty /var/log/nginx/error.log manually but it disappeared on a reboot, along with all the other ones that threw this error message (the *arr ones, jellyfin, etc)

Do I need to change some log related setting somewhere?

If I do make one manually it works fine:

root@DietPi:/etc/nginx# vim /var/log/nginx/error.log
root@DietPi:/etc/nginx# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
root@DietPi:/etc/nginx# dietpi-services restart

 DietPi-Services
─────────────────────────────────────────────────────
 Mode: restart 

[  OK  ] DietPi-Services | restart : nmbd
[  OK  ] DietPi-Services | restart : smbd
[  OK  ] DietPi-Services | restart : php7.3-fpm
[  OK  ] DietPi-Services | restart : nginx
[  OK  ] DietPi-Services | restart : transmission-daemon
[  OK  ] DietPi-Services | restart : qbittorrent
[  OK  ] DietPi-Services | restart : rtorrent
[  OK  ] DietPi-Services | restart : nzbget
[  OK  ] DietPi-Services | restart : deluged
[  OK  ] DietPi-Services | restart : jellyfin
[  OK  ] DietPi-Services | restart : medusa
[  OK  ] DietPi-Services | restart : aria2
[  OK  ] DietPi-Services | restart : sabnzbd
[  OK  ] DietPi-Services | restart : jackett
[  OK  ] DietPi-Services | restart : sonarr
[  OK  ] DietPi-Services | restart : radarr
[  OK  ] DietPi-Services | restart : lidarr
[  OK  ] DietPi-Services | restart : bazarr
[  OK  ] DietPi-Services | restart : htpc-manager
[  OK  ] DietPi-Services | restart : deluge-web
[  OK  ] DietPi-Services | restart : syncthing
[  OK  ] DietPi-Services | restart : docker
[  OK  ] DietPi-Services | restart : cron
root@DietPi:/etc/nginx#

Except it doesnt:

# dietpi-services status radarr

 DietPi-Services
─────────────────────────────────────────────────────
 Mode: status radarr

[FAILED] DietPi-Services | ● radarr.service - Radarr Daemon (DietPi)
   Loaded: loaded (/etc/systemd/system/radarr.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2021-02-12 19:02:27 CET; 2min 6s ago
  Process: 5102 ExecStart=/opt/radarr/Radarr -nobrowser -data=/mnt/dietpi_userdata/radarr (code=exited, status=226/NAMESPACE)
 Main PID: 5102 (code=exited, status=226/NAMESPACE)

Feb 12 19:02:27 OlDiet systemd[1]: radarr.service: Main process exited, code=exited, status=226/NAMESPACE
Feb 12 19:02:27 OlDiet systemd[1]: radarr.service: Failed with result 'exit-code'.
Feb 12 19:02:27 OlDiet systemd[1]: radarr.service: Service RestartSec=100ms expired, scheduling restart.
Feb 12 19:02:27 OlDiet systemd[1]: radarr.service: Scheduled restart job, restart counter is at 5.
Feb 12 19:02:27 OlDiet systemd[1]: Stopped Radarr Daemon (DietPi).
Feb 12 19:02:27 OlDiet systemd[1]: radarr.service: Start request repeated too quickly.
Feb 12 19:02:27 OlDiet systemd[1]: radarr.service: Failed with result 'exit-code'.
Feb 12 19:02:27 OlDiet systemd[1]: Failed to start Radarr Daemon (DietPi).

It seems the errors I got last time are all the same and not related to what was installed on the system before the restore.

# dietpi-services status jellyfin

 DietPi-Services
─────────────────────────────────────────────────────
 Mode: status jellyfin

[FAILED] DietPi-Services | ● jellyfin.service - Jellyfin Media Server
   Loaded: loaded (/lib/systemd/system/jellyfin.service; disabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/jellyfin.service.d
           └─jellyfin.service.conf
   Active: failed (Result: signal) since Fri 2021-02-12 18:44:01 CET; 13min ago
  Process: 3952 ExecStart=/usr/bin/jellyfin ${JELLYFIN_WEB_OPT} ${JELLYFIN_RESTART_OPT} ${JELLYFIN_FFMPEG_OPT} ${JELLYFIN_SERVICE_OPT} ${JELLYFIN_NOWEBAPP_OPT} (code=killed, signal=ABRT)
 Main PID: 3952 (code=killed, signal=ABRT)

Feb 12 18:44:01 OlDiet systemd[1]: jellyfin.service: Main process exited, code=killed, status=6/ABRT
Feb 12 18:44:01 OlDiet systemd[1]: jellyfin.service: Failed with result 'signal'.
Feb 12 18:44:01 OlDiet systemd[1]: jellyfin.service: Service RestartSec=100ms expired, scheduling restart.
Feb 12 18:44:01 OlDiet systemd[1]: jellyfin.service: Scheduled restart job, restart counter is at 5.
Feb 12 18:44:01 OlDiet systemd[1]: Stopped Jellyfin Media Server.
Feb 12 18:44:01 OlDiet systemd[1]: jellyfin.service: Start request repeated too quickly.
Feb 12 18:44:01 OlDiet systemd[1]: jellyfin.service: Failed with result 'signal'.
Feb 12 18:44:01 OlDiet systemd[1]: Failed to start Jellyfin Media Server.

or

# dietpi-services status sonarr

 DietPi-Services
─────────────────────────────────────────────────────
 Mode: status sonarr

[FAILED] DietPi-Services | ● sonarr.service - Sonarr Daemon (DietPi)
   Loaded: loaded (/etc/systemd/system/sonarr.service; disabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/sonarr.service.d
           └─dietpi-process_tool.conf, dietpi-services_edit.conf
   Active: failed (Result: exit-code) since Fri 2021-02-12 19:02:27 CET; 2min 37s ago
  Process: 5098 ExecStart=/usr/bin/mono -O=-aot /opt/NzbDrone/NzbDrone.exe -nobrowser -data=/mnt/dietpi_userdata/sonarr (code=exited, status=226/NAMESPACE)
 Main PID: 5098 (code=exited, status=226/NAMESPACE)

Feb 12 19:02:27 OlDiet systemd[1]: sonarr.service: Main process exited, code=exited, status=226/NAMESPACE
Feb 12 19:02:27 OlDiet systemd[1]: sonarr.service: Failed with result 'exit-code'.
Feb 12 19:02:27 OlDiet systemd[1]: sonarr.service: Service RestartSec=100ms expired, scheduling restart.
Feb 12 19:02:27 OlDiet systemd[1]: sonarr.service: Scheduled restart job, restart counter is at 5.
Feb 12 19:02:27 OlDiet systemd[1]: Stopped Sonarr Daemon (DietPi).
Feb 12 19:02:27 OlDiet systemd[1]: sonarr.service: Start request repeated too quickly.
Feb 12 19:02:27 OlDiet systemd[1]: sonarr.service: Failed with result 'exit-code'.
Feb 12 19:02:27 OlDiet systemd[1]: Failed to start Sonarr Daemon (DietPi).

Another oddity is that there’s no nginx config files for anything but rutorrent in /etc/nginx/sites-dietpi

root@DietPi:/etc/nginx# tree 
.
├── conf.d
├── fastcgi.conf
├── fastcgi_params
├── koi-utf
├── koi-win
├── mime.types
├── modules-available
├── modules-enabled
│   └── 50-mod-http-echo.conf -> /usr/share/nginx/modules-available/mod-http-echo.conf
├── nginx.conf
├── nginx.conf.bak_300121_0
├── proxy_params
├── scgi_params
├── sites-available
│   └── default
├── sites-dietpi
│   └── dietpi-rutorrent.conf
├── sites-enabled
│   └── default -> /etc/nginx/sites-available/default
├── snippets
│   ├── fastcgi-php.conf
│   └── snakeoil.conf
├── uwsgi_params
└── win-utf

7 directories, 17 files

I had a few things that I needed to seed on this box and that aspect works now so might just uninstall everything not needed for that purpose. It has been a fun experiment trying to migrate a system from metal to proxmox but setting things up from scratch is probably faster even though I will have to setup the different *arr things again.

Edit: of course the last ditch effort to make things work before giving up made it all work:

basically, I found where to change the log level to the same setting as the bare metal install before the migration, set it up and made folders for all the installed applications in /var/log, restarted the services and voila! workiework!!

I’ll write this up in a neat little thing some day soon with like what gotchas to watch out for maybe

Joulinar · February 12, 2021, 8:19pm

Hi,

/var/log is a temp file system.

tmpfs            50M   20K   50M   1% /var/log

MichaIng
Can you have a look? I’m not 100% sure on the mechanism to keep at least directories on /var/log on a reboot

eyduh · February 12, 2021, 10:52pm

I found it under an expandable menu here:

https://dietpi.com/docs/software/log_system/#full-logging

How do I set the Log System ?

To select the Log System listed below run from the command line:

dietpi-software

Choose Log System and select the desired item. Finally click on Install. DietPi will do all the necessary steps to change to the desired log system.

DietPi-Software Log System menu screenshot

I knew I had seen it before somewhere but kept looking under dietpi-config or launcher before I just searched the docs for “log”

Now the restore works (mostly)! I did a reboot and the previous bare metal install is now a virtual dietpi under qemu/kvm on proxmox c:

I did have some errors in jellyfin that I have to investigate further, but radarr/sonarr/lidarr/bazarr/transmission/jackett seems to work. I’ll investigate jellyfin and see if flaresolverr (docker deployment) still works.

MichaIng · February 13, 2021, 4:18pm

Even with /var/log in RAM, dietpi-ramlog.service should restore the directory and file structure from /var/tmp/dietpi/logs/dietpi-ramlog_store/ with empty files but correct permissions etc. This is the way how RAMlog can even work, as otherwise every reboot would break service starts that depend on /var/log/ file logging. However, this store directory is created on shutdown, so if you install software and run the backup directly without a reboot, it’s missing. You can force the creation of this RAMlog store as well via: /boot/dietpi/func/dietpi-ramlog 1

If it still does not work, then the service must have failed on boot: systemctl status dietpi-ramlog

TL;DR: DietPi-Backup is not made to migrate DietPi systems from one machine to a different one.
To do it right, start with an at best minimal Debian install on the VM and follow these instructions to turn it into a DietPi system: https://dietpi.com/docs/hardware/#make-your-own-distribution
Then install software inside the VM so that it is correctly detected and treated as a VM, not as a physical PC.

Restoring a backup from one system to a different/new system is naturally not a safe thing:

File systems have UUIDs, which are baked into bootloader configs and fstab. This is the reason why you needed to exclude /boot and /etc/fstab. However, now grub files installed elsewhere on the system do not match the the ones in /boot/grub anymore, which might cause other issues. Also you excluded all DietPi scripts, configs and status files, which is probably the reason why the RAMlog service failed and might cause other issues. So /boot/dietpi + /boot/dietpi.txt would need to be re-included at least.
Depending on how the VM works, the bootloader flashed to the virtual disk file outside of the file system(s) might not match the information stored elsewhere on the system, which might or might not cause issues.
Other device and interface infos, stored on the root file system might not match, as VM hardware and/or detection order might differ from the physical PC’s.
The type of machine, stored in /etc/.dietpi_hw_model_identifier, does not match anymore (VM vs PC).

To make things slightly more stable, at least you would need to reflash/reinstall the bootloader, if it’s even used by that virtualiser, e.g.: apt install --reinstall grub-efi-amd64
But the other things and likely more stay in an inconsistent stage, which would require a lot of manual edits to solve.