Is freebsd-update, really so retarded

Seeker

Seeker

Last time I've built OS from /usr/src, so now is:
Code: 
# 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
Code: 
55      */12       *       *       *       root    freebsd-update cron
Each day throws in my mail:
Code: 
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.
 
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?
 
Fourth field is: 2
Code: 
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.
 
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).
 
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?!
 
There is difference because people are different ... so do binaries compiled by different people in different environments differs...
 
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.

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?!
Click to expand...

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.
 
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?
 
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.
 
IOW, use # freebsd-update fetch / # freebsd-update install once and it'll successfully update to p2, and subsequent runs will say something like:
Code: 
# 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.
 
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.
Click to expand...

The cron opinion is in my the easiest way of keeping track of base updates. From the man page:
Code: 
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.
 
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.
 
If you see my cron entry, from start of thread, then you see that I run it once in 24 hrs ;)

Thx guys! ;)
 
Seeker said:
If you see my cron entry, from start of thread, then you see that I run it once in 24 hrs
Click to expand...
Someone correct me if I'm wrong. Doesn't
Code: 
55      */12       *       *       *       root    freebsd-update cron
tell cron to run the command at minute 55 every 12 hours, i.e. twice everyday?
 
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 ;)
 
Yea, yea, you are right guys. :p
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
 
Seeker said:
It was impossible, to go from STABLE to RELEASE using freebsd-update.
So I had to manually build world+kernel.
Click to expand...

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.
Code: 
# nextboot -k GENERIC
If everything went well you can copy GENERIC to kernel.

This is my preferred way to update my FreeBSD machines.
 
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
 
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.
Click to expand...

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

example diff on my 7.2 machine
Code: 
--- /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
Code: 
default prefix=/usr/RELENG_8_0
 
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
 
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
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top