13.0-p4 losing static IP during boot

Father Grigori

Father Grigori

Hello all.

I am having an issue with both my desktop and notebook not keeping their statically assigned (/etc/rc.conf)
network interface cards IP addresses.

If I recall correctly, this started after doing update to 13.0-RELEASE-p4 (freebsd-update fetch install).

AFAIK, both machines used to work perfectly with the same configurations before that.

Here´s my notebook /etc/rc.conf interface config as example:

Code: 
ifconfig_alc0="inet 192.168.0.113 netmask 255.255.255.0"

The boot process goes fine, with messages showing alc0 getting the IP, but then it shows:

Code: 
kenv: unable to get rc_system
Stopping network: alc0.

The same happens on my desktop computer, no matter if using bge0 or re0, etc. network cards.

If I manually apply:
Code: 
service netif restart

it assigns the IPs correctly, but after some traffic, the interfaces lose their static IPs again.
By the way, if getting IP via DHCP, it works fine.

Am I doing something wrong or did I forget to apply something?
Any help is appreciated. Thank you.
 
Father Grigori said:
Code: 
kenv: unable to get rc_system
Click to expand...
I think you might have a typo or something wrong in /etc/rc.conf. Maybe a missing quote somewhere?

Static IPs work just fine on 13.0. I have a whole bunch of 13.0 systems with static addresses.
 
SirDice said:
I think you might have a typo or something wrong in /etc/rc.conf. Maybe a missing quote somewhere?

Static IPs work just fine on 13.0. I have a whole bunch of 13.0 systems with static addresses.
Click to expand...
Hello SirDice.

The syntax of /etc/rc.conf is OK on both machines. I checked that.

When manually executing
Code: 
service netif restart
or
Code: 
/etc/netstart
the interfaces come up with correct static IPs, although after some traffic they reset and lose IP again.

I really don't know what's wrong, but the problem seems to be something during boot time.
 
covacat said:
have you used ghostbsd before on the same boxes ?
it seems it set rc_system kenv var to openrc
Click to expand...
Hello covacat.

No, I have never used GhostBSD on these boxes.

It is the first time I caught this
Code: 
kenv: unable to get rc_system
error.

And both PCs are plain FreeBSD.

Code: 
uname -opr
FreeBSD 13.0-RELEASE-p4 amd64

I am clueless...
 
Are you booting with EFI or CSM? You can check by looking at sysctl machdep.bootmethod. Maybe it's something that's been set in efivar(8).
 
Father Grigori said:
Oh, both lines were "leftovers" from some tests I did in the past.
I removed them now, whithout any effect.
Click to expand...
I didn't expect them to interfere but it's best to rule it out. Might want to go through your rc.conf the same way, if it's not needed/required remove it. That'll narrow down the possible places where things could go wrong.
 
did you reboot after adding rc_system="bsdrc" ?
Code: 
kern.geom.label.gptid.enable="0"
ipfw_load="YES"
zfs_load="YES"
rc_system="bsdrc"
$ kenv rc_system
bsdrc
 
SirDice said:
I didn't expect them to interfere but it's best to rule it out. Might want to go through your rc.conf the same way, if it's not needed/required remove it. That'll narrow down the possible places where things could go wrong.
Click to expand...
I´m going to review the whole file... just a moment.
covacat said:
did you reboot after adding rc_system="bsdrc" ?
Code: 
kern.geom.label.gptid.enable="0"
ipfw_load="YES"
zfs_load="YES"
rc_system="bsdrc"
$ kenv rc_system
bsdrc
Click to expand...
Yes, I rebooted the system after adding that line.
 
is the kenv msg showing up during boot, before the login prompt is shown ?
you can hack /etc/rc like this
add
set -x at the top before the stty line
...
set -x
stty status '^T' 2> /dev/null
....
enable console.log in /etc/syslog.conf
....
# uncomment this to log all writes to /dev/console to /var/log/console.log
# touch /var/log/console.log and chmod it to mode 600 before it will work
console.info /var/log/console.log
.....

remove the rc_system line from loader.conf
reboot
grep the rc_system line in console.log
 
SirDice said:
I didn't expect them to interfere but it's best to rule it out. Might want to go through your rc.conf the same way, if it's not needed/required remove it. That'll narrow down the possible places where things could go wrong.
Click to expand...
Here it is in entirity:

Code: 
kld_list="i915kms"
hostname="note01"
keymap="br.noacc.kbd"
dbus_enable="YES"
devd_enable="YES"

ifconfig_alc0="inet 192.168.0.111 netmask 255.255.255.0"

wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"
sshd_enable="YES"
linux_enable="YES"
ntpdate_enable="YES"
powerd_enable="YES"
inetd_enable="YES"
inetd_flags="-Ww"
sshd_enable="YES"
dumpdev="NO"
dsbmd_enable="YES"
#slim_enable="YES"
moused_enable="YES"
smartd_enable="YES"
cupsd_enable="YES"
webcamd_enable="YES"
vboxnet_enable="YES"
vboxguest_enable="YES"
vboxservice_enable="YES"
devfs_system_ruleset="system"
 
If everything else fails, you could attempt a freebsd-update IDS to check for unexpected changes or even reinstall your rc scripts by doing a make installworld. If you want to avoid compiling world, you could also just download the txz files and extract them over your existing base files.

Obviously, the latter is the nuclear option and not necessarily the best choice since it won't help you find the root cause for your issue.
 
Father Grigori said:
Code: 
devd_enable="YES"
Click to expand...
One of the few services that are enabled by default. Don't need to set this.

Code: 
inetd_enable="YES"
inetd_flags="-Ww"
Who uses inetd(8) in this day and age?

Code: 
dsbmd_enable="YES"
I don't recognize that one. What does it do?

Code: 
vboxnet_enable="YES"
vboxguest_enable="YES"
vboxservice_enable="YES"
It's a guest and a host?
 
You must log in or register to reply here.
Back
Top