2:15 p.m.
At the Fedora 16 Final Go/No-Go meeting today, the Fedora 16 Final
Release was declared GOLD and ready for release on November 8, 2011.
And to clarify: It is a nice, golden, almost... mustard-like color. :)
Thank you to EVERYONE for your sleepless nights, endless testing, prompt
bug-fixing, and endless patience through 5 release candidates.
A reminder that the Fedora 16 Release Wide Readiness Meeting will take
place Today, pretty much now, at 19:00 UTC (3 PM Eastern/ 12 PM Pacific) at
irc.freenode.net #fedora-meeting-1
https://fedoraproject.org/wiki/Release_Readiness_Meetings
========================================================
#fedora-meeting: F16 Final Go or No Go Meeting Round Two
http://fedoraproject.org/wiki/Go_No_Go_Meeting
========================================================
Meeting started by rbergeron at 18:00:29 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2011-11-03/f16_final_go_o...
Meeting summary
---------------
* Gathering Friends (rbergeron, 18:00:47)
* Why are we here (rbergeron, 18:01:27)
* Purpose of this meeting is to determine if all the Release Criteria
have been met, so we can ship this puppy out the door. (rbergeron,
18:02:17)
* LINK:
https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
(rbergeron, 18:02:36)
* Blocker Bugs (rbergeron, 18:02:53)
* LINK: https://fedoraproject.org/wiki/Current_Release_Blockers
(rbergeron, 18:03:03)
* Look at his beady, majestic eyes. (rbergeron, 18:03:35)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=750469 was just
reopened (robatino, 18:03:56)
* LINK:
https://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/Ma...
(tflink, 18:17:42)
* Test Matrices and etc. (rbergeron, 18:25:30)
* AGREED: 750469 needs to be fixed but does not need to delay f16
release; we can fix by updating l-i-t-d in all extant releases (14,
15) (adamw, 18:25:43)
* absolutely all tests are covered and pass or warn (rbergeron,
18:26:13)
* Release Engineering (rbergeron, 18:29:03)
* LINK: https://fedorahosted.org/rel-eng/ticket/4967#comment:17
(tflink, 18:31:09)
* Anything else before we Set Sail? (rbergeron, 18:35:01)
* To Go, or Not To Go? (rbergeron, 18:36:49)
* F16 is declared GOLD! Ship it. (rbergeron, 18:38:51)
* AGREED: F16 is declared GOLD! Ship it. (rbergeron, 18:39:04)
* Thanks to EVERYONE for your sleepless nights, your hard work, your
bug fixing. (rbergeron, 18:39:34)
* And endless testing, and endless building. (rbergeron, 18:39:45)
* There is a readiness meeting in ~20 minutes here in #fedora-meeting.
(rbergeron, 18:40:04)
* rbergeron will send out a GOLDEN GOLD MAIL to mailing lists.
(rbergeron, 18:40:22)
* in #fedora-meeting-1. (rbergeron, 18:40:39)
* Grats to everyone on shipping yet another INCREDIBLY feature-filled
release. (rbergeron, 18:41:27)
Meeting ended at 18:42:18 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* rbergeron (88)
* adamw (54)
* thedonvaughn (25)
* nirik (20)
* jsmith (10)
* tflink (9)
* N1tr0g3n (9)
* bcl (8)
* zodbot (5)
* dlehman (5)
* kparal1 (2)
* red_alert (2)
* robatino (1)
* hno_ (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
5:56 p.m.
On Thu, 2011-11-03 at 12:15 -0700, Robyn Bergeron wrote:
Thank you to EVERYONE for your sleepless nights, endless testing,
prompt
bug-fixing, and endless patience through 5 release candidates.
For the record, Fedora 16 required a total of 20 TC / RC composes.
That's a new record, at least since Fedora 12, which is as far back as
we have a handy record:
Fedora 12: 11 composes
Fedora 13: 17 composes
Fedora 14: 12 composes (F14 final was F14 RC1!)
Fedora 15: 11 composes
Fedora 16: 20 composes
This mostly reflects the fact that F16 makes major changes in very
release sensitive areas, but also I think that we're getting better at
detecting problems and resolving them as blockers and hence driving up
the quality of Fedora releases. (We also effectively 'added' two TCs to
the schedule by moving up the TC date for Beta and Final). Just to
tootle our own horn a little!
I'd certainly second Robyn's thanks to all the awesome folks on the
devel, releng and QA teams who worked so hard to get this thing done and
shiny without slipping any further. We bent process a little to make the
release date but we didn't compromise on quality at all, which is great.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:23 p.m.
On Thu, Nov 03, 2011 at 15:56:49 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
I'd certainly second Robyn's thanks to all the awesome folks on the
devel, releng and QA teams who worked so hard to get this thing done and
shiny without slipping any further. We bent process a little to make the
release date but we didn't compromise on quality at all, which is great.
Hopefully we'll try to figure out why so much heroic effort was needed
to keep from slipping any further than we did. That kind of thing tends
to burn people out and we don't want it happen regularly.
We also fudged the Go / No-Go meeting twice. We should either accomadate
this in thge process documentation or stop doing it.
1:17 a.m.
On Thu, 2011-11-03 at 23:23 -0500, Bruno Wolff III wrote:
On Thu, Nov 03, 2011 at 15:56:49 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
>
> I'd certainly second Robyn's thanks to all the awesome folks on the
> devel, releng and QA teams who worked so hard to get this thing done and
> shiny without slipping any further. We bent process a little to make the
> release date but we didn't compromise on quality at all, which is great.
Hopefully we'll try to figure out why so much heroic effort was needed
to keep from slipping any further than we did. That kind of thing tends
to burn people out and we don't want it happen regularly.
I think it boils down almost entirely to the big behaviour changes in
anaconda in F16, which unfortunately suggests F17 may also be a tricky
cycle, with the UI rewrite (and possible btrfs adoption). anaconda
provides a disproportionately high number of blockers, and the
bootloader and disk label changes in F16 caused change (and hence bugs,
change _always_ means bugs) in lots of paths we've simply not had to
worry about for a long time. All the issues with bootloader installation
on upgrade, BIOS boot partitions and so on are quite simply things we've
never previously had to deal with at all.
This didn't just cause _more_ bugs it caused bugs which were more
difficult to handle and test, because they weren't just 'hey, function X
doesn't work any more' but 'uh, now we're doing A, B and C differently,
our assumptions about D, E and F turn out to be wrong - what the heck do
we do about that?', which is a much more complex issue.
I hope this doesn't offend anyone from the anaconda team, but I do kind
of get the sense that perhaps all the implications of the changes
weren't planned out ahead of time; there seemed to be a lot of making it
up as we went along. The UI rewrite seems to be getting a lot of
pre-planning and whiteboarding and so on, so I'm vaguely hopeful that
they'll catch more of the pitfalls in advance, with that.
It'd be great if we can work with the anaconda team closely to try and
get involved all along the line in the UI rewrite stuff, and see if that
can reduce the pressure around release times - let's put that on the
table for the next meeting. But it might still turn out to be a tough
one. If anyone has any suggestions or ideas at all, please do contribute
them! The more thinking the better.
We also fudged the Go / No-Go meeting twice. We should either
accomadate
this in thge process documentation or stop doing it.
Yeah, agreed. I don't think there's any especial need for the go/no-go
to be an entire day ahead of the release readiness meeting, in all
honesty - it seems to work fine simply to do it earlier the same day. So
do you think it'd be alright to suggest that as a change for the F17 and
beyond scheduling? Every time we've decided the delay the go/no-go
decision, that choice in itself hasn't caused any problems, as far as
I'm aware. It simply gives us more time for validation, which is never a
bad thing...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:37 a.m.
On Thu, Nov 03, 2011 at 23:17:21 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
It'd be great if we can work with the anaconda team closely to try and
get involved all along the line in the UI rewrite stuff, and see if that
can reduce the pressure around release times - let's put that on the
table for the next meeting. But it might still turn out to be a tough
one. If anyone has any suggestions or ideas at all, please do contribute
them! The more thinking the better.
Yeah, I think early testing will be good there. (Unfortunately, that's
not an area I am good at helping with as I mostly do yum upgrades and
run rawhide/branched continuously rather than do lots of test installs.)
It might be useful to run through the test matrices at some other points in
the release cycle to get a heads up on potential blockers with more time
on them. It seemed this release we were in crisis mode for a lot of the
blockers.
Yeah, agreed. I don't think there's any especial need for the
go/no-go
to be an entire day ahead of the release readiness meeting, in all
honesty - it seems to work fine simply to do it earlier the same day. So
do you think it'd be alright to suggest that as a change for the F17 and
beyond scheduling? Every time we've decided the delay the go/no-go
decision, that choice in itself hasn't caused any problems, as far as
I'm aware. It simply gives us more time for validation, which is never a
bad thing...
I am concerned with the process as executed not matching the documentation.
I'd just like to see a change codified that either allows moving the Go /
No-Go meeting when appropriate or just schedule it closer to the
readiness meeting.
12:53 p.m.
On Fri, 4 Nov 2011 09:37:33 -0500
Bruno Wolff III <bruno(a)wolff.to> wrote:
On Thu, Nov 03, 2011 at 23:17:21 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
...snip...
> Yeah, agreed. I don't think there's any especial need for the
> go/no-go to be an entire day ahead of the release readiness
> meeting, in all honesty - it seems to work fine simply to do it
> earlier the same day. So do you think it'd be alright to suggest
> that as a change for the F17 and beyond scheduling? Every time
> we've decided the delay the go/no-go decision, that choice in
> itself hasn't caused any problems, as far as I'm aware. It simply
> gives us more time for validation, which is never a bad thing...
I am concerned with the process as executed not matching the
documentation. I'd just like to see a change codified that either
allows moving the Go / No-Go meeting when appropriate or just
schedule it closer to the readiness meeting.
I think moving the go/no-go meetings to thursdays and moving the
readyness meeting to friday is a fine plan. I think our mirroring is in
shape enough to where if we stage things late thursday or friday
morning we should be ok.
If we do this, next cycle we should NOT do any 'two part' go/no-go
meetings.
kevin
1:55 p.m.
On Fri, 2011-11-04 at 11:53 -0600, Kevin Fenzi wrote:
> I am concerned with the process as executed not matching the
> documentation. I'd just like to see a change codified that either
> allows moving the Go / No-Go meeting when appropriate or just
> schedule it closer to the readiness meeting.
I think moving the go/no-go meetings to thursdays and moving the
readyness meeting to friday is a fine plan. I think our mirroring is in
shape enough to where if we stage things late thursday or friday
morning we should be ok.
If we do this, next cycle we should NOT do any 'two part' go/no-go
meetings.
Well, what we were thinking of was moving go/no-go without moving
release readiness: there's no real reason there needs to be a whole day
between them, there's no tasks that must happen *after* go/no-go but
*before* release readiness AFAIK, so that whole day just winds up being
dead time. There's no intrinsic reason they can't simply be 1hr apart,
as we did for 16 Final.
So hey, if Friday's okay, we could do 'em both on Friday...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:06 p.m.
On Fri, 04 Nov 2011 11:55:00 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
On Fri, 2011-11-04 at 11:53 -0600, Kevin Fenzi wrote:
> > I am concerned with the process as executed not matching the
> > documentation. I'd just like to see a change codified that either
> > allows moving the Go / No-Go meeting when appropriate or just
> > schedule it closer to the readiness meeting.
>
> I think moving the go/no-go meetings to thursdays and moving the
> readyness meeting to friday is a fine plan. I think our mirroring
> is in shape enough to where if we stage things late thursday or
> friday morning we should be ok.
>
> If we do this, next cycle we should NOT do any 'two part' go/no-go
> meetings.
Well, what we were thinking of was moving go/no-go without moving
release readiness: there's no real reason there needs to be a whole
day between them, there's no tasks that must happen *after* go/no-go
but *before* release readiness AFAIK, so that whole day just winds up
being dead time. There's no intrinsic reason they can't simply be 1hr
apart, as we did for 16 Final.
So hey, if Friday's okay, we could do 'em both on Friday...
Well, friday might be cutting it a bit close. I guess we can see how
rapidly mirrors sync up for 16 and use that data to decide.
I think we have a more robust mirror tiering setup now than we had in
the past, so it may not take as long for tier0/1 mirrors to get content
and filter it out to others.
kevin
2:24 p.m.
On 4 November 2011 13:06, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 04 Nov 2011 11:55:00 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> On Fri, 2011-11-04 at 11:53 -0600, Kevin Fenzi wrote:
>
> > > I am concerned with the process as executed not matching the
> > > documentation. I'd just like to see a change codified that either
> > > allows moving the Go / No-Go meeting when appropriate or just
> > > schedule it closer to the readiness meeting.
> >
> > I think moving the go/no-go meetings to thursdays and moving the
> > readyness meeting to friday is a fine plan. I think our mirroring
> > is in shape enough to where if we stage things late thursday or
> > friday morning we should be ok.
> >
> > If we do this, next cycle we should NOT do any 'two part' go/no-go
> > meetings.
>
> Well, what we were thinking of was moving go/no-go without moving
> release readiness: there's no real reason there needs to be a whole
> day between them, there's no tasks that must happen *after* go/no-go
> but *before* release readiness AFAIK, so that whole day just winds up
> being dead time. There's no intrinsic reason they can't simply be 1hr
> apart, as we did for 16 Final.
>
> So hey, if Friday's okay, we could do 'em both on Friday...
Well, friday might be cutting it a bit close. I guess we can see how
rapidly mirrors sync up for 16 and use that data to decide.
I think we have a more robust mirror tiering setup now than we had in
the past, so it may not take as long for tier0/1 mirrors to get content
and filter it out to others.
I believe I have uttered those words before.. they are like saying "I
only have 2 days before retirement" in a movie :). In the past when we
have moved the release time closer we seem to end up with a series of
Tier-1 outages or some other issue where it takes a while to get bits
out. I would like to make sure that there are 100 hours before release
to make sure we have reasonable coverage.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
3:06 p.m.
fre 2011-11-04 klockan 11:53 -0600 skrev Kevin Fenzi:
If we do this, next cycle we should NOT do any 'two part'
go/no-go
meetings.
The "two part" meetings were both about critical blockers that were
known and actively being worked on at the time of the meeting. This
situation will happen no matter what day the Go/No-Go meetings are on.
The question asked is if having this "soft deadline" style is
acceptable, or if we should stick to documented procedure where the
release should have slipped at both those occations.
While it's nice that we did not slip further (esp for me meeting users
on the 11-13 Nov at FSCONS), it at the same time sets the wrong tone
about seriousness of having critical bugs discovered such late in the
process, and creates an enormous amount of stress and uncertainty for
everyone involved.
I do not think it's a healthy sign to have as many tc+rc spins as we had
this time. In how many of these respins were issues not reproducible
during a netinstall?
Regards
Henrik
12:22 a.m.
On Fri, 2011-11-04 at 21:06 +0100, Henrik Nordström wrote:
fre 2011-11-04 klockan 11:53 -0600 skrev Kevin Fenzi:
> If we do this, next cycle we should NOT do any 'two part' go/no-go
> meetings.
The "two part" meetings were both about critical blockers that were
known and actively being worked on at the time of the meeting. This
situation will happen no matter what day the Go/No-Go meetings are on.
Not necessarily. It's easy enough to go back over the logs; we've
certainly had quiet releases where nothing of the kind has happened. I
don't think we'd ever delayed the go/no-go prior to this cycle.
The question asked is if having this "soft deadline" style
is
acceptable, or if we should stick to documented procedure where the
release should have slipped at both those occations.
Well, I don't think anyone so far has said it's acceptable; we all seem
to more or less agree we should stop doing that and stick to the dates
we set. The question is whether there's any real _need_ for the go/no-go
to be nearly a whole day ahead of the release readiness meeting.
While it's nice that we did not slip further (esp for me meeting
users
on the 11-13 Nov at FSCONS), it at the same time sets the wrong tone
about seriousness of having critical bugs discovered such late in the
process, and creates an enormous amount of stress and uncertainty for
everyone involved.
I'm not sure it sets the wrong tone about the seriousness of the bugs -
there was never any question that if we actually couldn't resolve them,
we'd have to slip. But it certainly creates stress, yeah.
I do not think it's a healthy sign to have as many tc+rc spins as
we had
this time. In how many of these respins were issues not reproducible
during a netinstall?
I'm not sure the fact of having spins is a problem per se. Spins aren't
particularly difficult to do.
You can see the breakdown of all the RC spins:
https://fedorahosted.org/rel-eng/ticket/4967
RC2 was a quicky to fix a bug that was proposed soon after the initial
RC1. The bug is one that doesn't get covered by our formal validation
tests - we don't have any tests for remote home directories, but it's
something we do want to take as a blocker if an issue comes up. It's not
an issue you'd get on a straightforward local install.
The major issue for RC3 was upgrading a system which uses KDE, which was
broken due to a dependency issue. Our validation tests don't cover this
directly - upgrades are a massive area so what we test is just default
installations. But KDE is a supported desktop so when there's an issue
that would break the desktop for any KDE user who upgrades, that
obviously needs fixing. Again, this is not something you'd see on a
straight default install: you have to do a KDE install of F15 and then
try to upgrade it. We also took an update to xfwm which fixed an Xfce
nice-to-have...
...which actually broke Xfce thanks to one of my least favourite
situations, 'fix-this-bug-and-find-the-one-hiding-behind-it'. The RC3
fix meant that xfwm provided a dependency instead of metacity - which we
want, obviously, for Xfce - but in fact, gdm's fallback mode doesn't
work with anything but metacity. So when you fix it so the Xfce spin
doesn't have a bogus requirement for metacity, Xfce breaks, because it
turns out there's a *real* requirement for metacity which was
unexpressed. So in RC4, we took a gdm update to require metacity. But
that wasn't a blocker - only KDE and GNOME block releases. The major
blocker issue we fixed in RC4 was a regression in the kernel which broke
EFI boot on some systems. In theory you could hit this from a netinst,
sure - but you'd have to be installing via EFI on a system affected by
this bug. Previous RCs were tested on EFI by multiple people, but none
had a system affected by the bug.
Finally, RC5 fixed a bug when you do an F15 to F16 upgrade using the
traditional installer (DVD/netinst) written to a USB stick. Again, this
isn't something you'd hit just doing a straight through install of F16.
Note that the bug is masked if you write the USB stick with dd instead
of livecd-iso-to-disk, and there is a further wrinkle involved in using
l-i-t-d concerning whether you use the --format parameter.
So of all the issues that necessitated RC respins, no, you would not
have hit a single one just doing a straight-through netinst or DVD
install on a typical hardware configuration. That's something that's
required to work at *Alpha* stage. By final, we're covering much more
complex issues. This is kind of what I mean when I say we're actually
holding ourselves to reasonably high quality standards these days.
I do suspect that, if you've never actually gotten involved in the
release validation cycle, it's easy to underestimate the sheer amount of
possible configurations and workflows we have to consider. Just look at
the bugs fixed during RC stage, listed above - we've got remote home
directories, upgrades to systems using KDE, installs using EFI, and
upgrades using the installer written to a USB stick. Just look at those
variables - which desktop do you use? Do you boot via BIOS or EFI? Do
you use the traditional installer or a live image? Do you write it to a
USB stick or an actual disc? Do you use l-i-t-d or dd? Do you format the
USB stick or not? That's six 1/0 choices, 64 configurations - *just
considering the things that happened to be broken during F16 final RC
stage*. The total possible configuration space in all the things we
profess to consider release blocking is ridiculously huge, it's probably
somewhere in the millions. There's no way we can systematically cover
every issue.
We already are required to run this complete set of tests:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
https://fedoraproject.org/wiki/Test_Results:Current_Base_Test
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
for most composes (we fudge it a bit when the change between composes is
very small), and that doesn't really come close to covering everything
that can possibly go wrong. A 'full' validation matrix which gave us
near-100% confidence of covering everything on the first shot would go
on for pages and pages, and take massively more resources than we have
or, realistically, are ever going to have.
There are various 'hot topics' exposed during the F16 cycle that we'll
likely expand the matrix to cover better in F17 - bootloader location
issues, EFI issues, USB installer issues (when we first drew up the
installation tests, using USB sticks for installation was very rare, and
I think you couldn't actually write non-live images to USB at all), and
very large disks (plus 4k sector sizes) are some of the things we're
looking at - but we can't expand the coverage past the point where we
have the resources to actually carry it out, and we're never going to be
able to come really close to covering every possibility. Given this,
it's pretty impossible to avoid issues coming up along the way,
especially in a release like F16 which touches stuff we haven't touched
for a long time.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:04 p.m.
On Sat, Nov 5, 2011 at 5:22 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
There are various 'hot topics' exposed during the F16 cycle
that we'll
likely expand the matrix to cover better in F17 - bootloader location
issues, EFI issues, USB installer issues (when we first drew up the
installation tests, using USB sticks for installation was very rare, and
I think you couldn't actually write non-live images to USB at all), and
Last night I used livecd-iso-to-disk to write the rc5 64 bit DVD
install iso to an 8 GiB usbkey - which I am planning to test this
evening to install to a desktop.... i.e. the usbkey will be my install
(source) medium.
I have used this method for several years - and not had a failure yet
- I will report if there are any problems when I do this install for
f16....
--
mike c
3:20 p.m.
On Sat, 2011-11-05 at 17:04 +0000, mike cloaked wrote:
On Sat, Nov 5, 2011 at 5:22 AM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> There are various 'hot topics' exposed during the F16 cycle that we'll
> likely expand the matrix to cover better in F17 - bootloader location
> issues, EFI issues, USB installer issues (when we first drew up the
> installation tests, using USB sticks for installation was very rare, and
> I think you couldn't actually write non-live images to USB at all), and
Last night I used livecd-iso-to-disk to write the rc5 64 bit DVD
install iso to an 8 GiB usbkey - which I am planning to test this
evening to install to a desktop.... i.e. the usbkey will be my install
(source) medium.
I have used this method for several years - and not had a failure yet
- I will report if there are any problems when I do this install for
f16....
Ah, that's far too simple. ;)
See, the problem we solved in RC5 only came when you wrote the installer
to USB with l-i-t-d *and then used it to upgrade an F15 system*. The
problem was that anaconda doesn't filter out the USB key it's installing
from as a potential bootloader installation target, and it orders the
preferred bootloader target disks in the order they're presented by the
BIOS - and when you boot from a USB stick, the BIOS presents it as the
first disk. So when you run the traditional installer from a USB stick,
the USB stick starts out as the preferred bootloader target disk.
Why does this only affect upgrades, and why didn't we catch it before?
Well, on fresh installs, you get the 'cleardiskssel' screen, which is
the one where you put 'install target devices' on the right and 'data
storage devices' (i.e. "leave these alone!") on the left, and pick one
of the 'install target devices' to be the bootloader device with a radio
button. On upgrades, you _don't_ get that screen. So on a fresh install
it doesn't really matter which device anaconda would have chosen as the
bootloader target, as in practice you get to make the decision anyway,
and because of various other factors I won't go into here, that screen
doesn't 'default' to anything - it doesn't default to nominating the USB
stick as the bootloader target device.
Why didn't we catch it before? Before F16, when you upgraded, the
default action was not to actually write a new bootloader. The default
action was just to update the existing bootloader *configuration file*
in the Fedora installation being upgraded. Since this was almost always
what you wanted to do, very few people switched to the 'install new
bootloader' option when upgrading, which makes it much less likely we'd
catch this bug.
And _finally_, there is another dialog you _do_ see when you upgrade,
which essentially is designed to let you choose whether to put the
bootloader on the MBR or on the first partition of the target disk. It
has a drop-down labelled 'BIOS boot order' which is intended to let you
correct the ordering of the disks if anaconda somehow read it wrong -
what it really does is change the (hd0), (hd1) etc etc order that the
grub config file uses. But prior to F16, it would also change the target
disk for the bootloader install - so if anaconda had decided the USB
stick was the target disk, you could fiddle the BIOS boot order in that
dropdown and use that to make it pick the hard disk instead. So there
used to be a way to work around the problem.
Put all that together, and you get an F16 blocker. But it's a hell of a
lot of moving parts...and that's one of the problems anaconda team and
QA face all the time.
The pending F17 anaconda UI re-design isn't just intended to make
anaconda look shinier and be more user-friendly; it's also intended to
rethink a lot of these paths which have grown complex and messy over
time and are just badly designed. You may have noticed in the above that
there are two overlapping dialogs about bootloader location, and you
might get one or the other or both or neither depending on what
installation path you choose exactly, which is kind of silly. That's one
of the things the UI rewrite will be able to improve, and hence make
everyone's job easier, we hope...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:30 p.m.
On Sat, Nov 5, 2011 at 8:20 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
See, the problem we solved in RC5 only came when you wrote the
installer
to USB with l-i-t-d *and then used it to upgrade an F15 system*. The
problem was that anaconda doesn't filter out the USB key it's installing
from as a potential bootloader installation target, and it orders the
preferred bootloader target disks in the order they're presented by the
BIOS - and when you boot from a USB stick, the BIOS presents it as the
Wow - OK!
I decided to try another tack this evening on my test machine which
"was" running F15 - I placed the F16 install iso on a partition which
would not be touched - and loop mounted it - then pulled vmlinuz and
initrd.img into /boot, and made a new stanza in /boot/grub/grub.conf
(another technique I have used for years).
It booted into the installer just fine - but here is the catch/snag -
instead of being able to point the install to using the iso on the
unused partition it asks for a network location for the repos -but I
could not get it to use the local iso! Maybe I am being dumb or is
this something that can't be done with F16 installs?
Now the install is off and running but of course will take a lot
longer than using the local iso for the packages - but of course I
have now formatted the root partition so I can't go back to the start
point!
Have I done something dumb here? Or have I missed something in
getting an install to run off my HD?
--
mike c
3:40 p.m.
On Sat, Nov 5, 2011 at 8:30 PM, mike cloaked <mike.cloaked(a)gmail.com> wrote:
I decided to try another tack this evening on my test machine which
"was" running F15 - I placed the F16 install iso on a partition which
would not be touched - and loop mounted it - then pulled vmlinuz and
initrd.img into /boot, and made a new stanza in /boot/grub/grub.conf
(another technique I have used for years).
It booted into the installer just fine - but here is the catch/snag -
instead of being able to point the install to using the iso on the
unused partition it asks for a network location for the repos -but I
could not get it to use the local iso! Maybe I am being dumb or is
this something that can't be done with F16 installs?
Now the install is off and running but of course will take a lot
longer than using the local iso for the packages - but of course I
have now formatted the root partition so I can't go back to the start
point!
Have I done something dumb here? Or have I missed something in
getting an install to run off my HD?
Thinking about it I am now wondering if I should have added
"repo=hd:device" to the grub stanza kernel line.....
--
mike c
1:53 p.m.
On Fri, 2011-11-04 at 09:37 -0500, Bruno Wolff III wrote:
On Thu, Nov 03, 2011 at 23:17:21 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
>
> It'd be great if we can work with the anaconda team closely to try and
> get involved all along the line in the UI rewrite stuff, and see if that
> can reduce the pressure around release times - let's put that on the
> table for the next meeting. But it might still turn out to be a tough
> one. If anyone has any suggestions or ideas at all, please do contribute
> them! The more thinking the better.
Yeah, I think early testing will be good there. (Unfortunately, that's
not an area I am good at helping with as I mostly do yum upgrades and
run rawhide/branched continuously rather than do lots of test installs.)
It might be useful to run through the test matrices at some other points in
the release cycle to get a heads up on potential blockers with more time
on them. It seemed this release we were in crisis mode for a lot of the
blockers.
We tried to do that to some extent in 16 cycle by moving the TC date one
week up for both Beta and Final, and I think that worked pretty well. I
also noted on the retrospective that we should avoid the trap of
focusing too strongly on the blocker bugs we find _first_, and keep
testing while those are getting fixed to find any others that are
lurking.
> Yeah, agreed. I don't think there's any especial need
for the go/no-go
> to be an entire day ahead of the release readiness meeting, in all
> honesty - it seems to work fine simply to do it earlier the same day. So
> do you think it'd be alright to suggest that as a change for the F17 and
> beyond scheduling? Every time we've decided the delay the go/no-go
> decision, that choice in itself hasn't caused any problems, as far as
> I'm aware. It simply gives us more time for validation, which is never a
> bad thing...
I am concerned with the process as executed not matching the documentation.
I'd just like to see a change codified that either allows moving the Go /
No-Go meeting when appropriate or just schedule it closer to the
readiness meeting.
Yup, indeed, bending process is a bad habit to get into. We can bring it
up at the meeting and if everyone's happy with moving go/no-go back I
can talk to Robyn and have the 17 schedule changed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4577
days inactive
4579
days old
15 comments
7 participants
participants (7)
-
Adam Williamson -
Bruno Wolff III -
Henrik Nordström -
Kevin Fenzi -
mike cloaked -
Robyn Bergeron -
Stephen John Smoogen