<Guide at post #19> FreeBSD concise updating guide request

carlton_draught said:
Just curious... something I was wondering about when I was reading the handbook, why is it really necessary or desirable to edit the kernel config to your specifications? If hardware changes or something like that, wouldn't it get you into trouble? I would prefer to have something generic as possible to minimize opportunities for errors to crop up.
Click to expand...

Building a custom kernel lets you remove devices you'll never use, or set options that can only be built into a kernel. It's not a huge risk, since most modules can be loaded at runtime if you unexpectedly need them.

# cd /usr/src
# make clean && make buildworld && make buildkernel && make installkernel && make clean
Click to expand...

That's a shortened version of the normal update procedure, which includes a reboot after installing the new kernel to make sure it works. A reboot after that is needed to load the new world, too.
 
carlton_draught said:
If hardware changes or something like that, wouldn't it get you into trouble? I would prefer to have something generic as possible to minimize opportunities for errors to crop up.
Click to expand...

The 8.7 If Something Goes Wrong section in the manual is pretty self explanatory. Even has one of those nifty "best practices" blocks.

http://www.freebsd.org/doc/handbook/kernelconfig-trouble.html

It should state that your last kernel is saved as kernel.old. When you move your drive to another machine just go back to GENERIC and reconfigure.
 
Thanks wblock and UNIXgod. I might even give it a go. It was just a bit more than I wanted to do at the time, that's all. My immediate priority was being able to backup my system, which I could not do at the time because zfs send/receive was giving me "Argument List Too Long" errors. I didn't want to compound things by rendering my system completely unusable, even if the fear was unfounded.
 
carlton_draught said:
Thanks wblock and UNIXgod. I might even give it a go. It was just a bit more than I wanted to do at the time, that's all. My immediate priority was being able to backup my system, which I could not do at the time because zfs send/receive was giving me "Argument List Too Long" errors. I didn't want to compound things by rendering my system completely unusable, even if the fear was unfounded.
Click to expand...

Well I don't want to get in trouble for losing someone else's data ;). If you have an opportunity to practice on a clean machine first it might help. If you can't do that recompile GENERIC first and make sure you cp the files yourself and name it something like kernel.works, kernel.bak, or kernel.gen. It shouldn't matter what the name is as long as you remember it.

If your really paranoid go through the process of loading the cp'd kernel as if you had to. Once you go through that process and see it work move to the step of compiling your own kernel.

NOTE: Most of us( if not all) botch the kernel when we are new. Especially on the first try. It's a process much like anything else you grok in FreeBSD. If you do get stuck it's more important to figure out what went wrong vs fear and not doing it.

You are correct though. backups are important to know and probably should be considered a priority over everything else.

When you are ready to compile your kernel start a new thread and I would be more than happy to help you with grokking the config and maybe save you one less headache.
 
Thanks very much UNIXgod. I may indeed take you up on that offer.

You are right about grokking things in FreeBSD, you have to be able to experiment on an install you can afford to hose first. You have to feel ok with destroying your system otherwise you are too scared to learn properly. Fortunately I have backup and restore procedures worked out, tested and documented such that I can afford to hose my system. It has taken me months to get to this point. I will hopefully post them soon.

I did forget that I don't just need to update ports, I also need to update the kernel and "world" I guess, for security reasons if nothing else. So I will probably have to amend the procedures, but that's just life. Not sure whether I should do a fresh install of FreeBSD 8.1 versus upgrading. I've long been an install from scratch person from my Windows days, but if there is little that can go wrong I'll try upgrading. Anyway, thanks again.
 
You don't have to update kernel and world when you update ports.

The operating system and applications (for example ports) are distinct on FreeBSD. It is very rare when a port upgrade might require OS (kernel + world) upgrade. It is also possible to need to upgrade (some) ports after you upgrade the OS, especially if version number changes (some ports have the bad habbit to keep directory threes named after the OS version).

It is ok to follow the stable branch, which means that if you curently run FreeBSD 8.0-release recompiling and reinstalling today would bring you to 8.2-prerelease. It is safe, as long as you follow the instructions in the /usr/src/UPDATING file.

There is little point to do 'clean' install, because unlike Windows, FreeBSD does not collect garbage in 'the registry'. If anything is left, it's from ports and the OS has nothing to do with it. When you do large updates however, such as from 8.0 to 8.2, there might be number of files and libraries that are no longer current and you may wish to remove. These can be discovered with

# cd /usr/src
# make check-old

instead of check-old, you may also use check-old-dirs, check-old-files, check-old-libs
Beware, that you should make sure nothing is using the old libs. The OS files will not, but it is likely that an port compiled on the old system may reference some old library (they should not but... that's different story). But, if you recompile all your ports after upgrading the OS, you may delete the old libs with

# cd /usr/src
# make delete-old-files
# make delete-old-libs

The first make will delete old files (manpages, executables, configuration files) that are no longer neccesary. The second make will delete the old libraries.
 
yay for guides

Dave,

Thank you for asking this question and for posting your guide.

As a sysadmin coming from a Linux background into a new job supporting FreeBSD machines, I had a really hard time "getting it" that there is a distinction between the tiny amount of base software included in FreeBSD and the much larger blob of software that most people probably have on their systems to make them useful.
 
UNIXgod said:
When you are ready to compile your kernel start a new thread and I would be more than happy to help you with grokking the config and maybe save you one less headache.
Click to expand...
I've taken you up on this offer here. If I'm lucky I will get things working by myself, but either way, maybe it will help someone else. Thanks to everyone on the thread who has posted, I appreciate it.
 
I thought I would post my own notes on the process, in case it helps someone, or if I'm doing something questionable then someone more knowledgeable can offer some insight. Note that this all should be able to be derived from the handbook. Even when I point to bits where I've walked through it, I've linked to appropriate parts of the handbook.

This assumes that you are installing from ports (not packages), and using ports-mgmt/portmaster to manage your ports. It also assumes that you are tracking RELEASE (when it comes to world/kernel, which is completely distinct from ports).

Ports
Setup procedure:
  1. Install ports-mgmt/portmaster.
    # cd /usr/ports/ports-mgmt/portmaster
    # make install clean
  2. Configure portmaster. The arguments for the lines I uncomment are -b, -g, -d, -m, -w, --no-confirm.
    # vi /usr/local/etc/portmaster.rc
  3. Copy DutchDaemon's portupdater.sh script to somewhere like root/bin.
    # mkdir /root/bin
    Paste it in there.
    # chmod 700 /root/bin/portupdater.sh
Maintenance frequency: daily
Maintenance procedure:
  1. # /root/bin/portupdater.sh yes
  2. Read the output, do as it says. Pay close attention to /usr/ports/UPDATING warnings, these need to be followed if you use a port corresponding to a warning.
  3. If you are keeping on top of ports updating, it's effective to use the -a option.# portmaster -a (or # portmaster portdir/port, if you want to do particular ports first.)
  4. Sometimes if you are having difficulty, you will need to go to the port directory and do something like:
    # make deinstall
    # make reinstall clean

Documentation Set
Setup procedure: None
Maintenance frequency: weekly?
Maintenance procedure:
Replace "cvsup.wherever.FreeBSD.org" with a a nearby mirror.
# csup -h cvsup.wherever.FreeBSD.org -g -L 2 /usr/share/examples/cvsup/doc-supfile


World (includes kernel, sources and system binaries), aka Base System
Setup procedure: My thread goes over it here.
Maintenance frequency: weekly?
Maintenance procedure:
  1. Update the sources. If nothing is new, this is all you have to do.
    # csup /root/supfile
  2. If something has changed, then make a backup (my way is shown here). And then I walk through the steps in the next post.
 
You must log in or register to reply here.
Back
Top