Hosts are not ingesting, or imaging after NBP download:

Users
1

New hosts, and hosts already in MAAS that I am scheduling for re-imaging are failing at

Fetching Netboot Image
Booting under MAAS direction...
error: invalid magic number.
error: you need to load the kernel first.

Press any key to continue...

if I press any key I get to the grub/ephemeral menu, and escape out of that it starts to run the enlisting processes, and then powers the host off with no further action taken. New host are functionally ignored, not showing up in the GUI and hosts attempting deploy fail and are marked ‘failed deployment’.

I have tried

  • maas devinfra rack-controllers import-boot-images
    but that has not helped …

Suggestions would be appreciated.

thanks!
– ben.
maas version: 3.4.8-14396-g.300304e52
3.4/stable
Up-to-date - Mon, 11 Aug. 2025 20:46:46

1 Like
2

Please check the rackd logs and share them. It might be that you are trying to deploy a custom image that was uploaded in the wrong way.

3

Hi,

tailing the racks.log while one of the hosts having trouble I see:


2025-08-12 13:41:54 provisioningserver.rackdservices.tftp: [info] bootx64.efi requested by 10.250.20.125
2025-08-12 13:41:54 provisioningserver.rackdservices.tftp: [info] bootx64.efi requested by 10.250.20.125
2025-08-12 13:41:54 provisioningserver.rackdservices.tftp: [info] grubx64.efi requested by 10.250.20.125
2025-08-12 13:41:58 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/command.lst requested by 10.250.20.125
2025-08-12 13:41:58 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/fs.lst requested by 10.250.20.125
2025-08-12 13:41:58 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/crypto.lst requested by 10.250.20.125
2025-08-12 13:41:58 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/terminal.lst requested by 10.250.20.125
2025-08-12 13:41:58 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg requested by 10.250.20.125
2025-08-12 13:41:58 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg-b8:3f:d2:fd:74:ea requested by 10.250.20.125
2025-08-12 13:41:58 provisioningserver.rackdservices.http: [info] /images/custom/amd64/ga-22.04/rh810-py3/no-such-image/boot-kernel requested by 10.250.20.125

2025-08-12 13:42:32 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg-default-x86_64 requested by 10.250.20.125
2025-08-12 13:42:32 provisioningserver.rackdservices.http: [info] /images/ubuntu/amd64/ga-22.04/jammy/stable/boot-kernel requested by 10.250.20.125
2025-08-12 13:42:35 provisioningserver.rackdservices.http: [info] /images/ubuntu/amd64/ga-22.04/jammy/stable/boot-initrd requested by 10.250.20.125
2025-08-12 13:43:19 provisioningserver.rackdservices.http: [info] /images/ubuntu/amd64/ga-22.04/jammy/stable/squashfs requested by 10.250.20.125

I have 70+ hosts deployed with that rh810-py3 image, how can I verify and restore it’s functionality?

thanks!

1 Like
4

Apparently you uploaded a rhel image with base name custom/rh810-py3. You should have used rhel/rh810-py3 instead.

You can either delete/reupload the image or do a db surgery on the maasserver_bootresource table

5

I’m certainly not a DB surgeon :slight_smile:
but I would like to keep the ‘link’ for the existing hosts that are using the old custom/rh810-py3

|Redhat 8.10-py3 Custom|amd64|986.6 MB|Synced
Wed, 23 Oct. 2024 06:25:26|—|76|

any hope of finding out what changed that this image is failing to load correctly now?

6

Depends. Was version of MAAS did you use when you deployed that image successfully?

7

I have not actively changed version since we deployed with 3.4

and I have confirmed that re-uploading the image under name=‘rhel/rh810-py3x’ is able to deploy successfully

( doesn’t help systems that were deleted and now can’t re-enlist - so I’ll have to look up how to fully delete a system )

8

I made the update as recommended:
maas My_team boot-resources create name=‘rhel/rh810-py3x’ title=‘Redhat 8.10 rh810-py3x’ architecture=‘amd64/generic’ base_image=‘rhel/8’ filetype=‘tgz’ content@=rhel810-py.tar.gz

I am able to deploy the images but I do still see the alert in my logs, now referring to the new image:

2025-08-13 19:11:18 provisioningserver.rackdservices.tftp: [info] bootx64.efi requested by 10.250.20.123
2025-08-13 19:11:19 provisioningserver.rackdservices.tftp: [info] bootx64.efi requested by 10.250.20.123
2025-08-13 19:11:19 provisioningserver.rackdservices.tftp: [info] grubx64.efi requested by 10.250.20.123
2025-08-13 19:11:22 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/command.lst requested by 10.250.20.123
2025-08-13 19:11:22 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/fs.lst requested by 10.250.20.123
2025-08-13 19:11:22 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/crypto.lst requested by 10.250.20.123
2025-08-13 19:11:22 provisioningserver.rackdservices.tftp: [info] /grub/x86_64-efi/terminal.lst requested by 10.250.20.123
2025-08-13 19:11:22 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg requested by 10.250.20.123
2025-08-13 19:11:23 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg-b8:3f:d2:fd:74:ea requested by 10.250.20.123
2025-08-13 19:11:23 provisioningserver.rackdservices.http: [info] /images/rhel/amd64/ga-22.04/rh810-py3x/no-such-image/boot-kernel requested by 10.250.20.123