[ipxe-devel] Booting from local disk on HP ProLiant machines

[Andrew Bobulsky]

Hello again Christoph,

On Jan 8, 2013, at 1:46 PM, Christoph Schug <chris+ipxe-devel at schug.net> wrote:

> On 2013-01-08 16:19, Andrew Bobulsky wrote:
>>
>> Following a different thread regarding similar issues with sanbooting
>> a local disk under Virtualbox, I did some testing using GRUB4DOS as a
>> workaround, and wrote an application note on the wiki yesterday.
>>
>> If you'd like to give it a try:
>> http://ipxe.org/appnote/work_around_bios_halting_on_ipxe_exit
>
> Hi Andrew,
>
> great summary :-) The
>
> | chain http://server/grub4dos/grub.exe --config-file="rootnoverify (hd0);chainloader +1"
>
> seems to do the trick on my DL365 G5.

Awesome!  And thank you :)

> Apparently GRUB4DOS has the limitation that it cannot boot from LVM volumes but that is something I can live with. For a first test I went back to an traditional partition setup without LVM, for the final solution it is most likely enough to have everything on LVM except /boot/ (might be worth a note on the appnote document; additionally it should be referenced on http://www.ipxe.org/docs ... this is really valuable information).

An LVM partition isn't exactly a filesystem that GRUB4DOS can
understand, so that makes sense.  However, any OS kernel residing in
an LVM volume would need to be chain loaded by a bootloader that
*could* dive into one... Is there some inability to target *that*
bootloader with GRUB4DOS?  Since you chained the MBR of one of your
LVM members, there might be other ways to go about digging into the
underlying filesystem by using a different bootloader.  I'll look into
that!

I dropped Michael a line before writing that, and he said he'd add it
to the documentation when I was done.  I literally wrote it yesterday,
so I'm sure it'll be added soon ;)

> FWIW, I was working on a backup plan today by moving the logic whether to boot from local disk or from network to the layer of TFTP, more specific tftpd-hpa. I am just noting it here in case someone still has the requirement to boot from LVM-managed disks.
>
> Of course it would be also possible to do this directly in the dhcpd.conf, but I am not fancy the restart the mission critical DHCP service for ever change, nor do I want to DHCP to be dependent on LDAP (supported by vanilla ISC DHCPD) or some SQL database (there is some patch floating around which allows control over the host declarations, http://blog.alex.org.uk/2010/09/05/adding-sql-support-to-isc-dhcpd/).
>
> The idea would have been to add the MAC address also to the TFTP request as unique identifier ...
>
> | set client-dashed-mac = concat (
> |     suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 1, 1))),2), "-",
> |     suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 2, 1))),2), "-",
> |     suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 3, 1))),2), "-",
> |     suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 4, 1))),2), "-",
> |     suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 5, 1))),2), "-",
> |     suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 6, 1))),2)
> | );
> |
> | if exists user-class and option user-class = "iPXE" {
> |     set bootstrap-url = concat("http://${next-server}/ipxe/bootstrap/", client-dashed-mac);
> | } else {
> |     set bootstrap-url = concat("boot/", client-dashed-mac);
> | }
> | filename = bootstrap-url;
>
> ... but instead of providing a tftproot/boot/<client-dash-mac> file to have some mapfile (tftpd-hpa option "-m") which contains the MAC addresses of all machines which should do something with iPXE in order to rewrite those requests ("re" rules) to undionly.kpxe. Machines which shall boot from local disk are not to be listed here, their requests will get an access denied which is here the default policy ("a" rule). This aborts the PXE boot and those machines fall back to local boot.
>
> | re ^boot/00-1f-29-54-2f-e2$ /ipxe/undionly.kpxe
> | re ^boot/00-1f-29-5c-d5-74$ /ipxe/undionly.kpxe
> | a  ^

Interesting idea, for certain.  I've often wondered why there isn't a
TFTP server that supports dynamic content, but then again, we've
really worked around that need by having an HTTP stack at our disposal
:P

That said, I'll delve further into your LVM issue and get back to you,
if you don't mind!  I'm inclined to think that passing *all* clients
through the PXE step and then booting is thr most desirable scenario,
given the level of control it offers, and would be happy to offer any
solution that makes that as compatible of a goal as is reasonably
possible :)

> Well, that one also works, but of course I will stick to the plain iPXE solution using GRUB4DOS as this gives much more flexibility by the fact that HTTP is mostly used which allows dynamic configuration generation with standard tools (think of PHP, etc.) from a central configuration management database.
>
> Thanks once more
> Christoph

Cheers,
Andrew