AWS EC2 Import failing at booting

Creating a bug report/issue

I am not sure this qualifies as a bug, I would like to know if anyone has successfully imported DietPi to AWS as an AMI? I am hitting a brick wall - AWS AMI import is stuck in ‘booting’ stage.

Required Information

  • DietPi version | cat /boot/dietpi/.version
    G_DIETPI_VERSION_CORE=8
    G_DIETPI_VERSION_SUB=14
    G_DIETPI_VERSION_RC=2
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’
    G_LIVE_PATCH_STATUS[0]=‘not applicable’
    G_LIVE_PATCH_STATUS[1]=‘applied’
    G_LIVE_PATCH_STATUS[2]=‘applied’

  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    bullseye

  • Kernel version | uname -a
    Linux DietPi 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux

  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    Virtual Machine (x86_64)

  • Power supply used | (EG: 5V 1A RAVpower)
    Virtual machine

  • SD card used | (EG: SanDisk ultra)
    Virtual machine

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
    n/a

  • Was the software title installed freshly or updated/migrated?
    N/a

  • Can this issue be replicated on a fresh installation of DietPi?
    Yes

← If you sent a “dietpi-bugreport”, please paste the ID here →

  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

Download - import and export to vmdk/ovf, import to AWS.

Expected behaviour

AMI to load the image.

Actual behaviour

Stuck/blocked at ‘booting’ phase of AWS image import.

Extra details

1 Like
{
    "ImportImageTasks": [
        {
            "Architecture": "x86_64",
            "Description": "My server VM",
            "ImportTaskId": "import-ami-xxx",
            "LicenseType": "BYOL",
            "Platform": "Linux",
            "Progress": "39",
            "SnapshotDetails": [
                {
                    "Description": "DietPi",
                    "DeviceName": "/dev/sda1",
                    "DiskImageSize": 300255744.0,
                    "Format": "VMDK",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "my-bucket",
                        "S3Key": "vms/the.vmdk
                    }
                }
            ],
            "Status": "active",
            "StatusMessage": "booting",
            "Tags": [],
            "BootMode": "legacy_bios"
        }
    ]
}

Stuck like this for ~ 90 minutes.

As an alternative option, did you tried to get a plain Dabian image up? This way you could try to run our install script. It might be better compared to our VM images.

Hey @Joulinar ,

I hope this message finds you well, I truly appreciate your rapid response.

I dug around - not well enough :sweat_smile: - for a DietPi install script but could not find one. I will go this route and build up a Debian 11 instance, an excellent distro, I truly enjoy it.

The blocker for the VMWare/Virtualbox imports was the network - I did not dig deep but the image imports are failing at the network level and I wonder if there is a condition I am missing with the import. Other distros import without fail and network is not a problem.

I will build this out now and let you know if the distro boots as expected - I suspect it will.

Thank you!

Hey @Joulinar,

An update on your recommendation, the install script works great - there is one caveat, I received three errors surrounding /etc/default/grub:

[FAILED] File does not exist or cannot be written to by current user                               ││                                                                                                    ││ Please verify the existence of the file $3                                                         ││         /etc/default/grub                                                                          ││                                                                                                    ││ Retry with proper permissions or apply the setting manually:                                       ││         GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0"   

 [FAILED] File does not exist or cannot be written to by current user                               ││                                                                                                    ││ Please verify the existence of the file $3                                                         ││         /etc/default/grub                                                                          ││                                                                                                    ││ Retry with proper permissions or apply the setting manually:                                       ││         GRUB_CMDLINE_LINUX="net.ifnames=0" 

[FAILED] File does not exist or cannot be written to by current user                               ││                                                                                                    ││ Please verify the existence of the file $3                                                         ││         /etc/default/grub                                                                          ││                                                                                                    ││ Retry with proper permissions or apply the setting manually:                                       ││         GRUB_TIMEOUT=0 

How important are these grub rules and I should I include them in the bootloader file?

I look forward to your response, thank you in advance.

Not 100% sure, maybe @MichaIng knows. Does the system is booting fine?

Hi @Joulinar,

Thanks for the rapid response - the system is booting fine and works as expected.

I will clone and add the grub boot rules to another instance and retest.

ok perfect

Yeah our install script is quite generic if it comes to VPS provider. Not that easy to cover each and every setup existing. But good your system is working :slight_smile:

Probably GRUB is not used by this VPS but another bootloader, or even an external one. Our script and images for x86_64 always install/ship with GRUB.

Another thing that may be enhanced is the kernel:

  • We always install linux-image-amd64
  • For AWS EC2 and other VPS services there is however a tailored linux-image-cloud-amd64.

@Joulinar / @MichaIng ,

Thank you both for the weigh-in.

Joulinar, yes the script is generic but it should not be discounted - it is a great unbloated distro and I thank you all for taking the time to spin this up/maintain it!

Michalng, the EC2 instance is grub boot loaded and I believe the grub config changes are not necessary - the distro is running wonderfully on two instances.

FYI, I tried to run the install script on Windows Debian 11 enviro and ran into a few errors - I do not want to discuss them here, that is a new topic and simply want to point it out.

If you want to support Windows Debian 11 enviros try to run the install script. WSL is certainly not supported.

1 Like

An issue might be that we replace the GRUB device path with /dev/sda, so it works OOTB in most cases when generated on a different device or in container with /dev/loopX device.

How is the root device path/name?

echo "$G_ROOTFS_DEV"

Hi Team,

Excuse my late response.

echo “$G_ROOTFS_DEV” returns: /dev/xvda1