Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Mon, 2011-06-06 at 12:37 -0700, Joe Zeff wrote: > On 06/06/2011 10:11 AM, Michael H. Warfield wrote: > > To the preupgrade devs - I would strongly recommend you test with a > > known broken machine that has dependency problems that anaconda can NOT > > resolve and make sure it gracefully stops and generates sane, > > intelligible error messages... The current avidmux is a good place to > > start. > It's good to see that you're making progress and, if not out of the > tunnel yet you can at least tell that the light isn't an on-coming train. > If you haven't yet, I'd suggest putting in a bug report against > preupgrade because AFAIK none of the appropriate devs are on this list. I have not as yet, as I thought I might extract more from the corpse. Unfortunately, seems twas not to be (though I haven't totally given up quite yet). My latest effort... I did the following... rpm -qa --qf | sort -u > rpm.list Then yum reinstall `cat rpm.list` (I even turned off my cacher forcing it to re-download everything from the net from scratch.) Re-downloaded over 3800 packages. It then began to rerun the install phase and blew its brains out after about 2400 of the packages were installed with the stupid "Transaction would be destructive error" and landed me back at the ^D emergency mode prompt jail. Sigh. Here we go again. I know the drill... My entire domain is named after caves in Colossal Caverns Adventure. You're in a maze of twisty little passages all different. I know the drill all too well. Logged back in. Ran yum-complete-transaction. It had a lot to do with just about 1000 packages to rum after the LAST time systemctl committed harri karri and, this time, ran to completion with no errors. Still no joy... Rebooting still lands me back in the emergency mode hell. Running "systemctl default" still results in "Transaction would be destructive". I think systemd / systemctl is what's destructive on first principle. PoS. Right now, I'm beginning to believe it's this whole systemd systemctl garbage that's a crock of shit that stinks to high heaven. That's where the crashes are. The old SYSV scripts at least WORKED and didn't screw you over. That yum reinstall is telling me exactly what's broken and why anaconda hurled chunks earlier. It's that systemd setup that's hosed and blew up with no warning. It blew up in the middle of the recovery. If it did something like that in the middle of anaconda it's no wonder the machine is a steaming pile of molten RAM and disk. And still... THAT even took less time that preupgrade took on the first pass, even with the entire fresh redownload. Someone has done something seriously wrong in preupgrade. It may work in 99.99% of the cases but a single case of destroying a machine like this is simply inexcusable. Something that critical must be failsafe, and it's apparent to me this is not failsafe. Even if the ultimate fault in this case is systemd / systemctl, the bottom line at the end of the day is that preupgrade / anaconda did not detect / resolve the conflict / failure before you gave up control of the machine and before it was too late and irrecoverable. As much of a hassle as it has been at times over the years, the "yum upgrade" path has never, EVER left me with a machine that would not run. I can no longer say the same for preupgrade. Unfortunately, once THAT trust is lost, it can never be regained. Still trying to recovery the smoldering pieces but now getting very VERY close to just saying "screw it" and saving all 3TB off to another system and rebuilding this thing from scratch and restoring the data. That will take me a fraction of the time this has already even though the diagnostic data will be lost. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On 06/06/2011 10:11 AM, Michael H. Warfield wrote: > To the preupgrade devs - I would strongly recommend you test with a > known broken machine that has dependency problems that anaconda can NOT > resolve and make sure it gracefully stops and generates sane, > intelligible error messages... The current avidmux is a good place to > start. It's good to see that you're making progress and, if not out of the tunnel yet you can at least tell that the light isn't an on-coming train. If you haven't yet, I'd suggest putting in a bug report against preupgrade because AFAIK none of the appropriate devs are on this list. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Mon, 2011-06-06 at 09:05 -0500, Richard Shaw wrote: > On Sun, Jun 5, 2011 at 5:01 PM, Michael H. Warfield wrote: > > You'll get a lot of bitch about packages already installed but anything > > missing will get installed or you will get an error. Currently, it > > looks like avidmux from rpmfusion isn't reinstalling for me. Oh well. > > It eventually will. > Just an FYI, the avidemux package was broken by the move from js 1.70 > to 1.8.5 in Fedora 15. I'm working around it by re-enabling the > bundled js while I try to fix it. > There is already a new build available but hasn't made it into ...-testing > yet. That's very interesting. Very interesting indeed and explains a lot. Yeah, js was at the heart of the other packages I had to uninstall and manually reinstall like elinks as well. And, sigh, this appears to also be at the core of what blew preupgrade / anaconda out of the water on the machine where it did run and that I'm working to recover now. I found that on MtKing in emergency mode I could manually start up the network using ifup (service network (re)start was an epic fail thanks to the god's be damned systemctl command) and bring that up to a functioning level other than the dain bramaged bug in the networking code that's shutting down IPv6 router advertisements on bridges but that's a known problem and outside the scope of this mess. IAC, I got the box talking on the network and communicating with my package cache server once I had v6 back up. Ran yum update just to see if anything was missed or messed up in the install. That told the tale. Of the close to 4,000 packages (that's according to what get cached for fc15 on my cacher) that should have been installed or updated, it was still missing almost 60 packages, had almost a dozen and a half rpm database check errors (mostly missing requires) and it still had avidmux-* dependency errors that could not be resolved. That made sense. The two machines were equivalent in the installed databases. Why didn't anaconda stop and bitch about THAT if it couldn't resolve it? It appears that Anaconda got past whatever made it blow up with the "unhandled exception" in the case of the Forest machine and it continued on even with an unreconcilable dependency error. It then failed catastrophically near the end of the install phase but before any of the postinstall scripts where run (which is why initramfs was never created even though the kernel rpm was installed). So, I cleaned up avidmux-*, elinks, and one other package by doing a yum erase on js. Then I was able to install the remaining missing packages (which had already all been downloaded, they just hadn't gotten installed) and then reinstall the other packages I had removed other than avidmux. That update also cleaned up the "preexisting errors" mess in the rpm database. Everything is now installed but, still, none of the original 4000 some odd postinstall scripts were run. Still dumps me into emergency mode and "systemctl default" still complains about "Transaction would be destructive". So that still leaves me with a steaming pile I'm trying to clean up. Progress forward but not quite there yet. Not sure what the best path is to follow at this point. Downgrade to F14 and back up to F15? Try rerunning preupgrade again (I don't think so)? The good news is that, with the network back up this far, I can also move the two LXC based virtual machines (one of which is my master DNS server) off of that host and over to the alternate host, Forest, and I only have one machine flat on its rear out of this mess. That's doable. To the preupgrade devs - I would strongly recommend you test with a known broken machine that has dependency problems that anaconda can NOT resolve and make sure it gracefully stops and generates sane, intelligible error messages... The current avidmux is a good place to start. > Thanks, > Richard Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Sun, Jun 5, 2011 at 5:01 PM, Michael H. Warfield wrote: > You'll get a lot of bitch about packages already installed but anything > missing will get installed or you will get an error. Currently, it > looks like avidmux from rpmfusion isn't reinstalling for me. Oh well. > It eventually will. Just an FYI, the avidemux package was broken by the move from js 1.70 to 1.8.5 in Fedora 15. I'm working around it by re-enabling the bundled js while I try to fix it. There is already a new build available but hasn't made it into ...-testing yet. Thanks, Richard -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Sun, 2011-06-05 at 17:31 -0400, Michael H. Warfield wrote: > On Sat, 2011-06-04 at 12:33 +0100, Timothy Murphy wrote: > > Michael H. Warfield wrote: > > > > > Classically, for those servers (some of which originally started out on > > > FC1) have been upgraded using the yum upgrade method. > > > > As a matter of interest, what exactly is _the_ yum upgrade method? > > I've seen the term used by several people, > > but as far as I can see they refer to different methods. > > > And don't all upgrade methods use yum in some way? > > http://fedoraproject.org/wiki/YumUpgradeFaq > > This is a pure yum upgrade from F{x} to F{x+1} (some people have > reported success with x+2 but I would personally avoid that like the > plague) on a live running system without taking it down for the upgrade > process.. > > So (in very shortened abbreviated summary form), to upgrade from F14 to > F15 you run... > yum update > yum clean all > rpm --import https://fedoraproject.org/static/069C8460.txt > yum --releasever=15 --disableplugin=presto distro-sync Ok... My apologies. That really wasn't playing fair and very bad of me over simplifying things a bit too much. That summarizes the process described on the FAQ page (which I strong, STRONGLY recommend reading) but there's gotcha's in there. First off, I should mention, this is the newer process. The "--releasever" option and the "distro-sync" command are relatively new additions to yum. You use to have to manually download the release rpm, the release-notes rpm, and the GPG key and install them using rpm then run a "yum update" or "yum upgrade" (which are actually identical functions - they don't do anything different now, if they ever did anything different every in the past). You will often run into dependency failures and it may recommend using "--skip-broken" or something like that. I've had terrible luck with that where yum would enter in to infinite dependency resolution loops! The procedure I use is to start off with this command: rpm -qa --qf '%{NAME}\n' | sort -u > rpm.list Then do the steps above. If things slam into a dependency error, run "yum erase" to remove the trouble makers, provided it doesn't try to remove your entire system (saw that once around F11, iirc, that was fun to work around). Once the above workflow runs to completion with no dependency problems, then you run this: yum install `cat rpm.list` You'll get a lot of bitch about packages already installed but anything missing will get installed or you will get an error. Currently, it looks like avidmux from rpmfusion isn't reinstalling for me. Oh well. It eventually will. So this isn't necessarily a "fire and forget process" and it use to be worse. But... Then again... Neither is preupgrade. > (After a half an hour or so you'll probably complete this and reboot) > > yum groupupdate Base > > Now, I'm not quite sure exactly why that FAQ page recommends running > "yum update yum" since the first "yum update" should take care of that. > I have not been doing that step and it's never burned me (in fact, when > I have done that step, it's done nothing). > > You should also read the caveats in that FAQ about cleaning up config > files and looking for any strange .rpmsave or .rpmorg types of things. > I think, in the past, squid was notorious for changing configuration > file formats and you have to port. > > Also if you use Postgres, PAY CAREFUL ATTENTION TO DUMPING THE DATABASE > TO AN SQL DUMP FILE FIRST! That is not mentioned on that page but > almost every Fedora click has taken Postgres through and upgrade click > which can not automagically migrate the databases. I don't think > preupgrade or disk upgrades to any better here so it's not the fault of > yum upgrade. > > Mike > > > -- > > Timothy Murphy > > e-mail: gayleard /at/ eircom.net > > tel: +353-86-2336090, +353-1-2842366 > > s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland > > > > -- > > users mailing list > > users@lists.fedoraproject.org > > To unsubscribe or change subscription options: > > https://admin.fedoraproject.org/mailman/listinfo/users > > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > > > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Sat, 2011-06-04 at 12:33 +0100, Timothy Murphy wrote: > Michael H. Warfield wrote: > > > Classically, for those servers (some of which originally started out on > > FC1) have been upgraded using the yum upgrade method. > > As a matter of interest, what exactly is _the_ yum upgrade method? > I've seen the term used by several people, > but as far as I can see they refer to different methods. > And don't all upgrade methods use yum in some way? http://fedoraproject.org/wiki/YumUpgradeFaq This is a pure yum upgrade from F{x} to F{x+1} (some people have reported success with x+2 but I would personally avoid that like the plague) on a live running system without taking it down for the upgrade process.. So (in very shortened abbreviated summary form), to upgrade from F14 to F15 you run... yum update yum clean all rpm --import https://fedoraproject.org/static/069C8460.txt yum --releasever=15 --disableplugin=presto distro-sync (After a half an hour or so you'll probably complete this and reboot) yum groupupdate Base Now, I'm not quite sure exactly why that FAQ page recommends running "yum update yum" since the first "yum update" should take care of that. I have not been doing that step and it's never burned me (in fact, when I have done that step, it's done nothing). You should also read the caveats in that FAQ about cleaning up config files and looking for any strange .rpmsave or .rpmorg types of things. I think, in the past, squid was notorious for changing configuration file formats and you have to port. Also if you use Postgres, PAY CAREFUL ATTENTION TO DUMPING THE DATABASE TO AN SQL DUMP FILE FIRST! That is not mentioned on that page but almost every Fedora click has taken Postgres through and upgrade click which can not automagically migrate the databases. I don't think preupgrade or disk upgrades to any better here so it's not the fault of yum upgrade. Mike > -- > Timothy Murphy > e-mail: gayleard /at/ eircom.net > tel: +353-86-2336090, +353-1-2842366 > s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland > > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Sat, Jun 04, 2011 at 12:33:50 +0100, Timothy Murphy wrote: > > As a matter of interest, what exactly is _the_ yum upgrade method? > I've seen the term used by several people, > but as far as I can see they refer to different methods. yum update --releasever=f?? > And don't all upgrade methods use yum in some way? No exactly. Preupgrade downloads some stuf for and I think does a more robust rebuild of the boot images. (Sometimes it hasn't been possible to build the initrd for a new release while running under the old kernel.) I believe anaconda (I'm don't know about preupgrade) does the updates in a way that they aren't blocked by (some) dependencies. This is especially relevant if you use third party repos. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
Michael H. Warfield wrote: > Classically, for those servers (some of which originally started out on > FC1) have been upgraded using the yum upgrade method. As a matter of interest, what exactly is _the_ yum upgrade method? I've seen the term used by several people, but as far as I can see they refer to different methods. And don't all upgrade methods use yum in some way? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
Update... And now a real request for help... On Fri, 2011-06-03 at 14:34 -0400, Michael H. Warfield wrote: > Ok... > ITMT... I rebooted MtKing into the preupgrade process and turned it > loose. Strangely, it DIDN'T run into the unhandled exception like > Forest had. The machines should have been the same. Oh well. > Something like two HOURS later, though, and it's still grinding on the > disk. WTH? Why is preupgrade taking 4 times longer to upgrade a system > and that's with the system down and out of service during the entire > process. Well, it finally finished and I rebooted into the F15 kernel > and was almost immediately greeted with a kernel panic unable to mount > root fs on unknown block(0,0). Sigh... This would be real great at a > remote location. Ok, I'm screwed. Yum upgrade worked over on Forest > where preupgrade demonstrated an epic fail, and now MtKing has succumbed > to another failure. Tried booting into one of the F14 kernels that were > still on the system. You can forget that noise as well. I ended up at > the "Welcome to emergency mode. Use systemctl default or ^D to activate > the default mode". Grrr... Log in and tried that "systemctl > default"... No joy. "Failed to issue method call: Transaction is > destructive." Great. That's a delightfully spooky error that tells you > absolutely nothing. Looks like it burned my bridges on the way out the > door. Sigh... Poking around in emergency mode revealed that the F15 kernel had been install but no initramfs had been created for it and no initramfs line existed in grub.com. Now THAT is really weird. HTH did THAT happen? Seriously! Think about this. If it installed the kernel and the initrd command failed, why is the record even in grub.conf. If something failed there, don't touch anything. It's like something got half way there and threw up it's little cybernetic hands and said "we're done". That's not really a "preupgrade" fsckup per se but an F15 fsckup in my book somehow... Problem #2 Manually created the initramfs while in emergency mode. Amazing what you can do in what is suppose to be sub-single user mode, but it worked and I could edit and fix grub and I could manually create an initramfs for that 2.6.38 kernel... Cool... Sigh... Not so fast grasshopper... But now... The F15 kernel is doing exactly the same damn thing the F14 kernels are and dumping me in "Emergency mode" and "systemctl default" is bitching about "Failed to issue method call: Transaction is destructive." Sigh... So now I'm really screwed, although it looks much less like preugrade and more like a major screwup with the F15 install. Still boils down to the fact that I've got no recorded errors and no remote control of the machine and still not clue what screwed this whole mess up or how to get out of it. It's not the 2.6.35 (F14) kernel vs 2.6.38 kernel (F15) then what is it? It's not a preupgrade problem per se but the problem still exists and that blood machine is still dead. Just based on the "flavor" of the behavior it seems like something failed silently during the anaconda phase and something end up cross-wise as a consequence. I hate jumping to conclusions here but that's my working premise and I'm try to recover the machine from that. > OTOH... My son, who is another skilled developer and Linux enthusiast, > has used preupgrade successfully on one of his 64 bit stations but he > also noticed that the upgrade took seemingly forever. Like hours. So > that's not just me. > > Well, I've got a dead machine to try and recover from now. I've heard > all the arguments about how preupgrade should be so much better because > you're running anaconda on an install kernel. That has simply NOT been > my experience at all. On the contrary - exactly to the opposite. > Preupgrade fails to do the necessary disk space checking and dependency > checking that ultimately causes these failures, all of which could be > resolved remotely on a live running system without requiring repeated > reboots. I have no idea what anaconda is doing that is so broken that > it takes over 4 times longer to upgrade a system than yum, but the yum > upgrade path has worked flawlessly (not always effortlessly, but > flawlessly) for years. For now - preupgrade => epic fail * 2. If > anyone has any thoughts on what has caused either of the two remaining > problems (the kernel panic on the F15 kernel or the failure to run on > the F14 kernel) I'd be happy to hear them. ITMT, I guess I'll start > building a recovery CD to try and fix this mess. > > Regards, > Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- users maili
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Fri, 2011-06-03 at 14:47 -0700, Joe Zeff wrote: > On 06/03/2011 11:34 AM, Michael H. Warfield wrote: > > Well, that tells me right there that preupgrade is still not > > deployment grade yet. Not for remote servers at least. > So let me get this straight: preupgrade failed for you and therefor it's > not ready to be used (at least on remote servers) by anybody. Isn't > that a rather small sample size for such a sweeping generalization? No... It's not the fact that it failed. It's the way that it failed. If failed in a way that is not recoverable in that situation. That's the problem. The fact that it did not resolve all the issues before the commit. The fact that once you commit you stepped blindly down that road there was no going back. Those were the problems. It's not the failure. It's the lack of a recovery. I'll admit. Probably in the VAST majority of the cases it will succeed, and that's wonderful, but the fact remains you can not predict when it will fail and, therefore, you can not trust it in cases where you lose control of the machine (the anaconda phase). This is unacceptable in the remote case. My failures are only examples of why it's not deployment grade. Not reasons, per se, not absolutes that all will fail, only examples of how catastrophic the failures, when the occur, will be. > I'd expect that kind of response (and have seen it here, recently) from > some shallow, self-centered kid with little if any Linux experience. > Having it come from somebody who's been using Linux professionally as > long as you clearly have is a Bad Thing because it encourages beginners > to react badly to upgrade problems even more than they already do. > You have, of course, my sympathy. I'd offer whatever help I could, but > you seem to have things well in hand already and I hope everything turns > out OK. Quite frankly, I'm beginning to wonder if the issue is with F15 > and not the upgrade methods. And on that point you and I may well concur. Certainly the problems with the mistakes in bridging and routing wrt IPv6 have nothing to do with the upgrade process. As I have always done, I shall fill bug reports on what I find. That is, after all, why I continue to test things like this even when they have failed for me. I do not give up and I do try and get things to improve. And, sometimes, I'm known for my "bad day rants". Thank you for your tolerance. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On 06/03/2011 11:34 AM, Michael H. Warfield wrote: > Well, that tells me right there that preupgrade is still not > deployment grade yet. Not for remote servers at least. So let me get this straight: preupgrade failed for you and therefor it's not ready to be used (at least on remote servers) by anybody. Isn't that a rather small sample size for such a sweeping generalization? I'd expect that kind of response (and have seen it here, recently) from some shallow, self-centered kid with little if any Linux experience. Having it come from somebody who's been using Linux professionally as long as you clearly have is a Bad Thing because it encourages beginners to react badly to upgrade problems even more than they already do. You have, of course, my sympathy. I'd offer whatever help I could, but you seem to have things well in hand already and I hope everything turns out OK. Quite frankly, I'm beginning to wonder if the issue is with F15 and not the upgrade methods. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
[...] > Regards, > Mike My experience was exactly opposite. I upgraded from F13 to F15 without a hitch. While I was working at my workstation at home, I started preupgrade from the terminal and it downloaded the new packages. Once it was done, I rebooted it and made sure the upgrade process had started and left for my University. About an hour later from the university, I tried to login to my home workstation and walla! preupgrade had finished and booted to a working F15 machine, running with all my services just the way it was as if nothing had changed. FWIW, I think all the preupgrade headache arises when people don't realise it downloads the latest packages, creates a temporary repo and then uses anaconda for the upgrade. IMHO, if uptime and lack physical access to the machine is what is the prime concern, then an upgrade path via yum should be the prefered option. Just my 2 cents. -- Suvayu Open source is the future. It sets us free. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Preupgrade still sucks. Maybe sucks less, maybe sucks more.
Ok... The subject line may well get some unwanted attention and ignite a flame war but just bare with me. This has not been a fun last couple of days for me. Understand one thing about me. I manage a number of remote servers to which I had no console access other than serial consoles. I do have remote power control over them. If I have to drive an hour out to a colo facility to fix a broken install or upgrade, it's a very bad day. Classically, for those servers (some of which originally started out on FC1) have been upgraded using the yum upgrade method. There have been one or two times when that has been challenging, thanks to odd dependencies, but not many. I've gotten that down to a science where I dump the current rpm table using "rpm -qa --qf '%{NAME}\n" | sort -u" into a file and simply remove any conflicts until it upgrades and then reinstall based on what's in that file. The work that has been done on the yum upgrade page simplifying the process to the point where it's just a "yum update ; yum clean all ; yum --releasever=??" is incredible. It works so smoothly now compared to what you had to do years ago. And the server stays up the entire time of the upgrade. I don't loose any significant downtime with those machines. But... Each click of Fedora, I do try and give preupgrade a shot and see how bad it is or see if they've improved things. I do this on my local workstations and I can see how much downtime is involved and if there are any gotchas. So it was this time. My intent was to take two of my 64 bit machines and upgrade one, "Forest", using preupgrade and one, "MtKing" (both names from the old game of Colossal Caverns Adventure) using yum upgrade to compare the upgrade time, downtime and the resulting rpm sets. Both machines had the same rpms installed and both machines were up to date. I also use the pkgcacher package on one of my other servers so I'm only downloading copies of packages once and both machines can suck them in from that cache. So... Forest ran preupgrade and downloaded all the packages and was ready to reboot, which I did. MtKing downloaded all the packages and ran into dependency problems, which isn't uncommon with the yum updated path. So I decided, what the hell and ran preupgrade on it as well and then rebooted it. With the package cacher, the downloads of something like 2000-3000 packages took less that 5 minutes for each machine. While it was down and grinding on its disk, Forest got an non-specific unhandled exception and was stuck at the console requiring a manual reboot. Well, that tells me right there that preupgrade is still not deployment grade yet. Not for remote servers at least. That would have cost me a trip to the colo if it had been remote. Not good. MtKing also failed preupgrade but this was because it was short disk space in one partition. That was easy to fix but, again, it's requiring console interaction or it's dead. The yum upgrade also would have told me it was short on diskspace for the install before getting this far down the road and having the bloody server off line at the time, saving me a couple of reboots and other jacking around. So, I switch plans, knowing what the problem was on MtKing and having no clue what caused anaconda to hurl chunks on Forest. I freed up some space on MtKing and reran preupgrade while I ran yum upgrade on Forrest. Forest had some dependency problems, like MtKing (to be expected - they were the same), but this time I simply dumped the rpm table to a file, like I always do, and started removing the bad boys. Couple of minor things, really. Stick in the mud was avidmux which really had it tied in a knot with some missing upgrade library but had no problem pulling that and then yum upgrade is chugging away (still can't reinstall avidmux because of that missing library). Half hour later, it's done and the machine is rebooted and up, more or less. Then I found that someone had screwed up IPv6 over bridges by forcing accept_ra = 0 and forwarding = 1 in the bloody scripts. I'll deal with that with a bug report later. Absolutely stupid. A bridge is not forwarding, it's bridging and they go and break autoconf by this misguided step. But that's another story. Shortly after sorting that out, I have Forest up and the half dozen LXC virtual machines running on him and everything is right with the world. ITMT... I rebooted MtKing into the preupgrade process and turned it loose. Strangely, it DIDN'T run into the unhandled exception like Forest had. The machines should have been the same. Oh well. Something like two HOURS later, though, and it's still grinding on the disk. WTH? Why is preupgrade taking 4 times longer to upgrade a system and that's with the system down and out of service during the entire process. Well, it finally finished and I rebooted into the F15 kernel and was almost immediately greeted with a kernel panic unable to mount root fs on unknown block(0,0). Sigh...