| 17 Jul 2025 |
| @ersei:ersei.net left the room. | 14:49:39 |
| 19 Jul 2025 |
ma27 | In reply to @ma27:nicht-so.sexy I'll try to find a good reproducer, I'm not quite sure how I did it, but I have theories (that's why I asked if I should bother investigating) fwiw I tried to find the culprit by active attempts to reproduce and by just continuing to use it. none of that helped. In the meantime I also updated Lix to latest HEAD, so maybe it's something that got fixed later on 🤷 | 17:44:59 |
| 20 Jul 2025 |
K900 | @raitobezarius bonk https://buildkite.com/lix-project/lix/builds/3187/steps/canvas?sid=019826e4-e3d4-45d6-8df0-988dff4e54b9pls | 09:19:33 |
K900 | @raitobezarius bonk https://buildkite.com/lix-project/lix/builds/3187/steps/canvas?sid=019826e4-e3d4-45d6-8df0-988dff4e54b9 pls | 09:19:36 |
raitobezarius | Done | 10:34:17 |
K900 | Still busted :( | 12:12:28 |
raitobezarius | I will take a look when I can | 13:36:14 |
raitobezarius | In reply to @k900:0upti.me Still busted :( root cause found, this is a systemd/pasta bug | 14:41:18 |
K900 | Oh god | 14:41:25 |
raitobezarius | a workaround has been applied | 14:41:26 |
K900 | Great | 14:41:27 |
raitobezarius | this is related to IPv6 | 14:41:30 |
raitobezarius | all CI jobs have been kicked | 14:41:40 |
raitobezarius | an issue should be open shortly | 14:41:43 |
raitobezarius | and we will mitigate this | 14:41:45 |
raitobezarius | tl;dr: pasta is not adding properly IPv4 network on the eth0 interface leading to ENETUNREACH inside the sandbox when resolving via the systemd stub resolver | 14:42:26 |
raitobezarius | systemd not listening on [::1]:53 for stub listener does not make any easier | 14:42:37 |
raitobezarius | workaround: kill the IPv4 stub listener, add an IPv6 stub listener which modify the /etc/resolv.conf in a way that makes pasta effectively ipv6-only inside sandboxes | 14:42:57 |
aloisw | So how could downloads from GitHub ever work? | 14:43:23 |
raitobezarius | Excellent question | 14:44:15 |
raitobezarius | Could it be a "this is handled in the C++ code" vs. "a true FOD fetcher" situation? | 14:44:34 |
raitobezarius | I think we should probably try to understand how GitHub downloads worked | 14:45:17 |
aloisw | Possible, I'm only certain of FOD downloads working. | 14:45:25 |
raitobezarius | But
151 nix-build -E 'let pkgs = (import <nixpkgs> {}); in pkgs.runCommand "ip-a" { } "ip a"'
152 nix-build -E 'let pkgs = (import <nixpkgs> {}); in pkgs.runCommand "ip-a" { buildInputs = [ pkgs.iproute2 ]; } "ip a"'
153 nix-build -E 'let pkgs = (import <nixpkgs> {}); in pkgs.runCommand "ip-a" { buildInputs = [ pkgs.iproute2 ]; outputHashMode = "flat"; outputHashAlgo = "sha256"; outputHash = pkgs.lib.fakeHash; } "ip a"'
154 nix-build -E 'let pkgs = (import <nixpkgs> {}); in pkgs.runCommand "ip-a" { buildInputs = [ pkgs.iproute2 ]; outputHashMode = "flat"; outputHashAlgo = "sha256"; outputHash = pkgs.lib.fakeHash; } "cat /etc/resolv.conf"'
155 nix-build -E 'let pkgs = (import <nixpkgs> {}); in pkgs.runCommand "ip-a" { buildInputs = [ pkgs.iproute2 ]; outputHashMode = "flat"; outputHashAlgo = "sha256"; outputHash = pkgs.lib.fakeHash; } "resolvectl"'
156 cat /etc/resolv.conf
157 nix-build -E 'let pkgs = (import <nixpkgs> {}); in pkgs.runCommand "ip-a" { buildInputs = [ pkgs.iproute2 ]; outputHashMode = "flat"; outputHashAlgo = "sha256"; outputHash = pkgs.lib.fakeHash; } "resolvectl"'
158 nix-build -E 'let pkgs = (import <nixpkgs> {}); in pkgs.runCommand "ip-a" { buildInputs = [ pkgs.iproute2 ]; outputHashMode = "flat"; outputHashAlgo = "sha256"; outputHash = pkgs.lib.fakeHash; } "cat /etc/resolv.conf"'
| 14:45:45 |
raitobezarius | gave a clear root cause | 14:45:51 |
raitobezarius | I surmise this is fairly easy to test in a VM test | 14:45:59 |
aloisw | Also the thing that failed is a FOD I think? | 14:47:36 |
aloisw | Wait is only IPv4 to localhost broken? | 14:47:59 |
raitobezarius | inside the sandbox, you get 169.254.1.1 on thet0 | 14:49:51 |
raitobezarius | * inside the sandbox, you get 169.254.1.1 on eth0 | 14:49:52 |