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-prober | Assignee: | Hedayat Vatankhah <hedayatv> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | 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 05:26:11 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 752653 | ||
Attachments: |
Description
Adam Williamson
2012-04-11 01:00:15 UTC
Created attachment 576634 [details]
storage.log from the failed install
Created attachment 576635 [details]
program.log from the failed install
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. 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. Confirming this is a regression vs RC3. RC3 works fine. 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... 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. Created attachment 576646 [details]
screenshot
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. 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 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 https://fedoraproject.org/wiki/BugZappers Sounds like a +1 blocker for me -- lots of people use the functionality. For the record, my vote is +1 for *beta blocker* I think this is a common enough use case that it should be a beta blocker. +1 beta blocker +1 beta blocker 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 https://fedoraproject.org/wiki/BugZappers my vote is to ship RC4.1 for live 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 was able to install via RC4.1, usb stick created in windows using live usb creator and able to install to hard drive. Please don't close this, it needs to be fixed in grub2. dd USB of Beta[1] x86-64 installs to external USB HD successfully [1]http://kojipkgs.fedoraproject.org/images/livecd/443/443/Fedora-17-Beta-x86_64-Live-Desktop.iso ./tools_livecd-iso-to-disk.sh --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 8 GB USB formatted as GPT with 4 GB partition fat /dev/sdb1 2nd 4 GB left unformatted # ./tools_livecd-iso-to-disk.sh --format --reset-mbr Fedora-17-Beta-x86_64-DVD.iso /dev/sdb1 Verifying image... ./tools_livecd-iso-to-disk.sh: 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 WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdb!!! 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. squashfs.img 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 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! # Install completed and booted to firstboot/smolt/gdm/gnome3.4.0 _Wireless AP configured in anaconda was connected on boot. 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 grub.conf debug --graphics default=0 splashimage=@SPLASHPATH@ timeout 5 hiddenmenu title Fedora 17-Beta findiso kernel @KERNELPATH@ @ROOT@ rd.luks=0 rd.md=0 rd.dm=0 initrd @INITRDPATH@ syslinux.cfg 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 rd.md=0 rd.dm=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 Fedora. endtext kernel vmlinuz append initrd=initrd.img repo=hd:UUID=3147-B22E:/ root=live:UUID=310D-94BB xdriver=vesa nomodeset quiet rd.luks=0 rd.md=0 rd.dm=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. endtext 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. endtext 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 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. Testing: format fat boot flag label=LIVE /dev/sdb1 760MB rest unformatted Please don't clutter up this bug with livecd-iso-to-disk issues. Open a new bug for that if you are having problems. (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. 2 GB USB # 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) (back) Custom delete sdb GPT partition create GPT 2 create /boot ext4 500 create / ext4 71000 Install works 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 https://fedoraproject.org/wiki/BugZappers dd 16 GB USB TC2 live desktop USB Booted Install to Hard Disk Anaconda: 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 custom: 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 * 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 *Anaconda: 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 -create Bios Boot 2 /boot ext4 500 / ext4 7500 NO SWAP *Install proceeds. And Works I am not happy about the GPT partition of the installed HD in the laptop would be wiped..... Comment 32 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 https://fedoraproject.org/wiki/BugZappers 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 https://fedoraproject.org/wiki/BugZappers (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/common.sh 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. Created attachment 583401 [details]
30_os-prober output with bash -x
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. 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 https://fedoraproject.org/wiki/BugZappers 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. Created attachment 583651 [details]
This patch makes 20macosx ignore our dummy mach_kernel files.
Gah, ignore that. I'll supply a real fixed patch in a moment. Created attachment 583652 [details]
This patch makes 20macosx ignore our dummy mach_kernel files.
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. 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 https://fedoraproject.org/wiki/BugZappers os-prober-1.52-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/os-prober-1.52-3.fc17 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". 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 https://fedoraproject.org/wiki/BugZappers Oh, hell, someone should probably test that it can still detect *real* OS X installs. (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. os-prober-1.53-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/os-prober-1.53-1.fc17 os-prober-1.53-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/os-prober-1.53-1.fc17 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: https://admin.fedoraproject.org/updates/FEDORA-2012-7706/os-prober-1.53-1.fc17 then log in and leave karma (feedback). Discussed at 2012-05-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-11/f17-final-blocker-review-meeting-5.2012-05-11-17.04.html . 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 https://fedoraproject.org/wiki/BugZappers 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. |