diff --git a/.zshrc b/.zshrc index f1a568c..f7c8456 100644 --- a/.zshrc +++ b/.zshrc @@ -38,11 +38,12 @@ export GPG_TTY=$(tty) export EDITOR="nvim" [[ ! -f ~/.p10k.zsh ]] || source ~/.p10k.zsh -# export NVM_DIR="$HOME/.nvm" -# [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" -# -# +export NVM_DIR="$HOME/.nvm" +[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" + + #THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!! export SDKMAN_DIR="$HOME/.sdkman" [[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh" +# [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion diff --git a/network-manager-resolvd-config.md b/network-manager-resolvd-config.md new file mode 100644 index 0000000..7cf33e3 --- /dev/null +++ b/network-manager-resolvd-config.md @@ -0,0 +1,243 @@ +Excellent question. The fact that this happens *sometimes* is the key to understanding the problem. It points to a race condition or a conflict between the different services managing your network, specifically `NetworkManager` and `systemd-resolved`, based on the information your router is providing. + +Here's a breakdown of the moving parts and why they sometimes fail to cooperate. + +### The Actors on Your System + +1. **The Router (The Source of Truth):** + * When you connect to Wi-Fi, your router provides network configuration information. + * For IPv4, it uses **DHCP** to give you an IP address, a gateway, and DNS servers. + * For IPv6, it uses **Router Advertisements (RAs)** and/or **DHCPv6**. RAs can include information about which DNS servers to use. + * **The Core Issue:** Some routers, especially consumer-grade ones, are poorly configured. They advertise their own **link-local** (`fe80::...`) address as the DNS server in their IPv6 RAs. This is technically valid but problematic for many client systems. + +2. **NetworkManager (The Connection Manager):** + * Its job is to manage network interfaces (like `wlp1s0`). It brings the Wi-Fi up, handles authentication, and listens for the configuration data from your router (both DHCP and RAs). + * When it receives the DNS server information, it needs to pass it on to the system's resolver. + +3. **systemd-resolved (The DNS Resolver):** + * This is the service that actually performs the DNS lookups for your applications (like your web browser). It's designed to be a central clearinghouse for DNS. It maintains a list of all DNS servers learned from all network interfaces, caches results, and can handle advanced protocols like DNS-over-TLS. + +### The Conflict: Who Controls `/etc/resolv.conf`? + +The problem arises from how `NetworkManager` and `systemd-resolved` are configured to interact, and which one gets the final say over the `/etc/resolv.conf` file. There are two common modes: + +1. **Mode A: `NetworkManager` is in control (Your likely situation).** + * In this setup, `NetworkManager` takes the DNS server information it receives from the router and writes it *directly* into `/etc/resolv.conf`. + * The file comment `# Generated by NetworkManager` is the evidence for this. + * When your router sends that bad `fe80::1%wlp1s0` address, `NetworkManager` dutifully writes it into the file, and your system's DNS breaks. + +2. **Mode B: `systemd-resolved` is in control (The modern, recommended setup).** + * `NetworkManager` is configured to pass all the DNS information it learns to `systemd-resolved` via an internal system bus (D-Bus). + * `systemd-resolved` then manages the DNS servers internally. + * `/etc/resolv.conf` is then symlinked to a file managed by `systemd-resolved` (like `/run/systemd/resolve/stub-resolv.conf`), which contains only `nameserver 127.0.0.53`. This points all system queries to the local `systemd-resolved` daemon, which then intelligently forwards them to the correct upstream servers. + +### Why "Sometimes"? The Race Condition + +The fact that it's intermittent strongly suggests a race condition between your IPv4 and IPv6 configuration on startup or reconnect. + +* **Scenario 1 (Everything Works):** Your system connects, the IPv4 DHCP negotiation finishes first. `NetworkManager` gets a valid IPv4 DNS server (e.g., `8.8.8.8` or your ISP's) and writes it to `/etc/resolv.conf`. A moment later, the problematic IPv6 RA arrives, but `NetworkManager` might prioritize or already be using the working IPv4 server. +* **Scenario 2 (DNS Breaks):** Your system connects, but the IPv6 Router Advertisement is processed first. `NetworkManager` receives the `fe80::1%wlp1s0` address and writes it to `/etc/resolv.conf`. DNS is broken from the start. A few moments later, the IPv4 address might arrive, but `NetworkManager` might not update the config file, leaving the broken one in place. This can also happen after waking from suspend. Such intermittent failures are a known class of bugs [github.com](https://github.com/systemd/systemd/issues/21123). + +As one user on a forum described a similar situation, "After doing a -Syu and reboot, I no longer have access to the internet system-wide. I can ping 8.8.8.8 but not ping google.com" – this is the classic symptom you are experiencing [forum.endeavouros.com](https://forum.endeavouros.com/t/no-internet-dns-issues-after-update-networkmanager-systemd-resolved-on-kde/69865). + +--- + +### How to Verify and Fix This Permanently + +The best solution is to switch to the modern setup where `systemd-resolved` is in full control. + +#### Step 1: Check Your Current `resolv.conf` Setup + +Run this command to see what `/etc/resolv.conf` really is: + +```bash +ls -l /etc/resolv.conf +``` + +* **If it shows a file (`-rw-r--r-- ...`)**, you are in the problematic Mode A. +* **If it shows a symlink (`lrwxrwxrwx ... -> ../run/systemd/resolve/stub-resolv.conf`)**, you are in Mode B, but `NetworkManager` might still be misconfigured. + +#### Step 2: Configure NetworkManager to Use `systemd-resolved` + +1. Edit the main NetworkManager configuration file: + ```bash + sudo nano /etc/NetworkManager/NetworkManager.conf + ``` + +2. In the `[main]` section, add or uncomment the `dns` line and set it to `systemd-resolved`: + ```ini + [main] + plugins=ifupdown,keyfile + dns=systemd-resolved + + [ifupdown] + managed=false + ``` + +3. Save the file and exit. + +#### Step 3: Enable `systemd-resolved` and Create the Correct Symlink + +1. First, ensure the service is running: + ```bash + sudo systemctl enable systemd-resolved.service + sudo systemctl start systemd-resolved.service + ``` + +2. Next, remove the static file and create the correct symlink. This forces the system to use the local `systemd-resolved` stub resolver. + ```bash + # IMPORTANT: Back up the old file first + sudo mv /etc/resolv.conf /etc/resolv.conf.bak + + # Create the symlink + sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf + ``` + +#### Step 4: Restart and Verify + +Restart `NetworkManager` to apply all the changes. + +```bash +sudo systemctl restart NetworkManager +``` + +Now, your DNS should work reliably. Check your `resolv.conf` to confirm it points to `127.0.0.53`. To see the *actual* DNS servers your system is now using (which it gets from `NetworkManager`), use the `resolvectl` command: + +```bash +resolvectl status +``` + +This will give you a detailed report, showing the DNS servers for each interface (like `wlp1s0`). Even if the problematic `fe80::` address is listed there, `systemd-resolved` is smart enough to ignore or fall back from it if it doesn't work, preventing a total DNS outage. + + + + + +Excellent! You've correctly identified that you're in "Mode A," where `NetworkManager` writes directly to `/etc/resolv.conf`. Switching to the modern approach where `systemd-resolved` handles everything is the most robust and permanent solution. + +Let's walk through the process step-by-step. This is a standard and safe procedure on most modern Linux distributions. + +--- + +### Step-by-Step Guide to Switch to `systemd-resolved` + +We are going to reconfigure your system so that: +1. `NetworkManager` passes DNS information to `systemd-resolved`. +2. `systemd-resolved` manages all DNS lookups. +3. `/etc/resolv.conf` points to the local `systemd-resolved` service. + +#### Step 1: Configure NetworkManager + +First, we need to tell `NetworkManager` to stop managing `/etc/resolv.conf` by itself and start sending its DNS information to `systemd-resolved`. + +1. Open the `NetworkManager.conf` file with a text editor and `sudo` privileges: + ```bash + sudo nano /etc/NetworkManager/NetworkManager.conf + ``` + +2. Find the `[main]` section. Add a `dns` line and set it to `systemd-resolved`. If the line already exists but is set to something else (like `default`), change it. + + **Your file should look like this:** + ```ini + [main] + plugins=ifupdown,keyfile + dns=systemd-resolved + + [ifupdown] + managed=false + ``` + *(Note: You might have other settings in the `[main]` section. Just make sure the `dns=systemd-resolved` line is present and correct.)* + +3. Save the file and exit the editor (in `nano`, press `Ctrl+O`, then `Enter` to save, and `Ctrl+X` to exit). + +#### Step 2: Enable and Start `systemd-resolved` + +Now, let's make sure the `systemd-resolved` service is active and will start automatically on boot. + +```bash +# Enable the service to start on every boot +sudo systemctl enable systemd-resolved.service + +# Start the service right now +sudo systemctl start systemd-resolved.service +``` + +#### Step 3: Recreate `/etc/resolv.conf` as a Symlink + +This is the most important step. We will replace the static file that `NetworkManager` used to write with a symbolic link to the `resolv.conf` file that `systemd-resolved` provides. + +1. **Important:** Back up your current `resolv.conf` file. This lets you easily revert if something goes wrong. + ```bash + sudo mv /etc/resolv.conf /etc/resolv.conf.bak + ``` + This command safely renames the file. + +2. Create the new symbolic link: + ```bash + sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf + ``` + This links `/etc/resolv.conf` to the "stub" resolver file, which correctly points all DNS queries to the local `systemd-resolved` daemon. + +#### Step 4: Restart NetworkManager and Verify + +Finally, restart `NetworkManager` to apply all the changes and verify that everything is working. + +1. Restart the service: + ```bash + sudo systemctl restart NetworkManager + ``` + +2. **Verify the symlink:** Check that `/etc/resolv.conf` is now a link. + ```bash + ls -l /etc/resolv.conf + ``` + The output should look like this (colors and dates will vary): + ``` + lrwxrwxrwx 1 root root 39 Nov 18 10:30 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf + ``` + +3. **Verify the content:** Check what's inside the new `resolv.conf`. + ```bash + cat /etc/resolv.conf + ``` + The output should show `127.0.0.53` as the nameserver. This is the local `systemd-resolved` stub resolver. + ``` + # This file is managed by man:systemd-resolved(8). Do not edit. + ... + nameserver 127.0.0.53 + options edns0 trust-ad + ``` + +4. **Check the REAL DNS servers:** Use `resolvectl` to see which DNS servers `systemd-resolved` is actually using (which it learned from `NetworkManager`). + ```bash + resolvectl status + ``` + This will give you a detailed report. Look for the section corresponding to your Wi-Fi interface (`wlp1s0`). You will see the actual IP addresses of the DNS servers it is using. Even if the problematic `fe80::` address is listed, `systemd-resolved` is much more resilient and will fall back to other working servers. + +5. **Final Test:** + ```bash + ping archlinux.org + ``` + If you get a reply, congratulations! Your DNS is now being managed robustly by `systemd-resolved`. + +--- + +### How to Revert (If Needed) + +If anything goes wrong, you can easily go back to the old setup: + +1. **Restore the old `resolv.conf`:** + ```bash + sudo mv /etc/resolv.conf.bak /etc/resolv.conf + ``` + +2. **Edit `NetworkManager.conf` again:** + ```bash + sudo nano /etc/NetworkManager/NetworkManager.conf + ``` + Remove the `dns=systemd-resolved` line, or change it back to `dns=default`. + +3. **Restart NetworkManager:** + ```bash + sudo systemctl restart NetworkManager + ``` diff --git a/sdkman/config b/sdkman/config new file mode 100644 index 0000000..9b0e63c --- /dev/null +++ b/sdkman/config @@ -0,0 +1,2 @@ +# enable automatic env +sdkman_auto_env=true diff --git a/services/hibernate.conf b/services/hibernate.conf new file mode 100644 index 0000000..ff73bf7 --- /dev/null +++ b/services/hibernate.conf @@ -0,0 +1,2 @@ +[Sleep] +HibernateDelaySec=30min diff --git a/services/readme.md b/services/readme.md new file mode 100644 index 0000000..bb9b447 --- /dev/null +++ b/services/readme.md @@ -0,0 +1,28 @@ +```bash + +sudo tee /etc/systemd/system/suspend-radios.service << 'EOF' +[Unit] +Description=Disable radios before suspend +Before=sleep.target + +[Service] +Type=oneshot +ExecStart=/usr/sbin/rfkill block wifi bluetooth +ExecStop=/usr/sbin/rfkill unblock wifi bluetooth + +[Install] +WantedBy=sleep.target +EOF + +sudo systemctl enable suspend-radios.service +``` + +```bash +sudo mkdir -p /etc/systemd/sleep.conf.d +sudo tee /etc/systemd/sleep.conf.d/hibernate.conf << 'EOF' +[Sleep] +HibernateDelaySec=30min +EOF + +sudo systemctl daemon-reload +``` diff --git a/services/suspend-radios.service b/services/suspend-radios.service new file mode 100644 index 0000000..b40de6a --- /dev/null +++ b/services/suspend-radios.service @@ -0,0 +1,11 @@ +[Unit] +Description=Disable radios before suspend +Before=sleep.target + +[Service] +Type=oneshot +ExecStart=/usr/sbin/rfkill block wifi bluetooth +ExecStop=/usr/sbin/rfkill unblock wifi bluetooth + +[Install] +WantedBy=sleep.target