From 14.3 to 15.0

kerogaz

kerogaz

I tried upgrading from 14.3 to 15.0 .It upgraded without errors but encountered errors IPFW and unbound. I did a rollback and switched back to 14.3. Same errors on the first kernel. Now it boots only from the second kernel without errors. How do I make the second kernel the default boot kernel?
 
IPFW work with second kernel/But unbound still doesn't start. Only "service unbound onestart". It says to set unbound yes in rc.conf. But that unbound is already "yes."It seems that the system has stopped reading rc.conf correctly.
 
And IPFW first kernel
..... ipfw_ctl3 invalid option 93v0
............................................. 98v0
 
Dec 2 07:29:17 celebris kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled
Dec 2 07:29:17 celebris kernel: ipfw: ipfw_ctl3 invalid option 99v0
Dec 2 07:29:17 celebris kernel: ipfw: ipfw_ctl3 invalid option 92v0
Dec 2 07:29:17 celebris kernel: ipfw: ipfw_ctl3 invalid option 112v0
Dec 2 07:29:17 celebris kernel: ipfw: ipfw_ctl3 invalid option 98v0
Dec 2 07:29:17 celebris syslogd: last message repeated 2 times
Dec 2 07:29:17 celebris kernel: ipfw: ipfw_ctl3 invalid option 111v0
Dec 2 07:29:17 celebris kernel: ipfw: ipfw_ctl3 invalid option 98v0
Dec 2 07:29:17 celebris syslogd: last message repeated 2 times
 
Did you update your system via traditional freebsd-update or pkg upgrade? Did the conversion via the pkgbasify.lua script go smoothly?
 
USerID said:
Did you update your system via traditional freebsd-update or pkg upgrade? Did the conversion via the pkgbasify.lua script go smoothly?
Click to expand...
Yes .Upgrading was correctly without errors.But after rebooting ipfw not work and unbound
 
From the screenshot that looks like Unbound is trying to attach to a port that it's being denied access to. Is there anything in your ipfw ruleset preventing this, or is unbound trying to grab a low port as non-root?
 
bvdw78 said:
From the screenshot that looks like Unbound is trying to attach to a port that it's being denied access to. Is there anything in your ipfw ruleset preventing this, or is unbound trying to grab a low port as non-root?
Click to expand...
I think that unbound not start because rc.conf is not read correctly.It starts only as onestart
 
bvdw78 said:
From the screenshot that looks like Unbound is trying to attach to a port that it's being denied access to. Is there anything in your ipfw ruleset preventing this, or is unbound trying to grab a low port as non-root?
Click to expand...
I think 553 used unbound port not work because crash of ipfw
 
bvdw78 said:
From the screenshot that looks like Unbound is trying to attach to a port that it's being denied access to. Is there anything in your ipfw ruleset preventing this, or is unbound trying to grab a low port as non-root?
Click to expand...
I think 953 port not work because crash of ipfw
 
Your unbound-control process is failing to bind to 127.0.0.1 port 953. That's what the screenshot tells me. I'm not exactly deep into the workings of unbound, but what happens when you disable the firewall entirely for a single run?

Edit: unbound-control wouldn't even try to start if your rc.conf wasn't being read correctly.
 
bvdw78 said:
Your unbound-control process is failing to bind to 127.0.0.1 port 953. That's what the screenshot tells me. I'm not exactly deep into the workings of unbound, but what happens when you disable the firewall entirely for a single run?

Edit: unbound-control wouldn't even try to start if your rc.conf wasn't being read correctly.
Click to expand...
IPFW rules don't prohibit any ports.DNS resolver (unbound) configured to use port 953 as a "control port"
 
IPFW works just fine in 15.0. Doing the Windows-ism and just nuking the whole thing is not going to bring you any insights here. If you reboot with IPFW competely disabled, you can at least eliminate IPFW as a possible cause. If that doesn't make any difference, look at your unbound configuration. I looked into Unbound itself for a little bit, and there's some stuff going on with certificates and the like for the control interface. If you're not going to remote-control your unbound instance, you could just disable unbound-control altogether and be done with that. I'd also be interested in seeing whether unbound really isn't listening anywhere. What does sockstat -4 tell you, and is there any logging for unbound in /var/log?
 
bvdw78 said:
IPFW works just fine in 15.0. Doing the Windows-ism and just nuking the whole thing is not going to bring you any insights here. If you reboot with IPFW competely disabled, you can at least eliminate IPFW as a possible cause. If that doesn't make any difference, look at your unbound configuration. I looked into Unbound itself for a little bit, and there's some stuff going on with certificates and the like for the control interface. If you're not going to remote-control your unbound instance, you could just disable unbound-control altogether and be done with that. I'd also be interested in seeing whether unbound really isn't listening anywhere. What does sockstat -4 tell you, and is there any logging for unbound in /var/log?
Click to expand...
Now using ssh
sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
pal sshd-sessi 2248 4 tcp4 10.44.55.55:11954 10.44.1.1:32154
root sshd-sessi 2245 4 tcp4 10.44.55.55:11954 10.44.1.1:32154
root sshd 2002 8 tcp4 *:11954 *:*
root rinetd 1964 4 tcp4 xxxxx:40044 *:*
root rinetd 1964 5 tcp4 xxxxx:40055 *:*
root rinetd 1964 6 tcp4 xxxxx:40033 *:*
root rinetd 1964 7 tcp4 xxxxx:40066 *:*
root syslogd 1904 7 udp4 *:514 *:*
 
sudo service unbound onestart
Password:
Obtaining a trust anchor...
Starting unbound.
[1764670749] unbound[2584:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available
[1764670749] unbound[2584:0] warning: so-sndbuf 4194304 was not granted. Got 9216. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value).
[1764670749] unbound[2584:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available
[1764670749] unbound[2584:0] warning: so-sndbuf 4194304 was not granted. Got 9216. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value).



service unbound status
unbound is running as pid 2585.
 
Is your userland in sync with the kernel? You need to run freebsd-update multiple times, first one installs new kernel, second one installs new userland, twice a reboot is needed.

freebsd-version -k
freebsd-version -u

Have you reinstalled all packages after "successful" upgrade? (you need to verify the top question first before continuing)


pkg update -f
pkg upgrade -yf
 
driesm said:
Is your userland in sync with the kernel? You need to run freebsd-update multiple times, first one installs new kernel, second one installs new userland, twice a reboot is needed.

freebsd-version -k
freebsd-version -u

Have you reinstalled all packages after "successful" upgrade? (you need to verify the top question first before continuing)


pkg update -f
pkg upgrade -yf
Click to expand...
I've been upgrading from version 12.0 to 14.3 successfully. I've been doing everything correctly before the upgrade: freebsd-update fetch pkg upgrade. It was only when upgrading from 14.3 to 15.0 that this issue arose.
 
This really does look like a botched package upgrade. I'm typing this from 15.0-RELEASE as upgrade from 14.3 just this morning. I just installed unbound from packages (didn't have it running yet) and it starts, runs and resolves just fine for me with the default config that comes with the package. It's version 1.24.1 from the 'latest' packages:


FreeBSD-ports: {
url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
 
bvdw78 said:
This really does look like a botched package upgrade. I'm typing this from 15.0-RELEASE as upgrade from 14.3 just this morning. I just installed unbound from packages (didn't have it running yet) and it starts, runs and resolves just fine for me with the default config that comes with the package. It's version 1.24.1 from the 'latest' packages:


FreeBSD-ports: {
url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
Click to expand...
I think so too. It can be reinstalled. But you can't reinstall a failed IPFW upgrade...
 
bvdw78 said:
Looks like your upgrade is well and truly botched.
Click to expand...
I had the same unsuccessful upgrade on this computer from 13 to 14. I had to reinstall the system from scratch. And now I have to. It seems like today is not Friday the 13th. That's why I keep two identical servers. If one crashes after an update, I switch to the other. :)
 
You must log in or register to reply here.
Back
Top