Re: Bug#862992: systemd: avoid attempt to re-create /etc/mtab by systemd-tmpfiles-setup.service

2023-08-24 Thread Michael Biebl

On Mon, 18 Dec 2017 01:41:39 +0100 Cyril Brulebois  wrote:

Michael Biebl  (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


Bug#884647: marked as done (Stop using/creating /etc/mtab)

2023-08-24 Thread Debian Bug Tracking System
Your message dated Thu, 24 Aug 2023 16:39:06 +0200
with message-id <3debbc1e-3e9b-42ac-b998-0c8036dfb...@debian.org>
and subject line fixed in bookworm
has caused the Debian Bug report #884647,
regarding Stop using/creating /etc/mtab
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.)


-- 
884647: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884647
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  libapparmor12.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  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1
ii  libpam0g1.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  dbus1.10.18-1
ii  libpam-systemd  232-23

Versions of packages systemd suggests:
ii  policykit-10.105-17
ii  systemd-container  232-23
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-23

-- no debconf information




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
What's been implemented in 
https://salsa.debian.org/installer-team/finish-install/-/merge_requests/1 
sufficiently addresses this issue.


So closing the bug report.


OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---


Re: installer help screen (Was: Re: installation-guide: simplify RAM/disk space requirements)

2023-08-24 Thread Samuel Thibault
Holger Wansing, le jeu. 24 août 2023 08:01:46 +0200, a ecrit:
> Holger Wansing  wrote (Tue, 8 Aug 2023 00:06:14 +0200):
> > amd64:minimum_memory_strict=350
> > amd64:minimum_memory=780
> > 
> > i386:minimum_memory_strict=285
> > i386:minimum_memory=485
> 
> Looking at this values (the current ones from lowmem), we have 350MB for
> amd64 and 285MB for i386.
> The installer help screen F2 has the 285MB value (grabbed from i386 ?) even 
> on 
> the amd64 image.
> 
> Should this be sync'ed somehow?

They need to be updated when updating the values in lowmem, yes.

> (Of course, bumping this value from 285 to 350 means, that the i386 installer
> help screen says "350MB needed", which is strictly not correct, but that's 
> not a blocker IMO ?)

I'd say we can as well just put the amd64 values there.

Samuel



Re: installer help screen (Was: Re: installation-guide: simplify RAM/disk space requirements)

2023-08-24 Thread Holger Wansing
Hi,

Samuel Thibault  wrote (Thu, 24 Aug 2023 21:14:29 +0200):
> Holger Wansing, le jeu. 24 août 2023 08:01:46 +0200, a ecrit:
> > Holger Wansing  wrote (Tue, 8 Aug 2023 00:06:14 
> > +0200):
> > > amd64:minimum_memory_strict=350
> > > amd64:minimum_memory=780
> > > 
> > > i386:minimum_memory_strict=285
> > > i386:minimum_memory=485
> > 
> > Looking at this values (the current ones from lowmem), we have 350MB for
> > amd64 and 285MB for i386.
> > The installer help screen F2 has the 285MB value (grabbed from i386 ?) even 
> > on 
> > the amd64 image.
> > 
> > Should this be sync'ed somehow?
> 
> They need to be updated when updating the values in lowmem, yes.
> 
> > (Of course, bumping this value from 285 to 350 means, that the i386 
> > installer
> > help screen says "350MB needed", which is strictly not correct, but that's 
> > not a blocker IMO ?)
> 
> I'd say we can as well just put the amd64 values there.

Done.
Thanks


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076