Re: CentOS6: HELP! EFI boot fails after replacing disks...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



At Tue, 29 May 2018 10:03:07 -0400 CentOS mailing list <centos@xxxxxxxxxx> wrote:

> 
> On 28 May 2018 at 18:25, Robert Heller <heller@xxxxxxxxxxxx> 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 
UEFI...

> 
> 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@xxxxxxxxxxxx       -- Webhosting Services
                                               
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux