I'm using rEFInd to dual boot Windows 7 and Linux Mint 16. Everything works just fine, aside from a minor quirk that shows up when rebooting from Linux Mint: after the manufacturer splash screen, rEFInd is not loaded and the system hangs indefinitely. This doesn't happen on a cold boot or when rebooting from Windows 7.
I'm using rEFInd 0.7.7-1, which I've built from scratch (using GNU-EFI) and installed through install.sh. I've also tried a fresh install using the binaries from the Debian package, but the problem shows up either ways.
I'm working on a brand new, 64-bit Dell XPS 15 9530 (you can find the specs HERE). The firmware version I'm using is A02, which is the latest available from Dell website. Here is an extract of the output of dmidecode:
BIOS Information
Vendor: Dell Inc.
Version: A02
Release Date: 12/18/2013
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 2048 kB
Characteristics:
MCA is supported
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 0.2
Firmware Revision: 0.2
Here is my current partition layout:
Partition
Description
Mount Point
File System
Size
Label
/dev/sda1
ESP
/boot/efi
FAT32
100 MB
/dev/sda2
MSR
128 MB
/dev/sda3
Windows 7
NTFS
270 GB
WINDOWS
/dev/sda4
Data
/media/marco/dati
NTFS
500 GB
DATI
/dev/sda5
Linux Mint 16 Root
/
ext4
38 GB
ROOT
/dev/sda6
Linux Mint 16 Home
/home
ext4
108 GB
/dev/sda7
Swap
linux-swap
16 GB
In rEFInd settings, I'm using dont_scan_dirs to exclude the loaders in /EFI/Boot/ (which contains bootx64.efi), /EFI/Microsoft/Boot (which contains bootmgfw.efi, bootmgr.efi and memtest.efi) and /EFI/ubuntu (which contains GRUB). Also I've disabled scan_all_linux_kernels.
I'm populating rEFInd menu entries directly using the following two OS stanzas:
So, I'm using the kernel EFI stub loader to load Linux Mint and the Windows loader to load Windows 7.
Googling around I've found that there is a reboot parameter that can be passed to the Linux kernel to specify it's behaviour on reboot. I've added "reboot=value" to the options definition of the Linux stanza, experimenting different values, unfortunately to no avail. Here are some of the values I've tried:
reboot=acpi,warm
reboot=acpi,cold
reboot=force
reboot=cold
reboot=warm
reboot=efi,warm
reboot=efi,cold (this made the system hang on a black screen before showing up the manufacturer splash screen)
reboot=efi,cold,force (this resulted in an error: Unable to handle kernel paging request, with Code: Bad RIP value)
reboot=efi,warm,force
reboot=acpi,cold,force
reboot=acpi,warm,force
Neither of these were able to make rEFInd load properly on reboot. What can be the problem here?
Thanks for the help!
Marco Palena
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is almost certainly a firmware bug, although it could be that the Linux kernel is doing something strange on shutdown/reboot that's triggering the bug. To that end, your experiments with the reboot= kernel options might be worth continuing, if you've omitted any values; but you've tried enough that I'm doubtful anything else will work.
You could also try installing a copy of rEFInd as EFI/BOOT/bootx64.efi on the ESP, in case the problem is that the firmware is ignoring the NVRAM entries; such a problem might be fixed by having something available in the fallback location.
Another thing to try is to experiment with the BootNext EFI option, which you can set via the efibootmgr -n option. If you explicitly set that to rEFInd, it might do the right thing. If this works, you could incorporate such a call into a system startup script to ensure it's set correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm using rEFInd to dual boot Windows 7 and Linux Mint 16. Everything works just fine, aside from a minor quirk that shows up when rebooting from Linux Mint: after the manufacturer splash screen, rEFInd is not loaded and the system hangs indefinitely. This doesn't happen on a cold boot or when rebooting from Windows 7.
I'm using rEFInd 0.7.7-1, which I've built from scratch (using GNU-EFI) and installed through install.sh. I've also tried a fresh install using the binaries from the Debian package, but the problem shows up either ways.
I'm working on a brand new, 64-bit Dell XPS 15 9530 (you can find the specs HERE). The firmware version I'm using is A02, which is the latest available from Dell website. Here is an extract of the output of dmidecode:
Here is my current partition layout:
In rEFInd settings, I'm using dont_scan_dirs to exclude the loaders in /EFI/Boot/ (which contains bootx64.efi), /EFI/Microsoft/Boot (which contains bootmgfw.efi, bootmgr.efi and memtest.efi) and /EFI/ubuntu (which contains GRUB). Also I've disabled scan_all_linux_kernels.
I'm populating rEFInd menu entries directly using the following two OS stanzas:
So, I'm using the kernel EFI stub loader to load Linux Mint and the Windows loader to load Windows 7.
Googling around I've found that there is a reboot parameter that can be passed to the Linux kernel to specify it's behaviour on reboot. I've added "reboot=value" to the options definition of the Linux stanza, experimenting different values, unfortunately to no avail. Here are some of the values I've tried:
Neither of these were able to make rEFInd load properly on reboot. What can be the problem here?
Thanks for the help!
Marco Palena
This is almost certainly a firmware bug, although it could be that the Linux kernel is doing something strange on shutdown/reboot that's triggering the bug. To that end, your experiments with the
reboot=
kernel options might be worth continuing, if you've omitted any values; but you've tried enough that I'm doubtful anything else will work.You could also try installing a copy of rEFInd as
EFI/BOOT/bootx64.efi
on the ESP, in case the problem is that the firmware is ignoring the NVRAM entries; such a problem might be fixed by having something available in the fallback location.Another thing to try is to experiment with the
BootNext
EFI option, which you can set via theefibootmgr -n
option. If you explicitly set that to rEFInd, it might do the right thing. If this works, you could incorporate such a call into a system startup script to ensure it's set correctly.