[systemd-devel] DHCP6 client failing when /etc is mounted as overlayfs
Alessandro Tagliapietra
tagliapietra.alessandro at gmail.com
Tue Jun 1 21:32:43 UTC 2021
It seems that while DHCP6 doesn't return any error now and the DUID is
the same after reboot and after network restart by our agent:
DHCP6 Client DUID: DUID-EN/Vendor:0000ab118bf885a2ab7335a00000
it never gets a DHCP6 IP after network restart and the state stays in
"configuring".
Logs only show
DHCPv6 lease lost
IPv6 successfully enabled
and only a reboot fixes the problem. I think I'll probably just move
on and remove ipv6 support from the kernel (as it seems that changing
the default and all values from sysctl doesn't apply to networkd).
Thank you for helping
--
Alessandro Tagliapietra
On Tue, Jun 1, 2021 at 1:55 PM Alessandro Tagliapietra
<tagliapietra.alessandro at gmail.com> wrote:
>
> On Tue, Jun 1, 2021 at 1:09 PM Mantas Mikulėnas <grawity at gmail.com> wrote:
> >
> > If it's not writable at that point, systemd will *mount* a temporary writable file on top of it, and will generate an ID that's temporary for that boot.
>
> I've ended up copying /etc/machine-id onto our overlay etc directory
> before mounting the actual overlay, this way after mounting /etc the
> machine also persists across reboots.
> I think systemd still regenerates the machine-id on boot because the
> overlay isn't mounted yet, so a more long term solution would be to
> use an initramfs to mount the overlay before system starts (unless
> there are other ways to do so).
>
> >
> > It's possible that your overlay goes on top of that and provides its own empty machine-id file again...
> >
> >> Make our overlay mount unit depend on whatever service is generating machine-id and make sure our mount happens before the generation of machine-id?
> >
> >
> > That might work, and would allow the machine-id and thus the DUID to be persistent.
> >
> > As an alternative you could tell networkd to use DUID-LLT (?), which doesn't need the machine-id and just uses the MAC address, but there may be other things which use the machine-id anyway...
> >
> >>
> >> Thanks
> >>
> >> --
> >> Alessandro Tagliapietra
> >>
> >>
> >> On Tue, Jun 1, 2021 at 12:13 AM Mantas Mikulėnas <grawity at gmail.com> wrote:
> >>>
> >>> On Tue, Jun 1, 2021 at 10:07 AM Alessandro Tagliapietra <tagliapietra.alessandro at gmail.com> wrote:
> >>>>
> >>>> Hello everyone,
> >>>>
> >>>> I'm using yocto to create a custom linux image for a raspberry pi.
> >>>> We have an "agent" that writes /etc/systemd/network/20-eth.network when the final user wants to have a static IP address and we remove the file when they switch back to DHCP.
> >>>>
> >>>> After creating/deleting the file above we run `networkctl reload && networkctl reconfigure eth0`.
> >>>> We mount the overlayfs with a custom .mount unit.
> >>>>
> >>>> We've noticed that DHCP works fine if systemd-networkd starts before we mount the overlayfs but it doesn't if systemd-networkd is restarted/reconfigured after the folder is mounted or started after the overlay .mount unit.
> >>>>
> >>>> Every interface DHCP fails with:
> >>>>
> >>>> DHCPv6 CLIENT: Failed to set DUID-EN: No medium found
> >>>> eth0: DHCP6 CLIENT: Failed to set DUID: No medium found
> >>>
> >>>
> >>> My guess is that it's related to /etc/machine-id somehow becoming inaccessible, since networkd's DUID-EN (DUIDType=vendor) is based on that.
> >>>
> >>> --
> >>> Mantas Mikulėnas
More information about the systemd-devel
mailing list