mysterious proxmox installation issue

[zahnfee]

Hi,

I ran into this strange installation issue after my root disk died and I installed to a new disk.

I believe the main issue is that I have /var mounted to a separate disk and after the base debian-12 installation, I restored some files from backup,
including the /etc/fstab, which mounted the /var to the new installation.

Problem here: the cached files on that filesystem make apt believe that stuff is installed, which really is not.

This means that installing proxmox as I did originally did not work as expected.

My workaround is to install all packages with option --reinstall (I have an identical hot stand-by system, which serves as source):

while read -r pack; do apt install --reinstall -y "$pack"; done < /tmp/packages.txt | tee /tmp/apt-install.log

However this does not seem to reinstall the systemd files (ceterum censeo systemd esse delendam).

This is how it is:

/etc/systemd/system# ls -al
total 32
drwxr-xr-x 8 root root 4096 Apr 30 18:12 .
drwxr-xr-x 5 root root 4096 May  1 18:05 ..
lrwxrwxrwx 1 root root   45 Apr 30 18:12 dbus-org.freedesktop.timesync1.service -> /lib/systemd/system/systemd-timesyncd.service
drwxr-xr-x 2 root root 4096 Apr 30 18:07 getty.target.wants
drwxr-xr-x 2 root root 4096 May  1 16:37 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Apr 30 18:07 network-online.target.wants
drwxr-xr-x 2 root root 4096 Apr 30 18:08 sockets.target.wants
lrwxrwxrwx 1 root root   31 Apr 30 18:08 sshd.service -> /lib/systemd/system/ssh.service
drwxr-xr-x 2 root root 4096 Apr 30 18:12 sysinit.target.wants
drwxr-xr-x 2 root root 4096 Apr 30 18:12 timers.target.wants

and this is how it should be (from working hot stand-by):

drwxr-xr-x 15 root root 4096 Apr 10 09:57 .
drwxr-xr-x  5 root root 4096 Feb 19 18:03 ..
-rw-r--r--  1 root root  376 Apr 10 09:57 calibre-server.service
drwxr-xr-x  2 root root 4096 Jan 17 14:36 ceph.target.wants
lrwxrwxrwx  1 root root   34 Jan 24 16:45 chronyd.service -> /lib/systemd/system/chrony.service
lrwxrwxrwx  1 root root   45 Jan 11 12:10 dbus-org.freedesktop.timesync1.service -> /lib/systemd/system/systemd-timesyncd.service
drwxr-xr-x  2 root root 4096 Jan 17 14:36 getty.target.wants
lrwxrwxrwx  1 root root   38 Jan 17 14:35 iscsi.service -> /lib/systemd/system/open-iscsi.service
-rw-r--r--  1 root root  533 Feb 21 15:09 minidlna.service
drwxr-xr-x  2 root root 4096 Mar 11 18:20 minidlna.service.d
drwxr-xr-x  2 root root 4096 Apr  9 17:00 multi-user.target.wants
drwxr-xr-x  2 root root 4096 Jan 11 12:04 network-online.target.wants
-rw-r--r--  1 root root  671 Feb 13 09:37 openvpn-client@.service
drwxr-xr-x  2 root root 4096 Feb 23 14:19 openvpn-client@service.service.d
lrwxrwxrwx  1 root root   38 Jan 17 14:36 pve-manager.service -> /lib/systemd/system/pve-guests.service
drwxr-xr-x  2 root root 4096 Jan 17 14:36 remote-fs.target.wants
lrwxrwxrwx  1 root root   41 Jan 17 14:35 smartd.service -> /lib/systemd/system/smartmontools.service
drwxr-xr-x  2 root root 4096 Feb 15 17:04 sockets.target.wants
lrwxrwxrwx  1 root root   31 Jan 11 12:08 sshd.service -> /lib/systemd/system/ssh.service
drwxr-xr-x  2 root root 4096 Jan 17 14:36 sysinit.target.wants
lrwxrwxrwx  1 root root   35 Feb  1 16:23 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x  2 root root 4096 Apr 29 16:37 timers.target.wants
lrwxrwxrwx  1 root root   34 Feb  1 16:23 ulogd.service -> /lib/systemd/system/ulogd2.service
lrwxrwxrwx  1 root root   35 Jan 17 14:35 zed.service -> /lib/systemd/system/zfs-zed.service
drwxr-xr-x  2 root root 4096 Jan 17 14:35 zfs-import.target.wants
drwxr-xr-x  2 root root 4096 Jan 17 14:35 zfs.target.wants
drwxr-xr-x  2 root root 4096 Jan 17 14:35 zfs-volumes.target.wants

Any suggestions other that reinstalling again (I'm afraid the /var filesystem is messed up now and needs some tlc)???

kind regards,

z.

 

[zahnfee]

I solved my problem by unmounting the /var disk and using apt-clone to transfer all packages from the stand-by to the main system.
This worked just fine and I just need to restore the configs from backup.
dpkg --verify shows consistency and after a reboot port 8006 is listening again.

I will now have to consolidate the new /var and the original /var (some container files are there).

Any advice on caveats during container/vm restauration?

kind regards,

z.