New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cloudinit `.link` unit not working #174

Closed
dminkovsky opened this Issue Oct 25, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@dminkovsky
Copy link

dminkovsky commented Oct 25, 2014

Talked about this with @crawford yesterday on IRC, couldn't figure out why the following unit wasn't working:

#cloud-config

hostname: core1
coreos:
    units:
    - name: 99-net0.link
      runtime: true
      content: |
        [Match]
        Driver=pcnet32

        [Link]
        Name=net0
        MACAddress=00:0c:29:e1:49:41

The system boots without this link unit in effect:

core@core1 ~ $ ip link show   
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 1000
    link/ether 00:0c:29:e1:49:43 brd ff:ff:ff:ff:ff:ff

I tried naming it 00-net0.link, too, which had no effect. The hostname directive, is, however, respected.

Complete journalctl -b output can be found at this gist, which also contains output for udevadm test for the network device.

Here's some summary info:

  • The .link file is placed:
core@core1 ~ $ journalctl -b | grep net0
Oct 25 16:35:24 core1 coreos-cloudinit[628]: 2014/10/25 16:35:24 Writing unit 99-net0.link to filesystem at path /run/systemd/network/99-net0.link
Oct 25 16:35:24 core1 coreos-cloudinit[628]: 2014/10/25 16:35:24 Placed unit 99-net0.link at /run/systemd/network/99-net0.link
Oct 25 16:35:24 core1 coreos-cloudinit[628]: 2014/10/25 16:35:24 Ensuring runtime unit file 99-net0.link is unmasked
Oct 25 16:35:24 core1 coreos-cloudinit[628]: 2014/10/25 16:35:24 /run/systemd/network/99-net0.link is not null or empty, refusing to unmask

Despite this, reboots don't help. I tried setting runtime to false, but that had no effect beyond the placement of the .link file in /run or /etc.

  • According to udevadm test output, udev is aware of the 99-net0.link:
timestamp of '/run/systemd/network' changed
Parsed configuration file /run/systemd/network/99-net0.link
Parsed configuration file /usr/lib64/systemd/network/99-default.link
Created link configuration context.
  • The driver is, indeed, pcnet32:
core@core1 ~ $ dmesg | grep pcnet
[    2.563809] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
[    2.784013] pcnet32: PCnet/PCI II 79C970A at 0x1400, 00:0c:29:e1:49:43 assigned IRQ 18
[    2.787477] pcnet32: eth0: registered as PCnet/PCI II 79C970A
[    2.789931] pcnet32: 1 cards_found
[    6.385323] pcnet32 0000:00:11.0 enp0s17: link up
@bassam

This comment has been minimized.

Copy link
Member

bassam commented Feb 17, 2015

I'm seeing this too on 593.0.0. A workaround is to run:

sudo systemctl restart systemd-udev-trigger.service

to pickup the link files. I wish there was a way to run cloud-init earlier in the boot process, even before network.target or local-fs.target. This would let us customize networking and filesystems early.

@crawford

This comment has been minimized.

Copy link
Member

crawford commented Feb 27, 2015

@bassamtabbara this capability is on the roadmap, so we hear you. :)

@bassam

This comment has been minimized.

Copy link
Member

bassam commented Feb 27, 2015

@crawford thanks. As it stands I'm building my own CoreOS to workaround this.

@crawford

This comment has been minimized.

Copy link
Member

crawford commented Oct 20, 2015

Ignition supports this use-case nicely now. Give that a shot instead of coreos-cloudinit.

@crawford crawford closed this Oct 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment