FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 06-03-2011, 06:34 PM
"Michael H. Warfield"
 
Default 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}
" | 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... 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.

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@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!
--
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
 
Old 06-03-2011, 07:13 PM
suvayu ali
 
Default 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
 
Old 06-03-2011, 09:47 PM
Joe Zeff
 
Default 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
 
Old 06-04-2011, 04:53 AM
"Michael H. Warfield"
 
Default 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 | mhw@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!
--
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
 
Old 06-04-2011, 05:57 AM
"Michael H. Warfield"
 
Default 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 | mhw@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!
--
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
 
Old 06-04-2011, 11:33 AM
Timothy Murphy
 
Default 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
 
Old 06-04-2011, 12:56 PM
Bruno Wolff III
 
Default Preupgrade still sucks. Maybe sucks less, maybe sucks more.

On Sat, Jun 04, 2011 at 12:33:50 +0100,
Timothy Murphy <gayleard@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
 
Old 06-05-2011, 09:31 PM
"Michael H. Warfield"
 
Default 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 | mhw@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!
--
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
 
Old 06-05-2011, 10:01 PM
"Michael H. Warfield"
 
Default 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}
' | 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 | mhw@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!
--
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
 
Old 06-06-2011, 02:05 PM
Richard Shaw
 
Default Preupgrade still sucks. Maybe sucks less, maybe sucks more.

On Sun, Jun 5, 2011 at 5:01 PM, Michael H. Warfield <mhw@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
 

Thread Tools




All times are GMT. The time now is 09:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org