Odd problem with HPE smart array and sanboot

[p4rancesc0]

Hi,

I'm booting a couple of old HPE BL460G6 server with iPXE.
I'm using iPXE with MAAS and I'm stuck with the final phase of deploy where the ipxe.cfg should tell to the server to boot from le local drive.

Nothing new, I found a lot o people complaining about this and the HPE smart array controller.

But I found out really an odd behaviour:

If the ipxe script contains only:
sanboot
everyhting get stuck

But if I press control + B, enter the iPXE console, and issue the command:
sanboot
everything works like charm...

I tried with some sleep and other odd solution inside the but nothing seems to work.

Can anyone please explain to me the difference between issuing the sanboot command from a script or issuing into the interactive console ?

I'm using:

ipxe.pxe

and

undionly.kpxe

BR
Francesco

PS
it's the 3rd time I try posting... sorry in advance for eventually double or triple posting

[p4rancesc0]

Hi everybody, still so sorry for the triple posting.

I did some more testing:

If the ipxe script contains only:
console
and then execute manually
sanboot

everything get stuck

But if I press control + B, enter the iPXE console, and issue the command:
sanboot
everything works like charm...


So, I guess which is the difference between the CTRL+B console and the console instance created with the script.

I did some debugging...

This is code line where everything get stuck:

PHP Code:

__asm__ __volatile__ ( REAL_CODE ( "pushw %%es\n\t"
                                           "pushl %%ebx\n\t"
                                           "popw %%bx\n\t"
                                           "popw %%es\n\t"
                                           "stc\n\t"
                                           "sti\n\t"
                                           "int $0x13\n\t"
                                           "sti\n\t" /* BIOS bugs */
                                           "jc 1f\n\t"
                                           "xorw %%ax, %%ax\n\t"
                                           "\n1:\n\t"
                                           "popw %%es\n\t" )
                               : "=a" ( status ), "=b" ( discard_b ),
                                 "=c" ( discard_c ), "=d" ( discard_d )
                               : "a" ( 0x0201 ), "b" ( *address ),
                                 "c" ( 1 ), "d" ( drive ) ); 


it's inside :

src/arch/x86/interface/pcbios/int13.c

the function is:

static int int13_load_mbr ( unsigned int drive, struct segoff *address )

Best Regards
Francesco

[p4rancesc0]

Hi,
sorry to bother,

but this issue is still there after some months.

To me is very odd that issuing "sanboot" in the console (CTRL+B) works like a charm while in a script get everything stuck.

Can anyone help me out ?

BR
Francesco

[MultimediaMan]

There is a problem with with your PHP script formatting (syntax,whitespace) in the dynamic IPXE script.

There is an easy way to verify it, too:

Take the output of your PHP script in plain text and drop it into a php_test_script.ipxe

and post it here...

[p4rancesc0]

Hi,
I'm using MAAS, Metal As A Service.

This is the Script called when the deployment is finished.

PHP Code:

#!ipxe
# Boot the locally attached hard drives. On failure try the next locally
# attached hard drive. Fail on the last hard drive, if booting fails.
sanboot --no-describe --drive 0x80 ||
sanboot --no-describe --drive 0x81 ||
sanboot --no-describe --drive 0x82 ||
sanboot --no-describe --drive 0x83 


BR
Francesco

[MultimediaMan]

Sanboot to local disk (e.g. "sanboot --no-describe --drive 0x80") is not a supported feature, and this has been repeatedly mentioned and stressed for at least five (5) years. It works with some PCBIOS implementations, true, but not all. It doesn't surprise me at all that it doesn't work with the complex HP BIOS and HP Peripherals.

My recommendation is to avoid using the sanboot to try to "enforce" a local boot and instead use the (old and somewhat ponderous) HP BIOS tweak tool or through the HP IPMI tool as part of your build process: The tools for the HP G6 and G7 pre-date RedFish implementations, but they do exist. Since you have blade servers, you can also access these features from the C3000/C7000 Blade Server Management Engine CLI using SSH scripts.

I need to warn you: HP's G6 and G7 BIOS and ILO2/3 Firmware have been out of HP's quarterly software/firmware maintenance releases for several years, and will have several serious vulnerabilities which are difficult to to mitigate without removing basic functionality.

Good Luck,

M^3

[p4rancesc0]

Dear,

I must admit that in someway I'm glad to have some response.
Anyway the original question is still unanswered.
Why CTRL+B + sanboot works while just executing sanboot doesn't work ?

About "sanboot --no-describe --drive 0x80" maybe the problem is on MAAS developer side (Ubuntu Canonical) since the script comes from the unpatched code of MAAS and it's used for booting locally iPXE installation.

Last, still glad to hear that our g6 (+100) are unsupported and dangerous rubbish, maybe out there people expose ILO to public network or whatever, maybe someone is so extremely generous to make us a donation to swap that trash with brandnew g10.

Technically, enlisting, commissioning e deploying process are provided by MAAS, scripting something to control IPMI is still not possible out of the box, patching the snap of maas is quite a pain, a workaround is in production but those 2 line patch (one in each file) are still annoying to maintain.

BR
Francesco

[MultimediaMan]

OK, now that we understand that the problem is MAAS doing something nasty, try this:

Code:

#!ipxe
# Boot the locally attached hard drives. On failure try the next locally
# attached hard drive. Fail on the last hard drive, if booting fails.
sleep 3
sanboot --no-describe --drive 0x80 ||
sleep 3
sanboot --no-describe --drive 0x81 ||
sleep 3
sanboot --no-describe --drive 0x82 ||
sleep 3
sanboot --no-describe --drive 0x83

But I am starting to think the problem is just before this step... describe the sequence of events (or link to video of the boot sequence) that gets us to a black screen. Then describe how you use iPXE to hit CTRL-B. I'm thinking MAAS isn't sending a DHCP command to iPXE somewhere which is why it is just sitting there.