another upgrade, another disaster

[Neal Becker]

Basically the same kind of failure as the last several times I did updates.
This time f16->f17. Used preupgrade.

It seems to have all gone wrong when cpio failed, because a python package had
been installed using pip into the (default) system dirs. The conflict IIRC
happens because pip installs a dir where cpio expects a file (or vice-versa).

I've since learned to use pip install --user instead - but there was still a
leftover package.

I was happy (temporarily) to see that I could still reboot the machine. Remove
the offending package.

Then IIRC I restarted the upgrade. It seemed to complete OK. I was pleased to
see it appear to continue from where it left off.

On reboot, I found a huge mess. Duplicate packages (f16/f17) all over.

So,

1) Could I have actually recovered from this mess without a complete re-install?

2) Can't we make the install fail more gracefully?

3) Would it be possible to continue an failed install, and have it actually
work?

[Corey Richardson]

On Tue, 29 May 2012 16:42:30 -0400

Post by Neal Becker
Basically the same kind of failure as the last several times I did
updates. This time f16->f17. Used preupgrade.

I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

[Tom Callaway]

Post by Corey Richardson
I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

We do test preupgrade as part of the pre-release testing. The problem is
that people do all sorts of wacky things to their systems that cause it
to not work well. I'm sure that QA would love to have more people
testing preupgrade during the beta->RC window.

So, your statement that devs don't care isn't valid. It may still not be
worth the pain, depending on how much you have installed outside of the
Fedora Package universe.

~tom

==
Fedora Project

[Neal Becker]

Post by Tom Callaway

Post by Corey Richardson
I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

We do test preupgrade as part of the pre-release testing. The problem is
that people do all sorts of wacky things to their systems that cause it
to not work well. I'm sure that QA would love to have more people
testing preupgrade during the beta->RC window.
So, your statement that devs don't care isn't valid. It may still not be
worth the pain, depending on how much you have installed outside of the
Fedora Package universe.
~tom
==
Fedora Project

In this case, anaconda would fail just the same.

[Adam Williamson]

Post by Tom Callaway

Post by Corey Richardson
I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

We do test preupgrade as part of the pre-release testing. The problem is
that people do all sorts of wacky things to their systems that cause it
to not work well. I'm sure that QA would love to have more people
testing preupgrade during the beta->RC window.
So, your statement that devs don't care isn't valid. It may still not be
worth the pain, depending on how much you have installed outside of the
Fedora Package universe.

Not entirely valid, but if we're being completely honest, there is only
one preupgrade maintainer - hughsie - and he has a couple of other
full-time jobs. So I think it's fair to say it doesn't get as much
active maintenance as it might. The preupgrade bug list is quite long -
127 bugs, http://bugz.fedoraproject.org/preupgrade - and I know for a
fact it contains quite a few valid reports which could be fixed
by...development.

Your broader point is of course also true. upgrading is a fundamentally
unsupportable operation: the amount of variables in play when it comes
to upgrading a system which a person has been using, normally, for some
time is so huge as to be probably incalculable. What we test in a
programmed way is that you can do a clean installation of F16, update it
to current packages, then run 'preupgrade' and wind up with an F17
system that boots. That is the extent of the preupgrade validation
testing. Any further testing relies on people trying it and filing bugs,
as Tom says.

The particular failure scenario involved here - 'user let
SOME_THIRD_PARTY_THING screw up RPM-managed files' - is obviously quite
a long way down the list of things we're going to care about. There has
to be a limit to what we can achieve with the resources available to a
project like Fedora. We don't have a 2,000 system test lab stashed away
somewhere with a few hundred people in it running upgrade tests in
various arbitrary scenarios, 24 hours a day. We just don't. All we can
do is ask people to test and file bugs prior to release, and I think we
certainly do enough of that...

[Neal Becker]

Post by Adam Williamson

Post by Tom Callaway

Post by Corey Richardson
I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

We do test preupgrade as part of the pre-release testing. The problem is
that people do all sorts of wacky things to their systems that cause it
to not work well. I'm sure that QA would love to have more people
testing preupgrade during the beta->RC window.
So, your statement that devs don't care isn't valid. It may still not be
worth the pain, depending on how much you have installed outside of the
Fedora Package universe.

Not entirely valid, but if we're being completely honest, there is only
one preupgrade maintainer - hughsie - and he has a couple of other
full-time jobs. So I think it's fair to say it doesn't get as much
active maintenance as it might. The preupgrade bug list is quite long -
127 bugs, http://bugz.fedoraproject.org/preupgrade - and I know for a
fact it contains quite a few valid reports which could be fixed
by...development.
Your broader point is of course also true. upgrading is a fundamentally
unsupportable operation: the amount of variables in play when it comes
to upgrading a system which a person has been using, normally, for some
time is so huge as to be probably incalculable. What we test in a
programmed way is that you can do a clean installation of F16, update it
to current packages, then run 'preupgrade' and wind up with an F17
system that boots. That is the extent of the preupgrade validation
testing. Any further testing relies on people trying it and filing bugs,
as Tom says.
The particular failure scenario involved here - 'user let
SOME_THIRD_PARTY_THING screw up RPM-managed files' - is obviously quite
a long way down the list of things we're going to care about. There has
to be a limit to what we can achieve with the resources available to a
project like Fedora. We don't have a 2,000 system test lab stashed away
somewhere with a few hundred people in it running upgrade tests in
various arbitrary scenarios, 24 hours a day. We just don't. All we can
do is ask people to test and file bugs prior to release, and I think we
certainly do enough of that...

But we can, and should, at least try to make our systems tolerant of failures.
Just because we can't test everything. Defensive programming.

[Adam Williamson]

Post by Neal Becker
But we can, and should, at least try to make our systems tolerant of failures.
Just because we can't test everything. Defensive programming.

Sure. As someone else said, though, that's an issue in rpm if
anywhere...

[Panu Matilainen]

Post by Adam Williamson

Post by Neal Becker
But we can, and should, at least try to make our systems tolerant of failures.
Just because we can't test everything. Defensive programming.

Sure. As someone else said, though, that's an issue in rpm if
anywhere...

Dunno what kind of failures you're referring to here (not saying rpm
doesn't have any, just that it's not clear to me in this context), but
the vast majority of upgrade-related issues are not so much in rpm but
anaconda/preupgrade/yum level of things.

(One of) the recurring themes is
1) user has a system with bunch of non-default packages installed
2) user does an anaconda-upgrade with a DVD
3) anaconda blasts through the upgrade ignoring anything it can't upgrade
4) yum barfs on the resulting broken dependency mess

Anaconda (and perhaps preupgrade as well, I dont know it well enough to
comment) could be stricter and refuse to upgrade unless all dependencies
are met, either through user adding/adjusting (3rd party) repositories
as necessary or removing all offending packages, but that'd perhaps just
create a different kind of PITA.

It'd help if yum learned how to fix (at least some) pre-existing
problems instead of just complaining and giving up.

One thing that might also help is changing anaconda & preupgrade to use
yum distro-sync equivalent instead of the "regular" upgrade.

- Panu -

[Michael scherer]

Post by Panu Matilainen

Post by Adam Williamson

Post by Neal Becker
But we can, and should, at least try to make our systems tolerant of failures.
Just because we can't test everything. Defensive programming.

Sure. As someone else said, though, that's an issue in rpm if
anywhere...

Dunno what kind of failures you're referring to here (not saying rpm
doesn't have any, just that it's not clear to me in this context), but
the vast majority of upgrade-related issues are not so much in rpm
but anaconda/preupgrade/yum level of things.
(One of) the recurring themes is
1) user has a system with bunch of non-default packages installed
2) user does an anaconda-upgrade with a DVD
3) anaconda blasts through the upgrade ignoring anything it can't upgrade
4) yum barfs on the resulting broken dependency mess
Anaconda (and perhaps preupgrade as well, I dont know it well enough
to comment) could be stricter and refuse to upgrade unless all
dependencies are met, either through user adding/adjusting (3rd
party) repositories as necessary or removing all offending packages,
but that'd perhaps just create a different kind of PITA.

It would be much better to refuse to upgrade than to break later in weird way,
since users perception would be different.

First, they would either ask for help and then someone could explain what is wrong.

This would also reduce the number of failed upgrade and therefor the number of bugs
that cannot be reproduced, thus making them likely easier to spot and fix.

[Panu Matilainen]

Post by Michael scherer

Post by Panu Matilainen

Post by Adam Williamson

Post by Neal Becker
But we can, and should, at least try to make our systems tolerant of failures.
Just because we can't test everything. Defensive programming.

Sure. As someone else said, though, that's an issue in rpm if
anywhere...

Dunno what kind of failures you're referring to here (not saying rpm
doesn't have any, just that it's not clear to me in this context), but
the vast majority of upgrade-related issues are not so much in rpm
but anaconda/preupgrade/yum level of things.
(One of) the recurring themes is
1) user has a system with bunch of non-default packages installed
2) user does an anaconda-upgrade with a DVD
3) anaconda blasts through the upgrade ignoring anything it can't upgrade
4) yum barfs on the resulting broken dependency mess
Anaconda (and perhaps preupgrade as well, I dont know it well enough
to comment) could be stricter and refuse to upgrade unless all
dependencies are met, either through user adding/adjusting (3rd
party) repositories as necessary or removing all offending packages,
but that'd perhaps just create a different kind of PITA.

It would be much better to refuse to upgrade than to break later in weird way,
since users perception would be different.
First, they would either ask for help and then someone could explain what is wrong.
This would also reduce the number of failed upgrade and therefor the number of bugs
that cannot be reproduced, thus making them likely easier to spot and fix.

Yup. AFAICS anaconda doesn't even so much as warn about broken
dependencies on upgrade, giving users a false sense of things being all
peaches when in reality it could be creating an enormous mess. Witness
eg https://bugzilla.redhat.com/show_bug.cgi?id=826686 and
https://bugzilla.redhat.com/show_bug.cgi?id=826621 - a user might think
twice before proceeding with an upgrade creating 150-200 broken
dependencies, all of which silently ignored atm.

- Panu -

- Panu -

[Adam Williamson]

Post by Panu Matilainen

Post by Adam Williamson

Post by Neal Becker
But we can, and should, at least try to make our systems tolerant of failures.
Just because we can't test everything. Defensive programming.

Sure. As someone else said, though, that's an issue in rpm if
anywhere...

Dunno what kind of failures you're referring to here (not saying rpm
doesn't have any, just that it's not clear to me in this context), but

Read back in the thread. The specific 'disaster' that triggered the
thread initially is described thus by the reporter:

"It seems to have all gone wrong when cpio failed, because a python package had
been installed using pip into the (default) system dirs. The conflict IIRC
happens because pip installs a dir where cpio expects a file (or vice-versa)."

AFAIK that's at the rpm level, if we're talking cpio failure.

[Caterpillar]

2012/5/31 Adam Williamson <awilliam at redhat.com>

Post by Adam Williamson

Post by Tom Callaway

Post by Corey Richardson
I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

We do test preupgrade as part of the pre-release testing. The problem is
that people do all sorts of wacky things to their systems that cause it
to not work well. I'm sure that QA would love to have more people
testing preupgrade during the beta->RC window.
So, your statement that devs don't care isn't valid. It may still not be
worth the pain, depending on how much you have installed outside of the
Fedora Package universe.

Not entirely valid, but if we're being completely honest, there is only
one preupgrade maintainer - hughsie - and he has a couple of other
full-time jobs. So I think it's fair to say it doesn't get as much
active maintenance as it might. The preupgrade bug list is quite long -
127 bugs, http://bugz.fedoraproject.org/preupgrade - and I know for a
fact it contains quite a few valid reports which could be fixed
by...development.
Your broader point is of course also true. upgrading is a fundamentally
unsupportable operation: the amount of variables in play when it comes
to upgrading a system which a person has been using, normally, for some
time is so huge as to be probably incalculable. What we test in a
programmed way is that you can do a clean installation of F16, update it
to current packages, then run 'preupgrade' and wind up with an F17
system that boots. That is the extent of the preupgrade validation
testing. Any further testing relies on people trying it and filing bugs,
as Tom says.
The particular failure scenario involved here - 'user let
SOME_THIRD_PARTY_THING screw up RPM-managed files' - is obviously quite
a long way down the list of things we're going to care about. There has
to be a limit to what we can achieve with the resources available to a
project like Fedora. We don't have a 2,000 system test lab stashed away
somewhere with a few hundred people in it running upgrade tests in
various arbitrary scenarios, 24 hours a day. We just don't. All we can
do is ask people to test and file bugs prior to release, and I think we
certainly do enough of that...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

I would like to share my experience about upgrading from Fedora 16 to 17 a
quiet number of machines.

100% percenteage computer base have putted my hands on, had problems during
the upgrade from Fedora 16 to 17.

Which problems? First of all, the most happening error (~80%) is after
preupgrade-anaconda upgrade. Once the installation of fc17 packages has
finished, at reboot, grub2 still had Fedora 16 kernels. To fix that you had
to start one of those kernels (and conseguentely having a kernel panic when
doing a system restart) and do a grub2-mkconfig /boot/grub2/grub.cfg On
most cases, it fixed the problem, but not every single time.

Second bug I found out: during anaconda system upgrade, it freezed on
upgrading package "steel bank common lisp". To finish the upgrade I had to
reboot and let it start again.

Third bug: after preupgrade finished to download fc17 packages, I rebooted,
but grub did not have a “upgrade system” entry. So the computer is not
upgradable with preupgrade.

In these hours, bugzilla is being full of reports like these...
So now, developers say that they need more people to do beta testing, but
my question is: if at least 80% userbase had troubles with grub showing old
kernels, is it possible that nobody of testers had this problem? I really
don't think so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120531/bec343cc/attachment.html>

[Adam Williamson]

Post by Caterpillar
I would like to share my experience about upgrading from Fedora 16 to
17 a quiet number of machines.
100% percenteage computer base have putted my hands on, had problems
during the upgrade from Fedora 16 to 17.
Which problems? First of all, the most happening error (~80%) is after
preupgrade-anaconda upgrade. Once the installation of fc17 packages
has finished, at reboot, grub2 still had Fedora 16 kernels. To fix
that you had to start one of those kernels (and conseguentely having a
kernel panic when doing a system restart) and do a
grub2-mkconfig /boot/grub2/grub.cfg On most cases, it fixed the
problem, but not every single time.

Yes. We know about that one. We've had it filed since before release.
Actually, there are at least two issues in this area. See
https://bugzilla.redhat.com/show_bug.cgi?id=820340 ,
https://bugzilla.redhat.com/show_bug.cgi?id=820351 .

Post by Caterpillar
Second bug I found out: during anaconda system upgrade, it freezed on
upgrading package "steel bank common lisp". To finish the upgrade I
had to reboot and let it start again.

It's a buggy %post script in the package.
https://bugzilla.redhat.com/show_bug.cgi?id=822008

Post by Caterpillar
Third bug: after preupgrade finished to download fc17 packages, I
rebooted, but grub did not have a “upgrade system” entry. So the
computer is not upgradable with preupgrade.

Need more information.

Post by Caterpillar
So now, developers say that they need more people to do beta testing,
but my question is: if at least 80% userbase had troubles with grub
showing old kernels, is it possible that nobody of testers had this
problem? I really don't think so.

No, that is not the case. See above. The issues with old kernel sticking
around after upgrade were already known and reported before release.

The #820351 case is fundamentally more or less impossible to solve
entirely, outside of sticking Epochs in the kernel package. So there was
no point holding up the release for that. The #820340 case is specific
to preupgrade and isn't a showstopper, so we didn't hold the release for
that one either. There is an upgrade currently in testing that ought to
fix it.

[Caterpillar]

2012/5/31 Adam Williamson <awilliam at redhat.com>

Post by Adam Williamson

Post by Caterpillar
Third bug: after preupgrade finished to download fc17 packages, I
rebooted, but grub did not have a “upgrade system” entry. So the
computer is not upgradable with preupgrade.

Need more information.
Could it be? https://bugzilla.redhat.com/show_bug.cgi?id=826537#c27
So now, developers say that they need more people to do beta testing,

Post by Caterpillar
but my question is: if at least 80% userbase had troubles with grub
showing old kernels, is it possible that nobody of testers had this
problem? I really don't think so.

No, that is not the case. See above. The issues with old kernel sticking
around after upgrade were already known and reported before release.
The #820351 case is fundamentally more or less impossible to solve
entirely, outside of sticking Epochs in the kernel package. So there was
no point holding up the release for that. The #820340 case is specific
to preupgrade and isn't a showstopper, so we didn't hold the release for
that one either. There is an upgrade currently in testing that ought to
fix it.
Please apologize me, but if #820340 was not a showstopper, so which bug

should be a showstopper? I am very disappointed with that, because
preupgrade is the official supported way to upgrade Fedora versions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120601/0955c80d/attachment.html>

[Michal Schmidt]

Post by Adam Williamson
Please apologize me, but if #820340 was not a showstopper, so which bug
should be a showstopper?

The bug
* does not cause data loss
* is easy to recover from
* seems to be fixable with an update
=> Not what I'd call a showstopper.

Michal

[Reindl Harald]

Post by Michal Schmidt

Post by Adam Williamson
Please apologize me, but if #820340 was not a showstopper, so which bug
should be a showstopper?

The bug
* does not cause data loss
* is easy to recover from

for you and for me
not for the majority of users

Post by Michal Schmidt
* seems to be fixable with an update

how do you do the update if your system does not boot?
it is not sure that a kernel from the oldr release boots

Post by Michal Schmidt
=> Not what I'd call a showstopper

depends on the point of view

at a minimum it should be granted that the kernel of the new
distribution version is the default after dist-upgrade

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120601/125ff7b6/attachment.sig>

[Adam Williamson]

Post by Reindl Harald

Post by Michal Schmidt

Post by Adam Williamson
Please apologize me, but if #820340 was not a showstopper, so which bug
should be a showstopper?

The bug
* does not cause data loss
* is easy to recover from

for you and for me
not for the majority of users

Post by Michal Schmidt
* seems to be fixable with an update

how do you do the update if your system does not boot?
it is not sure that a kernel from the oldr release boots

In all our tests, it did.

Post by Reindl Harald

Post by Michal Schmidt
=> Not what I'd call a showstopper

depends on the point of view
at a minimum it should be granted that the kernel of the new
distribution version is the default after dist-upgrade

That's easy to lie around and say. Do you want to be responsible for a)
testing to ensure that it's the case, b) coming up with viable patches
to ensure it happens, and c) delaying the release until this is the
case?

[Adam Williamson]

I am very disappointed with that, because preupgrade is the official
supported way to upgrade Fedora versions

Strictly, no. It's *a* supported way.

Frankly, I'd prefer it if we more strongly recommended that people do
DVD/netinst upgrades. That path is less complex than preupgrade and
involves fewer moving parts; it's easier to test and easier to fix and
more likely, in general, to be working at any given point.

I'd put the possible upgrade methods in this order of
likely-to-workness:

1. netinst.iso / DVD.iso with 'updates' repo enabled
2. DVD.iso without 'updates' repo
3. yum *if you follow the instructions carefully*
4. preupgrade
5. yum by the He-Man method ('instructions are for wusses')

[Alexander Boström]

Post by Adam Williamson
Frankly, I'd prefer it if we more strongly recommended that people do
DVD/netinst upgrades. That path is less complex than preupgrade and
involves fewer moving parts; it's easier to test and easier to fix and
more likely, in general, to be working at any given point.

Please no. Once Fedora is installed it really ought to be able to
upgrade itself without needing new boot media twice a year, that's just
not user friendly. It's also much safer to first download everything and
then start the RPM transaction. (IIUC a normal Anaconda upgrade will
download packages during the upgrade.)

/Alexander

[Adam Williamson]

Post by Alexander Boström

Post by Adam Williamson
Frankly, I'd prefer it if we more strongly recommended that people do
DVD/netinst upgrades. That path is less complex than preupgrade and
involves fewer moving parts; it's easier to test and easier to fix and
more likely, in general, to be working at any given point.

Please no. Once Fedora is installed it really ought to be able to
upgrade itself without needing new boot media twice a year, that's just
not user friendly. It's also much safer to first download everything and
then start the RPM transaction. (IIUC a normal Anaconda upgrade will
download packages during the upgrade.)

You state an aspiration, I state my advice based on practical
experience. Your aspiration would be nice, sure. It doesn't accurately
match reality at present. I'm happy advising experienced users who don't
mind a bit of poking about to use yum to keep upgrading ad infinitum. I
would not recommend it to all users, though, or say it was our
supported-and-most-likely-to-work upgrade mechanism. And my most
important point, anyway, is that DVD/netinst upgrade is, practically
speaking, generally more reliable than preupgrade, in recent history.

[Björn Persson]

Post by Adam Williamson
Frankly, I'd prefer it if we more strongly recommended that people do
DVD/netinst upgrades.

I refuse to buy writable DVDs or CDs, because if I did I would be giving money
to the copyright lobby, helping to finance its campaign for ever-increasing
mass surveillance and censorship of the Net. It is possible to boot a DVD
image from the hard disk, but it's anything but easy and rarely succeeds at
the first attempt, so that's not something I want to fiddle around with twice a
year on both of my Fedora boxes.

I also won't install anything that I haven't checked the PGP signature on.
That excludes netinst.iso and Preupgrade, and if I use Anaconda I have to be
careful to not let it download anything.

Therefore I usually upgrade by Yum. That's also a laborious process, but I
usually get a mostly working system in the end.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120603/dff553a5/attachment.sig>

[Tomasz Torcz]

Post by Björn Persson

Post by Adam Williamson
Frankly, I'd prefer it if we more strongly recommended that people do
DVD/netinst upgrades.

I refuse to buy writable DVDs or CDs, because if I did I would be giving money
to the copyright lobby, helping to finance its campaign for ever-increasing
mass surveillance and censorship of the Net. It is possible to boot a DVD
image from the hard disk, but it's anything but easy and rarely succeeds at
the first attempt, so that's not something I want to fiddle around with twice a
year on both of my Fedora boxes.

You can write .iso image to USB key¹ and boot from it, you know.

¹ using 'dd' or Disks → gear icon → restore image.

[Björn Persson]

Post by Tomasz Torcz
You can write .iso image to USB key¹ and boot from it, you know.

Even the installation DVD images? What I've heard is that that only works with
the live CD images.

(The copyright lobby taxes even USB keys in Sweden now, but I have some that I
bought before they started doing that.)

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120603/14be41b8/attachment.sig>

[Josh Boyer]

On Sun, Jun 3, 2012 at 4:32 PM, Björn Persson

Post by Björn Persson

Post by Tomasz Torcz
You can write .iso image to USB key¹ and boot from it, you know.

Even the installation DVD images? What I've heard is that that only works with
the live CD images.

Indeed, even the DVD images. I did this on last Friday. That used to
not be the case, and it used to only work with the liveCD and boot.iso
images, but now DVD works as well. It even uses the repo contained on
the key instead of just acting like netboot.iso.

It's as if someone somewhere is off making real beneficial progress.
Whoever you are, I salute you and your dogged determinedness to ignore
emails!

josh

[Björn Persson]

Post by Josh Boyer
On Sun, Jun 3, 2012 at 4:32 PM, Björn Persson

Post by Björn Persson

Post by Tomasz Torcz
You can write .iso image to USB key¹ and boot from it, you know.

Even the installation DVD images? What I've heard is that that only works
with the live CD images.

Indeed, even the DVD images. I did this on last Friday. That used to
not be the case, and it used to only work with the liveCD and boot.iso
images, but now DVD works as well. It even uses the repo contained on
the key instead of just acting like netboot.iso.

OK, that's a welcome improvement. I might try that.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120603/c6e1a74b/attachment.sig>

[Brian C. Lane]

Post by Björn Persson

Post by Tomasz Torcz
You can write .iso image to USB key¹ and boot from it, you know.

Even the installation DVD images? What I've heard is that that only works with
the live CD images.

You can dd all of the iso's to USB or you can use livecd-iso-to-disk for
a bit more control over things (despite its name it also works with the
dvd iso).

[Adam Williamson]

Post by Brian C. Lane

Post by Björn Persson

Post by Tomasz Torcz
You can write .iso image to USB key¹ and boot from it, you know.

Even the installation DVD images? What I've heard is that that only works with
the live CD images.

You can dd all of the iso's to USB or you can use livecd-iso-to-disk for
a bit more control over things (despite its name it also works with the
dvd iso).

The best documentation for this at present is
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB - the
installation guide is a bit out of date (through no fault of the
authors, rather our fault in not notifying them of the various recent
improvements to the tools).

[David]

Post by Björn Persson

Post by Adam Williamson
Frankly, I'd prefer it if we more strongly recommended that
people do DVD/netinst upgrades.

I refuse to buy writable DVDs or CDs, because if I did I would be
giving money to the copyright lobby, helping to finance its
campaign for ever-increasing mass surveillance and censorship of
the Net. It is possible to boot a DVD image from the hard disk, but
it's anything but easy and rarely succeeds at the first attempt, so
that's not something I want to fiddle around with twice a year on
both of my Fedora boxes.
I also won't install anything that I haven't checked the PGP
signature on. That excludes netinst.iso and Preupgrade, and if I
use Anaconda I have to be careful to not let it download anything.
Therefore I usually upgrade by Yum. That's also a laborious
process, but I usually get a mostly working system in the end.
Björn Persson

Do you also wear a tinfoil hat?

- --

David

[Adam Williamson]

Post by Björn Persson

Post by Adam Williamson
Frankly, I'd prefer it if we more strongly recommended that people do
DVD/netinst upgrades.

I refuse to buy writable DVDs or CDs, because if I did I would be giving money
to the copyright lobby, helping to finance its campaign for ever-increasing
mass surveillance and censorship of the Net. It is possible to boot a DVD
image from the hard disk, but it's anything but easy and rarely succeeds at
the first attempt, so that's not something I want to fiddle around with twice a
year on both of my Fedora boxes.
I also won't install anything that I haven't checked the PGP signature on.
That excludes netinst.iso and Preupgrade, and if I use Anaconda I have to be
careful to not let it download anything.
Therefore I usually upgrade by Yum. That's also a laborious process, but I
usually get a mostly working system in the end.

Cool story bro.

Given that I was stating my personal opinion on the message we should
communicate to the general user population about which upgrade methods
are most likely to work with the least tweaking, though, I'm not sure
what relevance your personal qualms about buying optical media have to
do with anything. It's not like I said we should disable yum upgrades.

(you can, of course, boot from the DVD or netinst image without ever
touching optical media. It is trivial to write them to a USB stick.)

[Björn Persson]

Post by Adam Williamson
Given that I was stating my personal opinion on the message we should
communicate to the general user population about which upgrade methods
are most likely to work with the least tweaking, though, I'm not sure
what relevance your personal qualms about buying optical media have to
do with anything. It's not like I said we should disable yum upgrades.

You wanted to "more strongly recommended that people do DVD/netinst upgrades".
By recommending this we'd be encouraging users to buy more optical media and
thereby give more money to the copyright lobby. Given that freedom is one of
Fedora's core values I don't think we should encourage people to give money to
organizations that are fighting to take freedom away from the Internet.

It's unfortunate if the ethically better upgrade methods are more likely to
fail, but if we'd always do what is most likely to work then we'd also be
shipping unfree device drivers and patented codecs.

Note 1: I don't know exactly how widespread this private tax on storage media
is, but I'm fairly sure it exists in many more countries than just Sweden.

Note 2: Yes there are reusable optical media, so user's don't need to buy new
discs every time they upgrade Fedora. None the less, the more people use
optical media, the more optical media will be sold in total, and the more
money will flow to the copyright lobby.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120604/45543f3c/attachment.sig>

[Adam Williamson]

Post by Björn Persson

Post by Adam Williamson
Given that I was stating my personal opinion on the message we should
communicate to the general user population about which upgrade methods
are most likely to work with the least tweaking, though, I'm not sure
what relevance your personal qualms about buying optical media have to
do with anything. It's not like I said we should disable yum upgrades.

You wanted to "more strongly recommended that people do DVD/netinst upgrades".
By recommending this we'd be encouraging users to buy more optical media and
thereby give more money to the copyright lobby. Given that freedom is one of
Fedora's core values I don't think we should encourage people to give money to
organizations that are fighting to take freedom away from the Internet.

Good for you. As things stand, though, as a project, we have no position
on that issue and no objection to optical media. Everyone has their
bugbears. If you can make it clear that enough people in Fedora feel as
strongly as you do about copyright levies, then maybe things will be
different. But, still, the fact remains that the 'DVD' and netinst
images are not in fact tied to optical media. I'd guess (it is entirely
a guess, I have no data) that they're as often deployed via USB as they
are via discs, these days.

[Adam Williamson]

Post by Björn Persson
I also won't install anything that I haven't checked the PGP signature on.
That excludes netinst.iso and Preupgrade, and if I use Anaconda I have to be
careful to not let it download anything.

The checksums of the images themselves are signed, and the images are
built by the same team that controls the process for signing individual
packages, using a process by which only packages from the Fedora build
system could possibly be included.

You can't logically claim to trust the individual packages but not trust
the signatures on the DVD/netinst images. They are precisely equally
trustworthy.

[Björn Persson]

Post by Adam Williamson

Post by Björn Persson
I also won't install anything that I haven't checked the PGP signature
on. That excludes netinst.iso and Preupgrade, and if I use Anaconda I
have to be careful to not let it download anything.

The checksums of the images themselves are signed, and the images are
built by the same team that controls the process for signing individual
packages, using a process by which only packages from the Fedora build
system could possibly be included.
You can't logically claim to trust the individual packages but not trust
the signatures on the DVD/netinst images. They are precisely equally
trustworthy.

Once I have verified the signature on an ISO image I trust the packages and
other software that is included in that image. If that software downloads more
packages off the Net, then I don't trust those packages unless the signatures
on those packages are being verified. Anaconda doesn't verify package
signatures (bug 998), so I don't trust Anaconda to download packages.
Preupgrade also didn't verify any signatures last time I checked, so I don't
trust Preupgrade. Yum, on the other hand, does verify the package signatures,
so I trust Yum. (I always check that all repositories that are configured with
"enabled=1" also have "gpgcheck=1". I really hope Yum doesn't ignore that
setting.)

So the available options are:

· netinst.iso: downloads packages and installs them unverified ⇒ unacceptable

· DVD with the updates repository enabled: downloads packages and installs
them unverified ⇒ unacceptable

· DVD without the updates repository: installs only packages included in the
DVD image, which I verified ⇒ OK (at least from a security point of view)

· Yum: downloads packages, verifies them, and then installs them ⇒ OK

· Preupgrade: downloads a kernel, a ramdisk and packages, and installs them
unverified ⇒ unacceptable

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120604/fd9e4a25/attachment.sig>

[Brian C. Lane]

Post by Adam Williamson

I am very disappointed with that, because preupgrade is the official
supported way to upgrade Fedora versions

Strictly, no. It's *a* supported way.
Frankly, I'd prefer it if we more strongly recommended that people do
DVD/netinst upgrades. That path is less complex than preupgrade and
involves fewer moving parts; it's easier to test and easier to fix and
more likely, in general, to be working at any given point.
I'd put the possible upgrade methods in this order of
1. netinst.iso / DVD.iso with 'updates' repo enabled
2. DVD.iso without 'updates' repo
3. yum *if you follow the instructions carefully*
4. preupgrade
5. yum by the He-Man method ('instructions are for wusses')

It should be possible to make preupgrade always work the best. It has
the most knowledge about the running system so it can pass that on to
Aanconda. We really need to work on making it more reliable for F18.

[Benny Amorsen]

Post by Adam Williamson
3. yum *if you follow the instructions carefully*

Those instructions include dracut doing unspecified magic. For other
releases I'd agree with you and do a yum upgrade, but I must admit I
don't dare try this time.

Preupgrade is a bit higher priority for this release.


/Benny

[Josh Boyer]

Post by Benny Amorsen

Post by Adam Williamson
3. yum *if you follow the instructions carefully*

Those instructions include dracut doing unspecified magic. For other

The magic was quite specified. You rebuild the initramfs with the
convertfs module included, and pass the approriate arguments on boot.
There's a wiki page covering exactly that.

josh

[Benny Amorsen]

Post by Josh Boyer
The magic was quite specified. You rebuild the initramfs with the
convertfs module included, and pass the approriate arguments on boot.
There's a wiki page covering exactly that.

Yes, the invokation is specified in detail. There just isn't any
documentation of what it actually does, to enable you to e.g. do it by
hand or have a guess at fixing it if it goes wrong. That is just too
risky for me.

You cannot upgrade from Fedora 16 to Fedora 17 in an OpenVZ guest,
because those don't run an initrd at all (or even a separate kernel).


/Benny

[Michal Schmidt]

Post by Benny Amorsen
Yes, the invokation is specified in detail. There just isn't any
documentation of what it actually does,

I thought what convertfs does was quite clear.
If you need to know the details how it does that, take a look at
/usr/lib/dracut/modules.d/30convertfs/convertfs.sh

Michal

[Josh Boyer]

Post by Benny Amorsen

The magic was quite specified.  You rebuild the initramfs with the
convertfs module included, and pass the approriate arguments on boot.
There's a wiki page covering exactly that.

Yes, the invokation is specified in detail. There just isn't any
documentation of what it actually does, to enable you to e.g. do it by
hand or have a guess at fixing it if it goes wrong. That is just too
risky for me.

It moves all the content from /lib and /bin to /usr/lib and /usr/bin
respectively and then makes /lib and /bin symlinks. The wiki page
actually tells you this.

Also, this is Open Source software, not magic. You can always read
the code, which is ultimately the best documentation if you want to
know _exactly_ what it does.

Post by Benny Amorsen
You cannot upgrade from Fedora 16 to Fedora 17 in an OpenVZ guest,
because those don't run an initrd at all (or even a separate kernel).

Yes you can. You just have to be willing to figure it out.

josh

[Adam Williamson]

Post by Josh Boyer

Post by Benny Amorsen

Post by Adam Williamson
3. yum *if you follow the instructions carefully*

Those instructions include dracut doing unspecified magic. For other

The magic was quite specified. You rebuild the initramfs with the
convertfs module included, and pass the approriate arguments on boot.
There's a wiki page covering exactly that.

Note that the exact same magic is done for you automatically during an
anaconda/preupgrade-based upgrade; the same dracut invocation is
performed, it's just that you don't do it manually.

[Michal Schmidt]

Post by Benny Amorsen

Post by Adam Williamson
3. yum *if you follow the instructions carefully*

Those instructions include dracut doing unspecified magic. For other
releases I'd agree with you and do a yum upgrade, but I must admit I
don't dare try this time.

Upgrading with Anaconda causes the same 'magic' to be run.

Despite having to do more steps manually, I had better success with
upgrading to F17 using yum than with the other methods.

One problem with upgrading using Anaconda from F15 was when it
encountered the "qt-examples" package. Anaconda just reported an error
in the middle of the upgrade and offered no way to continue. Recovering
from that was quite painful. Further investigation showed the likely
reason was a case of the known symlink vs. directory rpm issue.
With yum upgrade the issue affects only the one package, but allows the
transaction to finish.

Michal

[Adam Williamson]

Post by Benny Amorsen

Post by Adam Williamson
3. yum *if you follow the instructions carefully*

Those instructions include dracut doing unspecified magic. For other
releases I'd agree with you and do a yum upgrade, but I must admit I
don't dare try this time.

It's not really unspecified; it's doing the /usr move. I've followed the
16->17 yum upgrade instructions on five systems with complete success.

[Adam Williamson]

Post by Caterpillar
2012/5/31 Adam Williamson <awilliam at redhat.com>

Post by Caterpillar
Third bug: after preupgrade finished to download fc17

packages, I

Post by Caterpillar
rebooted, but grub did not have a “upgrade system” entry. So

the

Post by Caterpillar
computer is not upgradable with preupgrade.

Need more information.
Could it be? https://bugzilla.redhat.com/show_bug.cgi?id=826537#c27

No. In that comment I'm talking about what happens to the bootloader
once anaconda has fired up and started running the upgrade - what
anaconda does to the bootloader config. If you don't get an 'upgrade to
fedora 17' entry at all after preupgrade first stage, that's some kind
of bug in preupgrade itself: preupgrade has failed to modify the
existing bootloader config to add the entry.

Post by Caterpillar
No, that is not the case. See above. The issues with old kernel sticking
around after upgrade were already known and reported before release.
The #820351 case is fundamentally more or less impossible to solve
entirely, outside of sticking Epochs in the kernel package. So there was
no point holding up the release for that. The #820340 case is specific
to preupgrade and isn't a showstopper, so we didn't hold the release for
that one either. There is an upgrade currently in testing that ought to
fix it.
Please apologize me, but if #820340 was not a showstopper, so which
bug should be a showstopper? I am very disappointed with that, because
preupgrade is the official supported way to upgrade Fedora versions

It doesn't stop you from doing a successful upgrade. All it does is stop
you from shutting down cleanly, once.

[Caterpillar]

Post by Adam Williamson

Post by Caterpillar
2012/5/31 Adam Williamson <awilliam at redhat.com>

Post by Caterpillar
Third bug: after preupgrade finished to download fc17

packages, I

Post by Caterpillar
rebooted, but grub did not have a “upgrade system” entry. So

the

Post by Caterpillar
computer is not upgradable with preupgrade.

Need more information.
Could it be? https://bugzilla.redhat.com/show_bug.cgi?id=826537#c27

No. In that comment I'm talking about what happens to the bootloader
once anaconda has fired up and started running the upgrade - what
anaconda does to the bootloader config. If you don't get an 'upgrade to
fedora 17' entry at all after preupgrade first stage, that's some kind
of bug in preupgrade itself: preupgrade has failed to modify the
existing bootloader config to add the entry.

One of my machines is doing that. It could be a usefull testing base to
fix that bug. I am completely avaible to do any test you suggest

[Sérgio Basto]

Post by Adam Williamson

Post by Caterpillar
I would like to share my experience about upgrading from Fedora 16 to
17 a quiet number of machines.
100% percenteage computer base have putted my hands on, had problems
during the upgrade from Fedora 16 to 17.
Which problems? First of all, the most happening error (~80%) is after
preupgrade-anaconda upgrade. Once the installation of fc17 packages
has finished, at reboot, grub2 still had Fedora 16 kernels. To fix
that you had to start one of those kernels (and conseguentely having a
kernel panic when doing a system restart)

I can confirm that , seems a grub problem doesn't add F17 kernel to
menu , and boots with F16 kernel

Post by Adam Williamson
Yes. We know about that one. We've had it filed since before release.
Actually, there are at least two issues in this area. See
https://bugzilla.redhat.com/show_bug.cgi?id=820340 ,
https://bugzilla.redhat.com/show_bug.cgi?id=820351 .
No, that is not the case. See above. The issues with old kernel sticking
around after upgrade were already known and reported before release.
The #820351 case is fundamentally more or less impossible to solve
entirely, outside of sticking Epochs in the kernel package. So there was
no point holding up the release for that. The #820340 case is specific
to preupgrade and isn't a showstopper, so we didn't hold the release for
that one either. There is an upgrade currently in testing that ought to
fix it.

To me seems grub2 bugs and I see more 2 bugs,
1- If have grub with some custom items, I don't know exactly what, I got
for example:
background_image -m
stretch /usr/share/backgrounds/verne/default/normalish/verne.png

upgrade boot entry miss at least definition of root
so I have to add set root='(hd0,msdos1)' to upgrade boot entry.

2- If I put load_video on upgrade boot entry , preupgrade boots with a
blank screen and I don't see any graphic, is a video problem. (I read
some bug block about this)

Hope that can help something.
ah and for recover a fail upgrade system , I got many tips here:
http://fedorasolved.org/Members/fenris02/post_upgrade_cleanup
but be careful not all of document is correct and is a little old.

Thanks,

[Rob K]

Post by Corey Richardson
On Tue, 29 May 2012 16:42:30 -0400

Post by Neal Becker
Basically the same kind of failure as the last several times I did
updates. This time f16->f17.  Used preupgrade.

I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

My anecdata beats your anecdata. Preupgrade works fine for me, and has
done for several releases now. Considering it's just anaconda with a
reboot in the middle, that's not too surprising.

[Adam Williamson]

Post by Rob K

Post by Corey Richardson
On Tue, 29 May 2012 16:42:30 -0400

Post by Neal Becker
Basically the same kind of failure as the last several times I did
updates. This time f16->f17. Used preupgrade.

I've heard nothing but bad things about preupgrade from lots of people,
and I've heard the developers either never hear about it, ignore it, or
don't care. I tried a preupgrade and it half-succeeded, I had to fix
the initramfs and a few other things afterwards though. IMO, it isn't
worth the pain.

My anecdata beats your anecdata. Preupgrade works fine for me, and has
done for several releases now. Considering it's just anaconda with a
reboot in the middle, that's not too surprising.

Well...it has to write a bootloader configuration, and a kickstart, and
it uses the fairly uncommon kernel pair method for running anaconda. All
of those can (and have) caused problems.

[Kevin Fenzi]

On Tue, 29 May 2012 16:42:30 -0400
Neal Becker <ndbecker2 at gmail.com> wrote:

...snip...

Post by Neal Becker
1) Could I have actually recovered from this mess without a complete re-install?

Sure. Confirm the correct repos were enabled, 'yum distro-sync' and
work through any dep issues that show up.

Post by Neal Becker
2) Can't we make the install fail more gracefully?

Well, I suppose in this case it would take rpm handling dir/link/file
issues a bit better. Or perhaps we could run a 'rpm -Va' before running
preupgrade and yell about issues like this?

Post by Neal Becker
3) Would it be possible to continue an failed install, and have it
actually work?

After a reboot I wouldn't think so... especially if something changed
on disk since the transaction failed.

kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120529/4ea47b29/attachment.sig>

[Przemek Klosowski]

Post by Kevin Fenzi

Post by Neal Becker
1) Could I have actually recovered from this mess without a complete re-install?

Sure. Confirm the correct repos were enabled, 'yum distro-sync' and
work through any dep issues that show up.

I think they changed it to 'yum distribution-sychronization'.

[Neal Becker]

Post by Corey Richardson
On Tue, 29 May 2012 16:42:30 -0400
...snip...

Post by Neal Becker
1) Could I have actually recovered from this mess without a complete re-install?

Sure. Confirm the correct repos were enabled, 'yum distro-sync' and
work through any dep issues that show up.

I did try distro-sync, but it looked like there would be a lot of issues, so I
abandoned that idea.

[Eric Smith]

Post by Neal Becker
I did try distro-sync, but it looked like there would be a lot of
issues, so I abandoned that idea.

I'd expect that if distro-sync has a lot of issues, preupgrade and
Anaconda are likely to as well. None of these do any magic.

[Steve Gordon]

----- Original Message -----

From: "Neal Becker" <ndbecker2 at gmail.com>
To: devel at lists.fedoraproject.org
Sent: Tuesday, May 29, 2012 4:42:30 PM
Subject: another upgrade, another disaster
[SNIP]
On reboot, I found a huge mess. Duplicate packages (f16/f17) all
over.

I did the upgrade using yum and ended up with the same end result. The steps to prepare the /usr split worked fine but when I brought the system back up after all was said and done I found I had both fc16 and fc17 versions of most if not all packages.

So,
1) Could I have actually recovered from this mess without a complete
re-install?

I eventually hit it with a hammer and did yum remove '*fc16*', when I reviewed the resultant transaction there were a handful of fc17 packages also removed as a result of dependencies but these were easily installed again, pulling in their fc17 dependencies instead. At this point I now appear to have a stable system and everything working, we'll see how long that lasts for though ;).

2) Can't we make the install fail more gracefully?
3) Would it be possible to continue an failed install, and have it
actually
work?
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bruno Wolff III]

On Tue, May 29, 2012 at 16:58:18 -0400,

Post by Steve Gordon
I eventually hit it with a hammer and did yum remove '*fc16*', when I reviewed the resultant transaction there were a handful of fc17 packages also removed as a result of dependencies but these were easily installed again, pulling in their fc17 dependencies instead. At this point I now appear to have a stable system and everything working, we'll see how long that lasts for though ;).

The problem with that is some packages might have been inherited into f17
from f16 because there weren't rebuilt for f17. (Since there was a mass
rebuild for f17 there aren't many of these.)

You can use package-cleanup --orphans to find packages not in any of
your currently used repos. You can take that list and list the available
packages (yum list available) to find ones with just blocked updates and
try removing the rest.

[Steve Gordon]

----- Original Message -----

From: "Przemek Klosowski" <przemek.klosowski at nist.gov>
To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
Sent: Tuesday, May 29, 2012 4:58:35 PM
Subject: Re: another upgrade, another disaster

Post by Kevin Fenzi

Post by Neal Becker
1) Could I have actually recovered from this mess without a
complete
re-install?

Sure. Confirm the correct repos were enabled, 'yum distro-sync' and
work through any dep issues that show up.

I think they changed it to 'yum distribution-sychronization'.

Both are still valid.

Steve

[Przemek Klosowski]

Post by Neal Becker
Basically the same kind of failure as the last several times I did updates.
This time f16->f17. Used preupgrade.
It seems to have all gone wrong when cpio failed, because a python package had
been installed using pip into the (default) system dirs. The conflict IIRC
happens because pip installs a dir where cpio expects a file (or vice-versa).
I've since learned to use pip install --user instead - but there was still a
leftover package.
I was happy (temporarily) to see that I could still reboot the machine. Remove
the offending package.
Then IIRC I restarted the upgrade. It seemed to complete OK. I was pleased to
see it appear to continue from where it left off.
On reboot, I found a huge mess. Duplicate packages (f16/f17) all over.
So,
1) Could I have actually recovered from this mess without a complete re-install?

I have an open install bug where a package blocks the install:

https://bugzilla.redhat.com/show_bug.cgi?id=822008

(an install-time error trips the install script into going interactive
and hanging on commandline input)

I managed to find and solve that by going to the shell console
(Ctrl-Alt-F2) and killing the postinstallation script for that package.
It affected that package, but allowed the whole thing to finish.

[Sérgio Basto]

Post by Neal Becker
On reboot, I found a huge mess. Duplicate packages (f16/f17) all over.

you have from yum-utils

package-cleanup --dupes

http://docs.fedoraproject.org/en-US/Fedora/14/html/Software_Management_Guide/ch07s03.html

[Andrea Musuruane]

Post by Neal Becker
Basically the same kind of failure as the last several times I did updates.
This time f16->f17.  Used preupgrade.

I'd like to share with you my experience about installing Fedora
17/x86_64. It is a real PITA. No doubts about it.

* 1st attempt:
Clean upgrade of Fedora 16 from DVD. I left the PC unattended while
anaconda was upgrading RPM packages. I returned a couple of hours
later and found a kernel panic. I was too angry to take note of the
error. The system was no longer able to boot.

* 2nd attempt:
New installation of Fedora 17 from DVD. I chose to enable also the F17
remote repositories including updates - but not updates-testing. I
left my harddisk layout unchanged (obviously I didn't format my
/home). All partition were already ext4. I choose the "Software
development" option. At about 80% of installation anaconda reported
that there were an error in an RPM package and it couldn't complete
the installation. The image was correctly checked after downloading
and brasero reported that the ISO was mastered fine on DVD.

* 3rd attempt:
Same as options as the 2nd attempt but this time I chose to enable
only the F17 remote repositories and I disabled the "Install repo" so
I presume all the packages were downloaded from the net. At about 85%
of installation I got a kernel panic - this time I took care of the
message "unable to handle kernel NULL pointer dereference at
0000000000000088".

* 4th attempt:
I rebooted from DVD and choose to update the current F17 system. It
was a desperate attempt. I know. The system couldn't boot.

* 5th attempt:
No remote repositories and "Graphical desktop" option. Same kernel
panic as the 3rd attempt.

I'm writing these notes from a Windows Notebook. I don't know what
else to do - apart from swearing. Any help is really appreciated.

Regards,

Andrea.

[Andrea Musuruane]

Post by Andrea Musuruane

Post by Neal Becker
Basically the same kind of failure as the last several times I did updates.
This time f16->f17.  Used preupgrade.

I'd like to share with you my experience about installing Fedora
17/x86_64. It is a real PITA. No doubts about it.

6th attempt:
I did a "minimal install" also enabling remote updates and at last I
can boot Fedora 17. Now the problem is how to install a graphical
desktop environment from minimal install. I googled without finding
nothing really useful. As previously, any help is really appreciated.

Thanks.

Andrea.

[Tomasz Torcz]

Post by Andrea Musuruane

Post by Andrea Musuruane

Post by Neal Becker
Basically the same kind of failure as the last several times I did updates.
This time f16->f17.  Used preupgrade.

I'd like to share with you my experience about installing Fedora
17/x86_64. It is a real PITA. No doubts about it.

I did a "minimal install" also enabling remote updates and at last I
can boot Fedora 17. Now the problem is how to install a graphical
desktop environment from minimal install. I googled without finding
nothing really useful. As previously, any help is really appreciated.

yum groupinstall "GNOME Desktop Environment"

[Jan Synacek]

Post by Tomasz Torcz

Post by Andrea Musuruane

Post by Andrea Musuruane

Post by Neal Becker
Basically the same kind of failure as the last several times I did updates.
This time f16->f17.  Used preupgrade.

I'd like to share with you my experience about installing Fedora
17/x86_64. It is a real PITA. No doubts about it.

I did a "minimal install" also enabling remote updates and at last I
can boot Fedora 17. Now the problem is how to install a graphical
desktop environment from minimal install. I googled without finding
nothing really useful. As previously, any help is really appreciated.

yum groupinstall "GNOME Desktop Environment"

This alone unfortunately doesn't do the trick. You will probably have to

yum groupinstall "X Window System"

as well as some drivers for your graphic card to get it working.

I also had to order selinux to relabel my entire /home to be able to get into
any gnome session.

[Andrea Musuruane]

Post by Jan Synacek

  yum groupinstall "GNOME Desktop Environment"

This alone unfortunately doesn't do the trick. You will probably have to
   yum groupinstall "X Window System"
as well as some drivers for your graphic card to get it working.
I also had to order selinux to relabel my entire /home to be able to get into
any gnome session.

I also had to install a bunch of other yum groups, edit systemd config
to default do a graphical boot, recreate my old users, chown their
directories, and perform restorecon on /home.

Bye,

Andrea.

[Adam Williamson]

Post by Andrea Musuruane
Clean upgrade of Fedora 16 from DVD. I left the PC unattended while
anaconda was upgrading RPM packages. I returned a couple of hours
later and found a kernel panic. I was too angry to take note of the
error. The system was no longer able to boot.
New installation of Fedora 17 from DVD. I chose to enable also the F17
remote repositories including updates - but not updates-testing. I
left my harddisk layout unchanged (obviously I didn't format my
/home). All partition were already ext4. I choose the "Software
development" option. At about 80% of installation anaconda reported
that there were an error in an RPM package and it couldn't complete
the installation. The image was correctly checked after downloading
and brasero reported that the ISO was mastered fine on DVD.
Same as options as the 2nd attempt but this time I chose to enable
only the F17 remote repositories and I disabled the "Install repo" so
I presume all the packages were downloaded from the net. At about 85%
of installation I got a kernel panic - this time I took care of the
message "unable to handle kernel NULL pointer dereference at
0000000000000088".

Frankly, I wouldn't trust your hardware.

The installer uses the same kernel as the installed system, so even if
you get it to install (which apparently you finally did), if you're
getting quasi-random kernel panics, I wouldn't be at all surprised if
you keep getting them on the installed system.

That (and 'inexplicable' errors like failure to read a package on
known-good media) points either to bad hardware or a kernel bug specific
to your system in some way (as we don't have any known general kernel
breakage AFAIK). You'd definitely need to get better data on one of the
crashes (i.e. an actual log, or at least screen capture) and give it to
the kernel team, to look into it.

It may be worth running memtest on the system, first, though.

[Andrea Musuruane]

Post by Adam Williamson

Post by Andrea Musuruane
Same as options as the 2nd attempt but this time I chose to enable
only the F17 remote repositories and I disabled the "Install repo" so
I presume all the packages were downloaded from the net. At about 85%
of installation I got a kernel panic - this time I took care of the
message "unable to handle kernel NULL pointer dereference at
0000000000000088".

Frankly, I wouldn't trust your hardware.
The installer uses the same kernel as the installed system, so even if
you get it to install (which apparently you finally did), if you're
getting quasi-random kernel panics, I wouldn't be at all surprised if
you keep getting them on the installed system.
That (and 'inexplicable' errors like failure to read a package on
known-good media) points either to bad hardware or a kernel bug specific
to your system in some way (as we don't have any known general kernel
breakage AFAIK). You'd definitely need to get better data on one of the
crashes (i.e. an actual log, or at least screen capture) and give it to
the kernel team, to look into it.
It may be worth running memtest on the system, first, though.

Everything can be and I will run memtest as you advised.

But I didn't had any kernel problem in the past - and I've used every
Fedora release on the same PC for about 4 years. After I could bypass
this problem - I could install the system, including I think all the
RPMs anaconda was trying to install without any problem. Note that I
don't run the same kernel used by anaconda because in fedora updates
there is available a newer one.

Anyway, in case I hit this issue again, I would be interested to know
how to get the log of this kind of error.

Regards,

Andrea.

[Adam Williamson]

Post by Andrea Musuruane

Post by Adam Williamson

Post by Andrea Musuruane
Same as options as the 2nd attempt but this time I chose to enable
only the F17 remote repositories and I disabled the "Install repo" so
I presume all the packages were downloaded from the net. At about 85%
of installation I got a kernel panic - this time I took care of the
message "unable to handle kernel NULL pointer dereference at
0000000000000088".

Frankly, I wouldn't trust your hardware.
The installer uses the same kernel as the installed system, so even if
you get it to install (which apparently you finally did), if you're
getting quasi-random kernel panics, I wouldn't be at all surprised if
you keep getting them on the installed system.
That (and 'inexplicable' errors like failure to read a package on
known-good media) points either to bad hardware or a kernel bug specific
to your system in some way (as we don't have any known general kernel
breakage AFAIK). You'd definitely need to get better data on one of the
crashes (i.e. an actual log, or at least screen capture) and give it to
the kernel team, to look into it.
It may be worth running memtest on the system, first, though.

Everything can be and I will run memtest as you advised.
But I didn't had any kernel problem in the past - and I've used every
Fedora release on the same PC for about 4 years. After I could bypass
this problem - I could install the system, including I think all the
RPMs anaconda was trying to install without any problem. Note that I
don't run the same kernel used by anaconda because in fedora updates
there is available a newer one.
Anyway, in case I hit this issue again, I would be interested to know
how to get the log of this kind of error.

Depending on how hard the fail is, it may be in /var/log/messages when
you reboot. If not, all you can do is take a picture of the screen when
the crash comes, or maybe try and use netconsole:

http://www.mjmwired.net/kernel/Documentation/networking/netconsole.txt

which I've got working once, but it's a bit finicky.

[Brian C. Lane]

Post by Andrea Musuruane

Post by Adam Williamson

Post by Andrea Musuruane
Same as options as the 2nd attempt but this time I chose to enable
only the F17 remote repositories and I disabled the "Install repo" so
I presume all the packages were downloaded from the net. At about 85%
of installation I got a kernel panic - this time I took care of the
message "unable to handle kernel NULL pointer dereference at
0000000000000088".

Frankly, I wouldn't trust your hardware.

ditto. Kernel panics are not normal :) The above info isn't enough to
track down what caused it, we need a picture of the screen.

[snip]

Post by Andrea Musuruane
Everything can be and I will run memtest as you advised.
But I didn't had any kernel problem in the past - and I've used every
Fedora release on the same PC for about 4 years. After I could bypass
this problem - I could install the system, including I think all the
RPMs anaconda was trying to install without any problem. Note that I
don't run the same kernel used by anaconda because in fedora updates
there is available a newer one.

Things work, until they don't. It is interesting that a minimal install
worked though. I would suspect bad ram as a possibility.

Post by Andrea Musuruane
Anyway, in case I hit this issue again, I would be interested to know
how to get the log of this kind of error.

If it isn't a kernel panic you can get all the logs from Anaconda from
/tmp/*log -- switch to tty2 and you will have a shell where you can copy
them off the system. File a bug and attach the files as individual
text/plain attachments.

Failure to read the install media usually shows up as errors in syslog.

[Ralf Ertzinger]

Hi.

Post by Neal Becker
1) Could I have actually recovered from this mess without a complete re-install?

There is a way to recover from (almost) all upgrade messes, although
it has several preconditions.

The first precondition is having a root file system on btrfs, the
second is that probably none of the code to actually do this exists
(yet).

My upgrade went as follows:

/ is a btrfs, without any subvolumes, /boot is an ext3, /home is
an ext4.

I created a snapshot of /, calling the subvolume f16 and rebooted into
the snapshot (basically to see if that worked). It did. So I then created
a snapshot of f16 calling it f17 and booted into that, in runlevel 3.

Then I proceeded to follow the wiki instructions of how to update a running
system using yum. Despite the scary warnings that worked very well, usrmove
and all.

If it had not, if it had failed at some point I always had the f16 snapshot
to fall back on (actually, I still have it as updating via yum does not
remove all the old kernels as anaconda does. And it still works).

Having a root file system that supports bootable snapshots is one of the
cooler things to have, and I look forward to the day that anaconda more or
less automatically supports what I have done manually.


(what is left to do is to remove the f16 files that live in the top btrfs
subvolume, which seems to be more equal than all the other subvolumes for
no discernable reason)

[Martin Sourada]

I used preupgrade for the first time and had a similar experience, but
nothing one cannot fix...

1. Prepared the preupgrade process (f16->f17)
2. reboot and start upgrade
3. upgrade gets stuck on some package (IIRC it was something lisp
related). No CPU or HDD usage for about half an hour
4. got impatient, do a hard reboot start upgrade again
5. this time succeeds
6. no F17 kernel in grub, boot into F16 one
7. fix grub2 and discover zillions of duplicate packages (f16/f17)
8. try to remove, but discover texlive gets removed too
9. upgrade to texlive 2012 (there isn't f17 repo for 2011)
10. cleanup duplicate packages (package-cleanup --cleandupes)
11. do an update
12. everything works as expected (only grub does not show any theme,
why?), sans some gnome-dumb-down related things.

Right now I have only four grub2 and ibus related issues:
* How in the world do I tell grub2 to use the theme that's installed
with it (it's beefy-miracle related)?
* How do I get ibus to use alt+shift resp. ctrl+alt+shift to switch
between input methods? It worked in f16, now it complains
alt+shift is not a valid key *confused*
* Where do I find and set Czech input method with qwerty layout instead
of qwertz in ibus? It worked in f16, now the option seems gone :(
* How do I tell ibus to use input method per window, instead of
desktop-wide? It worked in f16, now the setting seems gone :(

Just FYI, I'm using this on XFCE 4.10.

Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120609/47703e6c/attachment.sig>

[Adam Williamson]

Post by Martin Sourada
I used preupgrade for the first time and had a similar experience, but
nothing one cannot fix...
1. Prepared the preupgrade process (f16->f17)
2. reboot and start upgrade
3. upgrade gets stuck on some package (IIRC it was something lisp
related). No CPU or HDD usage for about half an hour
4. got impatient, do a hard reboot start upgrade again

Don't do this, if you can possibly avoid it. It's never a good idea to
abort an upgrade and restart it (it results in the other weirdness you
hit later). When anaconda is running, a console is available on tty2;
you can fiddle about with processes there to try and unstuck whatever's
stuck. That sounds somewhat like
https://bugzilla.redhat.com/show_bug.cgi?id=822008 ; there's a fix in
for that bug, but it only got pushed to stable in the last day or so.

[Martin Sourada]

Hi Adam,

On Sun, 10 Jun 2012 22:39:38 -0700

Post by Adam Williamson

Post by Martin Sourada
I used preupgrade for the first time and had a similar experience,
but nothing one cannot fix...
1. Prepared the preupgrade process (f16->f17)
2. reboot and start upgrade
3. upgrade gets stuck on some package (IIRC it was something lisp
related). No CPU or HDD usage for about half an hour
4. got impatient, do a hard reboot start upgrade again

Don't do this, if you can possibly avoid it. It's never a good idea to
abort an upgrade and restart it (it results in the other weirdness you
hit later). When anaconda is running, a console is available on tty2;
you can fiddle about with processes there to try and unstuck

I tried, but unfortunately it didn't occur to me that the package
post-install script got hung up so I just jumped to conclusion that it
was anaconda that hung up (both CPU, according to top, and HDD were
idling, I didn't see anything suspicious in the messages printed on
tty's and dmesg)...

Post by Adam Williamson
whatever's stuck. That sounds somewhat like
https://bugzilla.redhat.com/show_bug.cgi?id=822008 ; there's a fix in
for that bug, but it only got pushed to stable in the last day or so.

yeah, I discovered this bug after I sent the previous mail and it's
exactly the one I hit...

Thanks,
Martin