[SOLVED] dhcpd fails to start after first reboot on fresh install.

[lucifercipher]

dhcpd runs ok at install. Once rebooted, this happens. No changes made on a stock fresh install except IP configurations.

Here is the error:

/status_services.php: The command '/usr/local/sbin/dhcpd -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em1' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.2.8 Copyright 2004-2015 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ no such user: dhcpd If you did not get this software from ftp.isc.org, please get the latest from ftp.isc.org and install that before requesting help. If you did get this software from ftp.isc.org and have not yet read the README, please read it before requesting help. If you intend to request help from the dhcp-bugs at isc.org mailing list, please read the section on the README about submitting bug reports and requests for help. Please do not under any circumstances send requests for help directly to the authors of this software - please send them to the appropriate mailing list as described in the README file. exiting.'

opnsense: /status_services.php: The command '/bin/sh /tmp/dhcpd.sh' returned exit code '1', the output was 'chown: dhcpd: illegal group name' .

The group should exist right? No change was made to the custom image build for dhcpd.


Any ideas? Its NanoBSD image.

[domg]

Hi lucifercipher,

Which version of OPNsense are you using ?

OPNsense 15.7.1 fixed issue with dhcpd startup https://forum.opnsense.org/index.php?topic=915.0

[lucifercipher]

Hi,

I am using my own builds of 15.7.1 but the issue persists in the source for nanobsd images. There is no such error on CDROM installs. And i dont think that it is an old issue that hasn't been fixed. The dhcp issue mentioned in the startup were related to the upgrades from lower to 15.7.1. I found the problem so i have to rebuild the images from source. Since  I am using custom build kernel with custom drivers, i am not hooked up with opnsense updates at all so if anything, i have to do everything at my end. I am just hoping that franco is around to tell me if any other file is linked with the dhcpd config else the image builds will get messed up.

The temp issue is to disable the RD , reboot and re-enable the RD with a slight increase from 40-60 to 64-80Mb respectively. But i would like to get to the bottom of this and make it a permanent fix.

Issue
-----------
group and user is _dhcp not dhcpd

/usr/local/sbin/dhcpd -user _dhcp -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em1

root@amd64builds:~ # /usr/local/sbin/dhcpd -user _dhcp -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em1
Internet Systems Consortium DHCP Server 4.2.8
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
lease 192.168.1.100: no subnet.
lease 192.168.1.100: no subnet.
Wrote 0 leases to leases file.
Multiple interfaces match the same subnet: em0 em1
Multiple interfaces match the same shared network: em0 em1
Listening on BPF/em1/08:00:27:fd:bf:05/192.168.0.0/16
Sending on   BPF/em1/08:00:27:fd:bf:05/192.168.0.0/16
Sending on   Socket/fallback/fallback-net

I am confused about the NanoBSD builds. Its the same compile and build structure for both except the last stage of packaging is different for images. So why is this mismatch of group/ user for just the nano images?? :|


franco , can you show me the git commit for this issue?

EDIT: Commits and history for this issue is below in franco's post.

[franco]

Do not confuse the _dhcp and dhcp user/group. The former is used by the FreeBSD base system, the latter by the FreeBSD ports system.

Quick fix:

Running /usr/local/etc/rc.recover in a running system

Code story:

Nano has a twist in its setup that enables /var and /tmp MFS by default:

https://github.com/opnsense/tools/blob/master/build/nano.sh#L55

Since the FreeBSD package database resides under /var, nano invokes the following on bootup:

https://github.com/opnsense/core/blob/master/src/etc/rc#L126

Unfortunately, the original code added a regeneration step for the group and user files in case of disk crashes, and it does this recovery by default:

https://github.com/opnsense/core/blob/master/src/etc/rc.recover

This recovery step requires access to the package database, which is not there on early boot because there was no reverse symlink to /root/var/db/pkg, where /var/db/pkg really is:

https://github.com/opnsense/core/blob/master/src/etc/rc#L134

Code Explained:

Nano boots up for the first time and the recovery stage is ok creating the dhcp user/group, because /var/db/pkg is in the right place.

After bootup the package database is under /root/var/db/pkg with a symlink from /var/db/pkg so pkg doesn't have to be notified. Note that /var is a memory fs so that the symlink will disappear after reboot...

So after reboot recovery will kick in, but it can't find the database under /var/db/pkg because we moved it to persistent storage. The dhcp user/group is not found, causing problems later.

The fix is to also provide a link when /var is not mounted, which is persistent, but lies under the /var memory fs, see last github link.


I hope that explains it.

[lucifercipher]

Hey mate! Good to see you back in action again.  You did explain everything and i found that rc.recover workaround before touching the forum. But that is awesome to see the commits being pushed before and still going on. I will check the commits i details.

thanks again.