freebsd-update questions.

M

manilaboy1vic

Aloha world,

I have questions regarding my security update with freebsd-update.

So, originally I was running a custom kernel and having to recompile and install after receiving an update. I decided I want to run GENERIC so I could just update without hassles. My main reason for a custom kernel was to run dummynet. I figured out how to run dummynet and ipfw with /etc/rc.conf and /boot/loader.conf. I copied over GENERIC and ran freebsd-update fetch and freebsd-update install expecting 9.1-RELEASE-p9. But I was still seeing 9.1-RELEASE-p7.

I then ran:
cd /usr/src
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC

I now see the correct version.

Next time there's an update, can I simply run the update commands and expect it to work? My GENERIC is unmodified. I had a suspicion that I needed to install GENERIC to see the correct version.

I have IPFW running like it was before but what bothers me is that /var/run/dmesg.boot shows logging disabled.

/etc/sysctl.conf
Code: 
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=5
/boot/loader.conf
Code: 
net.inet.ip.fw.default_to_accept="1"
net.inet.ip.fw.verbose="1"
net.inet.ip.fw.verbose_limit="5"

/etc/rc.conf
Code: 
firewall_enable="YES"
firewall_logging="YES"
firewall_type="open"
firewall_script="/etc/fire"

I for the life of me cannot get logging enabled in dmesg, but I confirmed my security file is logging.
/var/run/dmesg.boot
Code: 
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to accept, logging disabled
root@yeaguy:/root #

Here is the sysctl -a
Code: 
net.inet.ip.fw.static_count: 37
net.inet.ip.fw.default_to_accept: 1
net.inet.ip.fw.tables_max: 128
net.inet.ip.fw.default_rule: 65535
net.inet.ip.fw.verbose_limit: 5
net.inet.ip.fw.verbose: 1
net.inet.ip.fw.autoinc_step: 100
net.inet.ip.fw.one_pass: 1
net.inet.ip.fw.enable: 1
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_max: 4096
net.inet.ip.fw.dyn_count: 0
net.inet.ip.fw.curr_dyn_buckets: 256
net.inet.ip.fw.dyn_buckets: 256
 
There's one important file which you're not showing us. What do you have configured in /etc/freebsd-update.conf?

I've been here myself and to make sure that freebsd-update didn't clash with my custom kernel I told it to update the base system while ignoring the kernel. So is it possible that you did the same?
 
Hi. Wow, I just ran the update again and it reverted back to 9.1-RELEASE-p7.

Currently I am rebuilding and installing the GENERIC from source, per the handbook.
 
ShelLuser said:
There's one important file which you're not showing us. What do you have configured in /etc/freebsd-update.conf?

I've been here myself and to make sure that freebsd-update didn't clash with my custom kernel I told it to update the base system while ignoring the kernel. So is it possible that you did the same?
Click to expand...

Hi. That file has been unmodified. I can post it if you like.
 
manilaboy1vic said:
That file has been unmodified. I can post it if you like.
Click to expand...
No need for that ;)

Well, in that case my suggestion would be to forget about the source tree and force freebsd-update to do the right thing. So, for example, you mentioned that your current target is FreeBSD 9.1-RELEASE-p9, that could be achieved using: # freebsd-update upgrade -r 9.1-RELEASE-p9 (do check the syntax yourself as well; it's been a while since I used freebsd-update).
 
I just want to run the GENERIC kernel so updating is painless. I cannot get back on the GENERIC kernel for some reason.

Doesn't this indicate a custom kernel: /boot/kernel/kernel?
 
The GENERIC kernel is part of the base system, and that is usually kept up to date using freebsd-update. As such my suggestion above.

My guess is that something went wrong somewhere along the way, also because you mentioned not having touched freebsd-update.conf. So if you kept using both freebsd-update and still applied your own kernel then I can imagine that eventually freebsd-update got lost somewhere.

The best way to solve this, as mentioned before, is telling freebsd-update to bring your system to a specific version. That will update the whole base system, after which you can continue to rely on freebsd-update without the need to build anything yourself.
 
I tried to specify what I wanted, it failed.

If I run the update, it will revert back to p7 after a reboot:

uname -a
Code: 
FreeBSD yeaguy.com 9.1-RELEASE-p9 FreeBSD 9.1-RELEASE-p9 #0: Fri Dec 13 13:22:42 PST 2013     root@yeaguy.com:/usr/obj/usr/src/sys/SIGH  amd64

I'm just going to do it the way I have been over the past. Update if I get an email and compile kernel and reboot.

I can't believe getting back on the GENERIC kernel is this difficult.
 
The latest kernel is 9.1-RELEASE-p7. p8 and p9 were errata notices that did not update the kernel so you can only see p9 via uname -a if you compiled manually. You have nothing to worry about.
 
Yea, I was actually looking at the security notices and did not see p9 anywhere. Then I looked at /boot/GENERIC and see that the dates are old. So if I copy /boot/GENERIC over and then build and install it, I'm on the GENERIC kernel?

I eventually want to do a minor to major update.
 
If you copied over the original GENERIC then you should be good. You may want to runs something like freebsd-update IDS to see that the file hashes match up to what is provided through freebsd-update. If the only files flagged are your local changes in /etc than you are good to go and should have no issues using freebsd-update to jump to 10-RELEASE.
 
junovitch said:
If you copied over the original GENERIC then you should be good. You may want to runs something like freebsd-update IDS to see that the file hashes match up to what is provided through freebsd-update. If the only files flagged are your local changes in /etc than you are good to go and should have no issues using freebsd-update to jump to 10-RELEASE.
Click to expand...

Here is what I'm seeing with freebsd-update IDS

Code: 
/boot/kernel/hpt27xx.ko has SHA256 hash a6c7fc65ee40df96e2f563989923cb763c7f18ece4255efe782832806f4d41b3, but should have SHA256 hash 9b9e343bf73ddf2ceefe609bc7e26fa18abd5ad0b4fa540a30e412b1214eb93e.

Code: 
root@yeaguy:/etc #  freebsd-update fetch && freebsd-update install
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 9.1-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 9.1-RELEASE-p9.
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
root@yeaguy:/etc # uname -a
FreeBSD yeaguy.com 9.1-RELEASE-p7 FreeBSD 9.1-RELEASE-p7 #0: Mon Sep  9 21:34:37 UTC 2013     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
root@yeaguy:/etc #

Bear in mind, previous to running this, I copied over GENERIC and built and installed it and rebooted.

I fixed permissions but am just curious about /boot/kernel/hpt27xx.ko. That seems off.
 
You must log in or register to reply here.
Back
Top