[CentOS] CentOS6: HELP! EFI boot fails after replacing disks...

Tue May 29 15:20:04 UTC 2018
Robert Heller <heller at deepsoft.com>

At Tue, 29 May 2018 10:03:07 -0400 CentOS mailing list <centos at centos.org> wrote:

> On 28 May 2018 at 18:25, Robert Heller <heller at deepsoft.com> wrote:
> > Then I shut the machine down, swapped in the new backup [2TB] disk and pulled
> > the old system [500G] disk and installed the third new [2TB] disk. The system
> > won't boot that way. It seems there is something in the UEFI (secure boot)
> > logic that wants the original disk, even if everything is moved over.
> >
> This caught my attention. Did you mean that you are using the secure
> boot options? I don't know if that ties down a system to a specific
> disk until it is cleared from the install. From all the other items
> you listed in the the thread, your system looks like it is booting
> into a form where it is saying it isn't UEFI anymore which would be a
> boot firmware option. The firmware can lock down what it thinks is ok
> to boot from and may require some sort of flush depending on the type
> of disks it thinks are ok. I had this with one set of systems where
> the system required a hard flush of UEFI buffers before it would boot
> from a larger disk. It was ok with the same old model but a new one
> was not possible.

Not using "secure boot" in the sense of setting any partitular security (the 
"secure" section of the  BIOS is not enabled.  What *was* enabled was the UEFI 
boot.  At this point I have mostly given up on UEFI.  I disconnected the 
optical disk (we don't really use it anyway) and connected the original boot 
disk as /dev/sdd and installed the third 2TB disk.  The system boots (in 
Legacy Mode) and it is now rebuilding the RAID array onto the new disk.  The 
/boot array now has three elements (partition 2 of the two new disks and 
partition 2 of the old disk).  I condemed the old (empty) RAID array on the 
old disk -- it now has an unformatted third partition that is not being used 
for anything.  I will be *eventually* upgrading the system to CentOS 7 
(sometime later this summer).  Maybe at that time I will revisit the world of 

> My debugging methodology at this point would be the following:
> 1. Boot from EL6 iso and see if EFI variables/modules work
> 2. Boot from EL7 iso and see if EFI variables/modules work
> 3. See if a Dell firmware update set is available and if the
> changelogs say it fixes EFI boot issues
> 4. repeat 1&2 if a firmware update is done.
> >From what I can tell, most of the install methods and 0 downtime
> 'hacks' we have used for the last 30 years on BIOS systems are either
> impossible or need serious fixes to work again in a UEFI world.

Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services