Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software BSD

Painlessly Update FreeBSD 123

Posted by timothy from the a-slight-pinch dept.
boarder8925 writes "Over at BSDnews, Steve Wingate has written an article on how to easily update FreeBSD. Wingate begins his article by saying, "One of the greatest advantages that *BSD has over other Unix variants is the cvsup/make world process. Unlike most Linux distributions it isn't necessary to wait months for a new version to be released for you to upgrade your system. The cvsup/make world process allows you to update your system at any time. I'm going to show you how to make the process as painless as possible." The article discusses the following: installing CVSup, choosing a cvsup server, configuring make.conf, and, finally, performing the upgrade. The piece is also available as a .pdf file."
This discussion has been archived. No new comments can be posted.

Painlessly Update FreeBSD More

Painlessly Update FreeBSD

Comments Filter:

  • This is different from the cvs guide (Score:3, Insightful)

    by RLiegh ( 247921 ) on Saturday April 24, 2004 @06:41PM (#8961575) Homepage Journal
    in the handbook how?

    • It's more risky than following the handbook. (Score:5, Informative)

      by TheLink ( 130905 ) on Sunday April 25, 2004 @11:42AM (#8965111) Journal
      The article is actually riskier IMO.

      Firstly: he doesn't track the RELENG_4_9 branch, he tracks the STABLE branch (RELENG_4 - e.g. the latest of whatever is considered stable for Release 4) - which is more likely to break working stuff than the RELENG_4_9 branch which is FreeBSD 4.9 that has just the updates for security problems. Yes many ppl don't have problems with RELENG_4, but if your job and reputation is on the line - only use it if RELENG_4_9 doesn't work (hardware, required features etc).

      Secondly: He skips the mergemaster -p step.

      The way I recommend is what's been in the FreeBSD handbook for years:
      Step 1: Synchronize your source [freebsd.org] Use cvsup. It's better. And track the RELENG branch.
      e.g. cvsup mycustomcvsupfile
      Where mycustomcvsup is like the stable-supfile but with the following tag instead of RELENG_4:
      *default release=cvs tag=RELENG_4_9

      Step 2: Building and Installing world [freebsd.org]

      optional step before:
      cp /etc/defaults/make.conf /etc/make.conf
      edit /etc/make.conf accordingly (compile options, whether ports openssl/openssh overwrites the base openssl/openssh etc)

      Then
      make buildworld
      make buildkernel KERNCONF=YOURKERNELNAME
      make installkernel KERNCONF=YOURKERNELNAME
      reboot and go to single user mode
      mergemaster -p
      (preliminary mergemaster stuff if things are too different between your config and what the new FreeBSD stuff is)
      make installworld
      mergemaster
      (to merge what's new in /etc and stuff to what your local custom config is like)
      reboot

      ***multiple machines.
      Here's where you might do things differently.

      Read this for some background: tracking for multiple machines [freebsd.org]

      Now once you built everything, you don't have to rebuild it on a different machine if you are using a compatible architecture. For example you specify a 686 CPU in your make.conf and kernel config, you can only reuse it on stuff which supports 686 class CPUs.

      I didn't bother with the NFS part (not applicable for some situations) - I just did the synchronize of src and ports and did the build on a fast machine with a fast connection.

      The default was 4-stable which tracks the current stable source of Release 4. For production machines I recommend tracking RELENG releases and not STABLE.

      Then build the kernel and sources.
      cd /usr/src
      make buildkernel KERNCONF=kernelformachineA
      make buildkernel KERNCONF=kernelformachineB
      make buildkernel KERNCONF=kernelformachineC
      make buildworld
      cd /usr/
      Then tarball the results: tar -zcvf src.tar.gz src && tar -zcvf obj.tar.gz obj && tar -zcvf ports.tar.gz ports

      Then I copied the tarballs (via CDR) to the slow machine which did not have a cvsup connection (not allowed by firewall policy etc)

      Then installed the results on the machine.
      cd /usr
      rm -rf src obj ports
      tar -zxvf src.tar.gz && tar -zxvf ports.tar.gz && tar -zxvf obj.tar.gz

      Then I ensured that the /etc/make.conf was correct etc.
      Then: make installkernel KERNCONF=therelevantkernel && make installworld.

      Note: to save the trouble of building desired ports software on the slow machine you have to make packages on the fast machine.
      e.g.
      cd /usr/ports/blahblah/softwarename
      make package
      ---
      You should also check out freebsd-update.

      freebsd-update is more like binary updating of stuff affected by security issues.

      Redhat is simpler on one hand and more complex on the other- sure you can ftp all the rpms and run a freshen. But it's harder to be sure everything is really consistent
      • Mergemaster is a painful step, and one that can often be confuse the user. It can usually be ignored.

        Mergemaster, in theory, is used to update the files in /etc. It is very kludgy, slow, and painful though. It makes a whole bunch of diffs between the existing files and the newly proposed files, then forces you to decide whether or not you want to replace them. The questions it asks are confusing, and it's not entirely intuitive as to what is going on. To me, it seemed as though it increased the likeli

  • Gentoo has this.. (Score:2, Informative)

    by pilot1 ( 610480 )
    Gentoo has this aswell. There are no distribution versions, a simple 'emerge -uDav world' will update the system.
    • I guess we'll never see any serious commercial apps for gentoo then.
    • Well, yeah, that's why he said "most".
      • Well, yeah, that's why he said "most".

        I think he's still wrong out of that respect. The major distros I know support this include:

        Gentoo
        Slackware
        Debian
        Redhat
        Mandrake

        This leaves very few major distros that don't. Considering that the majority of the remaining distros are based on one of the above, or on the fringe, I can't see how his point is all that valid.

    • Re:Gentoo has this.. (Score:4, Interesting)

      by UnseenEnigma ( 743397 ) on Saturday April 24, 2004 @09:04PM (#8962283)
      The only issue with gentoo is the lack of a central binary repository like the redhat channels system (official anyway - chinstrap is decent for those willing to stray). It was discussed at great length several months ago and decided not to be created despite having the backend infrastructure already in place. The great advantage of gentoo, and in a way the failure of bsd (and pretty much every commercial linux) is the ability to choose complex compile and build options with ease. For this same reason and the fact a binary repository could never handle a fraction of the possibilities it was never created :(. If however you consider implementing gentoo in a work environment with say 10-100 systems they could all be set to use a central compile server to your organisation or/and through distcc compile kickass fast! Although installs of gentoo are a pain (hopefully better if the installer gets built) it is by far the easiest to update, and customise of any linux. And (big + for me) none of the bs of no or modified media players, browsers, burner software etc of suse, redhat or mandrake because of cautios legal practises. I've been finding more and more things i like about the portage system the more i use it. Any new reasonably popular package seems to make it on the tree in less than a day. If their is a piece of software that isnt on the tree u need (happened to me once) u can either find or make a ebuild and submit it for inclusion in the tree My Conclusions Ms Windows - ah get it away from me!!!! Evil Redhat/Suse/Mandrake - Better but canabalises some stuff and out of date packages The BSD Trio - Stable, fast, easy update, and faster update due to binary Gentoo - Stable, fast, easy update and more customizable due to all source (usually)
      • Most of a gentoo install can be automated by a fairly simple script of just a few lines which you could ftp to the system and execute. An installer would speed things up a little bit but it's a pretty trivial install as it is. If you always partition the same, use the same services and so on, you can automate the interactive steps which take the longest, which is to say creating/editing config files.

        I picked up a R4400SC-powered Indy system recently and decided to put Gentoo/MIPS on it - I'm not sure it's

  • Just in case ... (Score:3, Informative)

    by boarder8925 ( 714555 ) on Saturday April 24, 2004 @06:45PM (#8961595)
    In case the site's Slashdotted ...

    Google cache of article [64.233.161.104]
    Google cache of .pdf file [64.233.161.104]

  • Anonymous Coward's Guide to Updating Debian (Score:1, Insightful)

    by Anonymous Coward
    # apt-get update; apt-get dist-upgrade

    Wasn't that hard?

    • Re:Anonymous Coward's Guide to Updating Debian (Score:5, Insightful)

      by rsax ( 603351 ) on Sunday April 25, 2004 @02:46AM (#8963563)
      Yes APT is great. It's easy to use and requires less effort than the FreeBSD upgrade process but it's too bad Debian stable is so hopelessly out of date. FreeBSD isn't. It's a stable operating system with upto date third party software delivered using the ports system. I've said this before and I'll say it again since this Debian comparison has been brought up.... I hear this argument from Debian advocates a lot: "Do you want a stable server or do you want bleeding edge?" Well with FreeBSD I get stable servers and still have packages that aren't a year or two [or sometimes more] old...... it is possible. And before anyone recommends that I run Debian testing instead please remember that the Debian Security team claim that they don't support anything besides the stable releases. I could use a Debian stable system and then mix match packages from unstable or testing and risk instability in the end or higher maintenance due to no security alerts from one source but then why not use FreeBSD instead in the first place?

      • Yes APT is great. It's easy to use and requires less effort than the FreeBSD upgrade process but it's too bad Debian stable is so hopelessly out of date.

        Three words: "End of Life"

        If we are looking at updates, the last extended support release of FreeBSD was 4.8, which was released in April, 2003.

        Its end-of-life is March, 2005.

        Debian Potato was released August, 2000 and end-of-lifed in June, 2003.

        Debian Woody was released in July 2002, and, assuming that tradition holds, will be supported

        • >Its rather nice not to change software in 3 years or so.

          Sure, if you like using 4 or 5 year old hardware. If you want to use newer hardware, you have to run a "testing" kernel. Case in point: a 160GB hard disk attached to an ATA/133 card... gotta have 2.4.20 to handle it. I would have been limited to using 127MB of it, and accessing it thru the mobo's blazingly fast UltraDMA/33 ports, if I was determined to stay with "stable".

      • Re:Anonymous Coward's Guide to Updating Debian (Score:1, Informative)

        by Anonymous Coward
        Yeah, Debian stable is pretty out of date... For Desktop systems.

        I use Debian stable on all of my servers; it still gets the security updaes, and stable is... Well, stable. Great for production servers.

        Debian testing works great on desktops, though. I'm running testing now, with kernel 2.6.5, and everything is wonderful, and best of all...modern. And pretty stable, too.

        If you don't need the fancy gui stuff, testing is the way to go. Most of the server oriented stuff is very up to date in stable.

  • cvsup in C? (Score:2, Informative)

    by Anonymous Coward
    Anybody know if cvsup will ever be rewritten in C instead of Modula-2 or whatever the heck that is?

    I'm hoping someday Gentoo will use cvsup because it's a bit more efficient (it doesn't have to re-compute all deltas every time like rsync).

    I use both FreeBSD and gentoo heavily but portage generally feels a lot slower than BSD ports, syncing as well as the various cache or dependency operations or whatever it does when it sits there spinning at me.
  • I have never used a linux distribution which lacks a tool for updating software without upgrading to the next official release. Redhat had one, mandrake had one, suse had one..and most importantly, debian has one.

    okay, minor lie; linux from scratch had no such tool. on the other hand, linux from scratch had no installer and consisted entirely of a manual explaining how to compile the software. :)
    • Article (or at least the blurb here) is (Score: -1, Troll)

    • Yes, linux has always had software to update software to the latest official release. What he is saying is that with BSD you can update the system to the latest software too, without waiting for the next version.

      In other words, on RedHat or Debian, I can update to the latest apache pretty easily with apt or rpm. Same on BSD. But on BSD I can also easily download and install the very latest updates to the kernel and base system straight from the official CVS without having to wait for binary updates to come

    • If that's true, then how come every time there's a new linux kernel version, hordes of slashdotters come out querying when it's going to included in their distro. With Linux you either have to wait until someone updates a kernel package (or emerge script), or go grab it and built it yourself manually. It's not going to happen instantaneously.

      That's the essence of what the article blurb is saying. No need to get all defensive about it. You chose to use a system that someone else integrated together for you

  • That's the easy solution? (Score:5, Insightful)

    by cperciva ( 102828 ) on Saturday April 24, 2004 @07:15PM (#8961762) Homepage
    If cvsup && buildworld && installworld is the easy solution, I wonder what he considers this to be:

    freebsd-update fetch
    freebsd-update install

    Yeah, ok, FreeBSD Update is only about tracking the release branch. But really, this story just covers the standard technique which people have been using for... well, longer than I've been using FreeBSD.

  • too many dependencies (Score:5, Insightful)

    by hak1du ( 761835 ) on Saturday April 24, 2004 @07:19PM (#8961794) Journal
    Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me.

    The underlying problem is really that C/C++ code has so much information compiled into each object file: even common, minor changes may require huge amounts of recompilation. While we practice abstraction and encapsulation at the source level, at the binary level, it is still mostly lacking.

    The choice shouldn't been between huge amounts of recompilation from source (Gentoo, BSD) or laborious hand-packging and version tracking (Debian, RedHat, etc.), this needs to be addressed by changing the underlying software infrastructure. Let's hope we'll move more towards JITs, dynamic binding, dynamic typing, and component-based software. Then we can finally get away from these massive recompilations and version hell.
    • FreeBSD also provides binary packages like gentoo does too. In gentoo the flag is -K IRC, FreeBSDs I can't remember
      • Gentoo has very very few binary packages. But, most Gentoo users (like me) accept compiling as part of using it.

        If you're looking for a power-user Linux with binaries, Debian would probably be a better way to go.

        And, I don't understand how this article is at all news. Hasn't FreeBSD had this for years?

        • If you're looking for a power-user Linux with binaries, Debian would probably be a better way to go.

          Debian indeed gives you a great selection of packages and does a good job on the dependency management.

          But that doesn't mean that the dependency problem has been solved--you are still paying the price for it. To make the Debian magic happen requires an enormous amount of labor and coordination. Even with that, there are dependency problems (fewer than if you try to do the same thing by hand with RedHat o

    • Re:too many dependencies (Score:4, Insightful)

      by josepha48 ( 13953 ) on Saturday April 24, 2004 @08:02PM (#8962018) Journal
      "Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me."

      No kidding. My NetBSD box taks hours to compile all these packages. If all you want to do is upgrade xscreensaver, all you have to type is make update ( or is it upgrade ). But what happens in the background is that it probably has newer requirements, like an updated gtk, which depends on pango updates, and that depends on .. and so on and so on, and then suddenly updating one program becomes updateing the WHOLE gnome desktop and compiling from sources. On an old 233Mhz that is a long time. But hey NetBSD and FreeBSD install on on old 233Mhz with only 64Megs of RAM, Redhat doesn't, ( debian does though ).

      I agree "The choice shouldn't been between huge amounts of recompilation ..." but I can't see having the whole GUI using JITs. Also most of these programs use dynamic binding.

      See the problem is that the maintainers of these packages, upgrade the requirements of the packages based on new features in these packages or just because it is the latest in the release tree and assumed to have less bugs. IE. xscreensaver probably would have compiled fine in teh above example with the gtk onn my system, but the Makefile for it has a requires gtk 2.2.x+ or something like that in it which it then checks to see if it is installed on the system. It should really have done, if gtkversion == 2.0 compile with gtk 2.0, and leave our whatever features that it is missing. Chances are there are none that require gtk 2.2 and 2.0 wont work just fine. However if it was gtk = 1.2 then update. A better example is programs that still use gtk 1.2. Is there really a difference between gtk 1.2.10 and 1.2.10nb2? Probably not enough that you are required to upgrade all the programs on the system. They should add an option, and call it make update_all which updates ALL the dependancies and then the default behavior should be make update just this one program. That's what the problem is with this compile stuff. I use Linux, NetBSD, FreeBSD, Windows, Sun, and Mac. They all have their plusses and minuses. It really depends on what you think is important.

      • I happened to have the bad luck to upgrade from a gimp-2.0pre3 built before gnome 2.6 hit the CVS, to a gimp-2.0 final from after gnome 2.6 entered. That was really awful, because the FreeBSD gimp port wouldn't build against the older libs the way you describe.

        This is particularly annoying because this is one of the main reasons I switched to BSD from Debian-- with Debian, unless you're running stable, the dependencies for any new binary package you install can cascade up the dependency graph and then ba

        • They upgraded libraries in a *prerelease* version? Why, was there a major showstopping bug found in the old version? I hope so, because that's a pretty poor development methodology otherwise.

          I'm sorry, I've spent 15 years developing commercial software, and the first rule you learn (okay, the first rule you learn is 'Always make backups of everything') is not to upgrade any of the libraries, tools, or whatever in the middle of a project unless there's a really compelling reason. That doesn't even take i

      • make update

        can be PITA. I even had a poster in my cubicle in the office saying "DON'T USE make update!"... The results may be difficult to predict... and you don't want all your KDE or Gnome packages suddenly disappear because of some weird dependency. I have also an occasion I found myself in a loop - a needs b needs c ... needs a...

        What I normally do nowadays on my NetBSD systems is use just 'make'; if there are dependencies, it will 'make install' them and if there were older versions of these in p

    • This doesn't help. If you have a managed/jit'ed language, one still wants the latest and the greatest. That means updating to that. Had gtk as the example were been a java/python whatever project, it still wouldn't
      be any less painful of updating if you want the latest. And interfaces
      are just as important here,.
      Change the interface and all dependant application needs to be updated
      to take adjust for that.
      Then there is the choice of what to update. If installing a new xscreensaver is what I want, pkgsrc on my
    • The underlying problem is really that C/C++ code has so much information compiled into each object file: even common, minor changes may require huge amounts of recompilation.

      What are you talking about? Major recompilation is a development issue, not an end-user issue.

      Whenever a new version of a package is installed, it is compiled from scratch. End users do not keep object files from previous versions of a package. Upgrading a package means recompiling all the binaries from scratch.

      Let's hope we'l

      • Have you ever deployed a component solution? I'm all for language agnostic component solutions, but there is tons of version hell in both the .NET and JAVA worlds.

        Yes, indeed there is. .NET and Java don't solve this problem. That's both because they have many other dependencies between modules and because their byte code format unnecessarily encodes too many dependencies.

        Nevertheless, JITs are an important part of the solution because they allow you to remove almost all compiled-in dependencies between
        • Yes, indeed there is. .NET and Java don't solve this problem. That's both because they have many other dependencies between modules and because their byte code format unnecessarily encodes too many dependencies.

          You can use reflection.

          Nevertheless, JITs are an important part of the solution because they allow you to remove almost all compiled-in dependencies between object files without sacrificing efficiency.

          They don't remove compiled-in dependencies. They compile just-in-time. (Hence the acronym)

      • Whenever a new version of a package is installed, it is compiled from scratch. End users do not keep object files from previous versions of a package. Upgrading a package means recompiling all the binaries from scratch.

        Please see ccache [samba.org].

    • Re:too many dependencies (Score:1, Interesting)

      by Anonymous Coward
      The problem isn't too many dependencies, the problem is that all current package managers suck. If I'm trying to migrate to the newest GIMP, I must first resolve all the dependencies for the new GIMP. This is only a problem because I'm forced to do it all at once. I have to first remove all of the old packages I'm going to replace with the new GIMP's dependencies, meaning my current system is unstable based off of a pending upgrade of one package. After that, I can compile/install the new GIMP, but I al
      • The problem isn't too many dependencies, the problem is that all current package managers suck. If I'm trying to migrate to the newest GIMP, I must first resolve all the dependencies for the new GIMP.

        With Debian, you don't have to: apt will do it for you. But that doesn't remove the dependencies--you still pay the price. What's the price? Huge downloads and enormous amounts of human effort going into this.

        Instead of lumping everything together in /usr/local, wouldn't it be better if packages binaries
    • Watch out people!
      This is a disgiused Java advocate! Don't be fooled to think; 'I wish there would be a language for that'.

      As soon as you'd say that, the Salesmen of The Sun would be knocking on your door.
      • I wouldn't advocate the use of Java in OSS because Java is highly proprietary and has many design flaws.

        I would advocate the use of Mono/C#, however, since it is open source, non-proprietary, and fixes many of Java's problems. And I don't "disguise" that at all--why should I?

        Unfortunately, neither Java nor C# were designed to deal specifically with this problem, so neither of them is a complete solution. But they help, and if you know what you are doing, they can actually help a lot. Another language t
    • Let's hope we'll move more towards JITs, dynamic binding, dynamic typing, and component-based software.

      Coincidentally, right now I'm in the middle of a rather lengthy recompile of Java...

      To the point at hand, the problem isn't compiled languages, it's developers not taking upgrades into account. If you change the functionality of an application, it stands to reason that you have to rebuild that application (or at least the components that have changed). I don't see where this is any more onerous than hav

  • Recommended step (Score:2, Informative)

    by Understudy ( 111386 )
    The article is nice and well written. I would however change one step.
    alias rebuild 'cd /usr/src && make update && make world && make kernel && mergemaster'
    to
    alias rebuild 'cd /usr/src && mergemaster -p && make update && make world && make kernel && mergemaster'
    The prebuildworld mode for mergemaster is a life saver. Read man mergemaster.

    • Re:Recommended step (Score:3, Informative)

      by cos(x) ( 677938 )
      Actually, for 'mergemaster -p' to do what it's intended to do, you need to have the current source code downloaded already. So, you would need to exchange the order of this command and 'make update':

      alias rebuild 'cd /usr/src && make update && mergemaster -p && make world && make kernel && mergemaster'

  • Issue #3?November 9, 2003 (Score:4, Interesting)

    by beefdart ( 520839 ) on Saturday April 24, 2004 @10:30PM (#8962652) Homepage
    I was scanning this... Got 1/2 way through and was wondering if he stole it, cause I swore i read it somewhere.

    Then I realized: Issue #3?November 9, 2003

    How the hell is this news? I love FreeBSD, its all I use. the only thing dead about it is bsd.slashdot.org

  • read UPDATING (Score:2, Informative)

    by knightbg ( 447872 )
    One thing this paper leaves out is reading UPDATING. You really really should check out the file /usr/src/UPDATING after you sync your tree but before you start building. Of course, the handbook will tell you that you should also be subscribed to the proper mailing list (freebsd-current or freebsd-stable) but at the very least, reading UPDATING is a Good Thing.

  • Why is his method special? (Score:3, Insightful)

    by hayds ( 738028 ) on Sunday April 25, 2004 @05:32AM (#8963905)

    When I first saw the headline about "painlessly updating", I thought this might be a great article about some new innovative way to update. Its not really anything new or interesting though, the whole article is basically saying: "cd /usr/src && make world && make kernel && mergemaster will update you system"

    Not wanting to sound rude, but no shit sherlock! Yes, this is a painless way to update your system. It is also the way to update your system, as is very well spelled out in the excellent FreeBSD Handbook so I'm not sure why it warrants an article....

    Maybe its just me but I think an article [onlamp.com] about portupgrade or something would have been more useful.

    • Not only that but it's actually harder than updating some of the other systems. Redhat is officially updated with up2date, right? Gentoo is emerge -uD world and then an etc-update process (which frequently sucks, but never mind that - I don't mind it too much when I'm updating.) He makes it sound like it's difficult to update other free Unixes/Unixalikes, which generally just ain't the case.
      • I've used gentoo some time ago but process of updating gentoo is almost same as FreeBSD, emerge does job same as make world/kernel and etc-update as mergemaster. So comparing them and telling that is easier it's not really true, I would say that difficulty is actually equal in both systems.

  • offer to overwrite /etc/passwd? Safe? UG! (Score:3, Informative)

    by lpq ( 583377 ) on Sunday April 25, 2004 @05:02PM (#8967284) Homepage Journal
    An update system that offers to overwrite /etc/passwd (and presumably every other security file) hardly seems like a safe or easy upgrade process.

    I can't say my DoC (SuSE) has it better -- they don't ever seem able to upgrade my system in a sane or coherent manner. Last time around, it upgraded my squid 3.0 to squid2, tried, unsuccessfully to put my named in a basement mail (when it hadn't even been bad), but it was thrown in the basement w/o the root servers file and when the root servers all expired some large amount of time (~3-4 months) later, various TLD's started disappearing. It was bizzare watching large sections of internet just "go away" a few days before it completely consumed itself. Then I found the problem -- it hadn't copied in the root servers file from the previous upgrade (and/or didn't install a new copy). I tried grabbing some updates with their Yast Online solution, but it kept downloading copies of 8.2 binaries when I have 9.0 loaded. I never had 8.2 loaded -- I went straight from 8.1 to 9.0. Later, I found, buried in some paragraph of fine print somewhere that their updates only support updating from the immediately preceding version -- this was after it had removed all unknown packages fro the package database. At this point I had all the 8.1 packages installed, but no longer noted as "installed" in the database over which it automatically upgraded and installed about 10-15 packages out of the 100-150 it should have installed (I guess ~10-15 packages kept some same valid name). I'm always rather afraid to do an upgrade under SuSE as I know it will usually involve lots of pain.

    On the flip side -- a fresh install of 9.0 for a never-used-linux user went real smooth -- they were able to navigate their way around after only one or two hiccups -- like buttons weren't where they used to be under Win, but I just told them they'd have to experiment a bit and find out how things were arranged differently. Once they experiemented some, they started finding what they needed surprisingly well. :-( & :-)
    -l
    • An update system that offers to overwrite /etc/passwd (and presumably every other security file) hardly seems like a safe or easy upgrade process.

      In FreeBSD /etc/passwd is provided for compatibility you can even erase it and system will work correctly (some programs may stop).
      This file is generated from /etc/master.passwd using command pwd_mkdb with option -p
  • "Unlike most Linux distributions it isn't necessary to wait months for a new version to be released for you to upgrade your system."

    Either this is a joke, or this guy never installed a Linux distro. Or maybe it was Debian Stable and he didn't realize what "stable" means.

    Sure, the BSD ports system is nice. But there's no need to make a blind comparative with "most Linux distributions" to justify it. It just feed trolls without actually helping anyone.

  • I don't know what version he is using but I'm running 5.2.1 and there is no /etc/defaults/make.conf, only an /etc/make.conf and that doesn't contain all the tags. and in /usr/src there is no Makefile. Am I doing something wrong here?
    • Okay.. When I manually ran cvsup -g -L 2 stable-supfile it added a Makefile and stuff in /usr/src but if the article is supposed to be a beginners look at upgrading the system, why does he assume that we have upgraded once before? And still no sign of /etc/default/make.conf..
      • make.conf doesn't exist in a /etc on a fresh system. You moved it instead of copying it (ie mv /etc/default/make.conf ../ instead of cp /etc/default/make.conf ../ )

        If you run mergemaster after you cvsup, you'll get a fresh copy in /etc/default.
        • No I havn't moved anything from /etc/defaults. If I had moved it it would still contain the defaults. The one in /etc/ only contains perl related tags. I have three 5.2.1 systems and not one of them has an /etc/defaults/make.conf And even after having run mergemaster there is still no make.conf there. Do you use 4.x or 5.x?
          • I hadn't checked on my 5-current box, but it appears you're correct, it doesn't exist on cvsweb (src/etc/defaults). My last comment was for 4.x machines, I guess I should have mentioned that. I didn't read the article, as it's rather irrelevant to me. I'm guessing the article is for 4.x?
            • Yeah it must be for 4.x I guess. It would be nice if he mentioned that in the article though. The only way someone can tell it's for 4.x is that there is no mention about editing stable-supfile and changing RELENG_4 to something else.
    • 5.2.1 doesn't work the same way as 4.x, for whatever reason - I guess a lot of the stuff in /etc/defaults/make.conf wasn't used in the same way /etc/defaults/rc.conf is, so they changed it.

      Anyway, you can find an example make.conf in /usr/share/examples/etc/make.conf

      Just copy that to /etc/make.conf and edit to taste.
    • /usr/share/examples/etc/make.conf

      It changed in the 5.x series

  • Ports upgrading is more painful (Score:3, Interesting)

    by cpghost ( 719344 ) on Monday April 26, 2004 @05:31AM (#8970743) Homepage

    Upgrading the base system is great and it works most of the time. I'd only wish cvsup/cvs were able to fetch a consistant source tree, but as long as CVS doesn't provide some kind of ACID semantics, it would be very hard to do so. There's always the risk of updating /usr/src in the midst of a commit.

    The ports are actually more painful to upgrade than FreeBSD proper. portupgrade does a great job at this, but it's not a panacea. First of all, portsdb -uU takes a hell of a time to generate a new INDEX.db, then you still have to fix some stale dependencies etc... This is the same problem as with Linux distros, and there is no easy solution to this.

    • portsdb -uU takes a hell of a time to generate a new INDEX.db

      This just took me 10 minutes on a server that was under 50% load at start time, with a ports cvsup on Saturday. The machine is a k6-2 350.

      I don't think that's unreasonable considering how old my servers are, and the number of ports it has to chew through (10,000+, maybe 11,000 now.)
  • Is there a way to upgrade your FreeBSD install using PACKAGES (bins) rather than CVS or ports (src)??
  • I can do this with windows. windowsupdate.com

    (this is the exact same format as a gentoo, debian, slackware, mandrake, suse, fedora, osx user would do so I'm only a troll if you're biased)

Slashdot Top Deals

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Close