Bug 842427

My bad, I just noticed that the problem was the LiveCD install used the F16 kernel!  So after I manually edited grub2.cfg to boot the F17 kernel, e100 works again.  So this is still a bug, but it is probably with grub2-install, so I'll change the component to that.

Created attachment 599862 [details]
Grub2.cfg produced by LiveCD install to hard disk

Sounds like 820351

*** This bug has been marked as a duplicate of bug 820351 ***

The problem is also produced when updating the kernel, so it is really a problem with grub2-install, not anaconda.

This problem is not 820351, as was clarified by Stuart's further comments, reproduced below. Re-opening.

"I'd like to point out that upgrading is not the issue.  I did a fresh install - but with a shared /boot with f16.  The f17 kernel was installed, but grub2.cfg picked the f16 kernel as the default!  Boot correctly was a simple matter of going to the "Advanced" subment and picking the correct kernel.

This is related to an ongoing problem for F16,F17 - grub2 adds kernels from older installs in a shared /boot, but with the wrong root filesystem!  You have to manually edit grub2.cfg to fix the root filesystem for older kernels (actually edit /etc/grub.d to avoid doing with every kernel upgrade).

The core problem is grub2-install knowing which kernel goes with which root filesystem.  For starters, it should remember what was in grub.conf or grub2.cfg previously."

(This issue is closely related to bug 820351; it wouldn't have shown up if the f17 installed kernel version was higher than the latest f16 update. Both issues could thus be mitigated for example by using a kernel versioning scheme like kernel-fc17.3.4.6-2 .)

From grubs point of view the grub behaviour described in this issue is correct and works as designed. The problem is that /boot is shared. grub will sort all the available kernels in /boot by version number and do not have any means to track which installation they belong to.

It is thus a user error to use a shared /boot ... and a anaconda bug that the user can do it without a proper warning of consequences.

Reassigning to anaconda.

Adjusting summary to something appropriate, then, AIUI. The bug is now basically that anaconda should discourage the use of /boot shared between multiple distributions, yes? So if you assign an existing partition as /boot, don't choose to format it, and that partition appears to already be a boot partition (contains kernel pairs), anaconda should display a warning message?

Anaconda already displays a warning message when you choose not to format /boot.

So, say I create an EFI partition, and then a /boot LV for each active Fedora version (16,17,18 at present), how to choose which install to boot?

My opinion is that the required information is already in grub.conf or grub2.cfg.  Grub itself doesn't need to worry about it, but grub2-install/grub2-mkconfig/anaconda does. 

May I humbly suggest that anaconda on detecting existing kernels in /boot:

a) make its best effort to preserve boot info.  E.g. use existing /boot/grub2/grub2.cfg or /boot/grub/grub.conf and add an entry for the just installed kernel at the top as the default.

b) issue the warning (as it already does) and for newbies willing to tackle the problem if it doesn't work, mention the file they need to mount and try to fix.

E.g. If my share boot config doesn't work, you need to mount /dev/sda2 as /mnt/boot and manually edit /mnt/boot/grub2/grub2.cfg

(In reply to comment #8)
> So, say I create an EFI partition, and then a /boot LV for each active
> Fedora version (16,17,18 at present), how to choose which install to boot?

FWIW: Fedora do currently not use grub2 for EFI.

Anyway: See http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config for upstreams recommendations for booting multiple OS's.

> a) make its best effort to preserve boot info.  E.g. use existing
> /boot/grub2/grub2.cfg or /boot/grub/grub.conf and add an entry for the just
> installed kernel at the top as the default.

That will not work when changing from grub to grub2.

That will not work when the grub2 syntax changes.

That will not work when the user has made non-trivial changes to the feature rich grub.cfg language.

That will not work when users run grub2-mkconfig. Doing that is getting common knowledge and is recommended in many places.

Finally: grubby already do something like that for ordinary kernel updates. It mostly works, but it is also so fragile that I find it obvious that it might be a fair compromise but isn't something that is worth using in other places.

Ok, so if grub.cfg is too feature rich to "add at the top" anymore, surely you can rename the old grub.cfg, create a new one with the new kernel, and add an entry to chain to the old grub.cfg.

Anaconda was saving the old grub.conf last I checked.  That is a Good Thing, and at least let me manually cut&paste to get a working boot again.

I'd respectfully add that I've been using shared /boot since probably FC2, to allow rolling upgrades with two separate root partitions. Let's say:

/dev/sda1 holds /boot (shared)
/dev/sda2 holds / for FC2
/dev/sda3 holds / for FC3

When FC4 comes out, tell anaconda to
 - format /dev/sda2 and use it as / for FC4
 - use /dev/sda1 as /boot without formatting it
result, I now have FC3 and FC4

When FC5 comes out,tell anaconda to
 - format /dev/sda3 and use it as / for FC5
 - use /dev/sda1 as /boot without formatting it
result, I now have FC4 and FC5


F17 was the first release to completely break this setup for me, while at the same time making it considerably harder to have valid entries in the "richer" grub2 syntax (that I haven't needed for well over a decade on a number of machines in the hundreds).

I really don't like having to choose whether break a perfectly working setup and having two /boot partitions for my rolling upgrades or learn what the absolutely minimal grub2 syntax for simply booting a kernel is - and create scripts that just do the right thing... scripts which were bundled in previous Fedora releases and actually did the right thing.

I guess this is being shoved down my throat anyway. Time to repartition my hard disk moving around some 250GB of data, yay.

(In reply to comment #11)
> F17 was the first release to completely break this setup for me

Correct.

But you also no longer need to have a separate /boot. The boot loader code installed in /dev/sda can read /boot from your /. A way to maintain a setup like yours in these modern times is to somehow add a configfile section to the grub.cfg read by your active boot loader - see http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config .

*** Bug 905298 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.