Dracut Findings for cloud-init

Note: This blog post is essentially notes from some investigation into dracut in the context of supporting its network configuration in cloud-init. Its intended audience is other cloud-init developers. If you're looking for an accessible introduction to dracut, this isn't it, I'm afraid!

I'm currently trying to work out how we should proceed with the parsing of dracut network configuration, to have feature parity with Ubuntu/initramfs-tools. This blog post is partly reporting on what I've found, and partly starting a discussion around how we should proceed.


All of this was run on an Oracle Linux 7.6 Virtual Machine running in Oracle Cloud Infrastructure. The version of dracut:

$ yum list installed | grep dracut.x
dracut.x86_64             033-554.0.3.el7        @anaconda/7.6  


This is what dracut produces in /run/initramfs:

$ tree /run/initramfs/
├── log
├── net.00:00:17:02:3f:34.did-setup
├── net.00:00:17:02:3f:34.up
├── net.ens3.dhcpopts
├── net.ens3.did-setup
├── net.ens3.gw
├── net.ens3.lease
├── net.ens3.pid
├── net.ens3.resolv.conf
├── net.ens3.up
├── net.ifaces
├── rwtab
└── state
    ├── etc
    │   ├── resolv.conf
    │   └── sysconfig
    │       └── network-scripts
    │           └── ifcfg-ens3
    └── var
        └── lib
            └── dhclient
                └── dhclient-b560099e-e294-4563-bc2f-fe800312c96b-ens3.lease

Note that 00:00:17:02:3f:34 is the MAC address of ens3. Let's run through the top-level entries quickly:

Now let's consider the state/ entries:

The most interesting file of all of the above (from our perspective) is the sysconfig network configuration that dracut writes out (its full path is /run/initramfs/state/etc/sysconfig/network-scripts/ifcfg-ens3). The full content of the file is:

# Generated by dracut initrd

This file is identical to /etc/sysconfig/network-scripts/ifcfg-ens3 in the booted system (including the first, commented line) except for a bunch of repeated NM_CONTROLLED=no lines.

I believe this contains all the information we would need to emit the appropriate cloud-init configuration (i.e. its name and the fact that it's a DHCP interface).

Path Forward

There are two potential paths forward:

  1. implement generic sysconfig network-scripts parsing (that could be used with net-convert, for example) and use that in cloud-init's dracut initramfs code, or

  2. implement parsing in cloud-init's dracut initramfs code which would handle only the dracut network configuration that we see generated.

I am leaning towards (2), implementing the parsing within the dracut code path. My feeling is that a generic parser is overkill for what we actually need to achieve here. If we keep the code contained within the dracut code path, then we can flesh it just as much as we need for the (probably) fairly simple network configurations that dracut can generate, without it seeming deficient when compared to the other network config parsers.

(Perhaps I'm being too conservative, and we can just implement a limited “generic” parser with the understanding that any future uses of it will have to expand it substantially.)

One important note: if implemented as part of the dracut code, the network-scripts parsing code should be structured so that it can easily be used as the basis for a more generic parser in future.

What do people think?