make customized option as default on boot menu

[george1421]

@kortnor Well this is going to me a multipart response here.

First. Let me see if I understand what you are doing. You are setting up something like a Raspberry Pi micro-cluster. You are booting the OS from usb flash and then you have your main storage attached via usb to an external HDD. Since this is an i5 cluster, I’ll assume its intent is for number crunching over file storage.

In this setup I would have concerns about that usb flash drive being burned out (memory cell failure) after a year or so of running. A better concept there is to only use the flash drive for booting and then run linux out of memory. Then only save the configs to the flash drive to avoid overwriting to the usb boot, then you can move main disk storage to the usb 3 interface.

Another issue with the way its setup is can you guaranty that usb flash drive will always be listed as /dev/sda? I have see situations based on which usb device initialized first became sda and the second device became sdb.

[george1421]

Ok so you are booting into the fog pxe menu and then the exit mode for that device is not selecting the usb flash drive so it can boot successfully. I think that is the root of the issue.

I guess I would have to ask the question back to you, how often do you need to reimage this cluster in a headless manner? Meaning what value is it to have your cluster connect to the FOG server on every reboot? In a situation like this if I never reimaged a node unless something failed on the device, I would not have it connect to the FOG server every time. Now if you were sending the image to memory on every boot (such as a true pxe boot) then you would need to connect to a pxe server on every boot. But in your case you only need the fog server for reimaging.

In this setup I might set the primary boot to the usb flash drive and then just press the F12 key (to access the boot menu) on boot to select pxe booting when you needed to reimage the device. You would need a console connect to the node to reimage it. But if you are only imaging on failure then you will be at the node anyway.

[george1421]

@Tom-Elliott This is a question for a developer.

In bios mode, do any of the exit modes reference the “Host Primary Disk” value that is stored in the Host Management details page? That way the op can set the disk he wants to image and boot from. That would work as long as one of the exit modes referenced this field.

[Junkhacker]

why not set the cluster nodes to network boot their os instead of booting from USB?

[Tom Elliott]

@george1421 The problem is the way “disk booting” works in grub and/or bios is that the field for the “Host” is setup for the inits. Init’s reference by the device name (/dev/sda,/dev/md0,/dev/hdd, etc…) where for Grub it’s accessed by (hd(0,0), hd(0,1), hd(1,0) etc…).

Knowing what is what is not straight forward.

[kortnor]

Thank you for all you answers,

we are running the os on USB 3 which gives us really good results. The nuc only have 1 sata connector and there is no micro-sd connector neither.
Because I’ve to attend a summit, I wont be able to make some test before friday ( regarding what @Tom Elliot is asking) .

The ultimate aim is that my colleague can restage this micro-cluster whenever they want and check what are the real impact on on the OS layer when you’re working with new hadoop version ( e.g. we have face huge dependencies issue between centos 6.6 and centos 6.7 which was a pain in the ass to resolve it I don’t even one to mention centos 7).

Best,

[Sebastian Roth]

@kortnor What you are looking for would be an option to add a new item to (FOG Configuration -> iPXE Boot Menu -> fog.bootusb) Menu Show With list. Unfortunately you can’t because all those options are kind of hard coded and you would need to dig into the PHP code to add a new item and make it work. But from what I read about your project you are only using this FOG server for your cluster, right? So there aren’t any other clients to boot the PXE menu? If that’s the case I would just make fog.bootusb the default (unset fog.local as default) for “Registered Hosts”. This way all your registered NUCs should use the entry as default.

In case you have other clients using the boot menu as well you could simply “hack” the bootmenu.class.php to make it work for you - very simple. First change back to fog.local as default for all hosts and edit the NUCs host settings in the web interface and set “Host Bios Exit Type” to “GRUB_FIRST_HDD”. Then open /var/www/html/fog/lib/bootmenu.class.php and edit line number 22 from:

'grub_first_hdd' => 'chain -ar ${boot-url}/service/ipxe/grub.exe --config-file="rootnoverify (hd0);chainloader +1"',

to

'grub_first_hdd' => 'chain -ar ${boot-url}/service/ipxe/grub.exe --config-file="rootnoverify (hd1);map (hd1) (hd0);chainloader (hd1)+1"'

Be aware that every host using the GRUB_FIRST_HDD exit will run this changed grub command line…

@Tom-Elliott Maybe you want to add GRUB_SECOND_HDD to the exit type list using this grub map command line?!

[sourceminer]

@kortnor said in make customized option as default on boot menu:

chain -ar http://${fog-ip}/${fog-webroot}/service/ipxe/grub.exe --config-file=“rootnoverify (hd1);map (hd1) (hd0);chainloader (hd1)+1” || MENU

Hi guy’s I am trying to do this now. I have 30 Older WYSE terminals that all need to boot via USB with a Micro Linux kernel to load Parallels RAS Client. Capture and setting primary disk to sdb works perfect. After PXE menu however it boots to the WYSEOS instead of the USB. Bios is set to boot to PXE then USB disk.

Adding a boot to /dev/sdb would be nice.

[Sebastian Roth]

@sourceminer I am fairly sure your case is different to what is being discussed in this fairly old thread. Please open a complete new one, refer to this and add your information: FOG version, more specific details about the client hardware, what exactly you are trying to achieve… all that!

[sourceminer]

Im my case its the same, I want to load from the second disk not the first (just like in this solution).
hd1 not hd0

[sourceminer]

@sebastian-roth Can you confirm where in version Running Version 1.5.0-RC-10
SVN Revision: 6080 This might be? @Tom-Elliott