Bug 973424 - Windows 7 Installation wasn't added to boot menu.
Windows 7 Installation wasn't added to boot menu.
Status: CLOSED DUPLICATE of bug 964586
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-11 18:36 EDT by Joseph Pesco
Modified: 2013-08-08 11:28 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-08 11:28:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
hostname: weaver, file syslog (105.85 KB, text/plain)
2013-07-13 15:33 EDT, Joseph Pesco
no flags Details
hostname: weaver, file anaconda.storage.log (295.65 KB, text/x-log)
2013-07-13 15:36 EDT, Joseph Pesco
no flags Details
hostname: weaver, file anaconda.program.log (49.84 KB, text/x-log)
2013-07-13 15:39 EDT, Joseph Pesco
no flags Details
hostname: weaver, file anaconda.packaging.log (942.31 KB, text/x-log)
2013-07-13 15:41 EDT, Joseph Pesco
no flags Details
hostname: weaver, file anaconda.log (37.31 KB, text/x-log)
2013-07-13 15:43 EDT, Joseph Pesco
no flags Details
hostname: weaver, file os-prober.report.071313 (127 bytes, text/plain)
2013-07-13 15:44 EDT, Joseph Pesco
no flags Details
hostname: weaver, This tarball contains anaconda logs, os-prober report, along with parted listings for weaver and reeding. (1.27 MB, application/x-tar)
2013-07-16 18:44 EDT, Joseph Pesco
no flags Details
anaconda.log (18.31 KB, text/plain)
2013-07-16 21:28 EDT, Steve Tyler
no flags Details
anaconda.packaging.log (933.17 KB, text/plain)
2013-07-16 21:29 EDT, Steve Tyler
no flags Details
anaconda.program.log (101.10 KB, text/plain)
2013-07-16 21:29 EDT, Steve Tyler
no flags Details
anaconda.storage.log (127.36 KB, text/plain)
2013-07-16 21:30 EDT, Steve Tyler
no flags Details
df.report.reeding.071613 (608 bytes, text/plain)
2013-07-16 21:31 EDT, Steve Tyler
no flags Details
df.report.weaver.071613 (714 bytes, text/plain)
2013-07-16 21:31 EDT, Steve Tyler
no flags Details
syslog (102.80 KB, text/plain)
2013-07-16 21:32 EDT, Steve Tyler
no flags Details
parted.report.reeding.071613 (2.28 KB, text/plain)
2013-07-16 21:33 EDT, Steve Tyler
no flags Details
parted.report.weaver.071613 (2.28 KB, text/plain)
2013-07-16 21:34 EDT, Steve Tyler
no flags Details
hostname: weaver, os-prober report (123 bytes, text/plain)
2013-07-18 16:17 EDT, Joseph Pesco
no flags Details
hostname: weaver: grub.cfg (4.65 KB, text/plain)
2013-07-27 11:44 EDT, Joseph Pesco
no flags Details

  None (edit)
Description Joseph Pesco 2013-06-11 18:36:00 EDT
Description of problem:
After installation Windows 7 partitions a.o.k. though not available.

Version-Release number of selected component (if applicable):
f19 i386 beta bfo installation

How reproducible:
Easily, perhaps this is as designed behavior?

Steps to Reproduce:
1. Install Windows 7
2. Boot from usb with bfo
3. Alot 100G of 320 GB HD to f19 beta

Actual results:
Boot and recovery mode boot for f19 beta.

Expected results:
Boot, recovery boot, and Win 7 boot option.  

Additional info:
(I'm reading through the duplicates list as well.)  I don't normally dual boot though I often install.
Comment 1 Steve Tyler 2013-07-08 11:04:59 EDT
Have you tried again with F19 Final?
What does "os-prober" show?
Comment 2 Steve Tyler 2013-07-08 21:51:15 EDT
Joseph: To reply to questions in a bug comment, click the reply link for it.
Comment 3 Joseph Pesco 2013-07-09 18:20:20 EDT
(In reply to Steve Tyler from comment #2)
> Joseph: To reply to questions in a bug comment, click the reply link for it.

I'll run through the procedure soon and get back to you with my results.  I need to research the utility you mentioned as well.  Thank you.
Comment 4 Steve Tyler 2013-07-09 21:30:35 EDT
The developers usually ask for the anaconda log files. Since it sounds like your install succeeded, they should be in /var/log/anaconda/.

Could you attach these log files as separate, uncompressed, text files?
(There is an "Add an attachment" link at the top of the bug report page.)


There is no man page for os-prober, but you can list the documentation with:
$ rpm -qd os-prober
(The log files will be more informative, but os-prober is what is used to find other operating systems when configuring the grub2 boot menu.)

Usage is:
$ sudo os-prober
Comment 5 Joseph Pesco 2013-07-13 15:33:15 EDT
Created attachment 773143 [details]
hostname: weaver, file syslog
Comment 6 Joseph Pesco 2013-07-13 15:36:20 EDT
Created attachment 773144 [details]
hostname: weaver, file anaconda.storage.log
Comment 7 Joseph Pesco 2013-07-13 15:39:24 EDT
Created attachment 773145 [details]
hostname: weaver, file anaconda.program.log
Comment 8 Joseph Pesco 2013-07-13 15:41:45 EDT
Created attachment 773146 [details]
hostname: weaver, file anaconda.packaging.log
Comment 9 Joseph Pesco 2013-07-13 15:43:08 EDT
Created attachment 773147 [details]
hostname: weaver, file anaconda.log
Comment 10 Joseph Pesco 2013-07-13 15:44:17 EDT
Created attachment 773148 [details]
hostname: weaver, file os-prober.report.071313
Comment 11 Joseph Pesco 2013-07-13 16:02:37 EDT
As per your request the the logs are attached.  The delay in responded can be attributed to reading "fedoraproject/wiki/bugs_and_feature_requests" and similiar documentation.  I burned an f19-i386-release DVD last week, but did not reinstall f19 on top of Windows 7 using bfo.  I can though without any difficulty.    

Comment 12 Steve Tyler 2013-07-13 16:49:37 EDT
Thanks for the attachments. I can't see any Windows file systems in them.

The installer is not seeing any NTFS or vfat partitions.

The os-prober output suggests Windows should be on sda2, but that is an LVM physical volume. What partition do you believe should have Windows?

This is based on anaconda.storage.log (sizes in MB are in parentheses, IIUC):

sda:  ATA ST320LT012-9WS14 (305245.335938)
  sda1: ext4  (500.0)
  sda2: LVM physical volume
    17:49:26,148 DEBUG blivet: vg size is 304736MB
    17:49:26,153 DEBUG blivet: vg vg has 56928MB free

sdb: Kingston_DataTraveler_109_00D0C9CCDF19EBC1C0005560-0:0 (7441.6875)

sdc: Multiple_Card_Reader_058F63666435-0:0 (7580.0)

Disclaimer: I am far from expert at interpreting the installer log files.
Comment 13 Steve Tyler 2013-07-13 18:01:05 EDT
In your original report you said you installed to the 320 GB HD. It looks like you were installing to sdc, which is the card reader, when these logs were saved. Is that what you meant to do?

Snippet from anaconda.log:
17:55:22,506 INFO anaconda: Setting up the installation environment
17:55:22,899 INFO anaconda: Creating disklabel on /dev/sdc
17:55:25,462 INFO anaconda: Creating lvmpv on /dev/sdc2
17:55:27,264 INFO anaconda: Creating ext4 on /dev/mapper/fedora_x-root
17:55:38,044 INFO anaconda: Creating swap on /dev/mapper/fedora_x-swap
17:55:38,493 INFO anaconda: Creating ext4 on /dev/sdc1
18:17:07,961 INFO anaconda: Performing post-installation setup tasks
18:17:08,022 INFO anaconda: Installing bootloader
18:17:08,023 INFO anaconda: bootloader stage1 target device is sdc
18:17:08,024 INFO anaconda: bootloader stage2 target device is sdc1
Comment 14 Steve Tyler 2013-07-13 18:31:59 EDT
Could you look for installer log files on your 320 GB drive (sda)? Those might show what happened to the Windows partition. If you can boot from sda, they should be in /var/log/anaconda/.
(I'm guessing you have *two* sets of log files, one on sda and one on sdc.)

You can get a good overview of your disks, partitions, and logical volumes with the "lsblk" command:
$ lsblk -mf
Comment 15 Steve Tyler 2013-07-13 23:12:54 EDT
The file systems on sda were created in 2012.
Is this system the one that had Windows?

Snippets from anaconda.program.log:
17:49:23,828 INFO program: Running... dumpe2fs -h /dev/sda1
17:49:23,944 INFO program: Filesystem created:       Mon Sep 10 19:58:35 2012
17:49:25,833 INFO program: Running... dumpe2fs -h /dev/mapper/vg-lv_home
17:49:25,974 INFO program: Filesystem created:       Mon Sep 10 19:58:41 2012
17:49:26,354 INFO program: Running... dumpe2fs -h /dev/mapper/vg-lv_root
17:49:26,484 INFO program: Filesystem created:       Mon Sep 10 20:00:32 2012
Comment 16 Steve Tyler 2013-07-14 13:31:46 EDT
In the attached syslog, os-prober reports LVM data on /dev/sda2, not Windows.
Are you working with more than one system?

Snippet from attached syslog:
18:17:25,584 NOTICE logger: os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on /dev/sda2
18:17:25,606 NOTICE logger: 50mounted-tests: debug: skipping LVM2 Volume Group on /dev/sda2

Contents of attached os-prober.report.071313:
/dev/sda2:Windows 7 (loader):Windows:chain
/dev/mapper/fedora_chenw-root:Fedora release 19 (Schrödinger’s Cat):Fedora:linux
Comment 17 Joseph Pesco 2013-07-16 18:44:33 EDT
Created attachment 774521 [details]
hostname: weaver, This tarball contains anaconda logs, os-prober report, along with parted listings for weaver and reeding.
Comment 18 Joseph Pesco 2013-07-16 19:38:47 EDT
Hi Steve, 

Sorry Steve, for having you read through the incorrect logs files!  My bad.  The installation "weaver" is on a 320G hd that also contains Win7 as stated in the original report.  

The earlier log files sent are from an f19-beta-x86_64 installation to an 8G sd card, this installation is called "reeding" and has been my prime installation for several weeks.  I'm attempting to move up to `f19-release-i386.16Gsd.sunbird'.  I had thought before the release of f19 to build a chart with the three filesystems in one direction and i386, x86_64 in the other direction, then do the installations.  I held myself in check.     

As part of this homework assignment log files placed in the tarball have been examined and extra care taken to identify the HD in the machine as the correct HD. The parted listings in the tarball have been diffed and notes concerning the logical volume varations made.  I'm only now beginning to use logical volumes!  The 32G USB device is a vfat general use storage.  The tarball was created on it.  The 8G USB device is the sd card containing reeding.

I've cooked up a clone on weaver of firefox and build the binaries, but they are aging fast and I've not done a thing with them.  To day I went to install vim-enhanced on sunbird.  Most of the packages are already upgrades!

At your service, and yours truly,
Comment 19 Steve Tyler 2013-07-16 21:28:23 EDT
Created attachment 774575 [details]
Comment 20 Steve Tyler 2013-07-16 21:29:04 EDT
Created attachment 774576 [details]
Comment 21 Steve Tyler 2013-07-16 21:29:42 EDT
Created attachment 774577 [details]
Comment 22 Steve Tyler 2013-07-16 21:30:29 EDT
Created attachment 774578 [details]
Comment 23 Steve Tyler 2013-07-16 21:31:03 EDT
Created attachment 774579 [details]
Comment 24 Steve Tyler 2013-07-16 21:31:47 EDT
Created attachment 774581 [details]
Comment 25 Steve Tyler 2013-07-16 21:32:14 EDT
Created attachment 774582 [details]
Comment 26 Steve Tyler 2013-07-16 21:33:32 EDT
Created attachment 774585 [details]
Comment 27 Steve Tyler 2013-07-16 21:34:12 EDT
Created attachment 774586 [details]
Comment 28 Steve Tyler 2013-07-16 23:51:31 EDT
Thanks for the logs.

Could you attach your os-prober output too? (It isn't in the tar file.)

The installer detected NTFS file systems on sda1, sda2, and sda3 (anaconda.storage.log).

AFAICT, os-prober did not detect anything on sda1, sda2, or sda3 (syslog).

The install version was os-prober-1.58-1.fc19.i686 (per anaconda.packaging.log), but there is a newer version.

What is your current version of os-prober?
$ rpm -q os-prober

Also, os-prober writes debug output to /var/log/messages each time it is run. Could you attach /var/log/messages from the system where you ran os-prober?

BTW, the ntfsprogs package has various tools for NTFS file systems.
This will show information about an NTFS file system:
$ sudo ntfsinfo -m /dev/sda3
(From your logs, sda3 was resized during the install.)

The ntfsprogs documentation can be listed with:
$ rpm -qd ntfsprogs
Comment 29 Steve Tyler 2013-07-17 00:08:51 EDT
The two parted files shows identical partitioning. The problem is that they both show sda1 as fat32, but the installer detected sda1 as NTFS:

Snippet from parted.report.weaver.071613:

Model: ATA ST9320325AS (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  14.0GB  14.0GB  primary   fat32        diag
 2      14.0GB  14.1GB  105MB   primary   ntfs         boot
 3      14.1GB  215GB   201GB   primary   ntfs
 4      215GB   320GB   105GB   extended
 5      215GB   216GB   524MB   logical   ext4
 6      216GB   320GB   104GB   logical                lvm
Comment 30 Joseph Pesco 2013-07-18 16:17:46 EDT
Created attachment 775499 [details]
hostname: weaver, os-prober report

This report was generated by os-prober-1.58-1.fc19.i686.
Comment 31 Joseph Pesco 2013-07-18 16:35:12 EDT
I've anaconda.storage.log open.  I'll check out the ntfs utility next.
Comment 32 Steve Tyler 2013-07-18 18:13:40 EDT
(In reply to Steve Tyler from comment #29)
> The two parted files shows identical partitioning. The problem is that they
> both show sda1 as fat32, but the installer detected sda1 as NTFS:

Maybe the partition type is wrong.
Were sda1, sda2, and sda3 created by the Windows installer?
Do you know what should be on sda1 -- a recovery partition?

$ egrep "DEVNAME|'ID_FS_LABEL'" anaconda.storage.log
 'DEVNAME': 'sda1',
 'DEVNAME': 'sda2',
 'DEVNAME': 'sda3',
 'ID_FS_LABEL': 'Acer',
Comment 33 Steve Tyler 2013-07-18 22:23:21 EDT
Thanks for attaching the os-prober output. A developer will need to take it from here.

Since os-prober is now detecting Windows on sda2, it should be possible to boot Windows by rebuilding /boot/grub2/grub.cfg:

1. Back up /boot/grub2/grub.cfg
   # cp -ip /boot/grub2/grub.cfg /boot/grub2/grub.cfg.BAK1

2. Rebuild /boot/grub2/grub.cfg:
   # grub2-mkconfig -o /boot/grub2/grub.cfg
   NB: grub.cfg is just a text file.

3. Reboot and see what you get in the grub2 menu.

grub2 documentation:
$ info grub2

grub2 config files:

grub2 packages:
$ rpm -qa 'grub2*' | sort
Comment 34 Joseph Pesco 2013-07-20 18:49:53 EDT
I'm still putting together a responce to the previous request: 

Yes, thank you! The first hd has the OEM Microsoft Windows 7 installation that was supplied when I purchased the machine.  I've done nothing to the best of my knowledge to void any warranty since purchase of this machine.  Though I goofed and did not get the Windows 8 upgrade for $15 dollars, before the experation date for the Windows 8 upgrade offer arrived.  My bad.  We all know how Mr. Gates et al are concerning the "Black Pearl" scenerio: a boatload of bootlegs.  Captain Sparrow thought the rule book fluid the Empire did not.

The first partition (if memory serves) is an installation image for Microsoft Office that is available to the user via a desktop icon.  I'm almost sure.  I was going to check when you asked for the information.  

I purchased a second 320G HD hard drive for Linux almost as soon as I purchased the machine.  I actually had an argument with the salesmen at the local brick and mortar retail store I'm still embarressed about because I was looking to purchase several 320G HDs,I was thinking about purchasing six, and he wouldn't supply a discount!

The installation on the second 320G hd is "f17-x86_64.fightingfalcon."

Sorry for the verbage, I think "attorney" while working and I get long winded.

Thanks for the instructions in comment 33, I've been entering chainloader & boot manually because I didn't know to update the grub2 configuration file I'll let you know how it turns out.
Comment 35 Steve Tyler 2013-07-21 01:33:30 EDT
Hedayat: This bug is reporting that after an F19 Beta install, a Windows 7 installation on sda2 was not listed in the grub2 menu. The attached syslog has debug output from os-prober, but there is no indication that os-prober found anything on sda2.

When os-prober is run on the installed system, it finds Windows 7 on sda2. The output is attached. Also, the Windows 7 installation can be booted by manually entering grub2 commands (Comment 34, last sentence).

Joseph: FYI, I am CCing Hedayat, who is the os-prober maintainer.
Comment 36 Hedayat Vatankhah 2013-07-21 01:48:29 EDT
Thanks for the explanation. I think this bug is probably a duplicate of bug #964586, which IIRC was fixed for F19 Final. The syslog output also is consistent with this assumption.
Would you please try F19 final to see if it works correctly?
Comment 37 Steve Tyler 2013-07-21 02:10:13 EDT
Thanks, Hedayat. Now it all makes sense ... :-)

Joseph, I am guessing you can reproduce this bug by booting the F19 Beta installer in rescue mode and running os-prober from there. Rescue mode is under the Troubleshooting menu item. Skip mounting anything.

NB: I have tried booting the F19 Final DVD in rescue mode on a system with Windows 7, and os-prober finds Windows 7 exactly as expected.
Comment 38 Steve Tyler 2013-07-21 05:54:42 EDT
I burned the F19 Beta netinst CD[1], and booted it in rescue mode.
os-prober finds Windows 7 fine.
Verified that it is running anaconda 19.30-1.
There are 23 ntfs* commands on the CD.

I also tried enabling UEFI boot and booting the CD that way.
Then, os-prober did not report any Windows partitions.
However, os-prober debug messages for the NTFS partitions were in /tmp/syslog.

So that doesn't seem to work as a reproducer ...

[1] F19 Beta netinst CD:
Comment 39 Steve Tyler 2013-07-21 12:31:20 EDT
The attached anaconda.packaging.log does not list any ntfs* packages.

Joseph: Could you attach /var/log/yum.log from the installed system?
Since os-prober is now finding the NTFS partitions and Windows 7, the ntfs* packages must have been installed later.
Comment 40 Steve Tyler 2013-07-21 12:43:16 EDT
This looks like a minimal install ...

Snippet from attached anaconda.packaging.log:
13:43:31,463 DEBUG packaging: Installing passwd.i686 (236/238)
13:43:32,974 DEBUG packaging: Installing man-db.i686 (237/238)
13:43:34,788 DEBUG packaging: Installing iprutils.i686 (238/238)
13:43:36,697 DEBUG packaging: Performing post-installation setup tasks
13:46:44,849 DEBUG packaging: VerifyTransaction time: 46.414
13:46:44,852 INFO packaging:  transaction complete
13:46:44,861 DEBUG packaging: QUIT:
Comment 41 Steve Tyler 2013-07-21 16:57:28 EDT
I think I have it figured out now ... :-)

There are _two_ sets of ntfs* commands. One set is in the installer environment (ctrl-alt-f2). The second set is in the install target environment. I believe that the installer does a "chroot /mnt/sysimage" at some point. After that, the commands in the installer environment are not accessible.

By doing minimal test installs to a VM disc image pre-partitioned with a 1GB NTFS partition, I have confirmed that F19 Beta does not install ntfs* commands, while F19 Final does install ntfs* commands. Indeed, F19 Beta installs 241 packages, while F19 Final installs 243 packages. The two extra packages are
ntfs-3g and ntfsprogs.

NB: Both F19 Beta and F19 Final have ntfs* commands in the installer environment.

== F18 Beta ==
$ qemu-img create f19-test-3.img 32G

Pre-partition disc with 1GB NTFS partition using gparted.

$ qemu-kvm -m 4096 -hda f19-test-3.img -hdb f18-test-1.img -cdrom ~/xfr/fedora/F19/beta/Fedora-19-Beta-x86_64-netinst.iso -vga std -boot menu=on

anaconda 19.30-1
kernel 3.9.2-301

Do a minimal install.
241 packages installed:
no ntfs packages installed

== F18 Final ==
$ qemu-img create f19-test-3.img 32G

Pre-partition disc with 1GB NTFS partition using gparted.

$ qemu-kvm -m 4096 -hda f19-test-3.img -hdb f18-test-1.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-netinst.iso -vga std -boot menu=on

anaconda 19.30.13-1
kernel 3.9.5-301

Do a minimal install.
243 packages installed:
Comment 42 Joseph Pesco 2013-07-24 10:35:37 EDT
Yes, of course.  The phone was off the hook, needed to code something, back now.

(BTW, my hardware gets very sluggish with anything approaching f19 and qemu.)
Comment 43 Steve Tyler 2013-07-24 11:12:32 EDT
Joseph, Comment 41 is FYI only. If you want to reinstall with F19 Final and report the results, that would be great. If not, that is fine.

In any case, I believe that we have enough information to close this bug as a duplicate of:
Bug 964586 - Anaconda does not isntall ntfs tools to allow OS-Prober to find windows partition and therefore creates no grub.cfg entry
Comment 44 Joseph Pesco 2013-07-24 14:06:32 EDT
  AOK, thanks for letting me help.
Comment 45 Joseph Pesco 2013-07-27 11:44:29 EDT
Created attachment 779120 [details]
hostname: weaver: grub.cfg

grub2.cfg from successful installation of f19 following the procedure described in this report bug.  Note that the installation was from DVD.
Comment 46 Steve Tyler 2013-07-27 12:11:52 EDT
Thanks for your followup report, Joseph. That's very good to hear. sda1 appears to be a recovery partition.[1]

BTW, you can add your own grub2 menu entries by editing /etc/grub.d/40_custom and then running grub2-mkconfig.[2]

[1] Snippet from attached grub.cfg:
menuentry 'Windows Recovery Environment (loader) (on /dev/sda1)' ...
menuentry 'Windows 7 (loader) (on /dev/sda2)' ...

[2] For example:
# cat /etc/grub.d/40_custom 
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'fir' {
        insmod part_gpt
        insmod ext2
        #set root='hd1,gpt2'
        search --no-floppy --label --set=root fir_boot
        configfile /grub2/grub.cfg
Comment 47 David Shea 2013-08-08 11:28:57 EDT

*** This bug has been marked as a duplicate of bug 964586 ***

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