The changing Fedora

Tue Jan 22 12:23:18 UTC 2013

On Tue, 2013-01-22 at 13:31 +0200, Cristian Sava wrote:
> On Tue, 2013-01-22 at 04:28 -0700, T.C. Hollingsworth wrote:
> > On 1/22/13, Cristian Sava <csava at central.ucv.ro> wrote:
> > > and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer
> > > be installed to a partition."
> > > http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-grub-installing.html
> > 
> > *anaconda* won't install GRUB2 to a partition.  You can still
> > accomplish it with `grub2-install --force`.
> > 
> > -T.C.
> 
> Thank you for the hint.
> 
> C.S.
> 
> 
My painful initial introduction to F18.
Maybe it will help someone

The important part is the use of core.img and the "not using" of block
addressing

I used bullets 3. and 5. successfully (on an all ext4 disk)!

John

 https://bugzilla.redhat.com/show_bug.cgi?id=872826#c36
https://bugzilla.redhat.com/show_bug.cgi?id=886502
Should be in the Release Notes somewhere?
Very slightly modified

NB Probably Only Valid for BIOS Booting?

Problem
There is no longer an option to install boot loader (GRUB) to a
partition.

Embedding GRUB to a partition contain an ext[234] file system is not
recommended by upstream
GRUB development, and in Fedora 18 is no longer an option.

Suggested alternatives:
1. Allow Fedora 18 to install GRUB2, to become your primary boot
manager/loader (default).

2. Do not install a boot loader using Anaconda
If you don't want your primary boot manager replaced, then in anaconda
you need to
deselect boot loader installation during F18 installation.

Installation Destination/Full disk summary and options
to reveal the Selected Disks dialog.

Select disks and click "Do not install bootloader".

"Your system will not be bootable without additional post-install
configuration.
It's suggested you do this after installation has successfully finished,
but before you reboot."

3. Configure the F18 boot loader manually at the end of installation
Actions
Create GRUB2 core.img, suppress embedding in the MBR and then produce
grub.cfg

Control/Alt/F2 to a console terminal just before rebooting

Establish with certainty which /dev/sdX device Fedora 18 is installed
on.
Is this valid if / and /boot are on different partitions?
mount | grep sysimage
chroot /mnt/sysimage

Install GRUB, using whole /dev/sdX device from previous step, not
including partition number
The --grub-setup option inhibits the installation of grub to the MBR
of /dev/sdX, however
all the required grub2 files are installed in their correct locations
grub2-install --grub-setup=/bin/true /dev/sdX

Then create grub.cfg - the name must be grub.cfg and NOT grub2.cfg
grub2-mkconfig -o /boot/grub2/grub.cfg

4. If there is already a GRUB2 instance, add a menu entry to that
distribution's grub.cfg, using 'configfile' to load the Fedora 18
grub.cfg created in step 3 above.

5. If you use a boot manager other than GRUB2, including GRUB Legacy,
you can have it
find and execute /boot/grub2/i-386-pc/core.img
for example a GRUB Legacy entry with Fedora 18 /boot found on the 3rd
partition:

title   Load GRUB2, Fedora 18
root    (hd0,3)
kernel  /boot/grub2/i386-pc/core.img
boot
----------------------------------------------------
Be careful with partition numbers when mixing grub and grub2
Be careful with the presence of the leading /boot depending upon
whether /boot is a separate partition
Not certain of the exact syntax to be used above if separate /boot
partition is present!!!!

#############################################################################################
If the above is forgotten during installation then the following may be
useful !
Necessary during my very first F18 install!

http://www.gnu.org/software/grub/manual/html_node/GRUB-only-offers-a-rescue-shell.html

27.1 GRUB only offers a rescue shell

GRUB's normal start-up procedure involves setting the 'prefix'
environment variable to a
value set in the core image by grub-install, setting the 'root' variable
to match,
loading the 'normal' module from the prefix, and running the 'normal'
command (see normal).
This command is responsible for reading /boot/grub/grub.cfg, running the
menu,
and doing all the useful things GRUB is supposed to do.

If, instead, you only get a rescue shell, this usually means that GRUB
failed to load
the 'normal' module for some reason.
It may be possible to work around this temporarily: for instance,
if the reason for the failure is that 'prefix' is wrong (perhaps it
refers to the wrong device,
or perhaps the path to /boot/grub was not correctly made relative to the
device),
then you can correct this and enter normal mode manually:

     # Inspect the current prefix (and other preset variables):
     set
     # Find out which devices are available:
     ls
     # Set to the correct value, which might be something like this:
     set prefix=(hd0,1)/grub
     set root=(hd0,1)
     insmod normal
     normal
However, any problem that leaves you in the rescue shell probably means
that GRUB was not correctly
installed.
It may be more useful to try to reinstall it properly using grub-install
device
(see Invoking grub-install). When doing this, there are a few things to
remember:

Drive ordering in your operating system may not be the same as the boot
drive ordering used by
your firmware. Do not assume that your first hard drive (e.g.
'/dev/sda') is the one that your
firmware will boot from. device.map (see Device map) can be used to
override this, but it
is usually better to use UUIDs or file system labels and avoid depending
on drive ordering entirely.

At least on BIOS systems, if you tell grub-install to install GRUB to a
partition
but GRUB has already been installed in the master boot record, then the
GRUB installation 
in the partition will be ignored.
If possible, it is generally best to avoid installing GRUB to a
partition (unless it is
a special partition for the use of GRUB alone, such as the BIOS Boot
Partition used on GPT).
Doing this means that GRUB may stop being able to read its core image
due to a
file system moving blocks around, such as while defragmenting, running
checks,
or even during normal operation. Installing to the whole disk device is
normally more robust.
Check that GRUB actually knows how to read from the device and file
system containing /boot/grub.
It will not be able to read from encrypted devices, nor from file
systems for which support
has not yet been added to GRUB.