DL380 G10 / RHEL Device Order

[Jimmy Vance]

---

@MikeJeezy wrote:

---

@Jimmy Vance wrote:

---

---

Please refer to this Customer Advisory, you need to set the "Number of OS bootable drives." to 0 on all the other controllers and be running HPE Smart Array firmware v1.34 (or later)
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00022532en_us

Can I ask why you are using legacy emulation mode and not UEFI? 

---

There is no technical reason why I suppose... just have not had a compelling reason to make the switch to UEFI.  We are running Smart Array firmware version 1.66. 

It appears, the customer advisory pertains to Legacy mode.   I will try UEFI.

---

Yes, you will only see the issue in Legacy mode, UEFI handles boot loaders in a different manner.  The enumeration problem is present in both BIOS and UEFI so you will need the %pre script in some form.  If you are PXE booting, you will need to make other modification to your DHCP and PXE bootloader to switch from BIOS to UEFI.  I'm also working on an updated version of the %pre script for kickstart 

[MikeJeezy]

---

@Jimmy Vance wrote:

---

---

Yes, you will only see the issue in Legacy mode, UEFI handles boot loaders in a different manner.  The enumeration problem is present in both BIOS and UEFI so you will need the %pre script in some form.  If you are PXE booting, you will need to make other modification to your DHCP and PXE bootloader to switch from BIOS to UEFI.  I'm also working on an updated version of the %pre script for kickstart 

---

Thanks.  I was able to work around this in Legacy mode by changing the "Number of OS bootable drives" (per the advisory) in the BIOS for all of the controllers.  I set the embedded controller to "1" and all of the other controllers to "0" (they were set to 2).

But, I did try UEFI mode, and I attempted to boot from the RHEL-Boot.iso.  The problem is I can't get to a boot prompt when hitting "Esc" at the install screen.  It goes to a GRUB prompt.  It's almost like it's text based for some reason... not sure yet.  I'd like to use UEFI mode, but still looking in to it.

[Jimmy Vance]

---

@MikeJeezy wrote:

---

@Jimmy Vance wrote:

---

---

Yes, you will only see the issue in Legacy mode, UEFI handles boot loaders in a different manner.  The enumeration problem is present in both BIOS and UEFI so you will need the %pre script in some form.  If you are PXE booting, you will need to make other modification to your DHCP and PXE bootloader to switch from BIOS to UEFI.  I'm also working on an updated version of the %pre script for kickstart 

---

Thanks.  I was able to work around this in Legacy mode by changing the "Number of OS bootable drives" (per the advisory) in the BIOS for all of the controllers.  I set the embedded controller to "1" and all of the other controllers to "0" (they were set to 2).

But, I did try UEFI mode, and I attempted to boot from the RHEL-Boot.iso.  The problem is I can't get to a boot prompt when hitting "Esc" at the install screen.  It goes to a GRUB prompt.  It's almost like it's text based for some reason... not sure yet.  I'd like to use UEFI mode, but still looking in to it.

---

'install screen' can be a few differnt screens, post a screen shot if you can.  Back in the syslinux days ESC would get you to a syslinux boot prompt. With Grub2 being the bootloader now ESC doesn't normally respond.  Grub needs a press of 'e' or 'c' at the initial boot screen and it will drop into a grub editor or grub command line

[MikeJeezy]

---

@Jimmy Vance wrote:

---

'install screen' can be a few differnt screens, post a screen shot if you can.  Back in the syslinux days ESC would get you to a syslinux boot prompt. With Grub2 being the bootloader now ESC doesn't normally respond.  Grub needs a press of 'e' or 'c' at the initial boot screen and it will drop into a grub editor or grub command line

---

Sorry I wasn't more clear. See attached image to see a comparison of UEFI and Legacy.  At boot: we (the Linux Admin) specifies node name, source repo, IPs, gateways, etc so that installation and configuration can happen.  When booting RHEL-boot.iso in UEFI mode, I see no way to get to a boot: prompt at the initial install screen.  (see attached)

[Jimmy Vance]

---

@MikeJeezy wrote:

---

@Jimmy Vance wrote:

---

'install screen' can be a few differnt screens, post a screen shot if you can.  Back in the syslinux days ESC would get you to a syslinux boot prompt. With Grub2 being the bootloader now ESC doesn't normally respond.  Grub needs a press of 'e' or 'c' at the initial boot screen and it will drop into a grub editor or grub command line

---

Sorry I wasn't more clear. See attached image to see a comparison of UEFI and Legacy.  At boot: we (the Linux Admin) specifies node name, source repo, IPs, gateways, etc so that installation and configuration can happen.  When booting RHEL-boot.iso in UEFI mode, I see no way to get to a boot: prompt at the initial install screen.  (see attached)

---

For UEFI boot, highlight the Install RHEL 7.5 boot line and press 'e' and you can edit the boot line options. Refer to Anaconda boot option information  https://rhinstaller.github.io/anaconda/boot-options.html  'inst.repo=' and 'ip=' are the options I think you are looking for. Options get added on the 'linuxefi' line which normally ends with 'quiet'   I found adding 'inst.geoloc=0' speed things up. Its been to long so I don't recall the reason, but I was getting installation failures until I added the geoloc line.

[MikeJeezy]

@Jimmy Vance  Because this project is so far behind now, we just ended up using Legacy mode and tweaking the BIOS settings per the customer advisory (In the BIOS, set "Number of OS bootable drives" to "1" on the controller driving the rear cage, and set it to "0" on all of the other controllers).  Using UEFI requires more time to modify the kixtart script than the Linux team is willing to dedicate this week.

While setting the "Number of OS bootable drives" to 1 for the embedded controller seems to work, that logical disk still shows up as  /dev/sdr which is a still a little odd to me, but maybe I am just old school. The kixtart script was modified to force installation to  /dev/sdr  and everything looks okay after reboot.

I guess I am still unsure what would happen if we remove a disk from the server (for example /dev/sdm) and restart.  The OS disk would no longer be enumerated as /dev/sdr, but I assume if we are using the UUID's in /etc/fstab, all should be okay.

Thank you kindly for all of your assistance and feel free to post any other thoughts if any.