freebsd-update - p3 - strange

xer

xer

Hello
I have a 7.1 installed version with GENERIC kernel config.
I did updated to 7.2 with freebsd-update and works so well.

Now, i made:
[cmd=]freebsd-update fetch[/cmd]
then
[cmd=]freebsd-update install[/cmd]
then
[cmd=]reboot[/cmd]

And the box would be a 7.2-RELEASE-p3
but i just see:
Code: 
[labs]:/root# uname -a
FreeBSD labs.xernet.net 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:57:44 UTC 2009     [email]root@i386-builder.daemonology.net[/email]:/usr/obj/usr/src/sys/GENERIC  i386


Why? Why i see p2 instead p3?

Anyway, today i did:
Code: 
cd /usr/src
make update
cd src/sys/i386/conf
config GENERIC
cd ../compile/GENERIC
make depend
make
make install
reboot
and then:
Code: 
[labs]:/root# uname -a
FreeBSD labs.xernet.net 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #0: Fri Aug 28 23:46:04 CEST 2009     [email]xer@labs.xernet.net[/email]

So, p3 will be installed just with regular compile mode, but, again i did:
Code: 
[labs]:/root# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 7.2-RELEASE from update5.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files will be updated as part of updating to 7.2-RELEASE-p3:
/boot/kernel/if_bce.ko
/boot/kernel/if_bce.ko.symbols
/boot/kernel/if_fxp.ko
/boot/kernel/if_fxp.ko.symbols
/boot/kernel/kernel
/boot/kernel/kernel.symbols
/usr/src/lib/libc/stdlib/malloc.c
/usr/src/sys/conf/newvers.sh
/usr/src/sys/dev/bce/if_bce.c
/usr/src/sys/dev/fxp/if_fxp.c
/usr/src/sys/kern/sys_pipe.c
/usr/src/sys/netinet6/in6.c
[labs]:/root# freebsd-update install
Installing updates... done.
[labs]:/root# reboot

after reboot...
Code: 
[labs]:/root# uname -a
FreeBSD labs.xernet.net 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:57:44 UTC 2009     [email]root@i386-builder.daemonology.net[/email]:/usr/obj/usr/src/sys/GENERIC  i386

So... at least, whats going on with freebsd-update ?
Any help please?
 
I have a similar question. Why doesn't the kernel version track the freebsd-update version? I did freebsd-update fetch, freebsd-update install, reboot, freebsd-update install again.

Code: 
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 7.2-RELEASE from update2.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 7.2-RELEASE-p6.

# uname -a
FreeBSD hostname 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct  2 12:21:39 UTC 2009     [email]root@i386-builder.daemonology.net[/email]:/usr/obj/usr/src/sys/GENERIC  i386

# sysctl kern.osrelease kern.osrevision kern.version
kern.osrelease: 7.2-RELEASE-p4
kern.osrevision: 199506
kern.version: FreeBSD 7.2-RELEASE-p4 #0: Fri Oct  2 12:21:39 UTC 2009
    [email]root@i386-builder.daemonology.net[/email]:/usr/obj/usr/src/sys/GENERIC
 
I guess that an update to userland (raising its patch level) doesn't necessarily mean an update to, or even a rebuild of, the kernel. So its patch level will remain at its current value.
 
This is, as far as I can tell, a correct guess.
Unfortunately, we currently don't have a way to tell at which patch level the system currently is, if the SA didn't touch the kernel (which is a common case).

We had a small talk about this at the last Developers' summit at EuroBSDCon in Cambridge and there was an idea to create some kind of userland tool to take care of this. However, I don't think there was any progress in this area so far :-(.

If you really want to see the patch level in uname's output, you have to upgrade from source and rebuild/reinstall the kernel (to re-read the newvers.sh) even if the SA didn't correct anything in the kernel and reboot.
 
I think the only place where a userland patch level is stored is in /var/db/freebsd-update/tag (field # 3 or 4 IIRC). I think I saw a PR some months ago about that tag not being updated when a rollback is performed.
 
Any freebsd-update will store the most recently seen tag there. Kernel or userland. That doesn't necessarily mean that it is the running updates, though. A mere fetch, will update the tag.
 
I don't know if that is the proper way to deal with it though... It is client side, so when a rollback is performed, it should uninstall the updates. However the client has still seen the new updates, and should have the latest tag and files already downloaded, and still have the latest tag INDEX.

If you do a rollback, you could at that point remove all files beneath the update directory.

I don't know if a rollback, rolls back the tag INDEX. IIRC it doesn't. I believe this is the proper behavior, though.
 
You must log in or register to reply here.
Back
Top