Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1601578 - All x86 BIOS boots fail with 'invalid magic number' errors
Summary: All x86 BIOS boots fail with 'invalid magic number' errors
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
: 1601585 (view as bug list)
Depends On:
Blocks: F29BetaBlocker
TreeView+ depends on / blocked
Reported: 2018-07-16 18:15 UTC by Adam Williamson
Modified: 2018-07-20 17:58 UTC (History)
9 users (show)

Fixed In Version: grub2-2.02-45.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1601815 (view as bug list)
Last Closed: 2018-07-20 17:58:43 UTC

Attachments (Terms of Use)
full grub.cfg file (deleted)
2018-07-16 18:42 UTC, Adam Williamson
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1601585 None None None Never

Internal Links: 1601585

Description Adam Williamson 2018-07-16 18:15:27 UTC
Since the Fedora-20180714.n.0 compose (the previous compose, Fedora-Rawhide-20180711.n.0, was OK), all x86 BIOS installs fail to boot after installation. After an option is chosen from the bootloader menu, an "invalid magic number" error is displayed for several seconds, then the system either reboots, stops, or displays a kernel panic (seems to depend on the system).

Some further info from jwb:

<jwb> 06:12:18> pjones, so i just did a real install and got an error after boot.  i looked at the boot stanza that was written out and it has a linux16 line for the vmlinuz, then a linux16 line for the initramfs, then an initrd16 line for the initramfs
<jwb> 06:12:35> pjones, if i remove that linux16 line trying to load the initramfs, it boots fine

I'll do a local reproduction and attach an exact grub.cfg file for the record, though I believe pjones has already reproduced the issue and is working on it.

Between the working and the failed compose were these changes to grub2:

* Fri Jul 13 2018 Peter Jones <> - 2.02-42
 - Revert broken moduledir fix *again*.

* Thu Jul 12 2018 Peter Jones <> - 2.02-41
 - Fix our linuxefi/linux command reunion.

* Wed Jul 11 2018 Peter Jones <> - 2.02-40
 - Port several fixes from the F28 tree and a WIP tree.

This is an obvious Beta blocker per Basic criterion "...A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.
A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles." on x86 BIOS, proposing.

Comment 1 Adam Williamson 2018-07-16 18:41:36 UTC
These are the exact lines I get in grub.cfg after an install from the Fedora-20180714.n.0 Everything netinst image:

	linux16	/vmlinuz-4.18.0-0.rc4.git4.1.fc29.x86_64 root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rhgb quiet LANG=en_CA.UTF-8
	linux16	/initramfs-4.18.0-0.rc4.git4.1.fc29.x86_64.img
	initrd16 /initramfs-4.18.0-0.rc4.git4.1.fc29.x86_64.img

I'll attach the full file as well.

Comment 2 Adam Williamson 2018-07-16 18:42:17 UTC
Created attachment 1459248 [details]
full grub.cfg file

Comment 3 Andre Robatino 2018-07-17 03:00:31 UTC
Still broken with grub2-2.02-44 after installing from using rescue mode.

Comment 4 Filipe Brandenburger 2018-07-17 07:25:49 UTC
Take a look at this pull request:


Comment 5 Filipe Brandenburger 2018-07-17 07:29:06 UTC
Just rebased that PR on top of current specfile...

I'd appreciate it if someone could take a look at it and merge it.


Comment 6 Martin Pitt 2018-07-17 07:55:53 UTC
In our Cockpit test VMs (for RHEL devel series) I'm getting the exact same broken config as in comment #1, i. e. initramfs gets loaded by *both* linux16 and initrd16. However, when I just run grub2-mkconfig in an otherwise unmodified system, I *only* get the

   linux16	/initramfs-4.18.0-0.rc4.git4.1.fc29.x86_64.img

line without the initrd16 one. So this is rather unpredictable. For the former the workaround is to simply drop the line, for the latter case it's s/linux16/initrd16/. So this is a bit brittle to work around in scripts.

But I confirm that dropping the linux16 /initramfs line fixes the boot.

Comment 7 Andre Robatino 2018-07-17 15:27:22 UTC
Confirmed fixed with grub2-2.02-45.fc29 ( ).

Comment 8 Adam Williamson 2018-07-17 16:36:32 UTC
*** Bug 1601585 has been marked as a duplicate of this bug. ***

Comment 9 Marian Csontos 2018-07-17 18:18:16 UTC
Workaround (add to %post) which works for me:

# Workaround for installation Bug 1601578:
cp /boot/grub2/grub.cfg{,.0orig}
sed -i -e 's|^\s\+linux16\s\+/initramfs-|\tinitrd16\t/initramfs-|' /boot/grub2/grub.cfg
sed -i -e 's|^\s\+initrd16\s\+/initramfs-|\tinitrd16\t/initramfs-|' /boot/grub2/grub.cfg
mv /boot/grub2/grub.cfg{,.1sed}
uniq /boot/grub2/grub.cfg{.1sed,}

Seeing Comment 6, instead of simply deleting linux16 line, it changes linux16 to initrd16, then makes whitespace same, and delete identical lines :-)

Seems there are some problems with zram on shutdown too... :-(

Comment 10 dominique 2018-07-20 09:46:16 UTC
I confirm that grub2-2.02-45.fc29 fix problem.

Comment 11 Adam Williamson 2018-07-20 17:58:43 UTC
Indeed, openQA tests are working now.

Note You need to log in before you can comment on or make changes to this bug.