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

[Diederik de Haas]

Package: base-files
Version: 13
Severity: important

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm creating a script to build an image where I essentially do this:
- - Create base system with debootstrap (minbase variant)
- - Install aptitude
- - Use aptitude to install more packages

And then I noticed the following in the log file:
```sh
E: Could not open lock file /var/lock/aptitude - open (2: No such file or directory)
E: Could not initialize dependency cache
...
W: Could not lock the cache file; this usually means that dpkg or another apt
tool is already installing packages. Opening in read-only mode; any changes you
make to the states of packages will NOT be preserved!
```

So I modified my script to first list the contents of `/run` and `/var`:

```sh
ls -lh /run:
total 0
drwxr-xr-x 4 root root 160 Oct 8 13:16 host
ls -lh /var:
total 36K
drwxr-xr-x 2 root root 4.0K Jun 11 15:00 backups
drwxr-xr-x 5 root root 4.0K Oct 8 13:11 cache
drwxr-xr-x 8 root root 4.0K Oct 8 13:16 lib
drwxrwsr-x 2 root staff 4.0K Jun 11 15:00 local
lrwxrwxrwx 1 root root 9 Oct 8 13:12 lock -> /run/lock
drwxr-xr-x 4 root root 4.0K Oct 8 13:15 log
drwxrwsr-x 2 root mail 4.0K Oct 8 13:12 mail
drwxr-xr-x 2 root root 4.0K Oct 8 13:12 opt
lrwxrwxrwx 1 root root 4 Oct 8 13:12 run -> /run
drwxr-xr-x 2 root root 4.0K Oct 8 13:12 spool
drwxrwxrwt 2 root root 4.0K Jun 11 15:00 tmp
```

So `/var/lock` points to `/run/lock` ... which doesn't exist.
And that results in errors and a warning from aptitude with potentially
some serious consequences.


- -- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages base-files depends on:
ii gawk [awk] 1:5.2.1-2
ii mawk [awk] 1.3.4.20230808-1

base-files recommends no packages.

base-files suggests no packages.

- -- no debconf information

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZSLSxQAKCRDXblvOeH7b
bjVhAQDi4c3eNjc46q5SwyUGAEOw2GYNeDCv8YaQQNzd8DJQvgEAkrLv9MZT7Poi
wNMhu8033wGVsGwn4RvoVhA509y8VwA=
=jW5K
-----END PGP SIGNATURE-----

[Santiago Vila]

El 8/10/23 a las 18:03, Diederik de Haas escribió:

> So `/var/lock` points to `/run/lock` ... which doesn't exist.
> And that results in errors and a warning from aptitude with potentially
> some serious consequences.

Thanks for the report. I think this has never happened until now.

Can you confirm that this happens only with the debootstrap version
in trixie/sid and not with the bookworm version?

If yes, I believe that we should reassign this report to debootstrap.

Thanks.

[Diederik de Haas]

I'm building the image using 'debos' on a Debian Bookworm system/VM:
diederik@debos-builder-deb12:~/pineian-images$ aptitude versions debootstrap
i A 1.0.128+nmu2 stable 500

But I'm building a Trixie system/image.

I reported the issue from my main PC assuming it wouldn't matter as
I thought the problem was a missing '-p' argument in debian/postinst.in/#L30
and that hadn't changed between Bookworm and Trixie/Sid.

[Diederik de Haas]

On Sunday, 8 October 2023 19:40:43 CEST Santiago Vila wrote:

> > So `/var/lock` points to `/run/lock` ... which doesn't exist.
> > And that results in errors and a warning from aptitude with potentially
> > some serious consequences.
>
> Thanks for the report. I think this has never happened until now.

When I put "Could not open lock file /var/lock/aptitude" into a search engine,
the first result was https://askubuntu.com/a/120757 from 2012-04-10
And the presented solution was "sudo mkdir /run/lock".
So it seems to me that nobody (apparently) never reported it before, but it
isn't a new problem by any means.
It could be that 'aptitude' is important to reveal the issue.

It's also possible that another program which normally gets installed, would
create that directory. I had not (yet) installed packages of priority
important or normal when the issue occurred.

> If yes, I believe that we should reassign this report to debootstrap.

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.

Cheers,
Diederik

[Santiago Vila]

severity 1053677 normal
thanks

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.

According to Bug #1039979 (where I'm asked to make such symlink relative,
which I can't for now because it's against policy) such directory is
re-created by systemd if you accidentally remove it, but it's
considered "legacy".

This is a snippet from /usr/lib/tmpfiles.d/legacy.conf:

----------------------------------------------------------------------
# These files are considered legacy and are unnecessary on legacy-free
# systems.

L /var/lock - - - - ../run/lock
L /var/log/README - - - - ../../usr/share/doc/systemd/README.logs
----------------------------------------------------------------------

This suggests to me that any program trying to use /var/lock directly
instead of /run/lock is probably buggy and should be fixed.

Therefore I think you should report this (as a different bug)
against any package trying to use /var/lock directly.

As I said, I don't think we can make base-files responsible for the
existence of /run/lock. If this is a bug at all in base-files,
it would be to remove /var/lock altogether, but that's something
I would have to coordinate with systemd maintainers. I'm going
to keep this open for now until we know if we can do that or not.

Thanks.

[Diederik de Haas]

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

[Santiago Vila]

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.

[Santiago Vila]

reassign 1053677 debos
thanks

El 11/10/23 a las 23:50, Diederik de Haas escribió:
> - install `debos` in a virtual machine
> - extract the attached archive*
> - do `cd run-lock-issue`
> - run `debos image.yml [2>&1 | tee -a build.log]`

Ok, I finally arrived at this point.

[ Note: I'm doing all this from a machine running bookworm ]

# debos image.yml
2023/10/15 20:55:56 error creating fakemachine: <nil>, kvm backend not supported: open /dev/kvm: no such file or directory, uml backend not supported: user-mode-linux not installed

[ I'm on a virtual machine, and having /dev/kvm available inside the virtual machine itself
is called "nested virtualization", and it's considered a "special feature", so I decided
to try the user-mode-linux route ].

After installing user-mode-linux:

2023/10/15 20:59:49 error creating fakemachine: <nil>, kvm backend not supported: open /dev/kvm: no such file or directory, uml backend not supported: libslirp-helper not installed
2023/10/15 20:59:49 fakemachine not supported, running on the host!

After installing libslirp-helper:

# debos image.yml
stat /lib/systemd/systemd-resolved: no such file or directory

After installing systemd-resolved:

# debos image.yml
Running /debos --artifactdir /root/run-lock-issue /root/run-lock-issue/image.yml --internal-image /dev/disk/by-fakemachine-label/fakedisk-0 using uml backend
2023/10/15 21:04:56 ==== image-partition ====
2023/10/15 21:04:57 Action `image-partition` failed at stage Run, error: exec: "parted": executable file not found in $PATH

After installing parted:

# debos image.yml

and then I finally can see what you reported:

2023/10/15 21:13:11 run-installer-script.sh | Reading package lists...
2023/10/15 21:13:13 run-installer-script.sh | Building dependency tree...
2023/10/15 21:13:13 run-installer-script.sh | Reading state information...
2023/10/15 21:13:14 run-installer-script.sh | E: Could not open lock file /var/lock/aptitude - open [...]

If I use deboostrap alone without debos, this is what happens:

# debootstrap trixie /tmp/trixie http://deb.debian.org/debian
[...]

# ls -l /tmp/trixie/run
total 24
-rw-r--r-- 1 root root 0 Oct 15 21:32 adduser
drwxrwxrwt 3 root root 4096 Oct 15 21:31 lock
drwxr-xr-x 2 root root 4096 Oct 15 21:31 log
drwxr-xr-x 2 root root 4096 Oct 15 21:30 mount
drwxr-xr-x 2 root root 4096 Oct 15 21:31 sendsigs.omit.d
lrwxrwxrwx 1 root root 8 Oct 15 21:31 shm -> /dev/shm
drwxr-xr-x 9 root root 4096 Oct 15 21:31 systemd
drwxr-xr-x 2 root root 4096 Oct 15 21:31 user

This seems a bug in debos to me. Hence I'm doing a reassign.

Thanks.