Re: Preupgrade still sucks. Maybe sucks less, maybe sucks more.
On Sun, Jun 5, 2011 at 5:01 PM, Michael H. Warfield m...@wittsend.com 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 Mon, 2011-06-06 at 09:05 -0500, Richard Shaw wrote: On Sun, Jun 5, 2011 at 5:01 PM, Michael H. Warfield m...@wittsend.com 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 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 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 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 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.
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.
On Sat, Jun 04, 2011 at 12:33:50 +0100, Timothy Murphy gayle...@eircom.net 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.
[...] 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
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.
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.
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 mailing list users@lists.fedoraproject.org To unsubscribe or
