Description of problem: After what seemed to be a successful install of f17 XFCE from a Live USB I rebooted and tried to boot the fresh install only to get a black screen that said GRUB at the top. I asked the installer to put grub in the partition instead of the MBR. The grub in my MBR chainloads to the grub in each of the partitions. This worked fine with f17 Alpha. I've since tried the KDE as well as the XFCE Beta RC1 and RC2 and none of the Beta releases will install a bootable OS. I booted in to one of my other f17 installs and tried to re-install grub to the partition via: [root@neuromancer ppk]# mount /dev/sda8 /mnt/otheros [root@neuromancer ppk]# mount --bind /dev/ /mnt/otheros/dev/ [root@neuromancer ppk]# mount --bind /dev/pts /mnt/otheros/dev/pts/ [root@neuromancer ppk]# mount -t proc none /mnt/otheros/proc/ [root@neuromancer ppk]# chroot /mnt/otheros/ /bin/bash [root@neuromancer /]# grub2-install /dev/sda8 /sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding. /sbin/grub2-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /sbin/grub2-bios-setup: error: will not proceed with blocklists. [root@neuromancer /]# grub2-install -f /dev/sda8 /sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding. /sbin/grub2-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. Installation finished. No error reported. Rebooting and trying to boot again yielded the same results as before. Looking in /boot/grub2 shows a lot fewer files than expected: [root@neuromancer grub2]# ls /mnt/otheros/boot/grub2/ device.map grub.cfg grubenv i386-pc locale themes The 3 versions of f17 I have installed now I had to install from the Alpha Live USBs and then yum update. Version-Release number of selected component (if applicable): f17 How reproducible: every time Steps to Reproduce: 1. install from live cd and put grub in a partiton instead of MBR 2. try to boot 3. Actual results: Expected results: Additional info:
Tried installing the Gnome version of Beta RC2 and had the same results. Here are the grub related bits of the program.log file: 00:02:17,979 INFO program: Running... grub2-set-default Fedora Linux, with Linux 3.3.0-1.fc17.x86_64 00:02:18,047 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg 00:02:18,144 ERR program: Generating grub.cfg ... 00:02:18,221 ERR program: Found linux image: /boot/vmlinuz-3.3.0-1.fc17.x86_64 00:02:18,231 ERR program: Found initrd image: /boot/initramfs-3.3.0-1.fc17.x86_64.img 00:02:18,374 ERR program: Warning: Please don't use old title `Fedora Linux, with Linux 3.3.0-1.fc17.x86_64' for GRUB_DEFAULT, use `Advanced options for Fedora Linux>Fedora Linux, with Linux 3.3.0-1.fc17.x86_64' (for versions before 2.00) or `gnulinux-advanced-a1481d2b-ef09-4425-8688-03ca17ae2732>gnulinux-3.3.0-1.fc17.x86_64-advanced-a1481d2b-ef09-4425-8688-03ca17ae2732' (for 2.00 or later) 00:02:19,148 ERR program: No volume groups found 00:02:21,636 ERR program: Found Fedora release 16 (Verne) on /dev/sda1 00:02:22,445 ERR program: Found Fedora release 17 (Beefy Miracle) on /dev/sda3 00:02:23,409 ERR program: Found Fedora release 17 (Beefy Miracle) on /dev/sda7 00:02:24,391 ERR program: Found Fedora release 17 (Beefy Miracle) on /dev/sda8 00:02:25,018 ERR program: done 00:02:25,104 INFO program: Running... grub2-install --force --no-floppy /dev/sda5 00:02:26,421 ERR program: /sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding. 00:02:26,424 ERR program: /sbin/grub2-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. 00:02:26,438 ERR program: Installation finished. No error reported.
Since this happens even outside the installer I'm thinking it's a grub2 problem.
--> Here are the entries from program.log while installing F17 Alpha (works fine): 15:10:02,613 INFO program: Running... grub2-set-default Fedora Linux, with Linux 3.3.0-0.rc3.git7.2.fc17.x86_64 15:10:02,710 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg 15:10:03,958 ERR program: Generating grub.cfg ... 15:10:04,083 ERR program: cat: /boot/grub2/video.lst: No such file or directory 15:10:04,654 ERR program: Found linux image: /boot/vmlinuz-3.3.0-0.rc3.git7.2.fc17.x86_64 15:10:04,737 ERR program: Found initrd image: /boot/initramfs-3.3.0-0.rc3.git7.2.fc17.x86_64.img 15:10:07,698 ERR program: No volume groups found 15:10:17,456 ERR program: Found Fedora release 16 (Verne) on /dev/sda1 15:10:21,052 ERR program: Found Fedora release 17 (Beefy Miracle) on /dev/sda3 15:10:23,613 ERR program: Found Fedora release 17 (Beefy Miracle) on /dev/sda5 15:10:26,017 ERR program: Found Fedora release 17 (Beefy Miracle) on /dev/sda7 15:10:28,714 ERR program: Found Fedora release 17 (Beefy Miracle) on /dev/sda8 15:10:31,161 ERR program: done 15:10:31,191 INFO program: Running... grub2-install --force --no-floppy (hd0,msdos6) 15:10:35,285 ERR program: /sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.. 15:10:35,286 ERR program: /sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. 15:10:35,405 INFO program: Installation finished. No error reported. --> Notice in the Beta log the calls to grub2-bios-setup are absent in the Alpha log --> After installing from the Alpha Live USB, /boot/grub2 has the full 200+ files. So something changed going from the Alpha to the Betas broke it.
*** Bug 810845 has been marked as a duplicate of this bug. ***
saw Bug 804835 (a proposed beta blocker) and i think this bug may be able to be closed as a duplicate of that one.
(In reply to comment #0) The blocklist warnings are expected - I don't see any problem there. > Looking in /boot/grub2 shows a lot fewer files than expected: > > [root@neuromancer grub2]# ls /mnt/otheros/boot/grub2/ > device.map grub.cfg grubenv i386-pc locale themes That is fine - the modules has been moved to a subfolder. (In reply to comment #3) > --> Here are the entries from program.log while installing F17 Alpha (works > fine): > > 15:10:02,613 INFO program: Running... grub2-set-default Fedora Linux, with > Linux 3.3.0-0.rc3.git7.2.fc17.x86_64 > 15:10:02,710 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg > 15:10:03,958 ERR program: Generating grub.cfg ... > 15:10:04,083 ERR program: cat: /boot/grub2/video.lst: No such file or directory ... > 15:10:31,191 INFO program: Running... grub2-install --force --no-floppy > (hd0,msdos6) That was a bug; grub2-install should be run before grub2-mkconfig. That should however have been fixed now. I guess the real problem here is that you have a partial and non-working bootloader in mbr, and you are thus not using the new boot loader you installed in the partition. Please try to grub2-install /dev/sda and see if that solves the problem.
"Please try to grub2-install /dev/sda and see if that solves the problem." That is however not an option if you have, lets say Truecrypt installed on the MBR. If you do the mentioned action, Truecrypt will be broken. Therefore its necessary to install the bootloader to the boot partition
(In reply to comment #7) > "Please try to grub2-install /dev/sda and see if that solves > the problem." That was said given the information given here. It is not a general advice. Bug 810845 is a different issue.
(In reply to comment #6) > (In reply to comment #0) > > The blocklist warnings are expected - I don't see any problem there. > > > Looking in /boot/grub2 shows a lot fewer files than expected: > > > > [root@neuromancer grub2]# ls /mnt/otheros/boot/grub2/ > > device.map grub.cfg grubenv i386-pc locale themes > > That is fine - the modules has been moved to a subfolder. > > (In reply to comment #3) > > --> Here are the entries from program.log while installing F17 Alpha (works > > fine): > > > > 15:10:02,613 INFO program: Running... grub2-set-default Fedora Linux, with > > Linux 3.3.0-0.rc3.git7.2.fc17.x86_64 > > 15:10:02,710 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg > > 15:10:03,958 ERR program: Generating grub.cfg ... > > 15:10:04,083 ERR program: cat: /boot/grub2/video.lst: No such file or directory > ... > > 15:10:31,191 INFO program: Running... grub2-install --force --no-floppy > > (hd0,msdos6) > > That was a bug; grub2-install should be run before grub2-mkconfig. That should > however have been fixed now. > > > I guess the real problem here is that you have a partial and non-working > bootloader in mbr, and you are thus not using the new boot loader you installed > in the partition. Please try to grub2-install /dev/sda and see if that solves > the problem. The bootloader I have in MBR is from a f16 install I have in sda1. I have six fedora installs on this machine. These partitions get reinstalled weekly when testing new fedora builds. The install in sda1 I always installs grub to the MBR and chainloads to the other partitions from there. So what you're suggesting is that every time I install, I put grub in the MBR and let it discover the other installs? I prefer having the choices of which kernel to boot separated into sub categories instead of one big list like what that method is going to create. With the default of keeping 3 selections per install at 6 installs I'm looking at 18 possible boot selections. So is there any way to keep it the way I have now and have it work? Right now my grub screen looks like this on boot: Fedora (3.3.1-5.fc16.x86_64) Fedora (3.3.1-3.fc16.x86_64) Fedora (3.3.0-8.fc16.x86_64) (sda3)--> f16 KDE (sda5)--> (sda6)--> (sda7)--> f17 KDE Alpha (sda8)--> f17 Gnome Beta RC4 much cleaner than having 18 choices on one screen IMO.
I now understand bug 804835 - and yes, this is a duplicate. (In reply to comment #9) > So what you're suggesting is that every time I install, I put grub in the MBR > and let it discover the other installs? No, quite the opposite. I didn't know that you had an existing 'master' boot loader in mbr, and my theory was that mbr perhaps had some old cruft. I fully agree that your way of doing it is the best way to handle multiple OSs on one machine. Both shared /boot and os-probing of kernels for other systems is not gonna work. Do you manually remove the master boot loaders os-prober entires and replace them with chainloader entries? *** This bug has been marked as a duplicate of bug 804835 ***
Btw: from the symptoms I guess you do the chainload using 'chainloader +1'? Is there any reason you don't use 'chainloader /boot/grub2/i386-pc/core.img' or 'multiboot /boot/grub2/i386-pc/core.img'? That should be much more stable. (Ok, some reasons to not use that could be the need for loading a file system module and that you have to 'guess' the name. Are there other reasons?)
(In reply to comment #10) > I now understand bug 804835 - and yes, this is a duplicate. > > (In reply to comment #9) > > So what you're suggesting is that every time I install, I put grub in the MBR > > and let it discover the other installs? > > No, quite the opposite. > > I didn't know that you had an existing 'master' boot loader in mbr, and my > theory was that mbr perhaps had some old cruft. > > I fully agree that your way of doing it is the best way to handle multiple OSs > on one machine. Both shared /boot and os-probing of kernels for other systems > is not gonna work. > > Do you manually remove the master boot loaders os-prober entires and replace > them with chainloader entries? > > *** This bug has been marked as a duplicate of bug 804835 *** My usual machine setup is to have a partition containing only grub that chainloads all my OS's in the MBR. Then every time I install an OS i always choose to install grub to the partition. That way I don't have to remove the os-prober entries and add my chainload +1's in every time i have to reinstall the 'master' OS partion. (In reply to comment #11) > Is there any reason you don't use 'chainloader /boot/grub2/i386-pc/core.img' > or 'multiboot /boot/grub2/i386-pc/core.img'? That should be much more stable. Oh cool- I'll try those ways. I found out how to do this chainload thing a long time ago and never had a reason to go back and reevaluate if there was a better way to do it until now.