El 9/10/23 a las 12:23, Diederik de Haas escribió:
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?
Ok, yes. Sorry, I did not express it correctly. I meant that base-files
is not responsible for ensuring that /run/lock exists "at all times".
As you rightly point out, there is indeed an attempt to ensure
that those directories exist after the very first install by debootstrap,
and this is done before /run becomes a ramdisk and before the first
reboot. I guess this is precisely your case.
What I would like to know is exactly what changed *elsewhere* so that
this code, which apparently used to work before, is not working anymore.
So: What is the parent directory which does not exist? It's /run ?
This directory belongs to base-files (try dpkg -L base-files).
Should it not be created by debootstrap when unpacking base-files?
BTW: I have not upgraded to trixie myself yet in my Desktop computer,
but I can use a virtual machine to test. Could you please explain exactly
how to reproduce the error? No need to post your script, only a *minimal*
case that shows the error.
Thanks.