Setting Up Manjaro for use with DigitalOcean

Support
1

Essentially, I’m trying to use the “Custom Image” feature on DigitalOcean to create a Manjaro server (reason being latest package versions for a personal project) from an Architect CLI installation to a VM.

DO has some requirements for custom images (https://www.digitalocean.com/docs/images/custom-images/):

Image has to be in an acceptable format: Done, I’ve used VirtualBox to create a VDI.
Size: Done. It’s far less than 100GB. The compressed upload is only around 1GB.
Filesystem: Done. I used ext4 during the VM setup.
SSH: Done. All set up, functioning, and launching at boot.

cloud-init is where I’m entering somewhat foreign territory. I modified the Ubuntu instructions as needed for Manjaro from here (How to Create a DigitalOcean Droplet from an Ubuntu ISO Format Image | DigitalOcean) removed the previous config files, replaced the datasource_list with datasource_list: [ ConfigDrive, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, SmartOS, None, NoCloud ] made sure cloud-init was enabled with systemctl, and ran the clean command for cloud-init.

This all appears to work. So, I shutdown the VM, gzip it, and upload to DO. But, after uploading the image to DO and trying to create a new droplet from it, I am immediately dropped to an emergency shell because it cannot find the rootfs. I must have done something partially right here, because I see it is the latest manjaro kernel. But, it won’t go anywhere beyond the emergency shell.

I’ve looked at https://wiki.archlinux.org/index.php/Cloud-init but I don’t see anything there that would help me out. I did even try this with the growpart AUR package to see if maybe that was why my filesystems weren’t being loaded, but that didn’t seem to change anything either.

Perhaps someone that knows more about cloud-init could point me in the right direction here? I know that there is an image-bootstrap project that creates OpenStack Arch images that work with DO (tested myself.) So, Manjaro should work, I just can’t figure out which part I’m missing here.

2

Running a cloud instance is usually only to provide network services - - no xorg - so you can achieve the same thing using an Arch image as base.

I have been setting up Linode and Hetzner instances using Arch images without very much fuzz.

Just remember three things

  • change ssh port
  • use public key auth
  • setup firewalld

On a side note - don’t use efi - it usually don’t work for cloud instances.

3

Yes, it will only be providing network services, and yes, the experimental Arch image from image-bootstrap does work. But, I’m not really looking to run straight Arch, I was looking to run Manjaro.

The SSH ports are changed, key auth is being used, and a firewall is in place.

I also used MBR when setting up the partition table. (I also used labeled/named mount points rather than UUID.)

I want to know where I’m going wrong with cloud-init when it comes to it not properly running/detecting my filesystems when trying to start new servers using the image.

4

I can think of a couple of possible solutions - they are ideas for that is worth :slight_smile:

Your problem is connected to the fact that your image is used as a template - which will create a new UUID upon creating by cloud provider - so to ensure the boot setup works as expected you will need to ensure the boot sequence can locate the root device.

Your droplet is fairly predictable when it comes to the disk device - it will unless very unusual circumstance - be /dev/sda

One possibility - one can use the /etc/grub/default and uncomment the line

#GRUB_DISABLE_LINUX_UUID=true

Another possibility is to label your root partition MJROROOT and use the GRUB_CMDLINE_LINUX_DEFAULT to set the root like this - you will obviously also be able to set root=/dev/sdaX - depending if you used MBR or GPT scheme for your disk layout.

GRUB_CMDLINE_LINUX_DEFAULT="root=LABEL=MJROROOT"

You can also use GPT - just remember to create a small unformatted partition of type 0xEF02 (BIOS Boot partition) - just install grub as usual

# grub-install --target=i386-pc /dev/sda

2020-12-09T17:23:00Z
NOTE EDIT: Just a thought - what is device naming on the droplet?

I mean - some providers use virtual device names like vdXy - which would make your disk configuration in your VM invalid.

Did you setup cloud-configure to configure the disk layout? Such as in /etc/cloud/cloud.cfg disk_setup: - as far as I can see there is no default settings related to disk setup - which would explain why you image fails.

Examples