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-----

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

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@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.

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.

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

severity 1053677 normal
thanks

El 9/10/23 a las 0:34, Diederik de Haas escribió:

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.

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.

Isn't that the whole point of line 76?

Cheers,
  Diederik

El 9/10/23 a las 12:23, Diederik de Haas escribió:
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.

Hi! Sorry for the delay.

Yep.

Yes. /run is missing, therefor the creation of /run/lock fails

I assume it's running the postinst script of base-files, which tries to create
/run/lock, but fails as /run doesn't exist.
Whether deboostrap or another package should be responsible for creating /run,
I do not know. I think base-files is a good candidate as it already creates
many top-level dirs and it also tries to create /run/lock.

- 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]`

See the error msg as reported in OP.
Note that this image is *very* minimal to show the issue; it won't boot as
it's missing all the important packages (kernel/initramfs/init/etc)

*) This is similar to what I'm using, but stripped of most things which
weren't relevant. I'm actually using arm64 as architecture, but I changed that
to amd64 assuming that would be (even) easier.

Cheers,
  Diederik

reassign 1053677 debos
thanks

El 11/10/23 a las 23:50, Diederik de Haas escribió:

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.