Re: battery botched f11 to f12 upgrade (macppc-ibookG4)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 10 Jun 2010 07:08:09 -0400
Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote:

> Joel Rees writes:
> 
> > Ran for ten or twenty minutes and finished with no output. 
> > 
> > No news is good news in this case? Or bad?
> 
> Correct. That's good news.
> 
> >> Weed those 
> >> out. For what's left, run rpm -q again to get the version of both the old 
> >> and the new package, then rpm -e the old one.
> > 
> > Ouch. About fifty, sixty packages. That matches the guess I had on how far it had gotten before the battery gave out. (Poor, abused battery. Probably hates me.)
> 
> This is in the ballpark of what to expect.
> 
> > {talking-to-myself}
> > Do I dare try to use grep to feed that to a loop, or should I do this by hand? And would it be safer to delete the new ones, instead, assuming that, since I never got close to the cleanup phase, none of the old packages would have been deleted.
> > 
> > Anyway, I need to look at what's there.
> > {talking-to-myself.}
> 
> You can take the output of uniq, grab the dupes, turn that into a script 
> that runs 'rpm -q'.
> 
> This will emit the old version and the new version of each package. I pull 
> that into emacs, manually go down the list and nuke the new version, leaving 
> the list of old version, and then turn it into a script that runs rpm -e on 
> what's left, the old versions.
> 
> This is not something that I've done just on one occasion. More than once 
> borked an upgrade myself, this is what I had to do. I know the drill.

Haven't done it with the rpm command, but when I'm doing a rm on a list, I tend to just use a GUI editor and paste rm in front of the file names. That way I don't have a loop that I have to test with dry-run sytax.

Loops are "cooler", I'll admit, and I do like to use them when the result is creative, rather than destructive.

> >> Until you do these steps, attempting to deal with your upgrade is just 
> >> spinning your wheels.
> >> 
> >> Step 4: grab and burn a Fedora install DVD. Boot it, and tell it to upgrade 
> >> your existing Fedora installation.
> > 
> > Well, I'm not sure why you suggest that. Extra tools in the DVD? Or just the time actually spent in a mixed state with the netinstall CD, downloading and installing at the same time? Or do you just mean that I should avoid preupgrade? 
> 
> Well you said your preupgrade is running of disk space on /var. This method 
> installs off the DVD, avoiding that.

Another of those things where it can be uncomfortable, even if one knows that the upgrade packages are going into /var/cache.

> I've never understood the appeal of preupgrade.

It "feels" like it knows more about what's going on than the netinstall CD, for instance. But that's because a lot of the work is being done by a fully functioning system. When you reboot and let the install kernel take over, however, it's just as stripped-down as the netinstall CD.

> I have a bunch of machines. 
> It's faster for me to torrent a DVD image once. Takes very little time, then 
> I use it to upgrade each machine, then let it update itself with the few 
> bits from Everything that's not on the DVD cut.

Great for a fresh OS. Yes.

In this case, I'm upgrading to the six month-old F12. netinstall grabs the most current of everything. I don't know which way that will go with preupgrade. But I'll hopefully find out in a couple more hours.

> Seems to me it's going to take much longer to have every machine download 
> the individual packages, separately once for each machine.

Have you considered setting up a local mirror? Theoretically (haven't actually done it myself, mind you), that's what I'd do if I had a lot of machines to keep up to date. (I'd like to have the reason to find out for real, some time, but so far none of my jobs have taken me that direction. I've got to learn how to sell the board of education on Linux.)

Okay, for the record (and, hopefully, if I have to find this again, I'll be able to google it):

I put the list in a file, used yum info and rpm -q to get an idea of which new duplicate packages to erase, erased the ones I figured would get in the way. Then I used the volume manager to cut 5G out of the spare space. Went down to single-user and 

mount /dev/mapper/GrP-varcache /mnt
cp -r /dev/cache /mnt

woops. That froze on re-boot. Killed the power and used the openFW pseudo-grub to boot runlevel 3 by adding "3" after the name of the kernel I was booting and 

mount /dev/mapper/GrP-varcache /mnt
rm -fR /mnt # double-check what I'm deleting before I hit ENTER
cp -R --preserve=all /dev/cache /mnt

Checked both to make sure it looked right and made sure /etc/fstab was set right and re-booted. I'll either return that partition to the spare pool later or boot single-user and clear out the now-dead /var/cache or whatever later, I guess. Anyway, it was stable, so I rebooted the netinstall CD and found that it still didn't want to upgrade.

So I decided to try preupgrade. Used the cli version. Everything downloaded okay (6 hours on my 1 MB/S bottom-of-the-line broadband), and it rebooted to the install kernel, and ultimately said,

"The root for the previously installed system was not found."

I nosed around the web for some clues and found lots of stray ideas and some stuff in Bugzilla. But I remembered something I had seen deleting the new versions of the duplicate packages. Couldn't find it in /boot, so I looked in /etc and there it was: /etc/fedora-release (I'm pretty sure it wasn't release-fedora.)

/etc/fedora-release contains the very short string marking the current version. I made a backup copy just to be safe, and edited it, changed 12 back to 11 and Constantine back to Leonidas. 

This time, the netinstall CD recognized the updateable system and gave me the option. but I already had all the packages in /var/cache, so I gave it the four-finger (It's a Mac notebook) salute and this time told it to boot the preupgrade kernel in text mode. 

Text mode may not have been a good idea, although it seemed necessary with the CD. 

(At the boot prompt for the CD, type "linux text", for the preupgrade, hit the tab key at the boot prompt to get a list of kernels, and type the name of the preupgrade kernel followed by "text".)

It chugged away a bit and then the screen went blank. But the HD idiot lamp is flashing irregularly, so I'm just letting it go for however long it takes, probably about four hours, if I remember right from the last upgrade. (1.2 GHz processor, but the memory bus is only 125MHz or thereabouts.)

The scary part is how I'm going to know when it's done.

Hopefully that's enough that I can find what I need next time, and not so much that I won't be able to find it.

I'll post the results tomorrow. (And check to see how incoherrent today's posts are.)



-- 
Joel Rees 
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux