Security update. Should be 8.1-RELEASE-p2?

DutchDaemon said:
Wouldn't that kernel replacement require a reboot to show the new version in uname, though?
Click to expand...

It would I suppose, although you could always live without that knowing that it won't be updated until you reboot. Or my other suggestion, that freebsd-update will at least tell you that uname will report the wrong version unless you recompile the kernel. Or completely remove the pX version from the uname info, because it isn't compatible with binary OS updates a la freebsd-update?
 
after run freebsd-update fetch and install

[ thread merged in - Mod. ]

I use FreeBSD 8.1-RELEASE with Generic Kernel and AMD64 version , after run these command for fix security risk
Code: 
freebsd-update fetch && freebsd-update install
I reboot system and when I run uname -a I see this
Code: 
FreeBSD mfaridipc.faridi 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
and I see my FreeBSD is Release and I do not see something like
Code: 
p1
or
Code: 
p2
I think I must see something like this
Code: 
FreeBSD mfaridipc.faridi 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Mon Jul 19 02:36:49 UTC 2010     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
Am I right ?
 
DutchDaemon said:
Wouldn't that kernel replacement require a reboot to show the new version in uname, though?
Click to expand...
True.

Not something production server admins are particularly fond of, especially if it's just for getting base system version information right.
Click to expand...
Admins shouldn't be afraid to reboot their systems, uptime is highly overrated. If the service you are providing doesn't allow for downtime (even scheduled downtime) you should be using some fail-over or high availability solution.
 
Let the record show that I am weary of uptimes > 1 month myself. I was talking more about the 'change management mafia' that cannot admin a server without an Excel spreadsheet containing their tickets.
 
DutchDaemon said:
I was talking more about the 'change management mafia' that cannot admin a server without an Excel spreadsheet containing their tickets.
Click to expand...
Ah, the joys of ITIL and a corporation that treats it like it's the only true way of doing things. So you end up spending 3 hours doing all sorts of administrative crap for a change that only takes 10 minutes to implement x(
 
SirDice said:
Ah, the joys of ITIL and a corporation that treats it like it's the only true way of doing things. So you end up spending 3 hours doing all sorts of administrative crap for a change that only takes 10 minutes to implement x(
Click to expand...

Sirdice, ITIL does provide a pre-approved maintenance window. We use it where I work.
 
rbelk said:
Sirdice, ITIL does provide a pre-approved maintenance window. We use it where I work.
Click to expand...

Sure. Unfortunately about 99% of my work doesn't fall into that category ;)
 
OK, now everything is really clear.
Now I have to wait for version 8.2, and using freebsd-update utility to upgrade 8.1 to 8.2.
I have one more question; Often this method fails? I mean the attempt failed updates i.e. from 8.0 to 8.1. I ask because I never did a binary upgrade. I always installed the new release from CD, but never update. This time I want to do update. Is there anybody who failed update using freebsd-update utility?
 
Search the forum, there were some people who did have problems.
But on the other hand, people that don't have problems won't post here ;)
 
I believe you could easily overwrite the variable though by editing /etc/sysctl.conf :(
Another way to do it would be to have the kernel redistributed with the correct patch level on every update. (discussed in #bsdports) Not ideal, however it couldn't be changed in any way.
 
You must log in or register to reply here.
Back
Top