On 29/12/2016 15:46, Chris Murphy wrote:
On Wed, Dec 28, 2016 at 1:55 PM, Ron Leach<ronleach@xxxxxxxxx> wrote:
Grub starts fine, the F24 selection boots perfectly
into F24, but selecting Windows just causes the machine to 'hang', showing
a constant cursor in the top left corner of the screen.
Could be this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1347291
Indeed it is that bug. That bug report, initially of a dual-boot
problem with Windows 10, was added to with reports of similar failures
with Win 8.1, and Win 7. The symptoms of the 'hang' differed slightly
in each different Windows case, and the Win 7 symptoms reported there
were exactly those I had experienced.
While that bug was being analysed, a very useful work-around was
offered, exploiting a (relatively little known but) quite flexible
characteristic of the UEFI system. I'd noted that, among the various
boot options listed in the BIOS, are two 'software' loaders in
addition to the normally-expected hardware sources such as HDD, LAN,
FDD, USB, CD, etc. Those two 'software' loaders were:
'Fedora', and
'Windows Boot Manager'.
UEFI has a facility whereby if it attempts a boot from some source,
including a boot from a software loader, and that boot attempt fails,
UEFI will try the next source in the list. (That behaviour is common
for all the hardware sources, but it also applies for the software
boot loaders.) Further, UEFI is happy to let a software loader start,
think, take its time, and UEFI seems willing to wait for either a
successful boot, or for that software loader to 'exit' at any
arbitrary time later - and then UEFI will proceed to the next entry in
the boot list. Now, because of the bug the system will happily load
Fedora (but not Windows) when the top boot entry is the 'Fedora' boot
manager, but will happily load Windows (but not Fedora) if the top
boot option is Windows Boot Manager, *and* the Fedora boot loader can
be manually instructed to abort and exit, then the work-around
suggested in that bug report enables the Fedora boot loader to be
used, and still be able to lead to Windows being loaded. The way to
achieve this is 3 steps:
(i) Set the boot options to give 'Fedora' boot loader the 1st
priority, and give the 'Windows Boot Manager' 2nd priority - the
immediate 2nd priority. This step only has to be completed once.
(ii) On boot, the Fedora Grub menu choice will be presented, with
Fedora, and Windows, as selectable choices. If the user wants to run
Fedora, then that choice can be selected - and Fedora will load. A
further, quite simple, step is needed to load Windows.
(iii) To run Windows, the Windows option should be selected on screen
- but not executed yet. Instead, follow the advice at the bottom of
the Grub screen to edit the Grub setting (for the selected menu choice
- make sure it's Windows), by typing the letter 'e'. Grub will show
its short sequence of commands that it uses to load Windows. Insert
the word 'exit' into that sequence of commands - just before the line
starting with 'chainloader' would be a reasonable choice. You will
probably have to also hit 'return' so that 'exit' appears on its own
line. That's all. Again, follow the advice at the bottom of the
screen - this time to tell Grub to execute this now-altered sequence
of commands - by typing 'ctrl-x'. Windows should load.
This is a work-around for this bug and it can be used if a user
encounters the bug and cannot (or cannot yet) install the final fix,
which has, now, been fully released but has to be retrospectively
applied to F24 (I am not sure whether current downloads of F25 ISOs
already have this fix or not but, if not, then the work around works
anyway for F25, and the fix has also been fully released for F25).
Not only is this a work-around for this bug, but this trick - of
letting UEFI start with one software loader, and then subsequently
execute the next software loader - may be useful in other contexts as
well. I think it's a useful feature of UEFI to know about.
In the meantime if you have a version less than grub2-2.02-0.38 you could
try updating and see if that fixes the problem.
And that is the fix, finally released.
I used the work-around a few times because I was slightly wary of
updating Grub. Finally, I did run dnf, saw that the Grub update was
version ... .38, the version described and tested in the bug report,
so I did apply the update and, of course, Grub now perfectly manages
this dual-boot F24 and Win 7 machine.
Chris, I'm very much obliged.
Ah, you had asked about another detail:
On Wed, Dec 28, 2016 at 1:55 PM, Ron Leach <ronleach@xxxxxxxxx> wrote:
> The BIOS is
> set for UEFI with legacy settings.
I don't know what this 2nd sentence means. If you can take a cell photo so
the exact context can be determined, it might help understand better. If
this is a "legacy boot" option, as in a compatiblity support module to
present a faux-BIOS to the OS, this can be problematic. Was this enabled by
default (by the manufacturer)? The rest of your description sounds like the
firmware is UEFI and both OS's see it as UEFI, not legacy/BIOS.
The machine has 3 boot settings, CSM, UEFI, *and* "UEFI (legacy mode)"
which means it runs UEFI but also provides some kind of earlier BIOS
interfaces. We run the machine in that 3rd option, "UEFI (legacy mode)".
The Fedora documentation has a note about these options; I read it a
couple of days ago but I now cannot find the page, to give as a link.
(I must have read it on a laptop and our laptop is set to clear its
history each time FF closes). In essence, the Fedora live ISOs for
i686 require machines to be set for CSM; the x64 ISOs will run in
either UEFI or CSM. If running in UEFI, then any subsequent 'install'
will also require UEFI; if running in UEFI with legacy support, then
any subsequent install will require to run always in UEFI with legacy
support. Actually, this is also true with Windows. When we
initialised the laptop with W7, we were in UEFI (legacy), and I notice
that now W7 will not boot in UEFI mode - even when Windows Boot
manager is the top item in the boot options list.
In my text I'd tried to describe that "UEFI 'with legacy support'" mode.
Very many thanks for your post, it's been really helpful,
Ron
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
