Bug#1114860: systemd: Confusing error message about missing "/etc/machine-id" upon setup

[Luca Boccassi]

On Fri, 12 Sep 2025 09:09:32 +0800 Josh Triplett
<josh at joshtriplett.org> wrote:
> On Thu, 11 Sep 2025 21:23:00 +0100 Luca Boccassi <bluca at debian.org>
wrote:
> > On Wed, 10 Sep 2025 22:38:50 +0200 Hilmar Preusse <hille42 at web.de>
> > wrote:
> > > recently I noticed that setting up systemd failed to setup in one
of
> > my
> > > chroots. The error message was:
> > > 
> > > <snip>
> > > root at rasppi3:~# apt build-dep texlive-bin
> > > Summary:
> > >   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> > >   4 not fully installed or removed.
> > >   Space needed: 0 B / 58.3 GB available
> > > 
> > > Continue? [Y/n] y
> > > Error: Can not write log (Is /dev/pts mounted?) - posix_openpt
(19:
> > No such device)
> > > Setting up systemd (258~rc4-1) ...
> > > Cannot open '/etc/machine-id' in neither writable nor read-only
mode:
> > Function not implemented
> > > dpkg: error processing package systemd (--configure):
> > >  installed systemd package post-installation script subprocess
> > returned error exit status 1
> > > Errors were encountered while processing:
> > >  systemd
> > > Error: Sub-process /usr/libexec/apt-eatmydata/dpkg returned an
error
> > code (1)
> > > Error: Failed to process build dependencies
> > > <snip>
> > > 
> > > The root cause turned out to be a not mounted /proc filesystem,
the
> > setup
> > > worked fine after it was mounted. However I found that error
message
> > quite
> > > confusing: the file /etc/machine-id is there and is readable.
> > 
> > It's accurate, but not helpful, as the file can't be read as file
> > descriptors can't be used without procfs. This is not a supported
> > setup, sadly procfs is a hard runtime requirement.
> 
> Nobody is claiming that this should work without procfs mounted. The
bug
> report here is about a confusing error message. It would be helpful
if
> something in this error message mentioned /proc and led the user to
> realize it wasn't mounted.

Not really possible unfortunately. At debug level that would be
visible, but because of intentional design decisions only the lowest
level in the stack logs at >= info, but the real issue is in the top
layers, where only debug is allowed. The lowest level of the call stack
only knows that some operation failed and the errno-equivalent, it
doesn't know why it failed. So here the operation is trying to open
that file, and it can't, so it tells you that and the errno that
percolated down the call stack.