Hello,
we are using refind last version to boot our linux Kernel. We are booting on nuc Intel from broadwell to kabylake without problem. ( boot from EFI USB ) . We the last Intel nuc, 8generation , the boot process seems to be block . We can see refind boot, then cmdline of boot configuration , and system does not boot anymore. The same kernel, with the same configuration, just change refind to grub efi , works without problem.
Regards,
Nicolas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you please provide more details? For instance:
Can you select an OS to boot within rEFInd, or is its UI hung?
Can you launch something other than a Linux kernel using rEFInd? For instance, can you launch GRUB from rEFInd, or an EFI shell? (You'll need to install an EFI shell.)
When the system hangs, what exactly is shown on the screen? (A digital photo may be helpful.)
What is your configuration? Posting the complete refind.conf file, as well as /boot/refind_linux.conf from Linux, if it's present, may be helpful. Are you using manual boot stanzas, or relying on auto-detection of the kernel?
What Linux distribution are you using?
How did you install rEFInd? (Manually, using the .zip file and refind-install, installing an RPM or Debian package, etc.)
What version of rEFInd are you using? ("Latest version" isn't precise, since I released a new version on November 12, the day before you posted your query.)
Was rEFInd compiled with Tianocore or GNU-EFI? (This information is available on the about/info screen.)
Is Secure Boot enabled on the computer? If so, try disabling it. (See here for rEFInd's Secure Boot documentation.)
Absent other information, I'd suggest you look into the firmware version on your computer. Sometimes boot problems like these can be cleared up by updating (or, more rarely, by downgrading) the firmware version. I had an issue like this with a NUC I own, but it's an older version (a DC53427HYE), so if yours is a newer NUC, it's unlikely to have shipped with the exact problem firmware I had. I also don't recall the symptoms I experienced, but I do recall having to update the firmware to get it working correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you select an OS to boot within rEFInd, or is its UI hung?
Yes, we can select an os from refind, then linux kernel seems to be freeze.
( kernel is very big because it contains initramfs ( 100M)
When the system hangs, what exactly is shown on the screen? (A digital photo may be helpful.)
screen only show refind cmdline ( after chose os icon)
What is your configuration? Posting the complete refind.conf file, as well as /boot/refind_linux.conf from Linux, if it's present, may be helpful. Are you using manual boot stanzas, or relying on auto-detection of the kernel?
we are using latest binary distribution of refind.
Is Secure Boot enabled on the computer? If so, try disabling it. (See here for rEFInd's Secure Boot documentation.)
no
exactly same usb Key are starting linux Os without issue on number of Pc ( intel nuc, hp portable ) , only lastest Intel nuc 8generation does not boot with this freeze,
grubefi have no problem
Regards,
Nicolas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I assume you are not booting via the manual boot stanza you describe. If so, this sounds like an EFI stub loader problem, not a rEFInd problem per se, although I can think of a couple of possible causes that are more rEFInd-related. Your description of the kernel file as being 100MiB in size raises alarm bells. It could be that there's a bug in the EFI stub loader (or conceivably in the EFI itself) that's affecting the ability to read such a large file. If so, splitting the initrd off into a separate file might help. Also, rEFInd's EFI filesystem drivers include cache code that works well with most EFIs, but poorly with a few. The result is sluggish performance -- it may take a minute or two to load a normal-sized kernel on an affected computer. Your 100MiB kernel could take ten or twenty minutes to load if your EFI is affected in this way, so you might want to simply wait a while. (Try waiting at least an hour, just to err on the long side.) That's obviously not desirable on a day-to-day basis, but if this is the cause, moving the kernel to another filesystem may fix the problem. In my experience, ext2fs and ext3fs are hit worst by this, with Btrfs and ReiserFS performing best (amond rEFInd's drivers). Putting the kernel on a FAT filesystem is likely to produce the best load times.
You can test to see if it's an EFI stub loader problem by using another boot manager that uses the EFI stub loader. These include the firmware's own boot manager (which you'd configure via efibootmgr in Linux) and systemd-boot. Note that, without jumping through hoops involving rEFInd's (or some other source's) EFI filesystem drivers, these boot managers will load kernels only from FAT filesystems, so please check to see how rEFInd works with the kernel on a FAT filesystem first. If you configure one of these boot managers and still have the same problem, then you can be pretty sure that the problem is in the EFI stub loader.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
we are using refind last version to boot our linux Kernel. We are booting on nuc Intel from broadwell to kabylake without problem. ( boot from EFI USB ) . We the last Intel nuc, 8generation , the boot process seems to be block . We can see refind boot, then cmdline of boot configuration , and system does not boot anymore. The same kernel, with the same configuration, just change refind to grub efi , works without problem.
Regards,
Nicolas
Could you please provide more details? For instance:
refind.conffile, as well as/boot/refind_linux.conffrom Linux, if it's present, may be helpful. Are you using manual boot stanzas, or relying on auto-detection of the kernel?.zipfile andrefind-install, installing an RPM or Debian package, etc.)Absent other information, I'd suggest you look into the firmware version on your computer. Sometimes boot problems like these can be cleared up by updating (or, more rarely, by downgrading) the firmware version. I had an issue like this with a NUC I own, but it's an older version (a DC53427HYE), so if yours is a newer NUC, it's unlikely to have shipped with the exact problem firmware I had. I also don't recall the symptoms I experienced, but I do recall having to update the firmware to get it working correctly.
Yes, we can select an os from refind, then linux kernel seems to be freeze.
( kernel is very big because it contains initramfs ( 100M)
screen only show refind cmdline ( after chose os icon)
What is your configuration? Posting the complete refind.conf file, as well as /boot/refind_linux.conf from Linux, if it's present, may be helpful. Are you using manual boot stanzas, or relying on auto-detection of the kernel?
timeout 15
hideui singleuser,hints,hwtest,hints,editor,arrows
icons_dir next-theme/icons
showtools
menuentry w10_64k_np-[ro] {
icon EFI/BOOT/next-theme/icons/os_win_ro.png
loader /packages/x86_64_K
}
we are using latest binary distribution of refind.
no
exactly same usb Key are starting linux Os without issue on number of Pc ( intel nuc, hp portable ) , only lastest Intel nuc 8generation does not boot with this freeze,
grubefi have no problem
Regards,
Nicolas
I assume you are not booting via the manual boot stanza you describe. If so, this sounds like an EFI stub loader problem, not a rEFInd problem per se, although I can think of a couple of possible causes that are more rEFInd-related. Your description of the kernel file as being 100MiB in size raises alarm bells. It could be that there's a bug in the EFI stub loader (or conceivably in the EFI itself) that's affecting the ability to read such a large file. If so, splitting the initrd off into a separate file might help. Also, rEFInd's EFI filesystem drivers include cache code that works well with most EFIs, but poorly with a few. The result is sluggish performance -- it may take a minute or two to load a normal-sized kernel on an affected computer. Your 100MiB kernel could take ten or twenty minutes to load if your EFI is affected in this way, so you might want to simply wait a while. (Try waiting at least an hour, just to err on the long side.) That's obviously not desirable on a day-to-day basis, but if this is the cause, moving the kernel to another filesystem may fix the problem. In my experience, ext2fs and ext3fs are hit worst by this, with Btrfs and ReiserFS performing best (amond rEFInd's drivers). Putting the kernel on a FAT filesystem is likely to produce the best load times.
You can test to see if it's an EFI stub loader problem by using another boot manager that uses the EFI stub loader. These include the firmware's own boot manager (which you'd configure via
efibootmgrin Linux) and systemd-boot. Note that, without jumping through hoops involving rEFInd's (or some other source's) EFI filesystem drivers, these boot managers will load kernels only from FAT filesystems, so please check to see how rEFInd works with the kernel on a FAT filesystem first. If you configure one of these boot managers and still have the same problem, then you can be pretty sure that the problem is in the EFI stub loader.