Your message dated Thu, 24 Aug 2023 11:30:37 +0200
with message-id <da3a8b85-6a72-4367-86b4-86f7f2486...@debian.org>
and subject line Re: Bug#862992: systemd: avoid attempt to re-create /etc/mtab
by systemd-tmpfiles-setup.service
has caused the Debian Bug report #862992,
regarding systemd: avoid attempt to re-create /etc/mtab by
systemd-tmpfiles-setup.service
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
862992: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862992
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 232-23
Severity: normal
Dear Maintainer,
After having upgraded to Stretch, I noticed that
systemd-tmpfiles-setup.service attempts to create /etc/mtab as
configured in /usr/lib/tmpfiles.d/debian.conf. Unfortunately, this
does not work on some of my machines where / is mounted read-only and
consequently, systemd-tmpfiles-setup.service fails.
Moreover, this step does not seem to be necessary, as /etc/mtab is
symlinked to /proc/mounts after a fresh debootstrap. /proc/mounts in
turn symlinks to /proc/self/mounts, the same file as configured in
/usr/lib/tmpfiles.d/debian.conf.
What exactly are the reasons for re-creating /etc/mtab on every boot? Is
this step really necessary?
For now, I just use Jessie's version of /usr/lib/tmpfiles.d/debian.conf.
Best,
Maximilian Stein
-- Package-specific info:
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (900, 'testing'), (800, 'stable')
Architecture: amd64
(x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.115
ii libacl1 2.2.52-3+b1
ii libapparmor1 2.11.0-3
ii libaudit1 1:2.6.7-2
ii libblkid1 2.29.2-1
ii libc6 2.24-10
ii libcap2 1:2.25-1
ii libcryptsetup4 2:1.7.3-4
ii libgcrypt20 1.7.6-1
ii libgpg-error0 1.26-2
ii libidn11 1.33-1
ii libip4tc0 1.6.0+snapshot20161117-6
ii libkmod2 23-2
ii liblz4-1 0.0~r131-2+b1
ii liblzma5 5.2.2-1.2+b1
ii libmount1 2.29.2-1
ii libpam0g 1.1.8-3.5
ii libseccomp2 2.3.1-2.1
ii libselinux1 2.6-3+b1
ii libsystemd0 232-23
ii mount 2.29.2-1
ii util-linux 2.29.2-1
Versions of packages systemd recommends:
ii dbus 1.10.18-1
ii libpam-systemd 232-23
Versions of packages systemd suggests:
ii policykit-1 0.105-17
ii systemd-container 232-23
pn systemd-ui <none>
Versions of packages systemd is related to:
pn dracut <none>
ii initramfs-tools 0.130
ii udev 232-23
-- no debconf information
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
On Mon, 18 Dec 2017 01:41:39 +0100 Cyril Brulebois <k...@debian.org> wrote:
Michael Biebl <bi...@debian.org> (2017-12-18):
> Buster development is still young, so let's get this started by
> creating a bug report for finish-install.
>
> KiBi, if you know more places where /etc/mtab is used inside the
> installer, please let me know and I'll clone/reassign this bug
> accordingly.
Thanks Michael.
Added to my personal d-i/10 tracker; I'll poke at it when time permits
if nobody from debian-boot@ steps up in the meanwhile.
I've submitted
https://salsa.debian.org/installer-team/finish-install/-/merge_requests/4
in the mean time.
Afaics there is nothing left to do on the systemd side, so closing the
bug report.
KiBi, should you encounter more occurences of /etc/mtab in d-i, feel
free to poke me and I can submit corresponding bug reports/MRs.
Regards,
Michael
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
