Changing the Gateway IP in Rocky Linux

 

Step 1: Find the Real Connection Name

Before you change anything, ask NetworkManager what the connection is actually called. Do not guess.

Run this command:

Bash

nmcli connection show

What to look for:

Focus on the NAME column on the far left.

NAME	UUID	TYPE	DEVICE
enp1s0	5fb06bd0...	ethernet	enp1s0
Wired connection 1	2ad18c...	ethernet	enp1s0

• In the first row, the connection name matches the device name (enp1s0).

• In the second row, the connection is named Wired connection 1.

Copy the text from the NAME column exactly.

Step 2: Set the New Gateway

Now that you have the correct name, use nmcli to modify the configuration.

Syntax:

sudo nmcli connection modify "<CONNECTION_NAME>" ipv4.gateway <NEW_IP>

Example (If your name is "enp1s0"):

Bash

sudo nmcli connection modify "enp1s0" ipv4.gateway 192.168.0.70

Example (If your name is "Wired connection 1"):

Bash

sudo nmcli connection modify "Wired connection 1" ipv4.gateway 192.168.0.70

Step 3: Apply the Changes

Modifying the connection only updates the config file on the disk. To make it live, you must reload the interface.

Bash

sudo nmcli connection up "enp1s0"

(Replace enp1s0 with your actual connection name found in Step 1).

Step 4: Verify

Check the kernel routing table to confirm the default route has updated.

Bash

ip route show

You are looking for the line starting with default:

default via 192.168.0.70 dev enp1s0 proto static metric 100

---

Common Gotcha: DHCP Overrides

If you followed the steps above but ip route still shows the old gateway, your server is likely getting its IP via DHCP.

By default, DHCP provides an IP address and a gateway. The DHCP gateway will override your manual setting every time the interface comes up.

The Fix:

You need to tell NetworkManager to keep the DHCP IP address but ignore the DHCP gateway.

Bash

# 1. Ignore the automatic gateway from DHCP
sudo nmcli connection modify "enp1s0" ipv4.ignore-auto-routes yes

# 2. Enforce your manual gateway
sudo nmcli connection modify "enp1s0" ipv4.gateway 192.168.0.70

# 3. Apply changes
sudo nmcli connection up "enp1s0"

---

Summary

• Don't assume the connection name is "System enp1s0".

• Always check nmcli connection show first.

• Remember to reload with nmcli connection up after making changes.

Fix "Failed to Mount /sysroot" on Rocky Linux

 There are few things more heart-stopping for a System Administrator than watching a server boot, only to see it hang and drop into the dreaded Dracut Emergency Shell.

If you are seeing the error Failed to mount /sysroot followed by a prompt that looks like dracut:/#, your system has failed to load the root filesystem. On Rocky Linux (and RHEL/AlmaLinux), this is almost always caused by XFS filesystem corruption following a hard shutdown, power loss, or hypervisor crash.

---

Prerequisite: Understand the Environment

You are currently in the initramfs environment. This is a small, temporary filesystem loaded into memory before the real disk is mounted. Because the real disk is corrupted, the OS cannot transition to it.

Note: Rocky Linux uses XFS as its default filesystem. Unlike EXT4 (which uses fsck), XFS has its own set of tools, specifically xfs_repair.

---

Step 1: Identify Your Root Partition

First, you need to find the specific device name of your root partition. Since you are in a limited shell, standard commands like lsblk might not show what you expect.

Run the block ID command:

Bash

blkid

You are looking for a device labeled root or an LVM path.

• Standard Partition: /dev/sda2 or /dev/nvme0n1p2

• LVM (Most Common): /dev/mapper/rl-root or /dev/mapper/rocky-root

Can't see the /dev/mapper entries? If you use LVM (Logical Volume Manager) and don't see your volumes, they are likely inactive. Activate them manually:

Bash

lvm vgchange -ay

Run blkid again. You should now see your root volume.

---

Step 2: The Repair Process

Crucial Rule: Never run a filesystem repair on a mounted partition. Since the boot failed, your partition is likely unmounted, which is exactly what we want.

Attempt 1: Standard Repair

Run the repair command against your specific root device (replace the path below with the one you found in Step 1):

Bash

xfs_repair /dev/mapper/rl-root

Scenario A: Success If the command runs, shows a flurry of text, and ends with done, you are safe. Proceed to Step 3.

Scenario B: "Filesystem has a dirty log" If xfs_repair fails and says the log is dirty, it means there is pending metadata in the journal. It will suggest you mount and unmount the filesystem to replay the log.

Try to mount it manually to let the journal replay:

1. mount /dev/mapper/rl-root /sysroot

2. umount /sysroot

3. Run xfs_repair /dev/mapper/rl-root again.

Attempt 2: Force Log Zeroing (The "Nuclear" Option)

If the mount fails, or if xfs_repair refuses to run because the log is too corrupt, you must use the -L flag.

Warning: The -L flag forces the filesystem to zero out the log. This means you may lose the metadata for the most recent file operations that were occurring exactly when the server crashed. However, this is often the only way to make the disk mountable again.

Bash

xfs_repair -L /dev/mapper/rl-root

You should see output indicating that the log is being destroyed and the filesystem is being rebuilt.

---

Step 3: Verify and Reboot

Once the repair returns cleanly, verify that the filesystem is mountable.

1. Test Mount:

   Bash

   mount /dev/mapper/rl-root /sysroot
   

   If this command returns no output, it worked.

2. Reboot: You can now exit the Dracut shell. The system will detect the exit and attempt to resume the boot process.

   Bash

   exit
   

   (Alternatively, type reboot to restart the machine entirely).

---

Troubleshooting: "It still won't boot!"

If xfs_repair says the disk is clean but you still get boot errors, the issue might be in your /etc/fstab file (e.g., a secondary drive is failing, and the OS refuses to boot without it).

To check this from the Dracut shell:

1. Mount the system: mount /dev/mapper/rl-root /sysroot

2. Change root: chroot /sysroot

3. Edit fstab: vi /etc/fstab

Comment out any non-essential drives (like data drives or swap) to see if the system will boot with just the root drive.

---

Summary

The "Failed to mount /sysroot" error is intimidating, but xfs_repair is a robust tool.

1. Use blkid to find your device.

2. Use lvm vgchange -ay if using LVM.

3. Run xfs_repair /dev/device-name.

4. Use -L only if absolutely necessary.

How to Configure OPNsense (Rift Raven) with du Internet

 

Switching from a standard ISP router to a dedicated firewall like the Rift Raven gives you enterprise-grade control over your network. However, connecting it to a du (Nokia ONT) connection involves navigating MAC address locking, private WAN IPs, and NAT configurations.

This guide walks through the successful configuration, specifically tailored for a setup requiring a large internal network (/22 subnet) and handling "Double NAT" scenarios.

Phase 1: The Hardware & Cabling

Before touching the software, the physical connections must be correct. The Rift Raven typically has 2 ports: Port 1 (WAN) and Port 2 (LAN).

The Setup

1. The Source (du): Locate the white/black Nokia ONT on your wall. Find the active LAN port (usually LAN 1 or GE 1).

2. The Bridge: Connect an Ethernet cable from Nokia LAN 1 directly to Rift Raven Port 1 (WAN).

3. The Local Network: Connect Rift Raven Port 2 (LAN) to your PC (for setup) or to a Gigabit Switch.

   • Note: Since the Raven only has one LAN port, a switch is required to connect the rest of your home’s wall sockets (Patch Panel).

Critical Step: The "Handshake" Reset

du’s Nokia ONT locks onto the MAC address of the device connected to it. If you simply unplug your old router and plug in the Raven, it will likely block the connection.

The Fix:

1. Unplug power from the Nokia ONT.

2. Unplug power from the Rift Raven.

3. Wait 5 full minutes. (This clears the active session at the exchange).

4. Power on the Nokia ONT and wait for the "PON/Optical" light to turn solid green.

5. Power on the Rift Raven.

---

Phase 2: OPNsense Initial Configuration

Access the OPNsense interface (default: https://192.168.1.1) and run the Wizard.

WAN Settings (For du)

• Type: DHCP (du uses IPoE, not PPPoE, so no username/password is needed).

• Block Private Networks: UNCHECK (Crucial: See Phase 4).

• Block Bogon Networks: UNCHECK.

LAN Settings (The Custom /22 Range)

We configured the LAN to be larger than a standard home network to avoid IP exhaustion.

• IP Address: 192.168.0.1

• Subnet Mask: /22 (255.255.252.0)

• Range: This provides IPs from 192.168.0.1 to 192.168.3.254.

Tip: If changing the LAN IP locks you out of the web interface, use the physical console (VGA/HDMI + Keyboard) and select Option 2 to reset the interface IP.

---

Phase 3: Troubleshooting "No Internet" (The Gateways)

Once connected, you might see the WAN interface turn green, but devices on the LAN cannot access the internet. This is usually due to two specific issues found in du setups.

Issue 1: The "Double NAT" Problem

The Nokia ONT often acts as a router, assigning the Raven a private IP (e.g., 192.168.70.x) instead of a public one. OPNsense sees this "Private" WAN IP and assumes it shouldn't route traffic out to it.

The Fix: Hybrid Outbound NAT

1. Go to Firewall > NAT > Outbound.

2. Change Mode to Hybrid outbound NAT rule generation.

3. Click Save and Apply.

4. Ensure a rule exists mapping LAN net to WAN interface.

Issue 2: The Gateway Trap (Critical Configuration Error)

A common mistake is assigning a Gateway to the LAN interface.

• The Error: In System > Gateways, you might see a gateway named LAN_GW pointing to 192.168.0.1.

• The Consequence: This creates a routing loop. OPNsense tries to send internet traffic back into the LAN port.

The Fix:

1. Go to System > Gateways > Configuration.

2. Delete any Gateway associated with the LAN interface.

3. Go to Interfaces > [LAN].

4. Ensure IPv4 Upstream Gateway is set to Auto-detect or None.

---

Phase 4: Validating the Connection

To confirm everything is working, perform these tests in order:

1. Test from the Firewall (Diagnostics)

Go to Interfaces > Diagnostics > Ping.

• Ping 8.8.8.8 (Source: WAN): Success means the Raven connects to the internet.

• Ping https://www.google.com/search?q=google.com (Source: WAN): Success means DNS is working.

2. Test from a LAN Device (PC/Laptop)

Open a command prompt on your computer.

• ping 8.8.8.8

• If it fails: It is likely a NAT issue (See Phase 3, Issue 1).

• If it works: You are online.

---

Summary Checklist for Future Reference

If you ever reset the device, follow this "Golden Config":

• [ ] WAN Interface: DHCP enabled, "Block Private Networks" Unchecked.

• [ ] WAN Gateway: Monitor IP set to 8.8.8.8 (Disable Gateway Monitoring unchecked).

• [ ] LAN Interface: Static IP (192.168.0.1/22), Upstream Gateway set to None.

• [ ] NAT: Outbound NAT set to Hybrid.

• [ ] Cabling: Nokia LAN 1 → Raven WAN. Raven LAN → Switch.

Final Note on Hardware: Because the Rift Raven has limited ports, ensure your Gigabit Switch is connected to the Raven's LAN port to distribute the connection to the rest of your home's patch panel (D-5, etc.).