Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1171237

Bug#1053677: base-files: /var/lock points to non-existing /run/lock

From Santiago Vila <sanvila@debian.org>
Newsgroups linux.debian.bugs.dist
Subject Bug#1053677: base-files: /var/lock points to non-existing /run/lock
Date 2023-10-09 13:20 +0200
Message-ID <HmWsN-eBlg-5@gated-at.bofh.it> (permalink)
References (2 earlier) <HmLxn-eu8P-1@gated-at.bofh.it> <HmEvT-eq7h-1@gated-at.bofh.it> <HmVGp-eAQb-7@gated-at.bofh.it> <HmEvT-eq7h-1@gated-at.bofh.it> <HmVGp-eAQb-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-08 18:10 +0200
  Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-08 19:50 +0200
    Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-08 20:40 +0200
    Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-09 00:50 +0200
      Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-09 01:40 +0200
        Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-09 12:30 +0200
          Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-09 13:20 +0200
            Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-12 00:00 +0200
              Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-16 00:00 +0200

csiph-web