This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 811412

Summary: F17 Final TC3 has bogus OS X entries in grub2 when installed from dd-written images
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: os-proberAssignee: Hedayat Vatankhah <hedayatv>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 17CC: adam.stokes, bcl, bruno, dan.mashal, dennis, dhuff, hedayatv, Jasper.Hartline, jfeeney, jsmith.fedora, katzj, mads, pjones, rbergero, robatino, satellit, satellitgo, tflink
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: RejectedBlocker AcceptedNTH
Fixed In Version: os-prober-1.53-1.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-15 01:26:11 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 752653    
Description Flags
storage.log from the failed install
program.log from the failed install
sh -x 30_os-prober run and stderr output from /sbin/grub2-probe
30_os-prober output with bash -x
This patch makes 20macosx ignore our dummy mach_kernel files.
This patch makes 20macosx ignore our dummy mach_kernel files. none

Description Adam Williamson 2012-04-10 21:00:15 EDT
If I write F17 Beta RC4 desktop live to USB with dd, boot from it via BIOS mode, and try to do an installation, it does not succeed. At bootloader installation stage it pops up the 'there was a problem during bootloader installation, the system may not be bootable' warning. Indeed, on reboot, the system is not bootable - grub reports 'error: file `/grub2/i386-pc/normal.mod` not found. Entering rescue mode...' and gives me the rescue prompt.

Attaching program.log and storage.log.
Comment 1 Adam Williamson 2012-04-10 21:02:49 EDT
Created attachment 576634 [details]
storage.log from the failed install
Comment 2 Adam Williamson 2012-04-10 21:03:54 EDT
Created attachment 576635 [details]
program.log from the failed install
Comment 3 Adam Williamson 2012-04-10 21:15:01 EDT
Proposing as a Beta blocker, against my better judgment :/ image works fine if written via livecd-iso-to-disk, but lots of people prefer dd-type methods because they don't write from Fedora systems. Haven't tested liveusb-creator yet.
Comment 4 Adam Williamson 2012-04-10 21:23:35 EDT
Working theory - this is due to grub2-mkconfig getting confused by the macboot stuff on the USB stick. (Yes, it scans the USB stick). grub2-mkconfig run just ends with it claiming it's found OS X on the USB stick, and then it exits with status 1.
Comment 5 Adam Williamson 2012-04-10 21:29:09 EDT
Confirming this is a regression vs RC3. RC3 works fine.
Comment 6 Adam Williamson 2012-04-10 21:55:15 EDT
OK, I think I was right in comment #4: if you delete everything from the third partition of the USB stick (which has the OS X stuff), then boot via BIOS and run an installation, it works fine, no error, and the installed system boots.

so grub2-mkconfig is finding the 'OS X' on the stick, getting very confused, and just silently failing. Re-assigning to grub2 for now, though we may wind up having to work around grub2 auto-detection in livecd-tools somehow...
Comment 7 Dan Mashal 2012-04-10 23:22:37 EDT
Does not work from Windows live USB creator and latest KDE ISO, there is no option for Fedora 17 in Windows Live USB creator. Takes me to dracut shell. Attaching screenshot.
Comment 8 Dan Mashal 2012-04-10 23:23:34 EDT
Created attachment 576646 [details]
Comment 9 Tim Flink 2012-04-10 23:32:57 EDT
I created a bootable USB using liveusb-creator on F16 and the F17 beta RC4 x86_64 desktop livecd.

The installation was successful - no errors and everything works once I reboot.
Comment 10 Tim Flink 2012-04-11 13:37:07 EDT
I'm +1 blocker on this - a lot of people seem to use dd to create USB install media and this is a regression that you wouldn't hit until after installation
Comment 11 Adam Williamson 2012-04-11 13:38:22 EDT
OK, RC4.1 fixes this.

I'm a weak +1 blocker on this one, criterion "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media" in the case of live image written to USB via dd. This case is the only one available for doing a USB install from OS X and is commonly used by Windows users and users of non-Fedora Linux distros who don't have livecd-iso-to-disk available. liveusb-creator is available for other distros and Windows, but has its own quirks and experience tells me dd is at least _as_ commonly used as liveusb-creator, for whatever reason.

Fedora Bugzappers volunteer triage team
Comment 12 Jared Smith 2012-04-11 13:46:38 EDT
Sounds like a +1 blocker for me -- lots of people use the functionality.
Comment 13 Jared Smith 2012-04-11 13:54:42 EDT
For the record, my vote is +1 for *beta blocker*
Comment 14 Bruno Wolff III 2012-04-11 13:58:40 EDT
I think this is a common enough use case that it should be a beta blocker.
+1 beta blocker
Comment 15 Robyn Bergeron 2012-04-11 14:09:39 EDT
+1 beta blocker
Comment 16 Adam Williamson 2012-04-11 14:11:19 EDT
Accepted as a Beta blocker. RC4.1 is known to address this issue, so if we choose to ship RC4.1, we can close this. The effect of accepting this as a Beta blocker is that we cannot ship RC4.

Fedora Bugzappers volunteer triage team
Comment 17 Dennis Gilmore 2012-04-11 15:38:11 EDT
my vote is to ship RC4.1 for live
Comment 18 Brian Lane 2012-04-11 19:29:10 EDT
Created attachment 576915 [details]
sh -x 30_os-prober run and stderr output from /sbin/grub2-probe

This is actually a problem with grub2-probe used in 30_os-prober script.
Comment 19 Dan Mashal 2012-04-12 05:24:30 EDT
I was able to install via RC4.1, usb stick created in windows using live usb creator and able to install to hard drive.
Comment 20 Brian Lane 2012-04-12 09:14:01 EDT
Please don't close this, it needs to be fixed in grub2.
Comment 21 satellitgo 2012-04-14 16:16:34 EDT
dd USB of Beta[1] x86-64 installs to external USB HD successfully

Comment 22 satellitgo 2012-04-18 16:50:37 EDT
./ --format --reset-mbr Fedora-17-Beta-x86_64-DVD.iso /dev/sdb1

Used Diskutility on an 8 GB USB
did GPT format and 4 GB fat /dev/sdb1 left 4 GB unformatted
Boot USB
now I have 2 UUID entries repo=hd:UUID    then root=live:UUID
It shows the installation repo on list...Not sure of what happened  1-)GPT format with fat /dev/sdb1 and 2-)leaving 1/2 of 8GB USB unformatted.
-checking dependencies from install repo! look OK
-Installing from DVD repo....
will append commands and install record next
Comment 23 satellitgo 2012-04-18 16:53:38 EDT
8 GB USB formatted as GPT with 4 GB partition fat /dev/sdb1 2nd 4 GB left unformatted

# ./ --format --reset-mbr Fedora-17-Beta-x86_64-DVD.iso /dev/sdb1
Verifying image...
./ line 900: checkisomd5: command not found
Are you SURE you want to continue?
Press Enter to continue or ctrl-c to abort

/Packages found, will copy source .iso to target
Press Enter to continue or ctrl-c to abort

wipefs: WARNING: /dev/sdb: appears to contain 'gpt' partition table
Waiting for devices to settle...
mkdosfs 3.0.9 (31 Jan 2010)
mkdosfs 3.0.9 (31 Jan 2010)
Copying live image to target device.
   130367488 100%   20.36MB/s    0:00:06 (xfer#1, to-check=0/1)

sent 130383477 bytes  received 31 bytes  20059001.23 bytes/sec
total size is 130367488  speedup is 1.00
Copying /home/(user)/Desktop/Fedora-17-Beta-x86_64-DVD.iso
  2484076544 100%   10.41MB/s    0:03:47 (xfer#1, to-check=0/1)

sent 2484379867 bytes  received 31 bytes  10920351.20 bytes/sec
total size is 2484076544  speedup is 1.00
Updating boot config file
Installing boot loader
Target device is now set up with a Live image!
Comment 24 satellitgo 2012-04-18 17:21:19 EDT
Install completed and booted to firstboot/smolt/gdm/gnome3.4.0 
_Wireless AP configured in anaconda was connected on boot.
Comment 25 satellitgo 2012-04-18 17:25:38 EDT
There are 2 partitions: LIVE and LIVE-REPO(with Fedora 17 Beta-x86-64-DVD.iso)
anaconda must have created the /dev/sdb2 partition and installed the DVD.iso in the Unformatted 4 GB part of the 8 GB GPT USB
Comment 26 satellitgo 2012-04-18 17:34:16 EDT

debug --graphics
timeout 5
title Fedora 17-Beta
	kernel @KERNELPATH@ @ROOT@ rd.luks=0
	initrd @INITRDPATH@


menu separator # insert an empty line
label linux
  menu label ^Install or upgrade Fedora
  menu default
  kernel vmlinuz
  append initrd=initrd.img repo=hd:UUID=3147-B22E:/ root=live:UUID=310D-94BB quiet rd.luks=0
menu separator # insert an empty line
# utilities submenu
menu begin ^Troubleshooting
  menu title Troubleshooting
label vesa
  menu indent count 5
  menu label Install Fedora in ^basic graphics mode.
  text help
	Try this option out if you're having trouble installing
  kernel vmlinuz
  append initrd=initrd.img repo=hd:UUID=3147-B22E:/ root=live:UUID=310D-94BB xdriver=vesa nomodeset quiet rd.luks=0
label rescue
  menu indent count 5
  menu label ^Rescue a Fedora system.
  text help
	If the system will not boot, this lets you access files
	and edit config files to try to get it booting again.
  kernel vmlinuz
  append initrd=initrd.img repo=hd:UUID=3147-B22E:/ root=live:UUID=310D-94BB rescue quiet
label memtest
  menu label Run a ^memory test.
  text help
	If your system is having issues, a problem with your
	system's memory may be the cause. Use this utility to
	see if the memory is working correctly.
  kernel memtest
menu separator # insert an empty line
label local
  menu label Boot from ^local drive.
  localboot 0xffff
menu separator # insert an empty line
menu separator # insert an empty line
label returntomain
  menu label Return to ^main menu.
  menu exit
menu end
#label local
#  menu label Exit this menu and boot from ^local disk.
#  localboot 0xffff
Comment 27 satellitgo 2012-04-18 19:27:12 EDT
I suppose since all that is installed on

 the /dev/sdb1 LIVE partition is

  LiveOS   - 130.4 MB
  syslinux   -  29.4 MB

  Properties: 159.9 MB used
                       5.2 GB  free
  Filesystem type:msdos

 the /dev/sdb2 LIVE-REPO contains a 2.5 GB .iso file.

  Properties: 2.5 GB used
                168.9 MB free
  Filesystem type:msdos

It could be  much smaller.

Looks like a 4 GB USB should work just as well. 
format fat boot flag label=LIVE /dev/sdb1 760MB rest unformatted
Comment 28 Brian Lane 2012-04-18 20:36:24 EDT
Please don't clutter up this bug with livecd-iso-to-disk issues. Open a new bug for that if you are having problems.
Comment 29 Mads Kiilerich 2012-04-19 17:41:47 EDT
(In reply to comment #18)
> Created attachment 576915 [details]
> sh -x 30_os-prober run and stderr output from /sbin/grub2-probe
> This is actually a problem with grub2-probe used in 30_os-prober script.

I guess progress on this bug requires an easy way to reproduce the problem - for example a dump of the problematic partition ... if that can be used to reproduce the problem. strace and valgrind on grub2-probe might also tell something.
Comment 30 satellitgo 2012-04-19 18:41:32 EDT

# dd if=Fedora-17-Beta-x86_64-Live-Desktop.iso of=/dev/sdb bs=2M
323+0 records in
323+0 records out
677380096 bytes (677 MB) copied, 90.7649 s, 7.5 MB/s

Boots fine
Install requires a 2nd 8 GB USB formatted fat with/sdb1 boot flag in disk Utility in f17 
Or a HD

Install to Hard Disk (liveinst)
use whole disk  non lvm (required to get both USB's on left side
 (This is a bug in anaconda for custom)
 delete sdb GPT partition
 create GPT 2
 create /boot ext4 500
 create / ext4 71000
Install works
Comment 31 Adam Williamson 2012-05-04 18:20:44 EDT
So, testing the Beta is uninteresting, I believe, as we shipped RC4.1 as the Beta, remember: the one where we rolled back livecd-tools. The key question is 'does this work with Final TC2'. Can someone please dd an F17 TC2 live image to a USB stick, and try an install from it? If that works, we can close this.

Mads, the reproducer was actually as simple as the above. Nothing more was needed.

Fedora Bugzappers volunteer triage team
Comment 32 satellit 2012-05-04 20:10:36 EDT
dd 16 GB USB TC2 live desktop USB Booted
Install to Hard Disk

with Installed HD gnome3 TC2 /dev/sda 

Use whole disk

warns that the following pre-existing devices have been selected to be formatted destroying all data:
dev/sda Partition table (GPT) 
dev/sdb Partition table (GPT)

I did not proceede 

delete GPT Partiton
sdc1 Bios Boot 2
sdc2 /boot ext4 500
sdc3 / ext4 14500
 error: you have not created a bootloader stage1 target device ?

Will remove laptop HD and repeat
Comment 33 satellit 2012-05-04 20:57:35 EDT
* Note 4 GB USB is too small:
-message "live install requires a /partition of 4096"

works with laptop HD removed:
Used Disk Utility (Disks) on live USB to format 8 GB USB fat with /dev/sda1 fat LIVE boot flag set


Note got failure message if /dev/sda1 is mounted
Had to un-mount /dev/sda1 in Disk-Utility

* start anaconda again
-need to select use whole disk to get 2 USB's to left side of selection screen
(It is not possible to move USB's on right side in Custom)
-Hit back and select custom
(Now the 2 USB's are on the left side)
-Delete GPT on /dev/sda
 Bios Boot 2
 /boot ext4 500
 / ext4 7500
*Install proceeds. And Works

I am not happy about the GPT partition of the installed HD in the laptop would be wiped..... Comment 32
Comment 34 Adam Williamson 2012-05-07 19:51:54 EDT
So, dd'ing the Final TC3 DVD image, I hit an interesting wrinkle. The install works...and then there's two OS X entries on the grub2.cfg of the installed system! So the OS X detection stuff no longer crashes, but it still thinks the stick is an installed OS X system. Is there any way we can avoid this? I'll double check that this occurs with a dd'ed live image as well.

Fedora Bugzappers volunteer triage team
Comment 35 Adam Williamson 2012-05-08 02:27:43 EDT
Updating the summary, and dropping acceptedblocker, because this has now changed quite a bit from the initial report: it installs, but bogus OS X entries are in the bootloader menu. We should re-evaluate the blockeriness of the bug now its symptoms are significantly altered.

Fedora Bugzappers volunteer triage team
Comment 36 Mads Kiilerich 2012-05-08 06:44:33 EDT
(In reply to comment #34)
> ... there's two OS X entries on the grub2.cfg of the installed
> system! So the OS X detection stuff no longer crashes, but it still thinks the
> stick is an installed OS X system.

I guess further debugging of this issue through the bug tracker would need a generated grub.cfg and the output of 'os-prober'.

Even more helpful might be the output of os-prober when /usr/share/os-prober/ has been tweaked to start with
newns () {
  [ "$OS_PROBER_NEWNS" ] || exec /usr/libexec/newns bash -x "$0" "$@"

I assume it is a hard problem for os-prober to distinguish OS's on external hard drives (that should be included in the boot menu) from OS's on removable 'hard' drives. os-prober will however apparently not list for example bios/mbr bootable USB drives, so I guess it also shouldn't list removable bootable mac devices.
Comment 37 Adam Williamson 2012-05-09 20:10:32 EDT
Created attachment 583401 [details]
30_os-prober output with bash -x
Comment 38 Mads Kiilerich 2012-05-09 21:33:18 EDT
Someone more familiar with os-prober could probably have done without this output, but it convinced me how os-prober is being tricked by these new fancy multi-partitioned CDs.

The purpose of this new HFS partition is to make it look like a Mac OS - and /usr/libexec/os-probes/mounted/20macosx is tricked too.

The reason other kinds of bootable partitions on removable media isn't detected is that os-prober look for details of installed OS's and there is no tester for 'syslinux live cd'.

I guess os-prober should learn to ignore this kind of fake Mac partitions (and probably also mactel). I will thus reassign to os-prober.

MJG can probably describe a way to distinguish real and fake Mac OS's. CC'ing him.

I haven't seen it stated explicitly above that the weird thing is that these entries appear on non-apple non-EFI machines too. A simple ugly workaround could perhaps be to check for that in 20macosx - that would reduce the impact of this bug a lot.
Comment 39 Adam Williamson 2012-05-09 23:43:18 EDT
mads: oh, yeah, the system I'm testing on is a self-build PC and I did a BIOS install (you actually don't see these entries on an EFI install, of course, because it doesn't use grub2). I didn't think of that as weird, though, it kinda seemed 'obvious' to me that os-prober would detect an OS X install on a non-Mac. I don't think it should assume that only Macs will have OS X, there are people who install it on generic PCs (even if that's technically license infringement or whatever).

Fedora Bugzappers volunteer triage team
Comment 40 Hedayat Vatankhah 2012-05-10 04:48:58 EDT
Currently, 20macosx relies on a file named /mach_kernel in the HFS partition to detect MacOSX. If the partition contains a "fake" MacOSX, we need a way to distinguish between these two. Any help is highly appreciated. With more details (and/or pointers for the solution), I will also open a bug upstream.
Comment 41 Peter Jones 2012-05-10 14:49:41 EDT
Created attachment 583651 [details]
This patch makes 20macosx ignore our dummy mach_kernel files.
Comment 43 Peter Jones 2012-05-10 14:52:06 EDT
Gah, ignore that.  I'll supply a real fixed patch in a moment.
Comment 44 Peter Jones 2012-05-10 14:53:54 EDT
Created attachment 583652 [details]
This patch makes 20macosx ignore our dummy mach_kernel files.
Comment 45 Hedayat Vatankhah 2012-05-10 16:13:54 EDT
Thanks for the patch. But I just wonder if it is limited to Fedora?! ("our" dummy mach_kernel?). If so, I'll just add it as a Fedora-only patch and not inform upstream about it.
Comment 46 Adam Williamson 2012-05-10 17:52:50 EDT
pjones is working on a build. I wouldn't call the change fedora-specific exactly - after all, you might happen to have a fedora live stick plugged in while doing a grub install from ubuntu, or something. stranger things have happened. unless any valid OS X install would ever have 'Dummy' right where our fake one does, it seems like a safe and upstreamable change, wdyt pjones?

note the patch as posted is broken, it has a stray ]. we have a fixed scratch build and pjones will do a fixed real build soon.

Fedora Bugzappers volunteer triage team
Comment 47 Fedora Update System 2012-05-10 18:46:16 EDT
os-prober-1.52-3.fc17 has been submitted as an update for Fedora 17.
Comment 48 Mads Kiilerich 2012-05-10 19:17:37 EDT
I assume there will be the same problem with the fake hfs ESP partition that goes with mactel-boot.x86_64?

(There might be cases where the boot loader on that partition is the best way to start _another_ linux os, but usually there will have been generated "local" entries without os-prober and the hfs partition should thus be skipped.)

mactel-boot contains a mach_kernel with "This file is required for booting" and this "Dummy" workaround will thus not work.

It seems like os-prober should detect both, or even better that mactel-boot mach_kernel followed the same "protocol" and also started with "Dummy".
Comment 49 Adam Williamson 2012-05-10 23:06:09 EDT
For voting purposes: I think the current incarnation of this bug is really borderline for blocker status - it doesn't exactly break anything but it looks pretty bad. I'm definitely +1 NTH, we should take the fix.

Fedora Bugzappers volunteer triage team
Comment 50 Adam Williamson 2012-05-10 23:06:45 EDT
Oh, hell, someone should probably test that it can still detect *real* OS X installs.
Comment 51 Peter Jones 2012-05-11 08:50:52 EDT
(In reply to comment #45)
> Thanks for the patch. But I just wonder if it is limited to Fedora?! ("our"
> dummy mach_kernel?). If so, I'll just add it as a Fedora-only patch and not
> inform upstream about it.

Yeah - at this point it really is limited to Fedora.  At some point we'll probably want to look into some way to tell Fedora from RHEL from other OSes that may wind up using the code mjg59 wrote.
Comment 52 Fedora Update System 2012-05-11 13:27:35 EDT
os-prober-1.53-1.fc17 has been submitted as an update for Fedora 17.
Comment 53 Fedora Update System 2012-05-11 13:27:43 EDT
os-prober-1.53-1.fc17 has been submitted as an update for Fedora 17.
Comment 54 Fedora Update System 2012-05-11 17:51:11 EDT
Package os-prober-1.53-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing os-prober-1.53-1.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 55 Adam Williamson 2012-05-11 20:58:23 EDT
Discussed at 2012-05-11 blocker review meeting: . This was rejected as a blocker as it doesn't really break any criteria, the install works and boots. However, it is accepted as NTH as it looks bad and may be confusing to users. It can't be fixed with an update, as the problem happens at install time.

Fedora Bugzappers volunteer triage team
Comment 56 Fedora Update System 2012-05-15 01:26:11 EDT
os-prober-1.53-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.