F17 rc3

[taipan]

@Pumpino: I'm wondering if it's the 'chainloader' technique in combination with F17 that's the problem - here's why...

A few days ago i put F17-beta on a similarly partitioned system to yours, telling Anaconda to install the bootloader to the new system's root-partition, not to the MBR. I then updated the grub.cfg of the Ubuntu system's version that's already embedded there and tweaked it slightly to include the initrd-image that it had overlooked.

Upon booting into the shiny new F17 system, one of the first things that happened was that about 350 packages got updated automatically, including the kernel, from 3.3.0 to 3.3.6...

...However, there was no correspondingly new initrd-image, so i left my grub.cfg tweaks as they were, booting 3.3.0.

The reason i'm posting this now is that i'm currently looking at the grub.cfg installed by F17, and it only contains entries for 3.3.0, nothing for 3.3.6 - so maybe there's a problem with F17's grub.cfg auto-update mechanism that's hitting you because of the aforementioned 'chainloader' technique...

Does that make sense to anybody..?

[Pumpino]

@taipan: That would make sense. Using the chainloader technique is the only method I know of for easily booting multiple distros. It's not practical to manually update Grub every time there's a kernel update in another distro.

AdamW: Is it possible that you could get the relevant person to give Grub2 the once over and see if there's a quick fix before the official release?

[taipan]

@Pumpino: I think i just found the problem...

I got to wondering where the hell that 3.3.6 kernel came from, when 3.3.4 is the latest version listed in the updates repo - it appears that the 'updates-testing' repo is enabled on a fresh install and that initial package-update pulls in the new kernel.

I just removed 3.3.6 with PackageKit, then used yum to "yum install kernel" and not only did it install the desired 3.3.4 version, it also built the needed initrd-image and updated grub.cfg!

So if you've still got your original 3.3.0 kernel installed and can temporarily modify the Arch grub.conf to boot into it, you could then remove the problematic kernel, install the non-testing version, then revert back to your 'chainloader' approach...

...Unless you want to keep using the 'testing' repo, that is - in which case you appear to be f$cked.

Edit: I guess we should both probably do a "distro-sync", thinking about it, but i'll wait for the opinion of someone who's been using Fedora for more than a couple of days before trying that...

[AdamW]

So, it's getting confusing discussing two issues in one thread.

As far as the grub config issue goes, the description is extremely confused and there's nothing I can see that's a definite bug to fix. If you think there is, please describe it simply and clearly. There's no reason booting F17 in a chainloader config would result in grub.cfg not being updated properly on a kernel install; whether F17's grub is on the MBR or on a partition and gets chainloaded, its grub _config file_ will look much the same and be in the same place, and grubby should be able to update it.

As far as the installer issue goes, I'm sorry to be bald Pumpino but I simply don't believe you. There is only reason anaconda would pop up a message claiming that a partition must have a GPT disk label, and that's if you're doing a native EFI install. There's simply no other way to trigger that message that I can see. It's easy enough to check: go to a console, ctrl-alt-f2, and type 'efibootmgr'. If you get a list of boot entries, you're booted via EFI. If you get 'Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.', you're booted via BIOS or BIOS emulation.

[Pumpino]

@taipan: Thanks for the info. Updates-testing definitely isn't enabled by default in RC3, as I had no updates until I manually enabled it. I'll see what I can do with my current installation, but if it's not fixable I'll just reinstall.

@AdamW: OK, so you were right. :P It seems I had booted via EFI. The reason I got confused was I recently upgraded my motherboard to a GA-Z77X-UD3H and I remember seeing EFI boot disabled in the bios of the previous board. That said, after searching the bios of the Gigabyte board just now, I can't see an obvious way of disabling EFI boot. I'll do some research on how to do that, as your suggestion of "boot the installer via BIOS emulation and not native EFI" goes over by head. However, my limited understanding of EFI is that it's mainly to enable booting drives over 2TB, and that doesn't apply to my SSD, so I might be ok if I can disable it.

[AdamW]

So to give you the ten second overview - UEFI is the mooted replacement for BIOS. It's an entirely new standard for system firmware for PCs. Like ACPI replaced APM, UEFI is supposed to replace BIOS. It can get a bit confusing because people tend to use the word 'BIOS' somewhat sloppily, it's often used to refer generically to the system firmware on a PC, so you see stuff like 'this system has a UEFI BIOS'. But really, the above is how it is.

All systems I've ever seen which have a UEFI firmware also implement BIOS compatibility - they can boot as native UEFI, or they can boot in a mode that looks, to the operating system, exactly like a BIOS. If you don't want to deal with UEFI - and in your case, since you're trying to install alongside a BIOS-compatibility Windows installation, you don't - then you should boot the Fedora installer in BIOS compatibility mode.

Looking at your motherboard manual, I see this:

"Removable storage devices that support GPT format will be prefixed with "UEFI:" string on the boot device list. To boot from an operating system that supports GPT partitioning, select the device prefixed with "UEFI:" string."

That sounds rather like my system: when you put in a CD, DVD or USB stick that is capable of native UEFI boot, the firmware will give you _two_ entries for it in the boot menu, one with UEFI: in it and one without. So when you 'go into the BIOS' (more correctly, access the firmware configuration screen, but hey!) at boot, and go to the 'BIOS Features' screen, and change the boot order, you'll see, say:

UEFI: My_Awesome_USB_Stick
My_Awesome_USB_Stick

as available options. If you want to boot via BIOS emulation rather than native UEFI...pick the one *without* the 'UEFI:' prefix. If you want to boot via native UEFI, pick the one *with* the UEFI: prefix.

[Pumpino]

Thanks for the detailed explanation, Adam. I'll try going into the "bios", but I know the boot splash for the board has an option of displaying a boot menu, so that might do what I require too. I suppose Windows must take care of that automatically when it's installed.

Can I ask why anyone would want the EUFI boot if it causes the error message I encountered? Or is it only doing it for me because I have Windows installed on the same drive?

---------- Post added at 06:53 PM ---------- Previous post was at 05:13 PM ----------

Choosing to boot the DVD listing without the EUFI next to it worked. Also, there was no weird issue with chainloading after updating the kernel on this box. I guess I'll have to do a fresh install on my laptop and hope it doesn't reoccur.

Thanks again for the help.

[AdamW]

There's no massively user-visible benefit to doing native UEFI vs. BIOS-style booting, really. The (alleged...) benefits of UEFI are more to system and OS designers.

FWIW, Linus is caustic on UEFI, and reckons the only thing in it which is an actual concrete improvement is the GPT disk labelling format. Personally I'd agree, except I'd add the UEFI bootloader to the list of things that are actually good. Even with GPT, you're only really going to notice the benefits yourself if you like to have lots of partitions or you have very big disks (GPT supports >2TB disks).

In almost all practical cases you're frankly probably better off sticking with BIOS compatibility for now. At least everyone more or less understands how that works. In your case, you can't possibly do a UEFI native install without nuking your Windows installation (because you'd have to re-format the disk with a GPT disk label).

What a given system will default to when you stick in a disc/stick/whatever which is capable of both BIOS and UEFI-native boot is entirely up to the particular firmware implementation. Some will default to one mode, some to the other. It sounds like yours defaults to doing a UEFI-native boot, if you don't go in and ask for the BIOS-compatibility boot. Mine does the opposite (it defaults to BIOS boot unless I go in and pick UEFI-native). What's installed on the system has no relevance to what the firmware decides, and the medium itself can't express a preference. It's entirely up to the firmware to decide what to do.

[Pumpino]

Interesting. Just out of curiosity, what motherboard are you using?

[AdamW]

P8P67-Deluxe.