Your message dated Fri, 18 Sep 2026 11:46:11 +0000
with message-id <[email protected]>
and subject line Bug#1137258: Removed package(s) from unstable
has caused the Debian Bug report #832682,
regarding by default destroys settings done in the chroot stage
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 [email protected]
immediately.)
--
832682: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832682
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: live-build
Version: 4.0.3-1
The Live Build manual describes how to prepare a system in the chroot stage.
I do it.
On my live system (a firewall), I find destroyed settings in /etc/hosts,
/etc/network/interfaces, /etc/resolv.conf and probably several others.
Further, a user not existing in the chroot, "user" is created with a
world-known password "live". This user can sudo. (and via a little bit of
TCP, the whole world can sudo on my box...)
I had to spend many hours to dig out, what happened and how to work around all
this surprising magic. The reporter of case #787617 was surprised, too.
The architectural flaw, that I see in all these symptoms, is, that live-build
violates the principle of least surprise. It is a great tool to automate the
building of live images. And without all the magic, it could be a great tool
to do this generically for arbitrary live images based on Debian and Ubuntu.
The problem is, that this magic happens by default.
It is clear, that there has to be a separation between build time customisation
(which determines the properties of all produced live images) and run time
customisation (determining the properties of the particular running instance).
BUT: if I did not do any particular runtime configuration, I expect, that the
system behaves as defined at build time -- and if I do a particular chroot-time
customisation, that it survives chroot time (/etc/hosts is destroyed in a later
stage of lb_build).
This way, a tool, promising to be simple and used for a simple use case,
becomes complicated and unforeseeably expensive.
I would propose to switch default (no customisation) behaviour to the simplest
possible. Eg., if I don't define a live user, there will be none, if I don't
switch something on, which alters my /etc/network/interfaces, it shouldn't, ...
The various customisation "switches" shall have well-defined and -documented
behaviour.
Otherwise, the risk is too high, that I'm building a system full of security
flaws.
Carpe diem
--- End Message ---
--- Begin Message ---
Version: 20190301-lts1-5+rm
Dear submitter,
as the package open-infrastructure-system-tools has just been removed from the
Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/1137258
The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.
Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)
--- End Message ---
