Bug 973424
Description
Joseph Pesco
2013-06-11 22:36:00 UTC
Have you tried again with F19 Final? What does "os-prober" show? Joseph: To reply to questions in a bug comment, click the reply link for it. (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. 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.) anaconda.log anaconda.packaging.log anaconda.program.log anaconda.storage.log syslog 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 Created attachment 773143 [details]
hostname: weaver, file syslog
Created attachment 773144 [details]
hostname: weaver, file anaconda.storage.log
Created attachment 773145 [details]
hostname: weaver, file anaconda.program.log
Created attachment 773146 [details]
hostname: weaver, file anaconda.packaging.log
Created attachment 773147 [details]
hostname: weaver, file anaconda.log
Created attachment 773148 [details]
hostname: weaver, file os-prober.report.071313
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. Attached: anaconda.log anaconda.packaging.log anaconda.program.log anaconda.storage.log syslog os-prober.report.071313 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. 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 ... 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 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 ... 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 Created attachment 774521 [details]
hostname: weaver, This tarball contains anaconda logs, os-prober report, along with parted listings for weaver and reeding.
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, joe Created attachment 774575 [details]
anaconda.log
Created attachment 774576 [details]
anaconda.packaging.log
Created attachment 774577 [details]
anaconda.program.log
Created attachment 774578 [details]
anaconda.storage.log
Created attachment 774579 [details]
df.report.reeding.071613
Created attachment 774581 [details]
df.report.weaver.071613
Created attachment 774582 [details]
syslog
Created attachment 774585 [details]
parted.report.reeding.071613
Created attachment 774586 [details]
parted.report.weaver.071613
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 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 ... Created attachment 775499 [details]
hostname: weaver, os-prober report
This report was generated by os-prober-1.58-1.fc19.i686.
I've anaconda.storage.log open. I'll check out the ntfs utility next. (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', 'ID_FS_LABEL': 'PQSERVICE', 'DEVNAME': 'sda2', 'ID_FS_LABEL': 'SYSTEM_RESERVED', 'DEVNAME': 'sda3', 'ID_FS_LABEL': 'Acer', ... 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 http://www.gnu.org/software/grub/manual/ grub2 config files: /etc/default/grub /etc/grub.d/* grub2 packages: $ rpm -qa 'grub2*' | sort 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. 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. 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? 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. 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: https://dl.fedoraproject.org/pub/alt/stage/19-Beta-RC4/Fedora/x86_64/iso/Fedora-19-Beta-x86_64-netinst.iso 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. 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: ... 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 kernel-3.9.9-302 == 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: ntfs-3g-2013.1.13-5 ntfsprogs-2013.1.13-5 kernel-3.9.9-302 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.) 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 AOK, thanks for letting me help. 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.
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 #!/bin/sh 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 } *** This bug has been marked as a duplicate of bug 964586 *** |