Re: another upgrade, another disaster
Hi Adam, On Sun, 10 Jun 2012 22:39:38 -0700 Adam Williamson wrote: On Sat, 2012-06-09 at 16:11 +0200, Martin Sourada wrote: 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)... 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sat, 2012-06-09 at 16:11 +0200, Martin Sourada wrote: 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Josh Boyer jwbo...@gmail.com writes: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/07/2012 10:33 AM, Benny Amorsen wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Thu, Jun 7, 2012 at 4:33 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Josh Boyer jwbo...@gmail.com writes: 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Wed, 2012-06-06 at 12:15 +0200, Benny Amorsen wrote: Adam Williamson awill...@redhat.com writes: 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 Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Wed, 2012-06-06 at 07:53 -0400, Josh Boyer wrote: On Wed, Jun 6, 2012 at 6:15 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Adam Williamson awill...@redhat.com writes: 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Adam Williamson awill...@redhat.com writes: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Wed, Jun 6, 2012 at 6:15 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Adam Williamson awill...@redhat.com writes: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/06/2012 12:15 PM, Benny Amorsen wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, Jun 03, 2012 at 10:32:37PM +0200, Björn Persson wrote: Tomasz Torcz wrote: 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). -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgp7IqEnABga7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Tue, 2012-06-05 at 16:28 -0700, Brian C. Lane wrote: On Sun, Jun 03, 2012 at 10:32:37PM +0200, Björn Persson wrote: Tomasz Torcz wrote: 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). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, Jun 01, 2012 at 09:48:37AM -0700, Adam Williamson wrote:
On Fri, 2012-06-01 at 10:37 +0200, Caterpillar wrote:
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')
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.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
pgpwCBVSsgCAD.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, Jun 04, 2012 at 10:03:24AM +0200, Andrea Musuruane wrote: On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: * 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 0088. 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] 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. 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. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpQDtLirHSJY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, 2012-06-03 at 11:00 +0200, Alexander Boström wrote: fre 2012-06-01 klockan 09:48 -0700 skrev 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sat, 2012-06-02 at 20:17 +0200, Andrea Musuruane wrote: * 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 0088. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, Jun 4, 2012 at 7:57 AM, Jan Synacek jsyna...@redhat.com wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: * 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 0088. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, 2012-06-03 at 19:56 +0200, Björn Persson wrote: Adam Williamson wrote: 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.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, 2012-06-03 at 19:56 +0200, Björn Persson wrote: 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, 2012-06-04 at 10:03 +0200, Andrea Musuruane wrote: On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: * 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 0088. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, 2012-06-04 at 22:52 +0200, Björn Persson wrote: Adam Williamson wrote: 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 Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Tue, May 29, 2012 at 16:58:18 -0400, Steve Gordon sgor...@redhat.com wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
fre 2012-06-01 klockan 09:48 -0700 skrev 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote: On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, Jun 03, 2012 at 01:21:55PM +0200, Andrea Musuruane wrote: On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote: On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: 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. yum groupinstall GNOME Desktop Environment -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Adam Williamson wrote: 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 signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, Jun 03, 2012 at 07:56:48PM +0200, Björn Persson wrote: Adam Williamson wrote: 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. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/3/2012 1:56 PM, Björn Persson wrote: Adam Williamson wrote: 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPy6gzAAoJEObJ14kUYB6pxwMH/RM4TetkkGYswFQymelIz5h1 meRLfoCPT1SXqc3bAu3u2J8m9y2CdWULbaf6jqU1ce2y/Cu0zSJ3A02FvlSYlu30 okt6z8wn5gfKNqk6fpvwCYbMHP+TJsFLC41YE3vg86JDCo9JzEKSDt1oMuRYysTm Qb3gUbu/C0rmKAgp0DrHdaMypCbr/4wKDNmk2/8VFp2Tsh/709+jHxyJnxAGCiyC LutHtVh1mn1hMWmwcZ9hDb/hFUqNMasSl3EBpWYP8eS/zThkldo/W53wfQbnuSy2 UTqqx1hFXcFPpTCAb0URh8cImFWGV+7rxSj6+vTOjHv0iunxlTrXOCs1rnvi0zo= =4z2F -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Tomasz Torcz wrote: 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 signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, Jun 3, 2012 at 4:32 PM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Tomasz Torcz wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Josh Boyer wrote: On Sun, Jun 3, 2012 at 4:32 PM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Tomasz Torcz wrote: 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 signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Qui, 2012-05-31 at 14:58 -0700, Adam Williamson wrote: On Thu, 2012-05-31 at 22:21 +0200, Caterpillar wrote: 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 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, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/03/12 at 01:34pm, Tomasz Torcz wrote: On Sun, Jun 03, 2012 at 01:21:55PM +0200, Andrea Musuruane wrote: On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote: On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: 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. 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. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Il 01/06/2012 18:42, Adam Williamson ha scritto: On Fri, 2012-06-01 at 10:37 +0200, Caterpillar wrote: 2012/5/31 Adam Williamson awill...@redhat.com 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 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: 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 0088. * 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Hi. On Tue, 29 May 2012 16:42:30 -0400, Neal Becker wrote 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) -- Wir wollen mehr Netto vom Brutto, mehr Nuss im Cornetto -- The Incredible Herrengedeck, FDP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
2012/5/31 Adam Williamson awill...@redhat.com 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, 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/01/2012 10:37 AM, Caterpillar wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: 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 - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, Jun 01, 2012 at 01:18:23PM +0300, Panu Matilainen wrote: On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: 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. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/01/2012 01:39 PM, Michael scherer wrote: On Fri, Jun 01, 2012 at 01:18:23PM +0300, Panu Matilainen wrote: On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: 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 - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Am 01.06.2012 11:25, schrieb Michal Schmidt: On 06/01/2012 10:37 AM, Caterpillar wrote: 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 * 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 = 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, 2012-06-01 at 13:18 +0300, Panu Matilainen wrote: On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, 2012-06-01 at 10:37 +0200, Caterpillar wrote:
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')
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, 2012-06-01 at 11:36 +0200, Reindl Harald wrote: Am 01.06.2012 11:25, schrieb Michal Schmidt: On 06/01/2012 10:37 AM, Caterpillar wrote: 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 * 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. = 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 Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, 2012-06-01 at 10:37 +0200, Caterpillar wrote: 2012/5/31 Adam Williamson awill...@redhat.com 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 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. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Tue, 2012-05-29 at 16:50 -0400, Tom Callaway wrote: On 05/29/2012 04:46 PM, Corey Richardson wrote: 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Adam Williamson wrote: On Tue, 2012-05-29 at 16:50 -0400, Tom Callaway wrote: On 05/29/2012 04:46 PM, Corey Richardson wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: 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... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
2012/5/31 Adam Williamson awill...@redhat.com On Tue, 2012-05-29 at 16:50 -0400, Tom Callaway wrote: On 05/29/2012 04:46 PM, Corey Richardson wrote: 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@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Wed, May 30, 2012 at 6:46 AM, Corey Richardson co...@octayn.net wrote: On Tue, 29 May 2012 16:42:30 -0400 Neal Becker ndbeck...@gmail.com ndbeck...@gmail.com wrote: 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. -- Rob K http://ningaui.net I swear, if I collected all seven dragonballs, I'd bring back Jon Postel. - Raph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Thu, 2012-05-31 at 22:21 +0200, Caterpillar wrote: 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 . 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 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. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, 2012-06-01 at 07:30 +1000, Rob K wrote: On Wed, May 30, 2012 at 6:46 AM, Corey Richardson co...@octayn.net wrote: On Tue, 29 May 2012 16:42:30 -0400 Neal Becker ndbeck...@gmail.com ndbeck...@gmail.com wrote: 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
another upgrade, another disaster
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Tue, 29 May 2012 16:42:30 -0400 Neal Becker ndbeck...@gmail.com ndbeck...@gmail.com wrote: 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. -- Corey Richardson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 05/29/2012 04:46 PM, Corey Richardson wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Tue, 29 May 2012 16:42:30 -0400 Neal Becker ndbeck...@gmail.com wrote: ...snip... 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. 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? 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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
- Original Message - From: Neal Becker ndbeck...@gmail.com To: devel@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 05/29/2012 04:50 PM, Kevin Fenzi wrote: 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'. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
- Original Message - From: Przemek Klosowski przemek.klosow...@nist.gov To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, May 29, 2012 4:58:35 PM Subject: Re: another upgrade, another disaster On 05/29/2012 04:50 PM, Kevin Fenzi wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Kevin Fenzi wrote: On Tue, 29 May 2012 16:42:30 -0400 Neal Becker ndbeck...@gmail.com wrote: ...snip... 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Tom Callaway wrote: On 05/29/2012 04:46 PM, Corey Richardson wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 05/29/2012 04:42 PM, Neal Becker wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Neal Becker wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Ter, 2012-05-29 at 16:42 -0400, Neal Becker wrote: 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 -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
