| 21 Feb 2025 |
cleverca22 | nofail plus RequiresMountsFor results in no emergency mode, and the service doesnt start | 06:13:01 |
cleverca22 | Feb 21 06:10:16 backend1 systemd[1]: ipfs.service: Job ipfs.service/start failed with result 'dependency'. | 06:13:32 |
cleverca22 | thats perfect | 06:13:35 |
@elvishjerricco:matrix.org | yea, that's nearly the same thing as simply adding x-systemd.required-by=foo.service,x-systemd.before=foo.service, with the only difference being that my way doesn't mount the file system if foo.service isn't scheduled at boot. | 06:15:29 |
cleverca22 | under normal conditions, it should mount at boot, and start the service at boot | 06:19:59 |
@elvishjerricco:matrix.org | yea, the difference is negligible | 06:20:12 |
cleverca22 | the problem, is that somebody put the fileSystems config in a shared module and then deployed it to a dev machine in digital ocean a machine lacking the DO volume.... | 06:20:26 |
@elvishjerricco:matrix.org | it would only matter if you wanted to mask the service for some reason | 06:20:27 |
cleverca22 | so the machine instantly fell over | 06:20:32 |
cleverca22 | and nobody bothered fixing it, for 5 months | 06:20:39 |
@elvishjerricco:matrix.org | It'll mount at normally boot with either way | 06:21:28 |
@elvishjerricco:matrix.org | but the x-systemd. way would not mount if you masked the service for some reason | 06:21:54 |
@elvishjerricco:matrix.org | * It'll mount normally at boot with either way | 06:22:02 |
cleverca22 | ah | 06:22:13 |
| 24 Feb 2025 |
| ubalot joined the room. | 08:06:23 |
Arian | Do I need to worry about these logs in systemd-initrd?
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libnss_files.so.2"
initrd-linux> Warning: Couldn't satisfy dependency ld-linux-aarch64.so.1 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libc.so.6"
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libm.so.6"
initrd-linux> Warning: Couldn't satisfy dependency ld-linux-aarch64.so.1 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libm.so.6"
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libdl.so.2"
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libpthread.so.0"
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/mjqj5naakm09gfvwm8aalbzswdqwm9v5-gcc-13.3.0-libgcc/lib/libgcc_s.so.1"
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/04aq2w58qlqjvwamcljh1hahz744hlzd-libidn2-2.3.7/lib/libidn2.so.0.4.0"
initrd-linux> Warning: Couldn't satisfy dependency ld-linux-aarch64.so.1 for "/nix/store/04aq2w58qlqjvwamcljh1hahz744hlzd-libidn2-2.3.7/lib/libidn2.so.0.4.0"
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libresolv.so.2"
initrd-linux> Warning: Couldn't satisfy dependency ld-linux-aarch64.so.1 for "/nix/store/8d9rkvllf04pyz790vk6wd4k8mnc5c64-glibc-2.40-36/lib/libresolv.so.2"
initrd-linux> Warning: Couldn't satisfy dependency libc.so.6 for "/nix/store/8rywcj8s7gx9iy4hwipfz7nb87s9rib9-libunistring-1.2/lib/libunistring.so.5.1.0"
initrd-linux> Warning: Couldn't satisfy dependency ld-linux-aarch64.so.1 for "/nix/store/8rywcj8s7gx9iy4hwipfz7nb87s9rib9-libunistring-1.2/lib/libunistring.so.5
| 10:02:26 |
Arian | we are including libnss_files so I am confused. Also ld-linux-aarch64.so.1 missing sounds bad? | 10:02:47 |
Arian | oh wait our ld-linux is just a stab that says “this doesn’t work” anyway | 10:11:18 |
Arian | ah this is just glibc being glibc | 10:32:55 |
@elvishjerricco:matrix.org | This happens because glibc is effectively an implicit part of RPATH. So all the glibc libs are not found in the literal RPATH of an executable, but are found by the dynamic loader because it just knows to look there | 20:57:53 |
Arian | I just found out that systemd-fstab has a —generate-fstab flag that uses MountPoints= to synthesize an fstab file | 22:07:34 |
Arian | * I just found out that systemd-repart has a —generate-fstab flag that uses MountPoints= to synthesize an fstab file | 22:07:42 |
Arian | so we can use systemd.repart.partitions as a full replacement for fileSystems | 22:08:02 |
@elvishjerricco:matrix.org | oh | 22:09:08 |
@elvishjerricco:matrix.org | that's extremely interesting | 22:09:13 |
Arian | also has a —generate-crypttab | 22:09:18 |
Arian | yeh this is very dope | 22:09:54 |
@elvishjerricco:matrix.org | Arian: I think there's an issue here though. fstab is a dependency of toplevel, and a repart image depends on toplevel | 22:11:06 |
@elvishjerricco:matrix.org | so you can't use repart to get the fstab without making an infinite loop | 22:11:23 |
@elvishjerricco:matrix.org | unless you use a mock repart config that doesn't include toplevel | 22:11:35 |