| 20 Jul 2025 |
K900 | Oh god | 14:41:25 |
raitobezarius (DECT: 7248) | a workaround has been applied | 14:41:26 |
K900 | Great | 14:41:27 |
raitobezarius (DECT: 7248) | this is related to IPv6 | 14:41:30 |
raitobezarius (DECT: 7248) | all CI jobs have been kicked | 14:41:40 |
raitobezarius (DECT: 7248) | an issue should be open shortly | 14:41:43 |
raitobezarius (DECT: 7248) | and we will mitigate this | 14:41:45 |
raitobezarius (DECT: 7248) | 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 (DECT: 7248) | systemd not listening on [::1]:53 for stub listener does not make any easier | 14:42:37 |
raitobezarius (DECT: 7248) | 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 (DECT: 7248) | Excellent question | 14:44:15 |
raitobezarius (DECT: 7248) | Could it be a "this is handled in the C++ code" vs. "a true FOD fetcher" situation? | 14:44:34 |
raitobezarius (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | gave a clear root cause | 14:45:51 |
raitobezarius (DECT: 7248) | 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 (DECT: 7248) | inside the sandbox, you get 169.254.1.1 on thet0 | 14:49:51 |
raitobezarius (DECT: 7248) | * inside the sandbox, you get 169.254.1.1 on eth0 | 14:49:52 |
raitobezarius (DECT: 7248) | supposedly | 14:50:00 |
raitobezarius (DECT: 7248) | but actually the interface contain only IPv6 | 14:50:07 |
raitobezarius (DECT: 7248) | but the nameserver contain IPv4 only | 14:50:14 |
raitobezarius (DECT: 7248) | nameserver 169.254.1.1 namely | 14:50:21 |
raitobezarius (DECT: 7248) | In reply to @aloisw:julia0815.de Also the thing that failed is a FOD I think? golang dependencies | 14:50:56 |
raitobezarius (DECT: 7248) | (so yes) | 14:51:01 |
aloisw | In reply to @raitobezarius:matrix.org
nameserver 169.254.1.1 namely … which I presume pasta translates to 127.0.0.1, which does not work because resolved is listening on 127.0.0.53? | 14:52:06 |
raitobezarius (DECT: 7248) | well, your interface doesn't have 169.254.1.1 on eth0 | 14:52:30 |