| 20 Jul 2025 |
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 |
raitobezarius (DECT: 7248) | so it's immediately an ENETUNREACH | 14:52:34 |
raitobezarius (DECT: 7248) | if your interface had 169.254.1.1, maybe there would be a chance because resolved is listening on 127.0.0.1 as well IIRC? | 14:52:57 |
aloisw | hmm it does seem to have here?
aloisw@exodus ~/V/l/main (main) [1]> nix build --impure --expr 'with import <nixpkgs> {}; runCommand "meow" { outputHash = lib.fakeHash; } "${pkgs.iproute2}/bin/ip route; exit 1"'
error: builder for '/nix/store/5fjqh7v6wvi2swhpyab6pf53s7z35hv0-meow.drv' failed with exit code 1;
last 2 log lines:
> default via 169.254.1.1 dev eth0
> 169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.1.2
| 14:59:53 |
raitobezarius (DECT: 7248) | what is your ip a ? | 15:02:01 |
raitobezarius (DECT: 7248) | on the host? | 15:02:02 |
raitobezarius (DECT: 7248) | i mean | 15:02:12 |
raitobezarius (DECT: 7248) | do you have ipv4 connectivity on the host? | 15:02:16 |
raitobezarius (DECT: 7248) | for reference, this is the host builder | 15:02:32 |
raitobezarius (DECT: 7248) | [root@build01:~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: host0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 3e:b0:ee:45:01:14 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 2001:bc8:38ee:100:8000::20/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::3cb0:eeff:fe45:114/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
| 15:02:34 |
raitobezarius (DECT: 7248) | [root@build01:~]# ip -6 r
64:ff9b::/96 via 2001:bc8:38ee:100::100 dev host0 proto static metric 1024 pref medium
(ipv4 comes from there) | 15:02:54 |
aloisw | Ah that might do it, I do have ipv4 on the host. | 15:03:06 |
aloisw | Right, removing all IPv4 addresses (except 127.0.0.1/8 on lo) makes IPv4 connectivity go away in the sandbox too. | 15:05:29 |
raitobezarius (DECT: 7248) | which makes sense to some extent | 15:06:25 |
raitobezarius (DECT: 7248) | but creates that very funny situation | 15:06:29 |
raitobezarius (DECT: 7248) | where IPv4-only localhost services are now unreachable | 15:06:39 |
raitobezarius (DECT: 7248) | a workaround is to always add 169.254.1.1 to lo | 15:06:53 |
raitobezarius (DECT: 7248) | alternatively pasta could heuristically recognize NAT64 prefixes and do the right thing | 15:07:40 |
raitobezarius (DECT: 7248) | not so sure this is a good idea | 15:07:45 |
aloisw | In reply to @raitobezarius:matrix.org a workaround is to always add 169.254.1.1 to lo The arguments passed to pasta are not different, so this seems like a pasta issue? | 15:08:37 |
raitobezarius (DECT: 7248) | yep | 15:11:50 |
| 21 Jul 2025 |
jade_ | yippeee, time to reverse engineer how output-addressed store paths with references work. I could do IA but it's not truthful since Lix doesn't get to see the input as it's externally generated... | 19:00:41 |
jade_ | * yippeee, time to reverse engineer how output-addressed store paths with references serialize in nix-store --export. I could do IA but it's not truthful since Lix doesn't get to see the input as it's externally generated... | 19:00:49 |