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
