#377 RHBZ#590661 - GRUB bootloader should have a few seconds delay on a multi-boot setup
Closed None Opened 11 years ago by jlaska.

= Proposal topic =

[http://bugzilla.redhat.com/590661 590661] was reported by users on test@lists.fedoraproject.org. There is no consensus yet on whether to 1) document this as a known issue and release Fedora 13 on schedule, or 2) fix this issue ... and slip the release by 1 week.

A decision by FESCO is needed to determine whether this bug should be fixed in Fedora 13 or not.

= Overview =

A post-F12 change in anaconda (see [http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=8c24c48663851eedc2a2328641f9fdea8fcee94a commit]) has introduced a behavior change for people installing Fedora 13 in a dual-OS environment.

= Problem space =

Installing Fedora 13 in a dual-OS environment does not offer grub boot menu on boot. A user must press a <Modifier> key (e.g. Shift, Alt or Control) to access to the grub menu and change their boot options. This is a regression in behavior from Fedora 12. Fedora 12 would offer a grub boot menu with a 5 second timeout whenever installing in a dual-OS environment.

= Solution Overview =

The decision needed is to either:
1. Document this behavior on [http://fedoraproject.org/wiki/Common_F13_bugs Common_F13_bugs] and release Fedora 13 on schedule
2. Fix this issue, so that the Fedora 12 and Fedora 13 dual-OS boot experiences match, and slip the release of Fedora 13 by 1 week.

= Active Ingredients =

  • anaconda-devel (responsible for commiting the change and building the fix)
  • Fedora release engineering - responsible for building new RC#3 ISO media
  • Fedora QA - responsible for validating RC#3 media and providing timely test reporting

= Owners =


I would just like to note that due to the time-critical nature of this, please feel free to enter opinions/votes here; we may also grab FESCo members on IRC. Discussion of this is occuring on #fedora-devel.

Some comments from various people:

<notting> what was QE's opinion?
<pjones> jlaska: ping?
<Oxf13> he was happy with documenting the various workarounds
which is hold shift, or edit grub.conf, or install with an updates.img
<pjones> such as "hold down the shift key, and then change the file if you really want to"
<jlaska> I'm comfortable documenting the workaround here, the more important outcome for me was that this the decision take place in a larger audience (as it is now)
<pjones> which is, I might add, the same advice we give as a non-workaround for booting a different kernel.

<stickster> In the context of two issues it seems to be a big problem: 1. unexpected and hard to deal with for people in the user base, 2. regression from F12
<stickster> In the sense that (1) there's no way for the user to know what to do to get their other OS working, and (2) we don't have a way of making that plain to them anywhere in the distro that does boot

Note, this issue is fixed in rawhide, the question is whether or not to bring the fix to F13 and slip the release.

I'm strongly against slipping for this:

1) jlaska and I both mistook this as a reasonable default behavior rather than a bug
2) it's been present in every test release, alpha, beta, and RC without being noticed until now
3) I think the number of dual-booters is relatively small, and I consider them to be technical users
4) We should be discouraging use of dual-booting in favor of kvm anyway
5) The simple workaround ("hold shift") is the standard procedure for e.g. booting an older kernel.

I vote to not slip and document the workarounds.

This is a tough one, and I could see both arguments.

However, I find the not slipping case more compelling. So, I vote to not slip and make sure and document this as much as we can.

I don't think this is significant enough to slip the release.

My initial inclination agrees with Paul, and we really should fix this. I may reconsider.

This is the kind of bug that's potentially highly visible to first-time installers, so I'd lean towards slipping for it.

First time users: if they use the livecd/usbkey they won't see it at all, obviously.

And dual-booting requires a fair amount of being able to read docs. So, I kinda think we can get away with NOT slipping it and just documenting it well.

IMHO, it should be rel-eng and/or QA's decision whether to slip, not FESCo's, that's what the Go / No Go meeting is for.

To me, sure, this particular issue looks like an annoyance, but it's also very easily worked around. I also wonder whether this couldn't be fixed in an update. (If upgrading from F13 GA's GRUB, check whether we have multiple OSes and timeout=0, if so, fix it.) So I'd tend towards not slipping.

(That said, I think this timeout=0 idea was a bad one in the first place, even for Fedora-only installs. My 2 systems, both Fedora-only, both have non-zero GRUB timeouts set. But this is obviously not the time in the release cycle to discuss that.)

Replying to [comment:11 kkofler]:

IMHO, it should be rel-eng and/or QA's decision whether to slip, not FESCo's, that's what the Go / No Go meeting is for.

QA and release engineering can make a decision. However, given the scope of this behavior change, it was felt that input from a wider audience would be beneficial. This serves to keep all informed and offers a more transparent forum for reviewing pros/cons.

To me, sure, this particular issue looks like an annoyance, but it's also very easily worked around. I also wonder whether this couldn't be fixed in an update.

To know knowledge, this type of fix has no precedent for resolving post release. Could it be done, sure ... but modifying a users bootloader configuration well after initial install is probably less ideal.

Well, it certainly can't be automatically fixed - that breaks machines where people intentionally chose to have a timeout of 0, or where that /is/ the intended default (which is most machines.)

I should recant my second point above - apparently this was filed in late March, and I just hadn't gotten to that bug yet.

(though the reporter in that bug was actually complaining about the UI changing around this.)

By my count, the vote is indicating 'no slip'. Are any votes outstanding?

Slip | no Slip
| jkeating
| pjones
| kkofler
| skvidal
| ajax
| kevin
| ausil
mjg59 |
notting |
pfrields |
3 | 7

I'm the one missing and I don't think it is a release blocker. I agree it is an annoyance, but not a blocker.

For clarity, neither pfrields nor I are in FESCo, so the numbers are more like 7 to 2.

Thank you for all the feedback in this ticket. With this information, we were able to determine that bug#590661 alone would not cause a respin, and slip the Fedora 13 release. Unfortunately, early analysis of an NFS install failure found during test caused enough concern to warrant further investigation, and a slip of Fedora 13 by 1 week.

For details, see http://lists.fedoraproject.org/pipermail/test/2010-May/090881.html

It was also decided that bug#590661 would be moved to F13Target, and a well tested and isolated fix would be accepted into Fedora 13.

This ticket can be closed.

Login to comment on this ticket.