This was previously posted and ‘closed’ with a solution so I was unable to reply to that posting. The solution posted does not work.
There are multiple servers that need to boot from their internal hard drives and not from PXE/MAAS. How-ever I do not want to turn off PXE as this is a fall back solution if the drives fail or troubleshooting is needed on the server.
I took a server that was not in MAAS and I rebooted and it went into a PXE boot and then enlisted in MAAS, which is supposed to be turned off. Is there any option for this? I was hoping I could add it as a ‘device’ and MAAS would ignore it. But that does not work either.
Hi @kbm1, I was never able to find a solution for this either, the ticket was closed before I was able to test the proposed solution. Now that I have tested it, it does not work. We’re currently working around the unexpected power offs by only pointing boot options at MaaS for individual machines, rather than for the entire Subnet, so that machines are not PXE booted off of MaaS unintentionally, without first being added.
I am facing a similar case as mentioned in this thread.
In my case, we have a hardware automation stage (eg: firmware upgrade) that gets run before a machine gets added in maas.
In-order to make sure machines don’t come under maas umbrella, I am disabling PXE boot in Network Interface settings as part of the hardware automation task list. This works fine on machines which was/is not managed by maas and have PowerState = ON. I have a handful of machines with PXEBootState = enabled and PowerState = OFF. Every time our automation tries to PowerOn the machine to set PXEBootState = disabled, maas Powers Off the machine :-(.
MaaS version is 3.2.11 (setup via apt). I also have ‘enlist_commissioning=false’, but as per the document
enlist_commissioning: Whether to run commissioning during enlistment… Enables running all built-in commissioning scripts during enlistment.
What I can see is, during the enlistment stage the only script that gets executed is 30-maas-01-bmc-config , which adds the machine in MaaS db followed by its Power management.
@benhunt Would appreciate a status update on the work being done to handle the unexpected power off scenarios.
I am not on the Canonical team. As I mentioned in my update, the ticket was closed without being addressed, and this issue still presents challenges for us in our environment. We try to work around the behavior described by not pointing the machine’s DHCP boot options at MaaS until we are ready to commission and reimage it. If you would like to re-open a ticket on the issue, please copy it here and I am happy to voice my support for the issue.
