On Monday, 9 October 2023 01:37:09 CEST Santiago Vila wrote: > El 9/10/23 a las 0:34, Diederik de Haas escribió: > > I did initially wonder to which package to file the bug against as next to > > debootstrap I also considered to file it against aptitude. > > But as the base-files package creates the symlink, I think it's therefor > > also its responsibility to make sure it points to an existing directory. > I see your point, but the directory /run/lock is special, because > directory /run is usually a ramdisk. The base-files package may not be > responsible for creating it, because it would not survive a reboot.
It seems I'm missing something. https://sources.debian.org/src/base-files/13/debian/postinst.in/#L76: ```sh install_directory run/lock 1777 root ``` https://sources.debian.org/src/base-files/13/debian/postinst.in/#L28-L34: ```sh install_directory() { if [ ! -d "$DPKG_ROOT/$1" ]; then mkdir "$DPKG_ROOT/$1" chown "root:$3" "$DPKG_ROOT/$1" chmod "$2" "$DPKG_ROOT/$1" fi } ``` I interpret that as line 76 wants to create directory `/run/lock` and then in line 29 it tests whether the dir exist, which it does not, and then in line 30 it tries to create it ... and that FAILS as it *assumes* the parent directory is available, which it turns out not to be. ```sh ls -lh /run: drwxr-xr-x 4 root root 160 Oct 8 13:16 host ls -lh /var: drwxr-xr-x 5 root root 4.0K Oct 8 13:11 cache lrwxrwxrwx 1 root root 9 Oct 8 13:12 lock -> /run/lock lrwxrwxrwx 1 root root 4 Oct 8 13:12 run -> /run ``` Looking at the timestamps (^=part of OP) makes it looks like `/run/` itself was created on 13:16 by whatever created `/run/host`, but base-files ran its commands on 13:12. But the assumption that the parent dir exists is IMO the bug. > As I said, I don't think we can make base-files responsible for the > existence of /run/lock. Isn't that the whole point of line 76? Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.
