Add support for configuring VLAN interfaces in the initrd

Bug #1382054 reported by Jorge Niedbalski
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Fix Released
High
Dimitri John Ledkov

Bug Description

It would be helpful to be able to create VLAN network interfaces in initrd images provided
by Ubuntu, based on kernel command line parameters. (i.e. VLAN=eth0.100, )

Some use cases for this feature addition are MAAS users trying to boot machines
using a specific VLAN interface.

On a specific case we have 2 physical network interfaces, one is plugged into a specific VLAN interface,
Since we can specify the network interface on BIOS, the initial PXE boot occurs, but
then the installation fails when using the fast-path installer because the specific VLAN is not configured on the ram disk.

While we can use the other network interface because is a trunk interface that allows us to use
several VLANs, this is not supported on all the network architectures and some security limitations doesn't allows this method.

Reference Redhat implementation can be found here:

- http://marc.info/?l=initramfs&m=133767307516594

Reference Suse implementation can be found here:

- https://gitorious.org/opensuse/agrafs-mkinitrd/commit/6124f87f3132b6369c0335c319832619a49d0bf7

The command line syntax for this could be something like, similar to Redhat implementation

        vlan=<vlanname>:<phydevice>

For an example:

        vlan=eth0.2:eth0

Related branches

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
description: updated
tags: added: cts
Revision history for this message
Kick In (kick-d) wrote :

Hi,

I can confirm that it is often the case, and that it previously causes me headaches at installing debian/ubuntu distro via pxe on vlan tagged networks . Those where use of native vlan is reserved/forbiddenand where you must pass many mutualised switches.

tags: added: sts
tags: added: canonical-bootstack
Revision history for this message
stcz (stcz) wrote :

I wrote a hook to add a VLAN-Device to the initramfs, you can add in your /etc/initramfs-tools/initramfs.conf the following line:
VLAN=<Master Device>:<vlan id>
you can also add multiple devices:
VLAN="<Master Device>:<vlan id> <Master Device>:<vlan id>"
the hooks ans script are in the attachment.
I use it to unlock a encrypted root partition over a vlan hinterface.
Have fun.. :)

Revision history for this message
Martin (g-martin-2) wrote :

@SKOM: Thanks for providing the hook. Saved me a lot of time.
It may be worth mentioning that the new VLAN interfaces have to be shut down before booting by a line like this in initramfs.conf:
DROPBEAR_SHUTDOWN="eth0 eth0.1"

I wonder, why this configuration is not available by default in stock Debian: Neither encrypted root nor VLAN is very unusual in a server configuration.

Cheers, Martin

Changed in initramfs-tools (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
importance: Undecided → High
milestone: none → ubuntu-19.06
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I will go with dracut syntax here:
vlan=<vlanname>:<phydevice>

And will only support the .id naming, e.g.:

vlan=eth0.1:eth0

As i'd think dracut syntax is more popular, despite being a bit backwards parsing the pairs.

With added support, that phydevice is activated as well on s390x.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@Martin

Encrypted root is available in Ubuntu.

Changed in initramfs-tools (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.133ubuntu9

---------------
initramfs-tools (0.133ubuntu9) eoan; urgency=medium

  * Add support for creating VLANs via vlan=eth0.1:eth0 on kernel
    commandline, and as VLAN= conf.d snippet. LP: #1382054

 -- Dimitri John Ledkov <email address hidden> Fri, 14 Jun 2019 14:46:05 +0100

Changed in initramfs-tools (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.