7.4 now moved (available) on beta7.rocksclusters.org

[Philip Papadopoulos]

This is a 7.4 native (installer, all rolls recompiled).

In addition,

    - first stab at supporting nodes that pxeboot from uefi instead of bios

    - Autopartitioning creates a /boot/efi partition for nodes that booted via uefi

Still working on:

- Ipv4/IPV6 nameserver issues that sometimes crops up

- devel server doesn't initialized correctly

Haven't started on 

 -- Grid Engine or Son of Grid Engine Roll (if anyone wants to help with that, it would be appreciated.

-P

--

Philip Papadopoulos, Ph.D

ppapad...@ucsd.edu

(858) 822-3628

[Dietmar Rieder]

Hi,

I tested the new beta with UEFI frontend and backend nodes. It basically works fine, I just had to modify the access rights of 

/tftpboot/pxelinux/uefi.cfg/grubx64.efi  -> 755

/tftpboot/pxelinux/uefi.cfg/shim.efi   -> 644

another issue is the reinstallation of compute nodes:

In UEFI mode it seems that the installation of the bootmanager always puts "Rocks" as first boot option into the UEFI boot menu. So 

# rocks set host boot node-0-0 action=install

does not result in re-installation after a reboot of node-0-0

However, this can be fixed by changing the UEFI boot menu running script (similar to the one below) after the first reboot, I guess

This simple script restores the original boot order (PXE first, Rocks, .....):

#!/bin/bash

EFIBOOTORDER_=$(efibootmgr | grep BootOrder: | cut -d" " -f2)

EFIBOOTORDER=$(echo $EFIBOOTORDER_ | tr ',' "\n")

NEWEFIBOOTORDER_="${EFIBOOTORDER[1]} ${EFIBOOTORDER[0]} ${EFIBOOTORDER[@]:2}"

NEWEFIBOOTORDER="${NEWEFIBOOTORDER_[*]// /,}"

efibootmgr -o ${NEWEFIBOOTORDER}

Dietmar

[Dietmar Rieder]

... in order to get the UEFI boot order set to "PXE first, Rocks, ....."

I put the following script into the <post> section of extend-compute.xml

[....]

<post>

#!/bin/bash

EFIBOOTORDER_=$(efibootmgr | grep BootOrder: | cut -d" " -f2)

EFIBOOTORDER=($(echo $EFIBOOTORDER_ | tr ',' "\n"))

NEWEFIBOOTORDER_="${EFIBOOTORDER[1]} ${EFIBOOTORDER[0]} ${EFIBOOTORDER[@]:2}"

NEWEFIBOOTORDER="${NEWEFIBOOTORDER_[*]// /,}"

efibootmgr -o ${NEWEFIBOOTORDER}

</post>

This worked.

In essence the script just moves the "Rocks" UEFI boot entry from the first to the second position, since it was added to the first position

by the installer. If PXE is not on the first position a "rocks set host boot node-0-0 action=install" would not work.

 Dietmar

[Philip Papadopoulos]

What happens if PXE is set first in BIOS?  Does this post section still work as expected?   I think it will break that

configuration.

Here's a node, where I set in BIOS the boot order for IPv4 PXE to be first.

[root@compute-0-0 ~]# efibootmgr

BootCurrent: 0001

Timeout: 5 seconds

BootOrder: 0002,0004,0001,0006,0003,0005,0000

Boot0000* Windows Boot Manager

Boot0001* Rocks

Boot0002* UEFI: IP4 Realtek PCIe GBE Family Controller

Boot0003  UEFI: IP6 Realtek PCIe GBE Family Controller

Boot0004* UEFI: IP4 Realtek PCIe GBE Family Controller

Boot0005  UEFI: IP6 Realtek PCIe GBE Family Controller

Boot0006* CentOS

I'm going to reinstall this node and see if I get the same result. (I would expect so).

I'm just trying to understand how to set this automatically WITHOUT messing things up  That one can 

change the boot order from the OS when it's EFI is pretty cool :-).

If I run your script on this node:  The new BootOrder would be 0004,0002,0001, ....

which just flips the first two. (not bad in this case), but if it  were in BIOS as

0002,0001, .... initially, your script would have opposite of what was intended.    Disk would become first, not network.

I'm also not sure that keying off of 'Rocks' is generally applicable, either, Since a roll might install an updated kernel in a post

or otherwise do some changing of grub2.conf. 

-P

--
You received this message because you are subscribed to the Google Groups "rocks7-beta" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rocks7-beta+unsubscribe@googlegroups.com.
To post to this group, send email to rocks...@googlegroups.com.
Visit this group at https://groups.google.com/group/rocks7-beta.

To view this discussion on the web visit https://groups.google.com/d/msgid/rocks7-beta/b7346225-e4f4-460b-b761-779f62046cfe%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dietmar Rieder]

In my case:

Before I do the initial Rocks installation on the compute node over PXE I set "PXE boot first" in the BIOS,

then I do insert-ethers and boot the compute node. Rocks is being installed and the installer is then "somehow"

changing the UEFI boot order so that now the first option is "Rocks" (booting from disk). This is exactly what

we (?) do not want, that's why I thought it might be good to move the "Rocks" boot option in the UEFI boot

order to the second position and restore the boot order to the pre-rocks installation boot order, which

we set to "PXE first" via BIOS before installing rocks.

This works fine here (HP hardware)

In your message you say that you expect that the boot order is not changed, when you (re)install a compute

node, well this is what I expected to. However it gets changed (at least in my case), that's why I try to restore

it in the <post> section.

Dietmar

To unsubscribe from this group and stop receiving emails from it, send an email to rocks7-beta...@googlegroups.com.

To post to this group, send email to rocks...@googlegroups.com.
Visit this group at https://groups.google.com/group/rocks7-beta.

To view this discussion on the web visit https://groups.google.com/d/msgid/rocks7-beta/b7346225-e4f4-460b-b761-779f62046cfe%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Philip Papadopoulos]

THanks, Dietmar,

I replicated your experience.  On my single UEFI node.

I'll call this bad code in anaconda. It really shouldn't adjust bios boot order -- the logic

by the software designer is probably: "I just installed an OS, why wouldn't I want it to be

the first boot option?"  

I'll see if I can find the logic in anaconda's src to verify my assertion. There -might- be an

existing flag that we could throw to keep it from doing that.  

another approach would be to record

in <pre> section the original boot order and simply  restore that in a rocks <post> section. The

hitch there is that when a disk is unformatted, there is no boot action associated with the disk.

Your solution is also valid. Simply says, make it "second" - that might end up being the best. 

THanks for identifying the issue. 

Best,

Phil

To unsubscribe from this group and stop receiving emails from it, send an email to rocks7-beta+unsubscribe@googlegroups.com.

To post to this group, send email to rocks...@googlegroups.com.
Visit this group at https://groups.google.com/group/rocks7-beta.

To view this discussion on the web visit https://groups.google.com/d/msgid/rocks7-beta/4598cec9-7ebf-4efe-852d-b42ae1c7ca2e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.