How to Disable Network Interfaces from Loading at Boot Without NetworkManager on revWhiteShadow’s Blog

Introduction: Tackling Unnecessary Network Interface Initialization at Boot

At revWhiteShadow, we understand the frustration of encountering delays during system startup, particularly when caused by the automatic attempt to initialize unused network interfaces. This issue is more prevalent than one might think, especially on machines equipped with multiple Ethernet ports or virtual network interfaces that are not consistently active. This comprehensive guide addresses this specific problem, outlining several solutions to prevent inactive network interfaces from slowing down your boot process without relying on NetworkManager. We delve into configuration options, kernel parameters, and alternative approaches, empowering you to optimize your system’s boot time while maintaining control over your network settings.

Understanding the Problem: The Root Cause of Boot Delays

The observed delays during boot stem from the system attempting to bring up all configured network interfaces, regardless of whether they are physically connected or intended for immediate use. The dmesg output provides valuable insights, highlighting the “link is not ready” messages associated with the inactive interfaces (eth1, eth2, eth3). This indicates that the system is waiting for a link to be established before proceeding, which can significantly prolong the boot sequence. The root of this behavior lies in the default configuration that instructs the system to initialize all defined network interfaces at startup. We need to modify this behavior to skip unnecessary initialization steps. This article will help you achieve that.

Solution 1: Modifying Interface Configuration Files for Selective Boot

The most straightforward approach involves modifying the configuration files for each network interface to prevent them from being activated at boot. This method offers granular control over which interfaces are brought up, ensuring that only the necessary ones are initialized.

Locating the Interface Configuration Files

The location of these files typically resides within the /etc/sysconfig/network-scripts/ directory on Red Hat-based systems like CentOS, Fedora, and RHEL. For Debian-based distributions, these files are usually located under /etc/network/interfaces. However, our primary focus will be on the former due to the prevalent use of systemd and the ifcfg style configuration files.

Editing the Interface Configuration Files

For each network interface you wish to disable at boot (e.g., eth1, eth2, eth3), locate its corresponding configuration file (e.g., ifcfg-eth1, ifcfg-eth2, ifcfg-eth3) within /etc/sysconfig/network-scripts/. Open each file using a text editor with root privileges (e.g., sudo vim /etc/sysconfig/network-scripts/ifcfg-eth1).

Within each configuration file, locate the line that defines the ONBOOT parameter. This parameter determines whether the interface is automatically activated during boot. By default, it is usually set to ONBOOT=yes. To disable the interface at boot, change this line to ONBOOT=no.

ONBOOT=no

Save the changes to each configuration file. This ensures that the specified interfaces will no longer be automatically activated during the boot process.

Verifying the Changes

After modifying the configuration files, it is crucial to verify that the changes have been applied correctly. Reboot your system and observe the boot process. The delays previously caused by the inactive interfaces should be significantly reduced, if not eliminated entirely. You can also use the ip addr show command to confirm that the disabled interfaces are not active after the reboot.

Considerations for Dynamic IP Addresses (DHCP)

If any of the disabled interfaces are configured to obtain an IP address dynamically using DHCP, you may need to adjust the DHCP client configuration to prevent it from attempting to acquire an address for those interfaces. This is particularly important if the DHCP client is configured to start automatically at boot. The configuration files for the DHCP client are normally located under /etc/dhcp/dhclient.conf, consult your distribution’s documentation.

Solution 2: Utilizing udev Rules to Disable Interfaces

udev is the device manager in Linux that dynamically creates and manages device nodes in the /dev directory. It responds to hardware events, allowing you to define rules to automatically configure devices when they are plugged in or detected by the system. We can leverage udev rules to disable network interfaces based on their MAC addresses or other attributes.

Creating udev Rules

Create a new udev rule file in the /etc/udev/rules.d/ directory. The filename should end with .rules and typically starts with a number to indicate the order in which the rules are processed (e.g., 99-disable-unused-nics.rules). Use a text editor with root privileges to create and edit the file (e.g., sudo vim /etc/udev/rules.d/99-disable-unused-nics.rules).

Defining the Rules

Within the udev rule file, define rules to disable the specific network interfaces based on their MAC addresses. The following example demonstrates how to disable an interface with a specific MAC address:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:22:33:44:55", RUN+="/sbin/ip link set dev %k down"

Replace "00:11:22:33:44:55" with the actual MAC address of the interface you want to disable. The %k represents the interface name (e.g., eth1). You can find the MAC address of each interface using the ip link show command. Repeat this line, modifying the MAC address for each of the interfaces you wish to disable at boot.

Applying the udev Rules

After creating the udev rule file, you need to apply the changes. You can do this by running the following command:

sudo udevadm control --reload-rules
sudo udevadm trigger

This reloads the udev rules and triggers the processing of existing devices, including the network interfaces.

Testing the Rules

Reboot your system and verify that the specified network interfaces are disabled. Use the ip link show command to confirm that the interfaces are in the “DOWN” state.

Advantages and Considerations

udev rules provide a flexible and persistent way to manage network interfaces based on their attributes. This approach is particularly useful when dealing with dynamically assigned interface names or when you need to disable interfaces based on criteria other than their configuration files. However, it is essential to ensure that the MAC addresses used in the rules are accurate and that the rules are correctly configured to avoid unintended consequences.

Solution 3: Masking Systemd Services for Network Interfaces

Systemd is the system and service manager used by most modern Linux distributions. Each network interface managed by systemd has an associated service file (e.g., networking.service, network-online.target). By masking these service files, we can prevent systemd from attempting to start the corresponding interfaces at boot.

Identifying the Service Files

The service files responsible for managing network interfaces are typically located in the /lib/systemd/system/ directory. The naming convention for these files may vary depending on the distribution and the network configuration method used. Look for files that include the interface name (e.g., network@eth1.service).

Masking the Service Files

To mask a service file, use the systemctl mask command with root privileges. For example, to mask the service file for eth1, run the following command:

sudo systemctl mask network@eth1.service

Repeat this command for each interface you want to disable at boot (e.g., network@eth2.service, network@eth3.service).

Verifying the Changes

After masking the service files, reboot your system and verify that the specified network interfaces are not started. Use the systemctl status network@eth1.service command to confirm that the service is masked. The output should indicate that the service is “masked” and cannot be started.

Unmasking Services

If you need to re-enable a masked interface, you can unmask its service file using the systemctl unmask command:

sudo systemctl unmask network@eth1.service

After unmasking the service, you can start the interface using the systemctl start network@eth1.service command.

Considerations for Dependencies

Masking a service can affect other services that depend on it. Before masking a network interface service, ensure that no other critical services rely on that interface. Otherwise, masking the service may prevent those dependent services from starting correctly.

As the original user discovered, attempting to use kernel parameters to directly disable IPv6 on specific interfaces may not be effective in preventing the initialization attempts and associated delays. This approach is generally not recommended as it can have unintended consequences and is less granular than the other methods described above. However, for completeness, we will briefly outline the available kernel parameters and their potential (limited) use.

The kernel provides several parameters that control IPv6 behavior. These parameters can be set in the kernel command line, which is typically configured in the bootloader (e.g., GRUB).

  • ipv6.disable=1: This parameter disables IPv6 entirely, preventing the IPv6 module from loading. This is a drastic measure and may break applications or services that rely on IPv6.

  • net.ipv6.conf.all.disable_ipv6=1: This parameter disables IPv6 on all interfaces. It is similar to ipv6.disable=1 but allows the IPv6 module to load.

  • net.ipv6.conf.default.disable_ipv6=1: This parameter disables IPv6 on newly created interfaces.

  • net.ipv6.conf.<interface>.disable_ipv6=1: This parameter disables IPv6 on a specific interface (e.g., net.ipv6.conf.eth1.disable_ipv6=1).

Setting Kernel Parameters

To set a kernel parameter, you need to edit the GRUB configuration file (e.g., /etc/default/grub). Add the desired parameter to the GRUB_CMDLINE_LINUX_DEFAULT line. For example:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash net.ipv6.conf.eth1.disable_ipv6=1 net.ipv6.conf.eth2.disable_ipv6=1 net.ipv6.conf.eth3.disable_ipv6=1"

After modifying the GRUB configuration file, update the GRUB bootloader configuration:

sudo update-grub

Reboot your system for the changes to take effect.

Limitations and Risks

As mentioned earlier, using kernel parameters to disable IPv6 on specific interfaces may not completely prevent the initialization attempts and associated delays. The kernel may still attempt to bring up the interfaces, even if IPv6 is disabled. Additionally, disabling IPv6 may have unintended consequences for other applications or services. Therefore, this approach should be used with caution and only as a last resort. Other services can assume to use IPv6, so it is always recommended to carefully evaluate the consequences of this course of action.

Choosing the Right Solution

The best solution for disabling network interfaces at boot without NetworkManager depends on your specific needs and preferences. Modifying interface configuration files is the simplest and most straightforward approach for most users. udev rules provide more flexibility and persistence, while masking systemd services offers a systemd-native solution. Using kernel parameters is generally not recommended due to potential limitations and risks. Remember to test any changes thoroughly before implementing them in a production environment. Always consult your distribution’s documentation for the most accurate and up-to-date information.

Conclusion: Optimizing Boot Time by Managing Network Interfaces

By implementing one of the solutions outlined in this guide, you can effectively prevent inactive network interfaces from slowing down your system’s boot process. This optimization can significantly improve your overall experience, especially on machines that are frequently restarted. Remember to choose the solution that best suits your needs and always test your changes thoroughly. At revWhiteShadow, we are committed to providing you with the knowledge and tools you need to optimize your systems and enhance your computing experience. We hope this guide was helpful, and we encourage you to explore our other articles for more tips and tricks on system administration and optimization.