On Thu, Oct 23, 2014 at 4:55 PM, Thomas Bächler <thomas@xxxxxxxxxxxxx> wrote: > > A 2 minute Google search indicates that refind merely appends the initrd > as a kernel command line option (initrd=) - refind, like gummiboot, is > merely an EFI bootmanager and not a bootloader and thus relies on the > kernel's EFIstub feature. Therefore, refind does not load the initrd > itself, but delegates that task to the kernel. > > I am confused about this now. In my previous post I quoted that using refind boots with the dual initrd files in the refind_linux.conf file, and leads to lines in the journal log like: Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 Does this mean that the quoted early update has used the wrong file from an earlier date than current, or does this journal log line confirm correct early loading of the up-to-date microcode? Or does delegating the task to the kernel when efistub loading produce a correctly working processor with the intended new microcode at the early stage of booting the kernel? Thanks -- mike c
