Deploying custom Rocky 9 image: cannot open root device: squash

During last step (machine deploy {{ item.system_id }} distro_series="custom/rocky9") I get the following error on the machine I’m deploying to.

What may be the reason for that?

I’ve checked the web server works, and machine correctly booted several times before this using other images, eg a commissioning image. I’ve also recorded a video and can extract previous logs from it if needed.

this one is pretty interesting; why might MAAS refers to rocky as no-such-image?

The no-such-image path occurs when the deployment failed, the host reboots and asks MAAS for an image to netboot. This is now a Rocky host, and MAAS doesn’t support this operation, so it cannot find a suitable image and returns this invalid path.

Please check the Installation Output in the Logs tab

1 Like

thanks, I will check the previous step!

it looks like a problem with curtin which does not like RHEL 9; I will try a patch from

there’s no need for that patch, just use rhel/8 instead. MAAS doesn’t have special handling for different RHEL versions

1 Like

I’ve changed the command to maas "{{ maas_user }}" boot-resources create name="custom/rocky9" title='Rocky 9 Custom' architecture=amd64/generic base_image="rhel/8" filetype="tgz" content@="x1/rocky9.tar.gz" and got the same curtin error

Where should I specify rhel/8?

The command line is correct. Did you re-use the same database of previous runs? If so, you need to delete the old image first (there was a bug here, the fix is not released yet)

I completely delete all virtual machines (including jumphost with MAAS) before start; let me try again

I’ve noticed via maas admin boot-resources read that the rocky9 linux image does not have the base_image value recorded

    "id": 11,
    "type": "Uploaded",
    "name": "rocky9",
    "architecture": "amd64/generic",
    "resource_uri": "/MAAS/api/2.0/boot-resources/11/",
    "subarches": "generic",
    "title": "Rocky 9 Custom"

I’ve tried replacing rhel/8 with centos/8 and got the same error mentioning Red Hat version; I wonder in which other place RHEL 9 can be hardcoded, which is later given to curtin; could it be somewhere inside rocky9.tar.gz?

Probably /etc/redhat-release.

Sorry I missed that the error was in Curtin. This is fixed but not released yet. Can you test using MAAS from the 3.4/edge channel?

I opened a bug for this:

Hi Alexsander, thanks for your help!
All works for ppa:maas/3.4-next

1 Like