This... is not good. |
Ah!, I thought to myself. There's where my software updates are hiding.
I got to work. I fetch'd and updated my portsnap. I installed portmaster. I instructed portmaster to update all the things.
It failed.
I told portmaster to try again. Like a good, predictable, consistent automaton, it failed again. All right, time to get to troubleshooting, or, failing that, at least a basic exercise in literacy. I read the error message - portsnap was trying to update a port that had grown stale, meaning the maintainer had fallen off a cliff, so the powers-that-be in FreeBSD decided to prune the tree and remove the poor, neglected port from circulation. Trouble was, this stale port was a dependency for one of my other ports, which, curiously enough, actually needed to be updated.
Hmm. What to do? Well, let's try updating the ports one at a time. Maybe that'll work.
After updating a few ports individually, including my X server - that's the part that draws pretty pictures and windows in Linux* and BSD, for those of you paying attention at home - I decided it was about time to reboot. When my system rebooted, I was not greeted by pretty pictures.
Hmm again.
No worries - this isn't the first time in my life that I found myself dumped unceremoniously into a shell prompt. Back when I first started playing with Ubuntu during the heady days of Breezy Badger - I had a complimentary CD! - I made it a regular habit to update my graphics driver, which led to me making a regular habit out of rebuilding my X configuration and my kernel from the shell to recognize this new driver whenever either the driver or the kernel updated itself, which was obnoxiously often. It was scary the first time, annoying the second, and moderately frustrating after that, at least until Ubuntu introduced DKMS, which allowed binary graphics drivers to install much more smoothly than they had in the past. Though it had been a few years since I had dealt with that particular annoyance, I was still on familiar enough ground - no need to panic. It was, however, time to read the instructions a bit more carefully:
Important:
Before attempting an upgrade, read /usr/ports/UPDATING
from the top of the file to the date closest to the last time ports were upgraded or the system was installed. This file describes various issues and additional steps users may encounter and need to perform when updating a port, including such things as file format changes, changes in locations of configuration files, or any incompatibilities with previous versions. Make note of any instructions which match any of the ports that need upgrading and follow these instructions when performing the upgrade.
Oh. I skipped that step, didn't I?Before attempting an upgrade, read
/usr/ports/UPDATING
from the top of the file to the date closest to the last time ports were upgraded or the system was installed. This file describes various issues and additional steps users may encounter and need to perform when updating a port, including such things as file format changes, changes in locations of configuration files, or any incompatibilities with previous versions. Make note of any instructions which match any of the ports that need upgrading and follow these instructions when performing the upgrade.Well, no matter. I got to work - I started reading the UPDATING file, then realized very quickly that updating 500 ports in one shot was not a good idea. I was either going to be staring at the shell for the next week trying to rebuild each port from scratch, or I needed a way to get back to where I was. Of course, I didn't bother with backups - there wasn't anything really of consequence on that partition anyway, so wiping and reformatting wasn't out of the option. However, there had to be an easier way.
Then I stumbled across this.
Ah! Instructions for turning a FreeBSD 10 install with arbitrary ports installed into a PC-BSD installation - that might work. If nothing else, it might get my ports to get back to a PC-BSD-approved homeostasis. I started carefully at the beginning:
- I made sure /usr/local/etc/pkg/repos still existed - it did.
- I made sure /usr/local/etc/pkg/repos/pcbsd.conf still existed and confirmed that it had the approved incantations inscribed within.
- I decided that, if the configuration file was still there, chances were that the security certificate was still there, too. Besides, I was looking at the instructions on my phone since my computer only had the terminal, and writing a long, arduous command via touch-type sounded less than ideal. So I proceeded to the next step...
- pkg upgrade -fy dutifully ran. And ran. And ran. Over 2000 binary ports downloaded and reinstalled themselves. After a good 30-45 minutes, KDE relaunched itself and I found myself looking at the familiar PC-BSD login screen. Oddly enough, the keyboard and mouse didn't work, so I let the system sit until the hard drive light stopped blinking (I lost track of where in the chain of 2000+ ports the system was at and wanted to make sure it installed them all), then hit the power button.
After the reboot, everything was back to normal - I had a fully functioning PC-BSD system once more. I re-ran pkg upgrade -fy again just to make sure nothing was missing, rebooted once more after I confirmed its successful completion, then called it a day.
The experienced reminded me of my early days with Ubuntu Breezy Badger in another way. Back then, Ubuntu was much more closely linked to the Debian project than it is now - it wasn't just a meta-package that you could trivially install over a Debian Testing installation, but it was awfully close. Trouble was, if you tried to treat Breezy Badger as just a Debian Testing installation and started syncing your software accordingly, it was only a matter of time before you discovered the hard way that there was actually some coordination between Ubuntu's various installed packages, and no, you really didn't know how the different parts worked better than they did. That was a problem if you weren't careful since that touchy, uncoordinated Debian system was still lurking underneath, daring you to dig in and play, and the line between the coordinated but brittle Ubuntu universe and the laissez-faire Debian Testing installation underneath was poorly demarcated and documented. Frequently, you wandered right over it, blissfully unaware that you were on the wrong side of the tracks until, suddenly, the system pushed you against a wall and mugged you of your precious time.
For Ubuntu, I'm happy to report that those days are long gone. PC-BSD, on the other hand, is a different story. It might look like a FreeBSD install. It might even say it's a FreeBSD install when you feed it a uname -a in the shell. But it's not - not really. Not if you want everything to work right. There's a reason PC-BSD maintains their own ports repository and it's not because they're trying to keep FreeBSD's bandwidth costs down. You've been warned.
For the record, I haven't had this much fun in years.
***
* Unless you're running Wayland or Mir, both of which are precisely the sort of half-developed chaotic nonsense BSD folks find so disheartening about Linux.
No comments:
Post a Comment