Preupgrade still sucks. Maybe sucks less, maybe sucks more.

[Michael H. Warfield]

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 |  mhw at 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20110604/363a8600/attachment.bin