On 2016-02-22 16:37, Michael Howard wrote: > On 22/02/2016 15:36, Gordan Bobic wrote: >> On 2016-02-22 15:30, Michael Howard wrote: >>> On 22/02/2016 14:42, Gordan Bobic wrote: >>>> On 2016-02-22 14:26, Michael Howard wrote: >>>>> On 22/02/2016 11:50, Gordan Bobic wrote: >>>>>> It seems a little odd that the installer would put the kernel >>>>>> somewhere >>>>>> other than the target installation disk. Having UEFI on-board I >>>>>> can >>>>>> understand, but shouldn't the boot sequence in this case be: >>>>>> >>>>>> 1) u-boot (on-board) >>>>>> 2) UEFI (wherever u-boot can fetch it from) >>>>>> 3) grub (off the UEFI FAT partition on the target disk) >>>>>> 4) Kernel (/boot partition) >>>>>> >>>>>> Is there a good reason for deviating from this? >>>>>> >>>>> >>>>> Ok, reinstalling the original u-boot resolves the onboard kernel >>>>> issue, that is, the board now boots to OpenLinux again when no >>>>> other >>>>> devices are attached. So the 'Applied Micro Linux 3.12.0 >>>>> (aarch64)' >>>>> kernel is part of their (Gigabyte's) u-boot image. >>>> >>>> Right, so now that UEFI is working, it seems the next thing to do >>>> is to get grub2 loading from UEFI. From there on it should be >>>> trivial to get a sensible kernel booting. >>>> >>> >>> Ok, some strangeness happening here. It seems it wasn't the centos >>> installer that caused the issue of the board not booting to OpenLinux >>> afterall. Having reinstalled u-boot and confirmed the board booted to >>> OpenLinux, I chainloaded UEFI once more (using the instructions from >>> Phong Vo) in order to try manually booting centos. I couldn't >>> immediately see how to do that so I reset the board and now back to >>> non booting board. Go figure. >>> >>>> I do find it baffling that the installer that requires UEFI would >>>> do something so fundamentally different in terms of configuring >>>> the boot process compared to the x86 method of doing it. >>>> >>> >>> I guess it doesn't afterall. >>> >>>> Hmm... I wonder... Did you create a 250MB FAT partition on the >>>> disk of type EF00 (GPT), for the UEFI boot loader part (the >>>> stuff that ends up in /boot/efi)? >>> >>> Well, this installer is completely new to me. At the opening screen >>> of >>> the text install I had to select various aspects of the install >>> before >>> it would let me proceed. One of which is the selection of the install >>> disc and how it should be partitioned. I changed from LVM to basic >>> partitioning and an efi partition was reported to have been created. >>> Once the install began, there was no requirement for further user >>> interaction. >> >> Hang on, you mean the installer in this case is text based anaconda, >> rather than GUI? >> > > Yes, that's correct. The installer has problems with network also, in > that it doesn't find a 'link up' on any port. Hence it won't start vnc > installer either. > > As mentioned, my accusation about the installer overwriting the > onboard kernel was way off mark, although something (chainloading > EFI?) does. The irony of that is killing me right now: https://lists.fedoraproject.org/pipermail/users/2013-February/431095.html It is a long thread, but it does make for an entertaining (if also at times depressing) read. Dumbing down and crippling the text installer was a retarded idea back when it was done in F11 (and it filtered down into EL6). History seemingly hasn't shown it to be any less retarded than it seemed to many of us back then. > Anyway, the install does in fact succeed, which is great. I probably > should have stuck with the LVM partitioning scheme but hey ho, I can > re run things now that I know UEFI is working. > > So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 > kernel. Great start, thanks to all. > > There is no networking so I need to get the installer to recognise the > nics at install time. So installer produces a bootable system, complete with a working kernel? Does it use grub2 or does it do some magic to boot the kernel straight from UEFI? Gordan