Ask Your Question
2

How to fix dual-boot after updates

asked 2018-09-07 01:38:38 -0500

degski gravatar image

updated 2018-09-19 23:26:56 -0500

I am new to Fedora/Linux/BSD, so please bear with me.

Yesterday, after installing Fedora and after lots of diggin', I was able to have a proper dual-boot system (so this is my second day with Fedora). Then as this was the iso-distribution I installed, the system started to download updates, I rebooted the system, this morning after the downloads were complete, and then my nicely working dual-boot was broken again. I can get into Fedora, I'm writing this on Fedora. When I select Windows Boot Manager, though, there is an error alloc magic is broken, I then push enter and then some more stuff shows up for a fraction of a second and then the system reboots, so I cannot read what that says.

EDIT: I filmed the boot (booting Windows Boot Manager from the F12 boot menu) so I could slow it down to show what happens when I launch the window boot manager, it says as follows:

System BootOrder not found. Initializing defaults.
Creating boot entry "Boot0028" with label "Fedora" for file "\EFI\fedora\shimx64.efi"

Reset System

So when I issue sudo efibootmgr in a terminal, I have many entries, not just 3, 4 or 5 or so (who thought this was a good idea [to just keep creating new ones])? It seems all is related to some mis-configuration of efibootmgr (grub2).

Yesterday, I added in the UEFI settings the grubx64.efi file as allowed, that did the trick. But then when I rebooted after the updates this morning, the system complained that shimx64.efi (what does this .efi do?) was missing (i.e. not allowed), so I added that, that did again the trick (Fedora worked again), but windows does not boot with the alloc magic is broken message.

I would particularly like to thank @cmurf for looking at lots of spaghetti on the wall as he calls it! Thanks.

edit retag flag offensive close merge delete

Comments

during update do you have asked by system to update grub configuration (a feature request if you wanted it to be changed) ??? check your grub.cfg and any grub.cfg backup in your system

nisankh gravatar imagenisankh ( 2018-09-07 06:00:34 -0500 )edit

@nisankh As I am a total nitwit in respect of Linux/BSD, I did not do anything else than simply reboot. Should I post the grub.cfg file?

degski gravatar imagedegski ( 2018-09-07 07:39:12 -0500 )edit

4 Answers

Sort by ยป oldest newest most voted
2

answered 2018-09-07 12:43:35 -0500

cmurf gravatar image

updated 2018-09-07 12:52:36 -0500

Based on the efibootmgr output in the pastebin link, I think this is a bug. Not user error. It might actually be more than one bug, and there might be NVRAM corruption confusing the firmware (which can act like a multi-layered bug). And it's possible it has already been fixed due to the update :-) I know that's confusing. From the pastebin, check out line 11 and line 12. Line 11 is Boot0003, which is the currently booted entry. Notice how the content is differently formatted than line 12, Boot0004. And notice how all the superfluous boot entries are like Boot0004.

I've seen this behavior before where buggy firmware doesn't see or honor BootOrder, therefore can't find a bootloader, therefore firmware follows EFI/BOOT/BOOTX64.EFI - which is actually shim.efi and works with fallback.efi to get Fedora to boot even when there are no Fedora boot entries found in NVRAM. And when this fallback is used, it adds an NVRAM boot entry for Fedora. And the bug, is that the firmware still doesn't see these added entries (yes we see them, but it doesn't), so BOOTX64.EFI keeps being run every time you boot, and another Fedora entry is added each time, and eventually NVRAM gets full or corrupt, and the firmware then gets really confused.

But then you did a software update and now you have this differently formed Boot0003. The fix for bugs of this sort sometimes happen in shim, or GRUB, or the kernel, or the firmware. So I have no idea what was updated that might explain the Boot0003 format change. But also, Windows won't boot which I think is a side effect of a really cluttered up NVRAM and ensuing confusion. Anyway, all of that is a guess, but I need more information.

  • What is the first line from dmesg | grep DMI ? That should report make/model and firmware revision for your computer. And then compare that to manufacturer support downloads, and see if they have something newer.
  • What do you get for mokutil --sb-state ? This reports the state of Secure Boot, doesn't change anything.

I think a good next step is to clean out some of these superfluous boot entries in NVRAM. Try doing this:

sudo efibootmgr -b 0,1,2,4,5,6,7,8,9,A,B,C,D,E,F,10,11,12,13,14,15,16,18,19,1A,1B,1C,1D,1E,1F,20,24,25,26,27,28,29,2A,2B,2C,2D -B

That should delete all of them except entries 3 (current Fedora) and 17 (Windows). You can confirm with sudo efibootmgr -v and report back if it's successful or if there are errors.

Next, there is more than one way to try to boot Windows. This should bypass shim+grub and directly load the Windows Boot Manager one time.

sudo efibootmgr --bootnext 17

Now reboot.

OK that's quite a lot of things to ... (more)

edit flag offensive delete link more

Comments

The info:

https://pastebin.com/VNn3ys7n

https://pastebin.com/fYkhsTsx

The cleaning up:

https://pastebin.com/U07P4zci

I checked with ACER and as you could see, my firmware is 1.25 and there is a version 1.37 (and a Spectre fix, 1.39, not sure I want that one), so after I've gathered the courage, I'll upgrade the firmware, possibly, if all goes well, a good idea anyway.

By-passing shim+grub still gives the same error as before as posted in the EDIT of the question, just with a different number (0000). Now the output of efibootmgr -v looks like this:

https://pastebin.com/HQN7YU2R

degski gravatar imagedegski ( 2018-09-07 21:08:21 -0500 )edit

From here, it appears that just to get back into Windows (and install the firmware update)

bcdedit /set "{bootmgr}" path \EFI\Microsoft\Boot\bootmgfw.efi

should work, and then later just set it back with:

bcdedit /set "{bootmgr}" path \EFI\fedora\shimx64.efi

A question regarding this, should it be grubx64.efi instead of shimx64.efi?

degski gravatar imagedegski ( 2018-09-07 22:26:14 -0500 )edit

You need shimx64.efi if secure boot is enabled.

If nothing else works, you might bypass your problem by

  • disable secure boot
  • copy grubx64.efi to EFI/BOOT/BOOTX64.EFI

If you copy the microsoft efi file to BOOTX64.EFI it should give you windows.

villykruse gravatar imagevillykruse ( 2018-09-08 00:41:52 -0500 )edit

Sorry, for some reason I didn't get email notification of replies. I recommend users@ list https://lists.fedoraproject.org/archi... or #fedora channel on irc.freenode.net for faster turn around for such complex issue that needs a lot more back and forth.

cmurf gravatar imagecmurf ( 2018-09-08 17:11:05 -0500 )edit

What do you get for

rpm -q shim-x64
rpm -q grub2-efi-x64
sudo blkid
sudo ls -l /boot/efi/EFI/Microsoft/Boot

Unfortunately bcedit only runs in Windows, it's not a Linux command, what we're trying to do is get you a way to boot back to Windows. I agree with villykruse, sudo cp /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi /boot/efi/EFI/BOOT/BOOTX64.EFI likely will get you to boot Windows but then you're likely stuck only booting Windows. I'm trying to test things slowly, reversibly, so you don't get more stuck than you are. Firmware is definitely not behaving normally.

cmurf gravatar imagecmurf ( 2018-09-08 17:18:35 -0500 )edit
1

answered 2018-09-09 15:30:10 -0500

cmurf gravatar image

updated 2018-09-09 15:34:55 -0500

@degski OK from your last paste I see this in /boot/efi/EFI/Microsoft/Boot/ for lines 26-28:

-rwx------. 1 root root   18600 Nov 13  2017 bootmgfw.efi
-rwx------. 1 root root 1253792 Aug  7 09:12 bootmgfw__.efi
-rwx------. 1 root root 1257376 Aug  3 06:39 bootmgr.efi

I do not know what the first one is, but 18600 bytes is bogus. The second file has the correct size, but it's incorrectly named. My advice is to remove the first one and rename the second one to bootmgfw.efi. For example on my dual boot Windows 10:

-rwx------. 1 root root 1273760 Aug  2 15:39 bootmgfw.efi
-rwx------. 1 root root 1257376 Aug  2 15:39 bootmgr.efi

I think this explains at least the problem being unable to boot Windows 10. Both GRUB's configuration file, and the Windows boot entry in NVRAM (efibootmgr), are currently pointing to this bogus 18K file that cannot possibly be a valid Windows bootloader.

For what it's worth, any Microsoft supplied Windows 10 ISO image, if you mount it and look around for bootmgfw.efi you can copy it to your local /boot/efi/EFI/Windows/Boot. So if the copy you have still doesn't work after renaming it, get a known good one. You can download Windows 10 install ISOs from Microsoft's web site for free without a serial number. This bootloader file is signed by Microsoft, and that signature is what UEFI Secure Boot being enabled is checking (among other things).

If Secure Boot is disabled, this bootloader file's signature is not validated, it's blindly used. So...if I were being a little paranoid, and wonder what a bootkit attack might look like, it might look like this! Make someone's computer unbootable and see if they disable secure boot and now I'm in! This is why I'm really really fussy about any advice to disable Secure Boot without thoroughly understanding why someone's having the problem they're having.

I'm on #fedora and #fedora-qa right now, if you join either channel and type cmurf I'll get a notification.

edit flag offensive delete link more

Comments

@cmurf Sorry, 12 hours ago (from when I'm posting now) I was asleep. I think you are right, I'll tell you why, I've downloaded the correct Windows Install Media, installed, updated and re-imaged, updated that install (now they are absolutely matching) and then I rebooted. The same "alloc magic is broken" message and I can again no longer boot into Windows. To be clear, I did NOT boot into Fedora, nor did I launch Grub. So it seems to me that Fedora is violating an important rule that the files on the EFI partition that don't belong to that software should never ever be altered.

degski gravatar imagedegski ( 2018-09-10 03:50:11 -0500 )edit

@cmurf In EFI\Boot there's actually a similar thing, there is bootx64.efi (from April 2018, i.e. Fedora 28 release time) and then there is bootx64__.efi (dated September 2017, i.e the Windows 1709 release). It looks like the Windows installer does not replace these files if the files on disk are newer that the files in the install-media.

degski gravatar imagedegski ( 2018-09-10 04:06:25 -0500 )edit

@cmurf I have deleted the bogus entries and renamed the xxxx__.efi entries to xxxx.efi, and now it works, without re-installing Windows (makes life a lot easier ;-) ). The Windows menu option from Grub still gives the alloc magic is broken message, but I couldn't care about that. The F12 option (and that works) is the right one IMO. And then I can also keep Windows as the default, because even though Fedora is great, Win10 is pretty good as well. How can I remove the "boot into windows option" from Grub? And, will anybody take action to have this fixed (I'll report it if you tell me where)?

degski gravatar imagedegski ( 2018-09-10 05:09:50 -0500 )edit

@cmurf I did poke around the install media, but I did not find any bootmgfw.efi. How do I "mount" the install media thumb-stick? It appears the files are out-of-date (W10-1709), so I'm interested to get them to the current W10-1803 version.

degski gravatar imagedegski ( 2018-09-10 08:31:16 -0500 )edit

@cmurf Secure Boot is ON, seems like a pretty decent idea (even though it complicates things).

degski gravatar imagedegski ( 2018-09-10 08:32:14 -0500 )edit
0

answered 2018-09-07 07:16:25 -0500

villykruse gravatar image

updated 2018-09-07 12:55:03 -0500

"System BootOrder not found. Initializing defaults" is a message from the shim fallback mechanism.

When the system boots the file /BOOT/BOOTX64.EFI (chich is a copy of the shim) it goes into fall-back mode and loads /BOOT/fallback.efi . This will try to install /fedora/shimx64.efi in the uefi configuration.

shimx64.efi is a pre-loader signed by MS so you can boot in secure mode. It then checks if grubx64.efi is properly signed by a Fedora key, and then loads it.

So, In Fedora run efibootmgr -v and check the contents, especially if it has the entry for windows. Also, check the contents of /boot/efi/EFI and check if the windows loaders are intact.

edit flag offensive delete link more

Comments

@villykruse

So I get this output: https://pastebin.com/fma4aPt0

How do I check "whether the windows loaders are intact"? I mean, how do I know that they are intact?

PS1: My posts are on moderation (because I'm a first-time poster), so it's not that I'm slow, but it takes time for somebody to have a look to check I don't post child-porn and stuff. PS2: Can no longer wait for moderation, have to go to bed, be back in (my) morning.

degski gravatar imagedegski ( 2018-09-07 08:00:25 -0500 )edit

I would not see your post anyway until I check in to this site, which I only do occasionally.

I have no windows; never had, so I can't say how the window loader files look like. I could suggest compare to another windows installation.

Your efibootmgr output looks "interesting" -- will need some time to check it out.

villykruse gravatar imagevillykruse ( 2018-09-07 11:15:36 -0500 )edit

You should remove all the duplicate entries, that is, all entries except 0003, 0017, 2001, 2002, and 2003

To remove entry "Boot002D"

efibootmgr -B -b 002D

and then continue with the next

efibootmgr -B -b 002C
efibootmgr -B -b 002B

and so on.

Hopefully, you can also remove 0021, 0022, and 0023.

villykruse gravatar imagevillykruse ( 2018-09-07 12:49:15 -0500 )edit
degski gravatar imagedegski ( 2018-09-07 21:09:51 -0500 )edit
0

answered 2018-09-19 23:25:37 -0500

degski gravatar image

After reading the guide-lines, I am adding the answer here below:

Summarizing and concluding. The issue I was seeing is caused by running BestCrypt Volume Encryption on my Windows system, the software changes the default way Windows boot works and then obviously breaks whatever Fedora assumes. Jetico (BCVE) does not provide a Linux version, so I'll be switching to VeraCrypt (ported to all relevant systems). I've already installed VeraCrypt on Fedora, but I'll hold of till version 1.23 comes out (which has now, 13.09.2018, been released) as the release notes show many fixes and improvements, particularly in the area of EFI boot matters.

Fast-forward: I've uninstalled (removed) Jetico's BestCrypt Volume Encryption (from Windows) and much to my surprise, doing just that, restored everything into working order, Grub is fully functional. I did now also install VeraCrypt 1.23 on both Windows and Fedora and this software package preserves the dual-boot, no more issues, whatsoever. There is the obvious advantage that now I can encrypt/decrypt and mount the same (encrypted) disk, both in Windows and in Fedora. I thought this was useful information, id. the update.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-09-07 01:32:09 -0500

Seen: 187 times

Last updated: Sep 19