how does fedora known grub2 boot device?

[wangmaster]

I just updated a system to fedora 17 to play around with it and noticed that the update didn't update grub. I suspect that this is because /dev/sda is my mechanical drive and /dev/sdb is my ssd (and my system is configured to boot from the ssd) so fedora by default updated grub2 on /dev/sda instead of /dev/sdb.

How does fedora know what drive to use as the grub2 boot device when there are multiple drives?

[sea]

AFAIK!
That piece of information is stored either in the bios_boot partition for GPT formatted disks or in the MBR.
Further partitions may have the boot flag, that flag indicates that grub should read some of its content to complete the list you can boot from.

Did you had run yet?:
grub2-mkconfig -o /boot/grub2/grub.cfg

[wangmaster]

the grub2 loader is installed onto the MBR or bios_boot partition yes but what I want to know is after an initial anaconda install (which asks you what drive you want it on) how does fedora know where grub2 is installed to update. Does it scan the drives? What happens if grub is installed on multiple drives?

Basically what happened was the upgrade (via preupgrade) from f16 to f17 didn't update grub on my boot drive (the SSD which is /dev/sdb under linux). I'm curious what piece of information the installer uses to determine where to update grub (or perhaps it doesn't update grub at all?)

I have run grub2-mkconfig -o /boot/grub2/grub.cfg
but that's not really relevant to my question I guess. That just generates the grub.cfg, it has no impact on where the grub2 loader is actually installed.

[sea]

It goes to /boot which, usualy, either is mounted or on the same partition as /.
There it finds the files (info) to load, which are contained /boot/grub2/grub.cfg

If you want to update a grub2 menu, that is inhabitant of another distro, you could achieve that by mounting/binding its directory.
As example: sdaX = ide disk
sdbX = ssd disk

you're ROOT is sda1
the according boot folder is /sda1/boot

the grub2 you want to change is in /sdb2/boot
so you mount /dev/sdb2 /mnt/ssd-boot
grub2-mkconfig -o /mnt/ssd-boot/grub2/grub.cfg

hth

[VernDog]

Originally Posted by wangmaster

the grub2 loader is installed onto the MBR or bios_boot partition yes but what I want to know is after an initial anaconda install (which asks you what drive you want it on) how does fedora know where grub2 is installed to update. Does it scan the drives? What happens if grub is installed on multiple drives?

Basically what happened was the upgrade (via preupgrade) from f16 to f17 didn't update grub on my boot drive (the SSD which is /dev/sdb under linux). I'm curious what piece of information the installer uses to determine where to update grub (or perhaps it doesn't update grub at all?)

I have run grub2-mkconfig -o /boot/grub2/grub.cfg
but that's not really relevant to my question I guess. That just generates the grub.cfg, it has no impact on where the grub2 loader is actually installed.

Run bootinfoscript, and it will show you where the MBR is is installed from.

[wangmaster]

I don't need to know where grub is installed.

I need to know HOW fedora knows where it's installed so that when it upgraded from f16 to f17, was it supposed to update the grub loader?

or what if grub rpm is updated, how does fedora know what device to run grub2-install or grub2-setup against?

[DBelton]

I'm not certain that Fedora does automatically update grub2 when the grub2 rpm is updated.

The last grub2 update I got, I still booted the old grub2 until I ran grub2-install myself, and specified where the bootloader was located.

[AdamW]

wangmaster: it doesn't know: during an install, you get asked. we always pop up the 'disk filter' screen, which lets you pick which disks will be involved in the installation and which won't, and also allows you to specify which disk will get the bootloader.

There's a dialog which pops up much later in install, at bootloader install time, which lets you choose whether to install the bootloader to a disk's MBR or to the start of the root or /boot partition. That dialog used to let you pick the target disk too. Now it doesn't any more, so we make sure the diskfilter screen pops up on all install paths (even custom partitioning, where it's really sort of redundant) as a kludge.

All this will change in F18, with the new UI. But the user will still have to specify the bootloader target device somehow. There's no way anaconda can possibly reliably decide that by itself.

On upgrade, frankly, we have a bit of a gap. You don't get to pick. anaconda picks a disk, essentially just the first one it scans which is a viable target, and the bootloader will get installed there. In most cases, we hope, it'll be the right one. The disk that gets picked will usually be the first disk in the BIOS boot order. (Happily, we fixed the bug where it'd often wind up being the USB stick you were running the installation from...) The dialog which lets you pick MBR or a partition to install to will pop up, I think, and will tell you what disk anaconda has picked, so if it's wrong, you can catch it. If it's wrong, the workaround - yes, I'm serious - is to boot back to BIOS and change the drive ordering so the drive you want the bootloader to be installed on is the first one. Then anaconda should pick it.

Prior to F16, the default on upgrade was not to actually reinstall the bootloader at all; we just updated the grub.cfg file and left the installed bootloader alone. For the F15->F16 upgrade this wasn't viable, because we want to switch to grub2. So we changed the default to be the 'install new bootloader' option, and disabled the 'update bootloader configuration' option. But quite honestly I don't think anyone spent a huge amount of time working out the possibilities as to where the new bootloader would actually get installed, so it kind of got muffed. In most cases, it works out alright, but there are corner cases where it doesn't.

For F17 we could probably have gone back to 'update bootloader configuration' by default for F16 upgrades (though really, there's quite a difference between grub2 1.99 and grub2 2.0b4, which is what we have in F16 and F17 respectively, so maybe not...), but we didn't. The default is still 'install new bootloader' and there are still the corner cases where it breaks. Well, sorry. :/ I'll try and make sure this is covered more sanely for the new UI in 18. In our defence, this whole area of bootloader location is psychopathically complicated to deal with and a fundamentally ridiculous design for operating system installers to cope with, and most of them don't make anywhere near as much of an effort to try as Fedora does. If you look at Windows or Ubuntu, they more or less just nuke the MBR on the first BIOS boot device in all cases and call that good.

On regular package updates (and yum upgrade), the bootloader isn't reinstalled at all. Only the config file is touched.

[wangmaster]

Adam,
Thank you for the detailed explanation. That was EXACTLY what I was looking for

Originally Posted by AdamW

On upgrade, frankly, we have a bit of a gap. You don't get to pick. anaconda picks a disk, essentially just the first one it scans which is a viable target, and the bootloader will get installed there. In most cases, we hope, it'll be the right one. The disk that gets picked will usually be the first disk in the BIOS boot order. (Happily, we fixed the bug where it'd often wind up being the USB stick you were running the installation from...) The dialog which lets you pick MBR or a partition to install to will pop up, I think, and will tell you what disk anaconda has picked, so if it's wrong, you can catch it.

This would be the case in an upgrade from media right? I did a pre-upgrade and I don't recall being prompted. In fact, I just booted to the preupgrade grub entry, saw it was going to do a few thousand packages, went to bed, woke up and it had rebooted into the new F17 install, albeit with the wrong F16 kernel (hehe. kernel panic on shutdown was fun) but I expected these kinds of things due to the pre-release nature of 17, in fact I find these things fun to fix .

If it's wrong, the workaround - yes, I'm serious - is to boot back to BIOS and change the drive ordering so the drive you want the bootloader to be installed on is the first one. Then anaconda should pick it.

I think this is a perfectly sane request with one caveat: if the two drives are on different controllers, the BIOS boot order doesn't effect the kernel drivers enumeration order, so even if I set the msata SSD to be the first drive, the driver for it is loaded after the AHCI driver, thus my boot ssd will always be /dev/sdb and the mechanical data drive will be /dev/sda no matter what the BIOS ordering is.

On regular package updates (and yum upgrade), the bootloader isn't reinstalled at all. Only the config file is touched.

Ahh. This is good to know. I assumed, not sure why, that the loader would be updated automatically.

---------- Post added at 03:15 PM ---------- Previous post was at 03:10 PM ----------

Might be a stupid question but does anything use device.map order?

My device.map has
(hd0) /dev/sda - this is the mechanical data drive
(hd1) /dev/sdb - this is the msata SSD boot drive

If I rearranged those and re-generated grub.cfg (grub.cfg appears to refer to the proper hdX values) would that effect how anaconda decides which devices to install the grub loader on or is this purely for grub.cfg to map hdX to the proper /dev node?

---------- Post added at 05:30 PM ---------- Previous post was at 03:15 PM ----------

FYI, I already said this, but your explanation was exactly what I was looking for You "apologized" a few times in there for the gaps but there's really no need for that. I fully understand the complexity of the bootloader details and I don't mind having to fix this stuff manually. I really just wanted to understand if what I'm doing manually is the right thing or if there was something I could do to make it more automated, especially when I actually update my other F16 systems (which have somewhat complicated drive configurations as well).

When it comes to these crazy boot loader configurations I really have no problem with manual intervention on my systems because I'm well aware that there's no easy way without human input. The installation process may be pretty smooth, but I'm sure it's not smart enough to read my mind .

[AdamW]

Yeah, with preupgrade the idea is that it runs unattended, so it doesn't prompt for anything. So when you do preupgrade there's somewhat more of a gap - it just tells anaconda to reinstall the bootloader to the first valid MBR, and that's what you get, no options. You might think that we should be able to do better with preupgrade because we could know how Fedora was booted and just reflect that configuration, rite? Interestingly, no - it's either very hard or impossible (I forget which) for a booted OS to know how the bootloader that booted it was run. It can't tell if it was booted from the the MBR of sda, the MBR of sdb, or the first sectors of sdb1. It just doesn't know. The best we can do is guess at MBR of /dev/sda, which is usually right.

AFAIK, no, anaconda never reads device.map, that's purely for grub to use. It goes simply by the order the kernel enumerates the devices, which is usually - with some caveats, like the one you cite - the BIOS boot order.