# Is freebsd-update, really so retarded



## Seeker (Jan 20, 2010)

Last time I've built OS from /usr/src, so now is:

```
# uname -a
FreeBSD blackhole.starforce.biz 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Mon Jan 18 07:19:45 CET 2010 root@blackhole.starforce.biz:/usr/obj/usr/src/sys/GENERIC  i386
```
From now on, I wana stick to binary upgrade mechanism, as I stick to RELEASE branch and GENERIC kernel

```
55      */12       *       *       *       root    freebsd-update cron
```
Each day throws in my mail:

```
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/etc/mtree/BSD.var.dist
/var/db/mergemaster.mtree

The following files will be updated as part of updating to 8.0-RELEASE-p2:
/boot/kernel/ip_mroute.ko
/boot/kernel/ip_mroute.ko.symbols
/boot/kernel/kernel
/boot/kernel/kernel.symbols
/boot/kernel/krpc.ko
/boot/kernel/krpc.ko.symbols
/usr/lib/libssl.a
/usr/lib/libssl.so.6
/usr/lib/libssl_p.a
/usr/lib/libzpool.a
/usr/sbin/freebsd-update
/usr/sbin/ntpd
/usr/src/etc/mtree/BSD.var.dist
/usr/src/libexec/rtld-elf/rtld.c
/usr/src/sys/cddl/compat/opensolaris/sys/vnode.h
/usr/src/sys/conf/newvers.sh
/usr/src/sys/kern/vfs_lookup.c
/usr/src/sys/netinet/ip_mroute.c
/usr/src/sys/netinet/raw_ip.c
/usr/src/sys/netinet/sctp_input.c
/usr/src/sys/netinet6/raw_ip6.c
/usr/src/sys/rpc/clnt_vc.c
/usr/src/usr.sbin/freebsd-update/freebsd-update.sh
```
Is *freebsd-update*, really so retarded, to not see, that it already is, up to date.

And no! I have no idea to initiate binary update to the *SAME* version, just to shut up *freebsd-update*.


----------



## DutchDaemon (Jan 20, 2010)

Source builds and freebsd-update do not intercommunicate, so you may have to 'humour' freebsd-update this one time to get its internal housekeeping in order. Not because it is retarded, but because it does not recognise what _you_ did before it came onto the scene, i.e. build your own OS and kernel from sources. What is the fourth field in /var/db/freebsd-update/tag?


----------



## Seeker (Jan 20, 2010)

Fourth field is: *2*

```
freebsd-update|i386|8.0-RELEASE|[color="Red"]2[/color]|?|?
```

It touches OS, into very sensitive spot, so yes, I think it must be able to determine, OS's current status/state, for tool of *this level*.


----------



## DutchDaemon (Jan 20, 2010)

Note: freebsd-update is supposed to run from a pristine disk installation forward. It is based on 'how FreeBSD leaves the factory'. You intervened by building your own OS, so it wants to revert to its 'factory settings' again. In a consumer electronics parallel: you broke the seal and your warranty is voided. Restore the original parts  Or keep tracking RELENG_8_0, of course. Don't mix and match, *unless* you build from the sources as updated by the freebsd-update 'Components' settings in freebsd-update.conf(5).


----------



## Seeker (Jan 21, 2010)

In my case...
It was impossible, to go from STABLE to RELEASE using freebsd-update.
So I had to manually build world+kernel.

So there *is* a difference in files installed, when I build from source and when I build with freebsd-update?!
Even *both* are 8.0-RELEASE?!


----------



## richardpl (Jan 21, 2010)

There is difference because people are different ... so do binaries compiled by different people in different environments differs...


----------



## gilinko (Jan 21, 2010)

Seeker said:
			
		

> In my case...
> It was impossible, to go from STABLE to RELEASE using freebsd-update.
> So I had to manually build world+kernel.
> 
> ...



You don't build with freebsd-update. Think of it as a advanced cp program(as it does binary updates), and if you have built the sytem yourself the dates of the files and possibly some of the checksums are wrong. That is what freebsd-update is telling you, and that *if* you want to use the tool this is what has to be done for it to function. If your system already is at the latest patch level, you have to remeber that. A tool is just a tool, which is what freebsd-update is. So if you want the binary upgrade/update path for the base system let freebsd-update reset your system to "factory default", and then move on from there. It doesn't take many minutes.


----------



## Seeker (Jan 21, 2010)

Yes, but I didn't used ANY custom compile options.
Kernel is GENERIC and all userland is built as default.
So it should be in a same state, to that achieved by freebsd-update tool.
No?


----------



## gilinko (Jan 21, 2010)

Checksums will still differ(I think), and that is what it is used to compare the current state to the wanted state. And if not built with the EXACT same enviroment as the binary, it will differ. So you need to replicate that environment to the letter for there not to be any difference.


----------



## Beastie (Jan 21, 2010)

IOW, use `# freebsd-update fetch` / `# freebsd-update install` once and it'll successfully update to p2, and subsequent runs will say something like:

```
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 8.0-RELEASE from update4.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 8.0-RELEASE-p2.
```
until p3.


Also, I wouldn't use cron or at least not schedule freebsd-update to run twice every day. It's not like there are fixes everyday or even every week.


----------



## gilinko (Jan 21, 2010)

Beastie said:
			
		

> Also, I wouldn't use cron or at least not schedule freebsd-update to run twice every day. It's not like there are fixes everyday or even every week.



The cron  opinion is in my the easiest way of keeping track of base updates. From the man page:

```
cron        Sleep a random amount of time between 1 and 3600 seconds,
                  then download updates as if the fetch command was used.  If
                  updates are downloaded, an email will be sent (to root or a
                  different address if specified via the -t option or in the
                  configuration file).  As the name suggests, this command is
                  designed for running from cron(8); the random delay serves
                  to minimize the probability that a large number of machines
                  will simultaneously attempt to fetch updates.
```


If no updates are found, it does nothing. If updates are found(and subsequently downloaded) it sends an email to the root user and tells them that there are updates available and that the need to be installed. And it keeps on sending the emails until the system is updated, so if you miss one you will be reminded the next day 

However I do think that once a days is quite enough.


----------



## Beastie (Jan 21, 2010)

I know about that all as I've read this man page more than once in the past.

My point is: having just a few patch levels, months apart, in an entire branch life cycle spanning years, it's a waste of resources to schedule an update everyday.
By frequently browsing freebsd.org - e.g. errata notices, security advisories, etc. (as any of us should), I'm aware of any security/bug fixes right away and I don't schedule updates but run them manually.


----------



## Seeker (Jan 22, 2010)

If you see my cron entry, from start of thread, then you see that I run it once in 24 hrs 

Thx guys!


----------



## Beastie (Jan 22, 2010)

Seeker said:
			
		

> If you see my cron entry, from start of thread, then you see that I run it once in 24 hrs


Someone correct me if I'm wrong. Doesn't

```
55      */12       *       *       *       root    freebsd-update cron
```
tell cron to run the command at minute 55 every 12 hours, i.e. twice everyday?


----------



## gilinko (Jan 22, 2010)

Yep, your correct Beastie. It will be executed twice a day. 

The recommended time is to run it at 03:00 if the computer is set to your local timezone and not UTC. That way the load on the update servers are spread out across the 24 timezones. Which is also found in the man page


----------



## Seeker (Jan 23, 2010)

Yea, yea, you are right guys. 
It is twice a day.

I forgot I've edited hour, from *12* to **/12*, in order to update 2 times, a day, instead of once.

I am not in a UTC zone, and all my periodic _stuff_ is being run at 03:00 AM


----------



## ohauer (Jan 31, 2010)

Seeker said:
			
		

> It was impossible, to go from STABLE to RELEASE using freebsd-update.
> So I had to manually build world+kernel.



To have a original kernel you could can extract the kernel from the ISO or from ftp and keep it as GENERIC in /boot.

The following command extracts the generic kernel from the ISO.

`# cd $PlaceWhereTheISOIsMounted/8.0-RELEASE/kernels/
# ./install.sh GENERIC`

Now freebsd-update will update this kernel and leave your own kernel untouched.
with the following command you are able to *boot from this kernel one time*.

```
# nextboot -k GENERIC
```
If everything went well you can copy GENERIC to kernel.

This is my preferred way to update my FreeBSD machines.


----------



## Seeker (Jan 31, 2010)

Thank you!

After 2 weeks, I accidentally csup-ed src tree and now freebsd-update started to complain again.
I had to once again run freebsd-update install to shut it up.
JUST csup-ed src tree


----------



## ohauer (Jan 31, 2010)

> After 2 weeks, I accidentally csup-ed src tree and now freebsd-update started to complain again.
> I had to once again run freebsd-update install to shut it up.



This is expected since the patches build by the secteam have a different CVS-ID.

example diff on my 7.2 machine

```
--- /usr/RELENG_7_2/src/usr.sbin/freebsd-update/freebsd-update.sh       2009-12-05 11:27:45.000000000 +0100
+++ /usr/src/usr.sbin/freebsd-update/freebsd-update.sh  2009-12-05 14:12:11.000000000 +0100
@@ -25,7 +25,7 @@
 # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 # POSSIBILITY OF SUCH DAMAGE.

-# $FreeBSD: src/usr.sbin/freebsd-update/freebsd-update.sh,v 1.8.2.4.4.2 2009/12/03 09:18:40 cperciva Exp $
+# $FreeBSD: src/usr.sbin/freebsd-update/freebsd-update.sh,v 1.8.2.4.4.1 2009/04/15 03:14:26 kensmith Exp $
```

Since I have more than one src-tree on my machine I use this in my csup file

```
default prefix=/usr/RELENG_8_0
```


----------



## Seeker (Feb 1, 2010)

I see, so to finalize...

Should I use _binary update mechanism_: freebsd-update ... IF I use CPUTYPE or CFLAGS in make.conf.

As those binaries, have been compiled somewhere else, with some other C settings


----------



## gilinko (Feb 1, 2010)

Seeker said:
			
		

> I see, so to finalize...
> 
> Should I use _binary update mechanism_: freebsd-update ... IF I use CPUTYPE or CFLAGS in make.conf.
> 
> As those binaries, have been compiled somewhere else, with some other C settings



If you use freebsd-update neither your kernel or base system will be optimized using your flags, only userland(eg ports). As you noted, they are build somewhere else and "optimized" to fit as many systems as possible. Hence the name _GENERIC_.

If you want your kernel and base system also be optimized with your flags, you have to build your own kernel+world and you can *not* use freebsd-update.


----------



## Seeker (Feb 1, 2010)

Just as I thought


----------

