improperly telling systems to sanboot

[Bret Wortman]

I found the code in boot_local.erb that is responsible for some of our DL380s trying to sanboot, which just doesn't work. I removed it and now everything we've set up with Razor (so far) works just hunky-dory.

Is there a better way to make this code mod so that I don't have to re-do it when we upgrade next? I'm pretty sure I just need to define something different in tasks/common but am not exactly sure how to proceed and would rather not break everything before I do.

What I _think_ I need to do:

1. Write a new file, say our_boot_local.erb, copied from boot_local.erb but with the above code removed or modified.
2. Change my centos task to have a boot_seq where 2 -> our_boot_local.

Is that really it?

Bret

[Scott McClellan]

Hi Bret,

On Fri, May 20, 2016 at 5:55 AM, Bret Wortman <br...@thewortmans.org> wrote:

I found the code in boot_local.erb that is responsible for some of our DL380s trying to sanboot, which just doesn't work. I removed it and now everything we've set up with Razor (so far) works just hunky-dory.

Can you elaborate on the error(s) you are seeing with this? I'd be happy to change it in our stock code if it's a pervasive problem, though this is the first I have heard about it. Our reason for using sanboot is likely from this line here:

You can use the sanboot command to boot from a local disk drive without exiting iPXE. This can be useful if BIOS bugs prevent you from being able to cleanly exit iPXE.

Is there a better way to make this code mod so that I don't have to re-do it when we upgrade next? I'm pretty sure I just need to define something different in tasks/common but am not exactly sure how to proceed and would rather not break everything before I do.

What I _think_ I need to do:

1. Write a new file, say our_boot_local.erb, copied from boot_local.erb but with the above code removed or modified.
2. Change my centos task to have a boot_seq where 2 -> our_boot_local.

Is that really it?

There is a simpler method. First, look at the value of your `task_path` variable in your config.yaml file. For ease of upgrades, we recommend keeping the /opt path intact on disk, but add, prior to that, a directory (or multiple) *prior* to that. So your task_path should be something like:

task_path: /etc/puppetlabs/razor-server/tasks:tasks

This example will look in /etc/puppetlabs/razor-server/tasks before the stock `tasks` folder. With that, you can create any overrides and new tasks there as long as the folder structure mirrors the stock task. So you'd copy the stock boot_local.erb and edit it in this path:

/etc/puppetlabs/razor-server/tasks/common/boot_local.erb

When Razor reaches for the `boot_local` step, it will pull from this new /etc path first.

Bret

Scott 

--
You received this message because you are subscribed to the Google Groups "puppet-razor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-razor...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-razor.
For more options, visit https://groups.google.com/d/optout.

[Bret Wortman]

What's happening for us is that some DL380s, when booting after installation, go through the PXE process and the sanboot 0x80 code is triggered, even though that's not how we want these systems to boot (and, in fact, they'll just hang there indefinitely if they do). Why is this happening? No clue. I'm not entirely sure what the sanboot 0x80 is supposed to do for us. I know some systems may require it, but it completely hoses our DL380s when it's there.

For one of our nodes:

# razor nodes node36 facts | grep is_virtual

     is_virtual: false

# razor nodes node36 metadata | grep sanboot

#

So I'm not clear on why the sanboot is being triggered anyway, but it is. If there's anything I can tell you about these systems to help, just say the word.

I'll move my code as you indicated. Thanks!