Description of problem: Used liveCD to install fc17 beta to a custom layout via a USB memory stick created via liveusb-creator. Install appeared to have worked, but when I try to boot, all I get is GRUB on the screen. Also, when I try to boot other Linux systems on the disk, they all die. Boot loader is NOT in MBR, but is in / of fc17. Version-Release number of selected component (if applicable): fc 17 beta for 32-bit Intel x86 Actual results: fc17 boot starts, but dies with GRUB on screen. Existing fc16 boot starts, get GRUB menu to choose system, but then get many messages about xxx failed. System hangs before window manager comes up. Same with fc15 and fc14. Had to restore from backups fc14, fc15, fc16, which now work. Expected results: fc17, fc16, fc15, fc14 would boot. Additional info: /dev/sda1 = Windows Vista (not used in custom layout) /dev/sda2 = Sun Solaris (not used in custom layout) /dev/sda3 = OS/2 boot manager (not used in custom layout) /dev/sda4 = Extended /dev/sda5 = /spare5 (formated by fc17 as ext4) /dev/sda6 = swap (formated by fc17 as swap) /dev/sda7 = / (formated by fc17 as ext4) /dev/sda8 = /fedora16 (just mount point to fc17) /dev/sda9 = /fedora15 (just mount point to fc17) /dev/sda10= /fedora14 (just mount point to fc17) /dev/sda11= /lindata (just mount point to fc17) /dev/sda12= fat16 (not used in custom layout) /dev/sda13= fat16 (just mount point /data2 to fc17) /dev/sda14= fat16 (not used in custom layout) /dev/sda15= fat32 (just mount point /data3 to fc17) /dev/sda16= hpfs (not used in custom layout) rest of disk (another 6 or so partitions) not used in custom layout. Using fc16 to look at the fc17 partition, I notice that /fc17/boot/grub2/device.map has (hd0) /dev/sda (hd0,msdos7) /dev/sda7 while fc16 has (hd0) /dev/sda (hd0,8) /dev/sda8 I will try another install, but this time choose just / and swap in the custom layout.
Install from LiveCD using custom configuration to just / and swap resulted in a fc17 system that will not boot. Just GRUB appears on the screen. At least this time, the other FC systems were left alone and continue to boot.
In my fc15 system, I added an entry for fc17 to grub.conf. I booted fc15 and picked fc17 from the grub menu. That booted fc17 where I did the first boot stuff. So, it appears that the LiveCD installs a bad grub2 configuration.
I see that the problem of booting fc17 and getting just "GRUB" on the display is a duplicate of bug 804835. But, the fact that an install to hard disk from LiveCD made other Fedora partitions unbootable is a new bug and a potential beta blocker.
Description of problem: Installed from Fedora-17-Nightly-20120416.08-x86_64-Live-lxde.iso with grub in / of F17. I use a custom partitioning scheme with legacy grub in the MBR pointing to a boot partition (/dev/sda2) from which F16's and F17's grub2 in chainloaded. Will not boot. Manual editing of F16's /boot/grub2/grub.cfg file to include an entry for F17 enabled me to boot.
Please attach /var/log/anaconda/anaconda.storage.log and /var/log/anaconda/anaconda.program.log to this bug (one at a time and as type text/plain). Thanks.
Created attachment 583089 [details] anaconda.storage.log anaconda.storage.log
Created attachment 583090 [details] anaconda.program.log
Created attachment 583091 [details] program log
Created attachment 583092 [details] storage log
Since those logs are from my 2nd install (the one where I only used / and swap), it is not clear how much they will help. Also, I think I have /dev/sda3 and /dev/sda4 backwards. The IBM OS/2 boot manager (a primary partition) is the last cylinder of the disk, so would be sda4.
(In reply to comment #4) > Description of problem: > Installed from Fedora-17-Nightly-20120416.08-x86_64-Live-lxde.iso with grub in > / of F17. I use a custom partitioning scheme with legacy grub in the MBR > pointing to a boot partition (/dev/sda2) from which F16's and F17's grub2 in > chainloaded. Will not boot. Manual editing of F16's /boot/grub2/grub.cfg file > to include an entry for F17 enabled me to boot. Correct me if I'm wrong, but you want to boot a bootloader in the MBR, have it chainload the F16 grub, which in turn chainloads F17 grub? Any time you install the F17 bootloader to a partition, the task of adding an entry to your main bootloader to chainload the F17 bootloader is on you. The fedora installer will not modify bootloader configurations outside of what it has been instructed to modify/configure.
(In reply to comment #3) > I see that the problem of booting fc17 and getting just "GRUB" on the display > is a duplicate of bug 804835. > > But, the fact that an install to hard disk from LiveCD made other Fedora > partitions unbootable is a new bug and a potential beta blocker. Can you explain a bit more what exactly is not working that was previously working? Did it break your main (MBR) bootloader so that it cannot load itself? Or, does it appear to have altered its configuration such that it no longer knows how to find/load the other OSes? Or, are you saying that it still knows where/how to load those other OSes but the boot block and/or /boot directory of those other OSes has somehow been altered?
The MBR bootloader (IBM's OS/2 bootloader that takes one cylinder in a primary partition) still worked. From it, I could pick Windows, OS/2, Solaris, and fc14, fc15, fc16, fc17. Windows, OS/2 and Solaris still could be booted. Picking fc17 got just GRUB on the screen (bug 804835). Picking any of fc14, fc15, fc16 got a GRUB menu to pick an OS to boot. When I picked the latest kernel for any of fc14, fc15, fc16, I got (after pressing Alt-D) many error messages about things not found. And a window manager would not start. So, it appears that the install of fc17 altered the /boot in each of fc14, fc15, fc16. This only happened when I told the installer of fc17 about swap, /, /fc14, /fc15, /fc16, and some data partitions. My workaround for bug 804835 is to have fc15 load a kernel and ramfs (not chainload) of fc17. I understand grub of fc15 so can edit the config file. I do not understand grub2 of fc16, so leave its config file alone.
I think your setup is a bit too complex for us to support.