Consequences of using portupgrade -a on a running system

foo_daemon

foo_daemon

Just thought I would share something that happened to me today which I found pretty hilarious.

I use the Chromium browser on FreeBSD 10.0-RELEASE; I noticed that there were lots of available upgrades on my existing packages, so I did a portupgrade -ack on my live system to upgrade all installed ports.

I was using Chromium with about 10 open tabs as per usual while the upgrade performed in the background, but after a while noticed that trying to open any new tabs resulted in the "Aw, Snap! Chrome is broken" page. Tried to run a separate instance of Chrome via the CLI and I got:

Code: 
Shared object "libprotobuf.so.8" not found, required by "chrome"

Well, crap, it looks like devel/protobuf got a bump to libprotobuf.so.9, and I know Chromium will take about 2-3 hours to rebuild on my system to use the new library. I tried to make a symlink libprotobuf.so.8 in /usr/local/lib/ that just pointed to the .9 so, but that lead to an undefined reference library error for some specific call when trying to run Chrome from the CLI.

To top it off, the 10 already open browser tabs began to suffer from some peculiar issue where I could not change the URL of an open site. Doing so and hitting enter resulted in an infinite loading wheel for that page, but I could use backward/forward arrows just fine, and also clicking on any HREF link on that page would load that linked page just fine, so changing any of those open tabs to a different webpage/domain became an interesting "6 degrees of Google" problem where I had to use existing links to somehow get to Google or some other search engine.

I think there's a way to edit the current page with Chrome developer tool, so I probably could have changed the HREFs and navigated that way, but just thought I'd share this somewhat humorous anecdote of why you probably shouldn't do portupgrade without expecting some application interruption :)

Anyone have any similar stories?
 
foo_daemon said:
I noticed that there were lots of available upgrades on my existing packages, so I did a portupgrade -ack on my live system to upgrade all installed ports.
Click to expand...

Don't do that (throwing -a at an upgrade tool), or at least don't do it until you have followed any new steps in /usr/ports/UPDATING.

This article uses ports-mgmt/portmaster, but the principle is the same: Upgrading FreeBSD Ports.

Well, crap, it looks like devel/protobuf got a bump to libprotobuf.so.9 , and I know chromium will take about 2-3 hours to rebuild on my system to use the new library... I tried to make a symlink libprotobuf.so.8 in /usr/local/lib/ that just pointed to the .9 so, but that lead to an undefined reference library error for some specific call when trying to run chrome from the cli .
Click to expand...

Don't symlink libraries either. It's a short-term "cure" that makes for long-term problems.
 
I switched to building ports using ports-mgmt/poudriere and hosting my own package repositories. This means that building updated ports doesn't affect my running systems, even if there are errors. Upgrading the packages on each machine is then very fast since it's just installation; the compilation is already done. I believe it's the best of both worlds; the convenience of pkg(8) with the flexibility of choosing port compilation options.
 
asteriskRoss said:
I switched to building ports using ports-mgmt/poudriere and hosting my own package repositories. This means that building updated ports doesn't affect my running systems, even if there are errors. Upgrading the packages on each machine is then very fast since it's just installation; the compilation is already done. I believe it's the best of both worlds; the convenience of pkg(8) with the flexibility of choosing port compilation options.
Click to expand...
Yep, I fully agree. If you have some spare hardware setting up your own repository is just brilliant. The hardware doesn't have to be fast, it really doesn't matter if takes a day to build all your packages. Consecutive runs will only build the ports that have been updated or had their options changed. So doing regular builds will speed things up a bit as there's no need to rebuild everything from scratch (although that's still possible if you want).

I for one am never going back to my old situation :D
 
I've htm (17), txt (3), and msg (20-ish) (files) saved in /usr/ports/ports-mgmt/poudriere for eventual reading, but I notice a lack of a more-recent Howto in the subsection in this forum. For anyone reading this thread and about to implement a repository, maybe a new howto could be written.
 
Just as to add to the previous suggestion... I'm doing the same for my network of servers, however, instead of using ports-mgmt/poudriere I'm relying on ports-mgmt/portmaster, which can be very easy too.

Still; noteworthy here is that the (backup) server on which I host this repository is also a shadow copy of the other (live) web servers. So basically; I install, package and test the ports on the backup server and if everything works to my satisfaction I'll upgrade these packages on the rest of my servers using the package repository.

The fun part is that a mere directory share (either using NFS or Samba or...) is all you need. I considered it a very easy accessible way since most options are more or less default in portmaster anyway.

On that subject, jb_fvwm2; someone already did ;-)
 
Last edited by a moderator:
Great tips; thanks! I actually already have ports-mgmt/poudriere installed, and I'd been meaning to RTFM and start using it but hadn't gotten around to it yet.. now I have a very good reason to :)

wblock@ said:
Don't do that (throwing -a at an upgrade tool), or at least don't do it until you have followed any new steps in /usr/ports/UPDATING
Click to expand...

Yes, I forgot to mention that I had already looked through and performed the steps in /usr/ports/UPDATING after my portsnap fetch update
 
You must log in or register to reply here.
Back
Top