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 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 at deepsoft.com -- Webhosting Services