No SSH response after building distribution on a cloud instance


Today I started experimenting with installing DietPi on Oracle Cloud free tier arm instances. I booted an instance using the latest Bulleye cloudgeneric-arm64 image, which I downloaded from Debian Cloud repo. After accessing the ssh, I made my distribution over PREP.

Expected behavior

  • Be able to SSH after the reboot for the first run of dietpi

Actual behaviour

  • After rebooting at the last sequence instance, it stops responding to SSH, thereby losing access to the compute instance altogether.

Extra details

  • Generic Image
  • Firmware: UEFI_64
  • Port 22 after the reboot reports closed
  • Dietpi will not respond even after accessing the instance using it’s cloud serial console


[ INFO ] DietPi-PREP | The used kernel version is:
- Linux dietpi 5.10.0-16-cloud-arm64 #1 SMP Debian 5.10.127-1 (2022-06-3 0) aarch64 GNU/Linux
[ INFO ] DietPi-PREP | The following kernel images and modules have been found:
ls: cannot access ‘/lib/modules’: No such file or directory
total 76K
drwxr-xr-x 4 root root 4.0K Aug 16 08:16 dietpi
-rw-r–r-- 1 root root 18K Aug 11 17:08 dietpi-LICENSE.txt
-rw-r–r-- 1 root root 15K Aug 11 17:08
-rw-r–r-- 1 root root 16K Aug 16 08:16 dietpi.txt
drwxr-xr-x 3 root root 16K Jan 1 1970 efi
drwxr-xr-x 5 root root 4.0K Aug 16 08:15 grub
[ OK ] DietPi-PREP | Completed, disk can now be saved to .img for later use, o r, reboot system to start first run of DietPi.
[ OK ] DietPi-PREP | To create an .img file, you can “poweroff” and run the fo llowing command from the host/external DietPi system:
- bash -c “$(curl -sSfL i/master/.build/images/dietpi-imager)”

How should I troubleshoot the installation when I lose access to SSH over the remote instance?


Does Oracle Cloud is offering some kind of web console access? Maybe you could ask Oracle Cloud guys how to access a system once SSH connection got lost

I just added this in the main post. So, I’m able to access the instance which is reporting healthy but the OS inside.

I guess you need to check if the system has network connection and if SSH service is running.

Some VPS providers ship Debian with UFW preinstalled. I’m not sure if this one does or not, but if so you might have better luck if you take it down first with ufw disable or similar.

As I understood, he finished conversation into DietPi. Means UFW should not be installed.

Oh gotcha, I did not realize the script already removes UFW.

I found the reason for this:

This happens because dietpi, for some odd reason, removes everything inside /boot/ except /efi/, /grub/ and /dietpi/ .

All important files necessary for grub including .config, initrd.img and .vmlinuz present inside /boot/ are removed after downloading an update to those. It should not remove the latest versions. When wrapping up cleaning the system towards the end it removes the old and new versions too.

I had to manually install openssh and put those files back to boot successfully.

As you can see in the “Log” I attached in the main post above, dietpi fails to find any kernel. But interrupting the PREP command in between, putting those files back and resuming the command will correctly yield the kernel found by dietpi. (I forgot to take log this time)

Now I have a working copy of dietpi on oracle ampere arm instance.

I guess @MichaIng could explain it better than I, but we don’t claim our PREP script working on each platform, cloud server or bare metal server. The script is covering the most common cases we use to build our images. Of course, there might be cases where the script is not respecting a specific package needed to be able to run on a specific environment. Especially cloud servers are quite different. :smile:

Usually for a VPS, the VM “device” would be suitable, however, it is for x86_64 only, currently. We aim to liberalize this to support any VM architecture.

When selecting “Generic Device” it is important to check which kernel and bootloader the original VPS images contains, and whether it is preserved by the dietpi-installer. It keeps all packages named linux-image-* linux-dtb-* and “u-boot” in its name, but probably for the Oracle ARM VPS this isn’t sufficient.

I can confirm debian11-cloudgeneric-amd64 works perfectly as x86_64 Virtual Device No need for any workaround and interrupting the PREP. However, I received these errors during installation; they seem to have no effect. Obviously, x86_64 is slow as compared to running on arch64.
I will await for the homebrew command to be platform agnostic in the future.
Now I have to figure out a way for dietpi to detect the ethernet controller of the instance. Any pointers that I should be looking for?

As of now we expect the Ethernet adapter to be called eth0. Available interfaces could be checked as follow

ip a