At Tue, 29 May 2018 10:03:07 -0400 CentOS mailing list centos@centos.org wrote:
On 28 May 2018 at 18:25, Robert Heller heller@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:
- Boot from EL6 iso and see if EFI variables/modules work
- Boot from EL7 iso and see if EFI variables/modules work
- 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.