Installing DietPi on OpenVZ VPS

Creating a bug report/issue

Required Information

  • Kernel version | Linux 4.19.0 #1 SMP Thu Dec 15 20:31:06 MSK 2022 x86_64 GNU/Linux
  • Architecture | amd64
  • SBC model | ethernetservers OpenVZ VPS

Additional Information (if applicable)

  • Software title | dietpi-installer
  • Was the software title installed freshly or updated/migrated?
  • Can this issue be replicated on a fresh installation of DietPi?

Steps to reproduce

  1. Login to VPS via ssh and then executing the dietpi-installer script

Expected behaviour

dietpi installs without disconnecting from ssh and then i get a dietpi os on my vps

Actual behaviour

it hangs after it removes ifupdown package and i have to reinstall the debian image.

Extra details

i managed somehow to make it work but it is because i chose the container image and what happens is mawk didnt work and it didnt autopurge the apt packages.

when i tried to install mawk before installation, the same thing happens. it autopurges ifupdown and then it hangs and i have to reinstall the debian image.

Did you tried to reinstall mawk after conversion into DietPi finished?

yes i did. but it didn’t change much. my problem is not after the installation. its before.

the installation is sort of successful is because mawk wasn’t there so the apt autopurge command didnt run and delete ifupdown when i picked the Container Image selection. i already tried installing mawk before the installation and picking the same options and the result that it autopurges ifupdown resulting in a hang because the ssh connection is broken.

after installing mawk

Just to avoid a misunderstanding. We are not able to support/guarantee our install script working on each and every VPS available on the market. For some, workarounds are needed.

no misunderstanding. i’m just letting you guys know my problem and hopefully there will be a solution to this. granted this workaround is not pretty rn but i hope in the future me or anyone else wouldnt encounter this.

it’s up to @MichaIng as our developer to decide if he like to invest into such special case or not.

A VPS is not a container but a VM. So choose “Virtual Machine” and all should be good.

The container ID is currently used by us in combination with systemd-container for software builds and tests. And this container engine by default uses the host’s network directly, hence does not need any own network stack. It is planned to add a selection or dedicated hardware ID for containers with own network stacks. But it would still not be working for a VPS, which requires a bootloader and a kernel, both removed and not required for container images.

The missing mawk is very strange. It is part of a debootstrap base installation, pulled in as (one of three possible) dependency of base-files and has “required” priority, so that it is never autoremoved. However, it can be indeed manually removed if either gawk or original-awk is installed, which both as well satisfy the base-files dependency. So we should install mawk explicitly and autoremove any of the other two, if installed.
EDIT: Done: v8.19 · MichaIng/DietPi@745d09a · GitHub

Btw, the kernel seems to be pretty outdated and not the Debian kernel. The server itself was on an OpenVZ VPS in the past, so I am pretty sure it works very well with the Debian kernel, which is Linux 5.10 on Bullseye and 6.1 on Bookworm (which i would recommend now that it has been released).

Thank you for taking the time to fix the issue. i tried to install dietpi again on another OpenVZ VPS by different provider, but i got the same thing happened to me. this particular vps is idling as of now and i dont use them because they can’t open the fuse module in the kernel. i can provide the login to the vm panel and ssh login if you want to investigate further into this issue.

when it removes ifupdown you lose connection. Maybe you can run the script in background? (not sure if this will work, maybe it’s interactive :thinking:)

You must use the installer from the Dev branch, as the above correction has not yet been applied to the Master branch.

1 Like