On Fri, 12 Sep 2025 09:09:32 +0800 Josh Triplett <[email protected]> wrote: > On Thu, 11 Sep 2025 21:23:00 +0100 Luca Boccassi <[email protected]> wrote: > > On Wed, 10 Sep 2025 22:38:50 +0200 Hilmar Preusse <[email protected]> > > wrote: > > > recently I noticed that setting up systemd failed to setup in one of > > my > > > chroots. The error message was: > > > > > > <snip> > > > root@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.
