Bug#1071227: busybox-udeb: provides binaries that are also provided by kmod-udeb (e.g. modprobe)

[Michael Tokarev]

16.05.2024 20:17, Philip Hands пишет:

Package: busybox-udeb
Severity: normal
User: debian-rele...@lists.debian.org

Hi,

I notice that busybox-udeb provides the following binaries in /sbin:

   depmod insmod lsmod modinfo modprobe rmmod

while kmod-udeb provides the same, except located in /usr/sbin.


https://salsa.debian.org/installer-team/busybox/-/commit/a52da181d4cd0e41c04ab1d5be9130270df0f696
#1060134

fwiw.

/mjt
--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Re: udhcpc search domain

[Michael Tokarev]

26.04.2024 13:24, Frédéric Guyot wrote:

After looking at this a bit more closely , it seems that netcfg is calling 
udhcpc with  limited set options. see here:
https://salsa.debian.org/installer-team/netcfg/-/blob/master/dhcp.c#L38 


We would just need to add "search" to this list of options and update the 
/etc/udhcpc/default.default.script as stated previously.


I just committed this change:
https://salsa.debian.org/installer-team/busybox/-/commit/bd0d90574a4e39b39d38b664ad15ac0c2ca1bbad

It's interesting we had no complaints about this so far..

/mjt

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Re: Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Michael Tokarev]

Ok,

I'm removing whole modutils from busybox udeb (besides depmod, this is
lsmod, insmod, rmmod, and modprobe).  All these are provided by
kmod-udeb as far as I can see (as symlinks to kod).

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Michael Tokarev]

09.04.2024 16:48, Cyril Brulebois wrote:

Marco d'Itri  (2024-04-09):

Yes. Nowadays kmod has many more features related to compressed modules
and verification of signatures.
Can we agree that kmod should provide these programs for d-i?
Or can the d-i maintainers just tell us what they want?


I meant to come back to this after experimenting, then things happened…

I picked kmod at the time because it worked, and because busybox didn't
work, which I summed up in:
   
https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145

(plus follow-up commit, woopsie
   
https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07
)

I'm fine with sticking to kmod regarding module support in d-i. I'm not
sure we should keep support in two different modules, so dropping it
from busybox would work for me. Others might have different views on
this, though.


So, should I disable module utils in busybox-udeb now?
Wanted to spare some time on busybox, this bug report come in.

Is kmod udeb ready and used in d-i already, or does it need some
prep first?

Thanks,

/mjt

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1065463: debootstrap can deal with native dpkg file replacement feature

[Michael Tokarev]

05.03.2024 03:36, Steven Shiau :

Package: debootstrap
Version: 1.0.134
Severity: wishlist

Dear Maintainer,

As mentioned here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065394#28
For the moment on Mar/5/2024 in the Debian Sid repository, libuuid1 "Provides:
libuuid1t64 (= 2.39.3-9)", and an exact version of libuuid1t64 which
is not in repos. libuuid1 and libuuid1t64 have "Replaces:" on each other 
already.
debootstrap should be able to solve the libuuid1t64 dependency by installing 
libuuid1 only.


I think we should not add complexity to debootstrap just to be able to perform a
transition like this once in 20+ years.

/mjt

Bug#1064400: discover-data: install files into /usr

[Michael Biebl]

Source: discover-data
Version: 2.2013.01.13
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. discover-data installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru discover-data-2.2013.01.13/debian/changelog 
discover-data-2.2013.01.13+nmu1/debian/changelog
--- discover-data-2.2013.01.13/debian/changelog 2022-01-09 10:27:19.0 
+0100
+++ discover-data-2.2013.01.13+nmu1/debian/changelog2024-02-21 
14:53:10.0 +0100
@@ -1,3 +1,10 @@
+discover-data (2.2013.01.13+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install files into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Wed, 21 Feb 2024 14:53:10 +0100
+
 discover-data (2.2013.01.13) unstable; urgency=medium
 
   * Rewrite debian/rules using dh, keeping only a few directives.
diff -Nru discover-data-2.2013.01.13/debian/rules 
discover-data-2.2013.01.13+nmu1/debian/rules
--- discover-data-2.2013.01.13/debian/rules 2022-01-09 10:26:49.0 
+0100
+++ discover-data-2.2013.01.13+nmu1/debian/rules2024-02-21 
14:52:44.0 +0100
@@ -4,10 +4,10 @@
dh $@
 
 override_dh_auto_build:
-   dh_auto_build -- hwlistsdir=/lib/discover
+   dh_auto_build -- hwlistsdir=/usr/lib/discover
 
 override_dh_auto_install:
-   dh_auto_install -- hwlistsdir=/lib/discover
+   dh_auto_install -- hwlistsdir=/usr/lib/discover
 
 override_dh_installchangelogs:
dh_installchangelogs ChangeLog

Bug#1063728: keyboard-configuration: format of XKBOPTIONS not specified

[Michael Gold]

Package: keyboard-configuration
Version: 1.226
Severity: minor

Dear Maintainer,

/etc/default/keyboard refers to "the keyboard(5) manual page", which
says:
  XKBOPTIONS
Specifies the XKB keyboard option components. Options usually
relate to the behavior of the special keys (, ,
, , etc.) Default: not set.

This does not say how multiple options should be separated.  Luckily,
there are examples suggesting the value can be a comma-separated list
with no whitespace.

The actual expectations should be stated explicitly, and the same goes
for XKBVARIANT.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.85
ii  liblocale-gettext-perl  1.07-6+b1
ii  xkb-data2.41-1

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages console-setup depends on:
ii  console-setup-linux1.226
ii  debconf [debconf-2.0]  1.5.85
ii  xkb-data   2.41-1

Versions of packages console-setup suggests:
ii  locales2.37-15
ii  sysvinit-utils [lsb-base]  3.08-6

Versions of packages console-setup-linux depends on:
ii  init-system-helpers  1.66
ii  kbd  2.6.4-2

Versions of packages console-setup-linux suggests:
ii  console-setup  1.226

Versions of packages keyboard-configuration is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.6.4-2
ii  systemd   255.3-2

-- debconf information:
  keyboard-configuration/unsupported_options: true
  console-setup/fontsize-text47: 8x16
  console-setup/guess_font:
  console-setup/fontsize-fb47: 8x16
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/model: Generic 105-key PC
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/switch: No temporary switch
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/layout:
  console-setup/charmap47: UTF-8
* keyboard-configuration/compose: No compose key
  keyboard-configuration/unsupported_layout: true
  console-setup/use_system_font:
  console-setup/fontface47: Fixed
  console-setup/framebuffer_only:
* keyboard-configuration/layoutcode: us
* keyboard-configuration/toggle: No toggling
* keyboard-configuration/xkb-keymap: us(dvorak)
* keyboard-configuration/altgr: The default for the keyboard layout
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
  console-setup/codesetcode: Lat15
* keyboard-configuration/other:
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/variantcode: dvorak
* keyboard-configuration/modelcode: pc105
* keyboard-configuration/variant: English (US) - English (Dvorak)
  console-setup/fontsize: 8x16
  keyboard-configuration/ctrl_alt_bksp: false
* keyboard-configuration/optionscode: ctrl:swapcaps
  keyboard-configuration/unsupported_config_options: true


signature.asc
Description: PGP signature

Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'

[Michael Tokarev]

09.02.2024 17:57, Thorsten Bonow :

dash << 'EOF'    [15:28:53]
if $( (true) 2>/dev/null); then
  echo "42"
fi
EOF
42

which only works in dash because of the added space between the command 
substitution $(...) and the subshell (...).

Does dash think it has to do arithmetic expansion "$((...))"?


Yes, arithmetic, and that's what bash does too.  dash does not understand
space between two closing parens though, ') )'.  And this is logical - if
the opening is "((", use the same matching "))" for closing.

$(( ... )) is arithmetic expression,
$( ( ... ) ) is a subshell.

Everything else is asking for trouble like this.


But what's POSIX take on this?  I couldn't find anything.  Is this a bug in 
dash or in setupcon?


It's a bug in setupcon.

/mjt

Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'

[Michael Tokarev]

09.02.2024 16:58, ca...@allfreemail.net

Package: console-setup
Followup-For: Bug #1063518

Consider making all scripts provided by console-setup shellcheck-clean, there 
are lots of tiny issues that can turn into big issues under the right 
conditions.


Please do not do this. Shellcheck is a huge problem and we had large amount
of bugs due to people trying to apply its suggestions.  It's very difficult
in many cases to spot why shellcheck is wrong (classic is the suggestion to
put $var into double quotes "$var" which breaks badly if $var is supposed to
contain zero or more separate words - this way, even boot scripts has become
buggy leading to system becoming unbootable).

Shellcheck is a very bad tool.

/mjt

Bug#1061238: discover: install binaries into /usr

[Michael Biebl]

Source: discover
Version: 2.1.2-10
Severity: normal
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr.
discover installs its binaries into /sbin.
Those should be moved to /usr/sbin instead.
Please find a build tested patch attached.

Regards,
Michael
>From 932f9862f0a8613ed552ec665753787468b7d633 Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Sun, 21 Jan 2024 11:17:00 +0100
Subject: [PATCH] Install binaries into /usr

---
 debian/discover.install | 6 +++---
 debian/rules| 1 -
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/debian/discover.install b/debian/discover.install
index ef6f77d..395299b 100644
--- a/debian/discover.install
+++ b/debian/discover.install
@@ -1,7 +1,7 @@
 etc/discover-modprobe.conf
-usr/bin/discover sbin/
-sbin/discover-modprobe
-sbin/discover-pkginstall
+usr/bin/discover usr/sbin/
+usr/sbin/discover-modprobe
+usr/sbin/discover-pkginstall
 usr/bin/discover-config
 usr/share/discover/init-discover
 usr/share/man/man1/discover-config.1
diff --git a/debian/rules b/debian/rules
index 181f79c..1335c03 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,7 +25,6 @@
 
 CONFIGURE_FLAGS= \
--prefix=/usr \
-   --sbindir=/sbin \
--sysconfdir=/etc \
--localstatedir=/var \
--mandir=\$${prefix}/share/man \
-- 
2.43.0

Re: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Michael Tokarev]

06.01.2024 11:40, Helmut Grohne:

On Sat, Jan 06, 2024 at 09:01:12AM +0100, Helmut Grohne wrote:

I also recommend to establish QA for all udebs to automatically detect,
report and address such conflicts as they evidently cause undefined
behaviour otherwise. That can be as simple as collecting file lists of
all udebs and comparing them.


This seems like a more generic problem. I downloaded all amd64 udebs and
the following files (normalized to account for aliasing) pose a
conflict:


From this list, only a few utilities are from busybox, namely wget and module
utilities (depmod/insmod/lsmod/modinfo/modprobe/rmmod).

My initial plan - with regular busybox package and with busybox udeb - is to
provide most things in busybox, so that other packages don't need to ship
udeb packages and the whole thing (be it d-i or initrd) is small.

Yes, some utils in busybox aren't as good as regular implementations. For
example, I just found out busybox's xz does not perform compression, only
decompression (-d option is mandatory).  Or #1003757 - missing functionality
in busybox ip.  Still, overall, it is enough for most things.  BTW, it looks
like with compressed kernel modules, busybox m-i-t needs some (albiet minor)
tweaks (it works but kernel produces warnings when busybox tries to load a
module).

Unfortunately this didn't work out for one reason or another.  One of the
reasons is perhaps #921556, where original util does more than needed but
busybox didn't implement the unnecessary functionality.

This needs to be thought about at a more general level. Including initrd
stuff (if we still need it, instead of relying on mkosi-initrd).  I use
my own initrd for a good reason, and this one does not include 2 or even
3 libc as debian does..

/mjt

busybox: CONFIG_FEATURE_DI_ENV_HACK: is it still needed?

[Michael Tokarev]

Hi!

There's a debian-specific patch in busybox since 2017 which adds ability
to lift variable name filtering rules for d-i.  A comment in there says:

This is not a long term fix for this problem: a different approach is
needed to parse the values from the kernel command-line, but we don't
want to be responsible for holding up the debian-installer alpha
release any longer than it has already.

Is it still needed in 2024?

Thanks,

/mjt

Re: Immediate fallouts from the big linux changes, and actions

[Michael Tokarev]

24.12.2023 11:16, Cyril Brulebois :
...

Searching for information about fuse and virtio, I finally noticed this
entry, which probably explains both fuse's “going away” and ditto for
some (but not all) virtio modules:

 * Set CONFIG_VIRTIO_FS and its dependencies to builtin, to allow building
   images that boot directly to rootfs (skipping the initrd)

as it changes:

 -CONFIG_VIRTIO_PCI=m
 +CONFIG_VIRTIO_PCI=y
 -CONFIG_FUSE_FS=m
 +CONFIG_FUSE_FS=y
 -CONFIG_VIRTIO_FS=m
 +CONFIG_VIRTIO_FS=y


Hm. This same argument can be used to include every storage- and 
filesystem-related
module into the kernel.  Why don't we have ahci and sd_mod built-in?  This does
look quite a bit strange to me to include this stuff..

(This commit is not about big linux changes but about small debian changes ;)

/mjt

Bug#1056628: udhcpc: file loss during upgrade due to Multi-Arch: same interacting with /usr-merge

[Michael Tokarev]

24.11.2023 02:27, Helmut Grohne:

Package: udhcpc
Version: 1:1.36.1-6~exp.1
Severity: normal
User: helm...@debian.org
Usertags: dep17p7

Hi Chris,

thanks for sitting down with me and doing this /usr-move. We aimed to be
careful and upload to experimental. Now dumat doesn't like your upload.
I'm trying to figure out why and whether this is an analyzer bug or a
real problem, so please do not move busybox to unstable for the time
bing.

What follows is details that you may skip entirely, but figured I better
write them down for my future self. So dumat figured that udhcpc is
Multi-Arch: same in bookworm and /sbin/udhcpc is a shared file. Then the
experimental package contains /usr/sbin/udhcpc. In theory, this could
result in a loss scenario, because you can install udhcpc for two
architecture in bookworm, ...


Helmut, udhcp is arch-all package.  You can't install two arch-all
packages at the same time..

I think we've been there before.  [/usr]/sbin/udhcpc is just a symlink
to [/usr]/bin/busybox.

/mjt

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Biebl]

Am 17.11.23 um 02:54 schrieb Michael Biebl:


That should do:



[snip patch]

oops, dropped one line too much from debian/rules.

Fixed patch attached.

diff --git a/debian/rules b/debian/rules
index 04018718b..b24b8f46f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -176,5 +176,4 @@ override_dh_installsystemd-indep:
 # explicitly list all packages with .service files here
dh_installsystemd -pbusybox-syslogd --name=busybox-klogd
dh_installsystemd -pbusybox-syslogd
-# the following does not work (see #1039142 for details):
-#  dh_installsystemd -pudhcpd --no-enable --no-start
+   dh_installsystemd -pudhcpd --no-enable
diff --git a/debian/udhcpd.service b/debian/udhcpd.service
index 0cdc24bc7..0d01d9722 100644
--- a/debian/udhcpd.service
+++ b/debian/udhcpd.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=Busybox udhcpd DHCP daemon
 Documentation=man:udhcpd(8)
-After=syslog.service network.target
+After=network.target
 
 [Service]
 Environment=DHCPD_OPTS="-S"


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Biebl]

On Tue, 14 Nov 2023 17:41:23 +0300 Michael Tokarev  wrote:

14.11.2023 14:56, Luca Boccassi wrote:
> On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev 
> wrote:
..

>> With just dh_installsystemd --no-enable, it is still started.
>> With dh_installsystemd --no-enable --no-start, it is started
>> as well, - apparently because initscript is started.  Also,
>> with --no-enable --no-start, it is not restarted on upgrades
>> if enabled locally.
>>
>> After doing several iterations, I decided to abandon this attempt, -
>> it just does not work, and I've no time to fight with the tools.
>>
>> If someone has a working recipe for all this madness, please
>> share a patch for d/rules.
>>
>> Tagging with "help" for now.
> 
> Could you please share a branch or a patch with your attempt? What you

> tried should work, but it's hard to say without looking at the
> implementation in details.

Sure thing, it is in current busybox master on salsa, here:

https://salsa.debian.org/installer-team/busybox/-/blob/master/debian/rules#L172

with udhcpd.service & udhcpd.init in the same dir.



That should do:


diff --git a/debian/rules b/debian/rules
index 04018718b..54e5cc225 100755
--- a/debian/rules
+++ b/debian/rules
@@ -175,6 +175,4 @@ execute_before_dh_installinit-indep:
 override_dh_installsystemd-indep:
 # explicitly list all packages with .service files here
dh_installsystemd -pbusybox-syslogd --name=busybox-klogd
-   dh_installsystemd -pbusybox-syslogd
-# the following does not work (see #1039142 for details):
-#  dh_installsystemd -pudhcpd --no-enable --no-start
+   dh_installsystemd -pudhcpd --no-enable
diff --git a/debian/udhcpd.service b/debian/udhcpd.service
index 0cdc24bc7..0d01d9722 100644
--- a/debian/udhcpd.service
+++ b/debian/udhcpd.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=Busybox udhcpd DHCP daemon
 Documentation=man:udhcpd(8)
-After=syslog.service network.target
+After=network.target

 [Service]
 Environment=DHCPD_OPTS="-S"



Only "--no-enable" is necessary. disabled services won't be (re)started.
Once enabled by the user, future package upgrades will restart the service.

I've also dropped After=syslog.service as syslog is socket activated by 
default, so this is not necessary.



root@pluto:~# apt install /tmp/udhcpd_1.36.1-5_all.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'udhcpd' instead of '/tmp/udhcpd_1.36.1-5_all.deb'
The following NEW packages will be installed:
  udhcpd
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 0 B/12.4 kB of archives.
After this operation, 51.2 kB of additional disk space will be used.
Get:1 /tmp/udhcpd_1.36.1-5_all.deb udhcpd all 1:1.36.1-5 [12.4 kB]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package udhcpd.
(Reading database ... 403057 files and directories currently installed.)
Preparing to unpack /tmp/udhcpd_1.36.1-5_all.deb ...
Unpacking udhcpd (1:1.36.1-5) ...
Setting up udhcpd (1:1.36.1-5) ...
udhcpd.service is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.12.0-1) ...

root@pluto:~# systemctl status udhcpd.service
○ udhcpd.service - Busybox udhcpd DHCP daemon
 Loaded: loaded (/usr/lib/systemd/system/udhcpd.service; disabled; 
preset: enabled)

 Active: inactive (dead)
   Docs: man:udhcpd(8)





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Tokarev]

14.11.2023 14:56, Luca Boccassi wrote:

On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev 
wrote:

..


With just dh_installsystemd --no-enable, it is still started.
With dh_installsystemd --no-enable --no-start, it is started
as well, - apparently because initscript is started.  Also,
with --no-enable --no-start, it is not restarted on upgrades
if enabled locally.

After doing several iterations, I decided to abandon this attempt, -
it just does not work, and I've no time to fight with the tools.

If someone has a working recipe for all this madness, please
share a patch for d/rules.

Tagging with "help" for now.


Could you please share a branch or a patch with your attempt? What you
tried should work, but it's hard to say without looking at the
implementation in details.


Sure thing, it is in current busybox master on salsa, here:

https://salsa.debian.org/installer-team/busybox/-/blob/master/debian/rules#L172

with udhcpd.service & udhcpd.init in the same dir.

Thanks,

/mjt

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Tokarev]

Control: tag -1 + help

On Sun, 25 Jun 2023 23:20:24 +0100 bl...@debian.org wrote:

Package: busybox
Severity: important
User: bl...@debian.org
Usertags: missing-systemd-service

Dear Maintainer(s),

busybox has been flagged by Lintian as shipping a sysv-init script
without a corresponding systemd unit file. The default init system in
Debian is systemd, and so far this worked because a transitional
sysv-init-to-unit generator was shipped by systemd. This is in the
process of being deprecated and will be removed by the time Trixie
ships, so the remaining packages that ship init scripts without
systemd units will stop working.

There are various advantages to using native units, for example the
legacy generator cannot tell the different between a oneshot service
and a long running daemon. Also, sanboxing and security features
become available for services. For more information, consult the
systemd documentation:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html

You can find the Lintian warning here:

https://lintian.debian.org/sources/busybox


This site can't be found.  But it's ok.

So in current state, only udhcpd lacks systemd file.  So I tried to
provide one.  The initscript for udhcpd checks for UDHCPD_ENABLED=yes/no
in /etc/default/udhcpd and does nothing if it is not enabled, which
is the default.  Since there's no way in systemd to check for that
(well, there is, with ExecConditional, but it ugly at best), I thought
to ship udhcpd.service not enabled by default.  Except it doesn't
work.

With just dh_installsystemd --no-enable, it is still started.
With dh_installsystemd --no-enable --no-start, it is started
as well, - apparently because initscript is started.  Also,
with --no-enable --no-start, it is not restarted on upgrades
if enabled locally.

After doing several iterations, I decided to abandon this attempt, -
it just does not work, and I've no time to fight with the tools.

If someone has a working recipe for all this madness, please
share a patch for d/rules.

Tagging with "help" for now.

Thanks,

/mjt

Bug#857763: udhcpd: Please set FEATURE_UDHCPD_WRITE_LEASES_EARLY in build config

[Michael Tokarev]

On Tue, 14 Mar 2017 17:25:50 + Sabahattin Gucukoglu  
wrote:

Source: busybox
Version: 1:1.22.0-19
Severity: wishlist

The dumpleases utility would be made more useful on a system with an SSD if 
FEATURE_UDHCPD_WRITE_LEASES_EARLY were set at build time, because then you 
wouldn't need to set a low auto_time (udhcpd.conf option) to get up-to-date 
lease information from an unprivileged account, without having to first send 
a signal to udhcpd from root. Please set this build option.


I guess it's still too much to write leases file on every DHCP ACK, even 6
years after this bug report has been submitted.

What would be useful though, is for dumpleases to send SIGUSR1 to dhcpd
before reading the leases file.  I guess.  Dunno how it would syncronize
though.

/mjt

Bug#1036446: Bug1036446: Please enable udhcpc6

[Michael Tokarev]

Control: tag -1 + pending

On Sun, 21 May 2023 04:11:09 +0200 Ben Hutchings  wrote:

Package: udhcpc
Version: 1:1.35.0-4+b2
Severity: wishlist
Tags: ipv6

Busybox has a DHCPv6 client (udhcpc6) but this is not included
in the Debian packages.

Please enable CONFIG_UDHCPC6 and the dependent features.


This probably needs udhcpc6 package too, similar to udhcpc package.

/mjt

Bug#925545: udhcpd: support for Runit supervision system

[Michael Tokarev]

On Tue, 26 Mar 2019 17:25:09 + Dmitry Bogatov  wrote:


Package: udhcpd
Version: 1:1.30.1-3
Severity: wishlist
Tags: patch
User: ru...@packages.debian.org
Usertags: runscript


Curious - Why are you filing this against udhcpd only,
why not to do it for other packages too?

Also, how runit handles restarts/reloads/shutdowns,
aren't additional scripts needed for this?

/mjt

Bug#1054557: Suggest home.arpa instead of "make something up" during installation if no dedicated domain name

[Michael Kjörling]

Package: debian-installer
Version: 20230607+deb12u2

As a part of the network configuration during the system installation,
the Debian installer prompts the user for a host name and a domain
name.

The domain name prompt includes the text:

"If you are setting up a home network, you can make something up, but
make sure you use the same domain name on all your computers."

It is generally undesirable to "make something up" with regards to a
domain name, as anything a user is likely to come up with can easily
cause DNS name conflicts either now or in the future, itself leading
to hard-to-diagnose connectivity issues and nonintuitive error
responses. It should be expected that any system installed today
likely will be connected to the Internet; therefore, where possible,
defaults and suggestions should encourage the use of settings which
make conflicts with other hosts on the global Internet less likely.

RFC 8375 of May 2018 (with a current status of Proposed Standard)
specifically reserves a special-use domain name for "non-unique use in
residential home networks". This is similar to the IPv4 address
reservations for "private Internets" in RFC 1918 (192.168.0.0/16,
172.16.0.0/12, 10.0.0.0/8).

The domain name reserved by RFC 8375 for this purpose is "home.arpa.".

The Debian installer should suggest to use that as the domain name
unless the user has specific cause to use a different domain name.

Proposed replacement text:

"If you are setting up or joining a network for which you do not have
another domain name to use, you should enter 'home.arpa' here."

It may even be beneficial if this is also reflected by the field being
pre-populated with "home.arpa".

-- 
Michael Kjörling

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

[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#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty

[Michael Tokarev]

Hi everyone!

Somehow I missed this whole issue, - I didn't see it until now.
Will adjust my mail filters.

08.08.2023 00:49, Philip Hands wrote:

Steve McIntyre  writes:


On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:

Hi Michael,

Cyril Brulebois  (2023-06-28):

Control: reassign -1 busybox-udeb 1:1.36.1-3


[…]


With a local build, confirmed -3 is buggy, and that reverting only
busybox-udeb to -1 is sufficient to restore syslog support in the
installer.

Reassigning there; the GRUB thing can be filed separately once we have
actual information via syslog.


A fix would be appreciated, we've got reports piling up about things we
have no logs for.


After weeks with this breakage, I've just uploaded a minimal NMU to
fix it, reverting the syslog changes since -1. I've buit and tested
successfully locally.


It turned out whole syslog thing in busybox is quite broken, - this is
obvious when you see my initial patch which started whole this issue.
Later on upstream did it in a different way which broke whole thing
entirely, which I tried to fix and it seemed to be working locally, I
notified upstream about the breakage and moved on, thinking it's all
set. But obviously it is not.


Thanks -- and I agree, it works :-)

   https://openqa.debian.net/tests/178534/logfile?filename=DI_syslog.txt

As it happens, over the weekend it occurred to me that I might be able
to pave the way to a fix for this bug by coming up with a test for the
failure.

Awkwardly, syslogd wants to open /dev/log and bails out if it's already
in use, so I resorted to (the somewhat disgusting hack of) using podman:


https://salsa.debian.org/philh/busybox/-/commit/2697f7cce81d1a70de202a30e7062dc9f64a94b1

At least it allows syslogd to run well enough to succeed or fail
similarly to the behaviour seen in the bug.


Gosh..


Here it is going wrong with the -3 code:

   https://salsa.debian.org/philh/busybox/-/jobs/4523822#L3963
   (lines 3969-3975, with the last line showing the entire syslog)

and here is an example of it going right:

   https://salsa.debian.org/philh/busybox/-/jobs/4523808#L3668

   Line 3668 here, saying "PASS: syslogd-works" indicates that we
   succeeded in grepping the test string in /var/log/syslog

The difference between these two is simply disabling
CONFIG_FEATURE_REMOTE_LOG, as seen here:

   
https://salsa.debian.org/philh/busybox/-/commit/89c253f75690dd41487b6fd6f9356a1e890a6ac2

I'm not proposing that as a fix, but it does seem to indicate where the
problem may be located. I'm afraid I've failed to work out what's
actually going wrong here (my C's pretty rusty).

BTW At one point I thought I'd narrowed it down to the while loop here:

   
https://salsa.debian.org/philh/busybox/-/commit/328fdfbe43cd8d9e4425c3ee1c68aadfa44ee434

but if that did work, it does no longer. Either I was mistaken about it
having worked earlier (I'm at least 80% sure that's not the case) or
something non-deterministic is going on ... which makes me wonder if the
underlying cause might be something to do with using uninitialised data
somewhere.

Hopefully this will be of some use to those more familiar with the code.


Oh well. So much work for so minor thing.. :(  I'm sorry for missing whole
thing, I'd act right away and fix whole thing in a minutes.

The whole thing is.. well, quite bad.  We identified a few issues, upstream
syslogd is entirely broken now, remote logging isn't that important and it
has just been enabled, - the fix for now is to just disable remote logging
and to revert to the previous-to-breakage situation as is done in the NMU
(remote logging is a niche thing in this context, while it might be useful
for sure - provided it actually works.)  And ping upstream.

The thing is that upstream will most likely fix it in a different way anyway,
as Denys likes to keep it small even if the code becomes barely readable,
and he has a few common practices which he uses when changing anything.

Thank you all for all this huge work.  Adding podman to the tests is.. oh 
well...

/mjt

Re: Changes to the default rsyslog configuration

[Michael Tokarev]

15.06.2023 15:25, Michael Biebl wrote:


# Log anything besides private authentication messages to a single log file
#
*.*;auth,authpriv.none    -/var/log/syslog

#
# Log commonly used facilities to their own log file
#
auth,authpriv.*        /var/log/auth.log
cron.*    -/var/log/cron.log
kern.*    -/var/log/kern.log
mail.*    -/var/log/mail.log
user.*    -/var/log/user.log


There's no daemon.log. Is it because we already have syslog?

Thanks!

/mjt

Re: Changes to the default rsyslog configuration

[Michael Tokarev]

15.06.2023 15:25, Michael Biebl wrote:

Hi providers of system-log-daemon,

when I started packaging rsyslog for Debian I based /etc/rsyslog.conf on what's been in /etc/syslog.conf at that time (as provided by the no longer 
existing sysklogd).


Unfortunately, this also meant, there was a lot of duplication (say mail messages being logged to 4 different files) and no one could explain to me, 
why we had this duplication / particular setup.


I tried to clean that up for rsyslog during the bookworm release cycle.
My guiding principle was to have a single log file containing everything (minus security sensitive information) and separate log files for commonly 
used facilities that are in use as of today.


I ended up with

#
# Log anything besides private authentication messages to a single log file
#
*.*;auth,authpriv.none    -/var/log/syslog

#
# Log commonly used facilities to their own log file
#
auth,authpriv.*    /var/log/auth.log
cron.*    -/var/log/cron.log
kern.*    -/var/log/kern.log
mail.*    -/var/log/mail.log
user.*    -/var/log/user.log


Hm.  Guess I'll use this for busybox-syslogd too. Thank you for the heads-up,
it come really timely, since just a few days ago I refreshed that package
and was now wondering what files needed to be there.

Another question is whenever to store files as root:adm, mode 0640 by default.
I guess these permissions are set by logrotate, but I'm not sure.

Thank!

/mjt

Changes to the default rsyslog configuration

[Michael Biebl]

Hi providers of system-log-daemon,

when I started packaging rsyslog for Debian I based /etc/rsyslog.conf on 
what's been in /etc/syslog.conf at that time (as provided by the no 
longer existing sysklogd).


Unfortunately, this also meant, there was a lot of duplication (say mail 
messages being logged to 4 different files) and no one could explain to 
me, why we had this duplication / particular setup.


I tried to clean that up for rsyslog during the bookworm release cycle.
My guiding principle was to have a single log file containing everything 
(minus security sensitive information) and separate log files for 
commonly used facilities that are in use as of today.


I ended up with

#
# Log anything besides private authentication messages to a single log file
#
*.*;auth,authpriv.none  -/var/log/syslog

#
# Log commonly used facilities to their own log file
#
auth,authpriv.* /var/log/auth.log
cron.*  -/var/log/cron.log
kern.*  -/var/log/kern.log
mail.*  -/var/log/mail.log
user.*  -/var/log/user.log

[1] contains a more detailed log of the individual changes.
If you want to apply the same set of rules to your log daemon is 
obviously up to you.
I just wanted to give you a heads up, as I think that some consistency 
between different syslog implementations within Debian might be beneficial.


Regards,
Michael


[1] 
https://salsa.debian.org/debian/rsyslog/-/commits/debian/master/debian/rsyslog.conf


OpenPGP_signature
Description: OpenPGP digital signature

Bug#907189: busybox-syslogd: Please provide systemd .service files (attached)

[Michael Tokarev]

21.01.2023 19:49, Michael Tokarev wrote:
..

What's the reason to provide these systemd services for busybox-syslogd?

In my view, busybox-syslogd can be used as a minimal syslogging service
on a bare minimal system without much else besides busybox itself.
On a system with systemd, systemd-journald is already running, and provides
far better logging services than busybox-syslogd, including kernel logging
and /dev/log redirection.

I don't really see the point in providing systemd .services for busybox-syslogd.


After some thinking and facing issues with logging on a low-power machine where
systemd-journald is taking just too much time to find journal entries, I think
it is a good idea to provide busybox-syslogd.

In /etc/init.d/busybox-klogd, we have if running_under_systemd; then exit; fi -
added by me, with a comment stating klogd makes no sense under systemd. This
is apparently wrong, - yes, journald does intercept kernel log and logs it to
the journal, but it suffers from the same prob: on a low-power machine these
journal entries takes ages to retrieve. So it makes sense to package klogd
too, and to provide systemd service file for it.

Doing that now.

/mjt

AW: PANIC Debian 11 LXDE After update no booting is possible

[Schwibinger Michael]

Good afternoon

Thank You.

I am a member of that group.


But they dont know the problem
or a solution.


Where can I ask?

Regards

Sophie





Von: Cyril Brulebois
Gesendet: Montag, 22. Mai 2023 09:10
Bis: Schwibinger Michael
Cc: debian-boot@lists.debian.org
Betreff: Re: PANIC Debian 11 LXDE After update no booting is possible

Hi,

Schwibinger Michael  (2023-05-22):
> Good afternoon
>
> I did the update and
> when doing new start:
> Crash
>
> The message
> panic occured
>
> What did I do wrong?
>
>
> What file should I post here
> for support the help?

This list is about the installer. Please get in touch with some generic
user support list instead, like https://lists.debian.org/debian-user/


Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

PANIC Debian 11 LXDE After update no booting is possible

[Schwibinger Michael]

Good afternoon

I did the update and
when doing new start:
Crash

The message
panic occured

What did I do wrong?


What file should I post here
for support the help?

Regards
Sophie

AW: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[Schwibinger Michael]

Good afternoon

I know that
but the other lists dont have experience with printing.

Thank You.

Can here somebody help
DEBIAN is not booting.

"panic occured".

Regards Sophie

Is there a DEBIAN list for printing?



Von: Steve McIntyre 
Gesendet: Dienstag, 2. Mai 2023 11:06
An: Schwibinger Michael 
Cc: debian-boot@lists.debian.org 
Betreff: Re: EPSON ET M 1120 new printer: If You can read this, you are using 
the wrong driver

On Tue, May 02, 2023 at 07:27:05AM +, Schwibinger Michael wrote:
> EPSON ET M 1120 new printer: If You can read this, you are using the wrong
>driver
>
>
>Good morning.
>Somebody here familiar with a printer?
>
>Regards
>Sophie

This is not the correct list for user support. Please go back to
debian-user or debian-german.

--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[Schwibinger Michael]

 EPSON ET M 1120 new printer: If You can read this, you are using the wrong 
driver


Good morning.
Somebody here familiar with a printer?

Regards
Sophie

Bug#1030850: Please stop creating /etc/timezone

[Michael Biebl]

Source: tzsetup
Version: 1:0.118
Severity: normal
X-Debbugs-Cc: 822...@bugs.debian.org

Hi,

regarding the latest changes in tzdata, which stopped creating
/etc/timezone [1], it was recommended that tzsetup should be updated
accordingly [2].

Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822733
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822733#78

Bug#907189: busybox-syslogd: Please provide systemd .service files (attached)

[Michael Tokarev]

Control: tag -1 + moreinfo

On Fri, 24 Aug 2018 16:39:00 +0200 "W. Martin Borgert"  
wrote:

Package: busybox-syslogd
Version: 1:1.22.0-19
Tags: patch

Please add systemd .service files to busybox-syslogd.
The attached files are taken from OpenEmbedded and
seem to work on my embedded device on Debian 9.
Thanks in advance!


What's the reason to provide these systemd services for busybox-syslogd?

In my view, busybox-syslogd can be used as a minimal syslogging service
on a bare minimal system without much else besides busybox itself.
On a system with systemd, systemd-journald is already running, and provides
far better logging services than busybox-syslogd, including kernel logging
and /dev/log redirection.

I don't really see the point in providing systemd .services for busybox-syslogd.

Thanks,

/mjt

Bug#1023501: busybox-static: version 1:1.35.0-3 breaks boot on hppa

[Michael Tokarev]

Control: tag -1 + confirmed

On Sat, 5 Nov 2022 21:18:58 +0100 Robert Luberda  wrote:

severity 1023501 grave
retitle 1023501 busybox-static: version 1:1.35.0-3 breaks boot on hppa 
and amd64

found 1023501 1:1.35.0-3
notfound 1023501  1:1.35.0-2

On Sat, 05 Nov 2022 13:31:51 + John David Anglin 
 wrote:

> Package: busybox-static
> Version: 1:1.35.0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> With 1:1.35.0-3, boot ends in initramfs:
> 
> Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.

> Begin: Running /scripts/local-premount ... done.
> Begin: Waiting for root file system ... Begin: Running /scripts/local-block 
...
mdadm: No arrays found in config file or automatically
> done.
> Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically

> >
> >  - Missing modules (cat /proc/modules; ls /dev)
> > ALERT!  LABEL=ROOT2 does not exist.  Dropping to a shell!


I had the same issue on amd64.
Removing mdadm package did not help.
Downgrading busybox-static to 1.35.0-2 fixed the issue.


Now this is interesting.  In -3, I included these changes:

commit ac478f88b64d5884d5e81bcd8f8344f0ec72df6a
Author: Michael Tokarev 
Date:   Mon Oct 17 12:52:23 2022 +0300

deb,static: enable blkid applet (useful for rescue purposes)

commit d371992b4a0394f02cd29cb9cb946080414f8afb
Author: Michael Tokarev 
Date:   Mon Oct 17 13:00:16 2022 +0300

deb,static: enable findfs applet (useful for rescue purposes)

Both really are useful for rescue purposes, I've hit this - the lack of
blkid and findfs in busybox - several times, and finally decided to enable
them.. It's a minimal version, it can help in many situations.

But it turns out debian initramfs generator includes its own blkiid, which
is more advanced than busybox's.  For regular (non-static) build, busybox
adds links to itself for applets it have but which aren't provided by other
tools already.  However, for the static build, it has CONFIG_PREFER_APPLETS=y
(in order to be more useful when the filesystem is damaged/incomplete), so
it ignores external implementation of these utilities.  And we end up in
this situation.

And for the static build, it is even more interesting to have these utils
available.

*sigh*

I'll disable one of them for -static build for now, to work around this
issue (have to check which one is to blame, most likely blkid).

But.. *sigh* :)

Thanks,

/mjt

busybox uploads

[Michael Tokarev]

Hi!

I uploaded a new busybox release today (mostly non-linux changes,
it now builds on hurd), but thought maybe I should've asked here
before doing that. But it was too late already.

Should I ask the next time?

Thanks,

/mjt

Re: Firmware GR result - what happens next?

[Michael Stone]

On Fri, Oct 14, 2022 at 10:52:01AM +0200, Santiago Ruano Rincón wrote:

5. transitional packages along with a helper package (that fails or
success during install) to prompt the user so they add non-free-firmware
section when needed.

Is there any reason why you are not considering 5.?


The danger we're trying to avoid is that a system with a working 
"something" (say, networking) gets upgraded, user reboots (or machine 
crashes, or there's a power failure, etc, etc.), the working "something" 
is now a not-working "something", and fixing it is really hard for the 
user who has no idea what happened and maybe doesn't have a network or a 
console or whatever any more. A package that fails during install will 
prevent the upgrade from completing, but will leave things in an 
in-between state until some action is taken, the upgrade restarted, and 
the upgrade manages to finish successfully. What happens if the 
reboot/crash/powercycle/etc happens during that in-between state? How do 
you make a firmware helper package that reliably prevents a kernel 
installation when the kernel doesn't have any dependencies on the 
firmware package, and also doesn't yank out the old working firmware, 
etc. I'm sure you can make the install explode, but making it reliably 
explode at just the right time seems harder. I guess this could all 
work, but I'm seeing a lot of potential for partial installs/failures 
with this approach and I suspect this would require transition code in a 
number of packages' preinsts, not a discrete "helper package".

Bug#1021922: console-setup: FTBFS make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2

[Michael Biebl]

Am 18.10.22 um 17:23 schrieb Samuel Thibault:

Control: severity -1 important

Hello,

Michael Biebl, le lun. 17 oct. 2022 13:53:44 +0200, a ecrit:

Source: console-setup
Version: 1.210
Tags: ftbfs


1.210 does actually build, it's +binnmu1 that doesn't, because + in the
build path gets confused with file assembly on the command line:


umask 022; /<>/Fonts/bdf2psf --log /<>/Fonts/Arabic-Fixed15.log  
/<>/Fonts/bdf/9x15-IL2.bdf+/<>/Fonts/bdf/9x15.bdf+/<>/Fonts/bdf/9x15c.bdf  
/<>/Fonts/standard.equivalents \


Ah, interesting.


I have now uploaded 1.211, which will thus fulfill your NMU need, and be
able to propagate. Leaving this bug as important open since +something
uploads are an important thing to support.


nod

Thanks for the upload, Samuel!


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021922: console-setup: FTBFS make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2

[Michael Biebl]

Source: console-setup
Version: 1.210
Severity: serious
Tags: ftbfs

console-setup FTBFS in unstable

gzip -9n >/acm/VISCII.acm >/<>/acm/VISCII.acm.gz
umask 022; /<>/Fonts/bdf2psf --log 
/<>/Fonts/Arabic-Fixed15.log  
/<>/Fonts/bdf/9x15-IL2.bdf+/<>/Fonts/bdf/9x15.bdf+/<>/Fonts/bdf/9x15c.bdf
  /<>/Fonts/standard.equivalents \

/<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set
 512 /<>/Fonts/Arabic-Fixed15.psf 
/<>/Fonts/Arabic-Fixed15.sfm
umask 022; /<>/Fonts/bdf2psf --log 
/<>/Fonts/Arabic-Fixed16.log  
/<>/Fonts/bdf/georgian16.bdf+/<>/Fonts/bdf/unifont.bdf+/<>/Fonts/bdf/h16.bdf+/<>/Fonts/bdf/etl16-unicode.bdf
  /<>/Fonts/standard.equivalents \

/<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set
 512 /<>/Fonts/Arabic-Fixed16.psf 
/<>/Fonts/Arabic-Fixed16.sfm
umask 022; /<>/Fonts/bdf2psf --log 
/<>/Fonts/Arabic-VGA14.log  
/<>/Fonts/bdf/legacy14i.bdf+/<>/Fonts/bdf/legacy14f.bdf+/<>/Fonts/bdf/legacy14l.bdf+/<>/Fonts/bdf/legacy14b.bdf
  /<>/Fonts/standard.equivalents \

/<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set
 512 /<>/Fonts/Arabic-VGA14.psf 
/<>/Fonts/Arabic-VGA14.sfm
umask 022; /<>/Fonts/bdf2psf --log 
/<>/Fonts/Arabic-VGA16.log  
/<>/Fonts/bdf/u_vga16_fix.bdf+/<>/Fonts/bdf/u_vga16.bdf+/<>/Fonts/bdf/legacy16c.bdf+/<>/Fonts/bdf/legacy16f.bdf+/<>/Fonts/bdf/legacy16k.bdf
  /<>/Fonts/standard.equivalents \

/<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set
 512 /<>/Fonts/Arabic-VGA16.psf 
/<>/Fonts/Arabic-VGA16.sfm
/<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file 
or directory
/<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file 
or directory
make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-Fixed15.psf] Error 
2
make: *** Waiting for unfinished jobs
/<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file 
or directory
make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-Fixed16.psf] Error 
2
make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA14.psf] Error 2
/<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file 
or directory
make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2



Full build log available at
https://buildd.debian.org/status/fetch.php?pkg=console-setup=all=1.210%2Bnmu1=1665832544=0

Re: Firmware GR result - what happens next?

[Michael Stone]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:

Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.


We also try to avoid silent install problems that might or might not 
result in a system that doesn't boot properly.

Re: Firmware GR result - what happens next?

[Michael Stone]

On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:

On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:

What's the plan for upgraded systems with an existing /etc/apt/sources.list.
Will the new n-f-f section added on upgrades automatically(if non-free was
enabled before)?


So this is the one bit that I don't think we currently have a good
answer for. We've never had a specific script to run on upgrades (like
Ubuntu do), so this kind of potentially breaking change doesn't really
have an obvious place to be fixed.


Is there a reason to not continue to make the packages available in 
non-free? I don't see a reason to force any change on existing systems.

Re: Firmware GR result - what happens next?

[Michael Biebl]

Hi Steve,

thanks for the update!

Am 02.10.22 um 16:27 schrieb Steve McIntyre:


* Tweaks to add the non-free-firmware section in the apt-setup module
   if desired/needed.


...


If you think I've missed anything here, please let me and Cyril know -
the best place would be the mailing list
(debian-boot@lists.debian.org).


What's the plan for upgraded systems with an existing 
/etc/apt/sources.list. Will the new n-f-f section added on upgrades 
automatically(if non-free was enabled before)?


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018788: override: rsyslog:admin/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: debian-boot@lists.debian.org


Hi,

as discussed in [1], I'd like to see the priority of rsyslog demoted
from important to optional.
We've been shipping with a persistent journal since bullseye and no
major issues have been reported since then and the feedback has been
positive so far.

Copying the rationale from this email:

The main reason here is, that I want to avoid that log data is stored twice on 
disk.

What exactly would this mean going forward:

- Existing systems will continue to have rsyslog installed (but they can
  safely uninstall rsyslog)

- Newly installed systems will no longer have rsyslog installed, unless
  some other package Depends on either rsyslog | system-log-daemon. But
  my recommendation is, that individual packages do not have a
  Depends/Recommends: rsyslog | system-log-daemon unless it is really
  crucial to their operation. Journald does provide /dev/log and a
  syslog() api call will make sure the log message ends up on persistent
  storage.

- If you prefer rsyslog on a systemd-based system you can easily install
  rsyslog and it will continue to work as-is.


There wasn't that much feedback on this RFC, but no objection afaics, so
I'd like to proceed with this plan.

Regards,
Michael


[1] https://lists.debian.org/debian-devel/2021/11/msg00179.html

Re: busybox upload and further maintenance

[Michael Tokarev]

Ok, it's been almost a month since my initial email here.

If there's no objections, I'll upload the new busybox release tomorrow
(from the "mjt" branch). It's enough waiting :)

I want to enable awk applet for d-i (udeb) config before the upload, for
some things it is much easier to use than e.g. sed.

I do have some more thoughts, including some doubts about the way I changed
the build procedure (it looks like there's a simpler way), but that's for
the future.

Thanks,

/mjt

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Michael Tokarev]

19.05.2022 17:23, Philip Hands wrote:

Michael Tokarev  writes:


19.05.2022 15:59, Philip Hands wrote:
...

Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:

LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
/usr/share/localechooser/languagelist)


That smells like awk usage, not sed ;)


Doh!

I started out with awk, as it's cleaner for this, and then noticed that
we don't have awk enabled in d-i's busybox, so changed to sed.


Is there a reason we don't have awk in busybox? Maybe it's time to enable it?
Some stuff, like this one, is really easier to do with awk.

(and I'm still waiting for a reply from Chris Boot about busybox).

Thanks,

/mjt

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Michael Tokarev]

19.05.2022 15:59, Philip Hands wrote:
...

Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:

   LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
/usr/share/localechooser/languagelist)


That smells like awk usage, not sed ;)

/mjt

Re: ifupdown/dhcp

[Michael Hudson-Doyle]

On Mon, 9 May 2022 at 08:07, Steve Langasek  wrote:

> On Sun, May 08, 2022 at 11:24:12AM -0400, Michael Stone wrote:
> > [apologies to package aliases getting this twice due to autocomplete
> fail]
>
> > I've been trying to make sense of the NEWS item in isc-dhcp-client (that
> > alternatives are needed) in combination with the functionality of
> ifupdown
> > and what the implications are for debian upgrades generally.
>
> > isc-dhcp-client as of the last upgrade is telling users to stop using it
> > (the default dhcp client for debian).
>
> > ifupdown (the traditional tool for managing networking on debian systems)
> > has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a
> > virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been
> > touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a
> > working configuration managed by ifupdown if installed, as it will try to
> > take over interfaces currently set, e.g., to manual). This seems
> suboptimal
> > at best.
>
> > I believe that ifupdown will attempt to use udhcpd if installed, which
> > should be a mostly-transparent change (except for the potential loss of
> > lease information and any customization of dhclient scripts) but it isn't
> > even on the ifupdown recommends list.
>
> > ifupdown also (used to?) use pump, but that package went away a long time
> > ago.
>
> > So what's the path forward, maintaining compatibility and not breaking
> > systems upgrading from current stable? Do we come up with a dhcpcd5
> variant
> > that *only* touches interfaces it is directed to touch via
> > /etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual
> > package and/or make it the default for ifupdown? Do we fork isc's dhcp
> suite
> > and just continue to use dhclient? Revive pump? Something else?
>
> Not an answer to your question, but a related issue I'll mention here.
>
> Ubuntu no longer uses isc-dhcp by default, because it no longer uses
> ifupdown; NetworkManager and networkd both have their own implementations
> of
> dhcp clients which are used by preference.  *However*, isc-dhcp is still
> installed as part of all Ubuntu systems, because it is the only client
> implementation that integrates with initramfs-tools
> (/usr/share/initramfs-tools/hooks/zz-dhclient) so if you are using nfsroot
> or any other network-based rootfs, it appears to still be the only game in
> town.  It would be a good idea to make sure as part of the deprecation of
> isc-dhcp-client that we get initramfs integration of whatever is the
> preferred replacement.
>

Well busybox's udhcpc would seem a likely candidate here -- but its IPv6
support (iirc the reason we switch to dhclient from klibc's ipconfig in
Ubuntu's initramfs, at least) is described as incomplete.

Cheers,
mwh

Bug#980127: busybox-static: Please enable the "hush" applet

[Michael Tokarev]

Control: tag -1 + moreinfo

On Thu, 14 Jan 2021 13:12:58 -0800 Josh Triplett  wrote:

Package: busybox-static
Version: 1:1.30.1-6
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

For busybox-static, I'd love to have the "hush" applet available. It's a
more feature-complete shell, including features such as brace expansion.

Please consider enabling CONFIG_HUSH and CONFIG_HUSH_BASH_COMPAT in
busybox-static.


Hi Josh!

Myself I haven't used hush in busybox but I always used ash. If we're to
enable hush, I think we should remove ash and make hush the only shell.
And do that in regular deb config too, - there's no good reason to keep
them different.

But I wonder what implications we might have there, if we switch from
ash to hush.  How compatible the two shells are? I dunno. I think it
needs to be verified at least..

busybox's ash is very limited indeed.

Thanks,

/mjt

Bug#964579: lsblk not included in busybox version used with installer

[Michael Tokarev]

Control: tag -1 + moreinfo

On Wed, 8 Jul 2020 23:23:51 + Holger Levsen  wrote:

Package: busybox
Version: 1:1.30.1-4
Severity: wishlist
x-debbugs-cc: Russell Weber 
submitter: Russell Weber 

On Wed, Jul 08, 2020 at 02:43:43PM -0600, Russell Weber wrote:
> Package: busybox
> Version: 1:1.30.1-4
> Severity: wishlist
> lsblk is a very useful tool for understanding your current disks and block
> devices. It can be used to
> query lots of information including disk manufacturer, serial number, model
> number, the structure of your disks if the disk is already in use for
> another block device. Given that the installer has mission critical goals
> associated with the disks, it's a bit of a mystery that lsblk isn't
> included into the busy box implementation used in the installer. This is
> especially important when seeding automatic/unattended installs for debian
> since many of the seed files used will query information from disks in
> scripts using the "d-i partman/early_command string" of debconf.  I can see
> that this issue has been raised in multiple places online: stack overflow,
> IRC.  However, scanning older tickets, I was not able to find a ticket
> which raises the issue.  Is there any reason that lsblk as a command is not
> included?  As far as I can tell, the bloat size would only be around 20-40
> KiB in size.  May I suggest that we start including the lsblk binaries in
> the next versions of Debian?


Hi Russel!

Thank you for the detailed bug description.

The only question remain is who will write lsblk for busybox, who
writes the actual code to do all this?  Can you help with that,
to collect all the mentioned information in a useful for the user
form?

This applet is not written.

Thanks,

/mjt

Bug#921556: busybox: Enable more applets to support initramfs-tools

[Michael Tokarev]

Control: tag -1 + upstream

On Wed, 06 Feb 2019 18:58:06 + Ben Hutchings  wrote:

Package: busybox
Version: 1:1.27.2-3
Severity: wishlist

Once we have busybox 1.28.0, we could enable these extra applets on
Linux:

ipconfig  [CONFIG_IPCONFIG]
nuke  [CONFIG_NUKE]
resume[CONFIG_RESUME]
run-init  [CONFIG_RUN_INIT]


So this is almost there, except of ipconfig which is not implemented yet.
There's just a wip version, a first draft, klibc-utils/ipconfig.c.txt,
not touched since initial import in Sep-2017.

It's an interesting goal there, to have everything in busybox to stop
providing two libCs and two shells and two everything in initramfs..

Thanks,

/mjt

Re: busybox upload and further maintenance

[Michael Tokarev]

08.05.2022 23:06, Cyril Brulebois wrote:

Michael Tokarev  (2022-05-08):

The prob is not the burden of maintaining it, I'm okay with that one.
It is just that the whole thing seems wrong :)

Again, I'm definitely not arguing for dropping it right now, but we
either plan to do this some other way, or we don't. If we do, we can
start some discussion/review in this area.


If you want to double check every single place where preseeding can
happen, and prepare a plan to make this patch dispensable, feel free to.
It just seems to me that the cost of doing so is huge compared to the
gain over the current situation it would represent.


yeah, that's a long way forward, I know.


Personally, I'd rather spend my time on finally letting go of gtk2, for
example. (And that's because I have to, not because I want to.)


Yeah.


The argument "it only affects the udeb" is lame :) Udeb does not need
to suffer - neither this one nor any other udeb, and actually it does
not only affect udeb, it affect busybox as a whole, and the upstream
change which we revert is there for a reason :)


For the avoidance of doubt, that patch guards the “new” code with a
macro check, keeping the “old” code when an option is set. That option
is only set in the udeb build:

 debian/config/pkg/deb:# CONFIG_FEATURE_DI_ENV_HACK is not set
 debian/config/pkg/static:# CONFIG_FEATURE_DI_ENV_HACK is not set
 debian/config/pkg/udeb:CONFIG_FEATURE_DI_ENV_HACK=y

so I'm not sure my argument is wrong in addition to being lame?


Cyrill, I was nothing more than joking about the lame part, really.
Please note the smile.

As of the DI_ENV_HACK, I wondered what an interesting name it is,
which is being noticed if I forget to apply patches.  And I stand
corrected, - indeed, you're absolutely right, this is something
specific to udeb due to this new config feature check.  I haven't
noticed it when I initially looked at the patch (briefly).

Thank you for correcting me there!

/mjt

Re: busybox upload and further maintenance

[Michael Tokarev]

08.05.2022 19:39, Cyril Brulebois wrote:

Hi,

Michael Tokarev  (2022-05-08):

I don't understand what is holding an upload right now, -- the salsa
busybox repository is more than 3 months old now.  I think it is ready
for an upload, - I think we should do it and deal with any issues
which may come.


Without knowing about the busybox situation specifically, it happens
that people prepare stuff but don't feel the need or confidence to
upload, so they can stay around for a while.


Yeah, I know this feeling very well, been there myself ;)

I prepared some changes in a separate branch (for now) named "mjt",
it is on top of current master - the changes I'd do in there.
There are many other things in there which needs to be reviewed.

Yet I don't see any reason to hold the upload further.

I'd love to hear opinion by Chris Boot who did most recent work
in there, - if it is okay for him if I merge my branch into
master.  And next, let's upload this thing. I can do that, or
Chris can do that, - provided he is not against me doing some
stuff in there.


In d/patches/ there's a hackish patch temp-deb-installer-hack.patch
which seriously needs addressing I think (not in this upload though),
-- has anything been done in this direction, to get values from the
kernel command line in some more sane place than shell environment?


Oh, what a blast from the past. It's been temporary for 5 years…


Yeah. As usual :)


I'm still not familiar with d-i and its internals, so I need some
help there. At least some discussion should be happening, I think,
because this seems to be a serious change for the d-i.  Yet keeping
this patch does not seem to be a good idea.


Well, I can understand the feeling but unless maintaining the patch
itself is a burden (which I kind of doubt, given it's quite targeted),
in which case I'm happy to help, it only affects the udeb, and makes
sure we don't break preseeding gratuitously…


The prob is not the burden of maintaining it, I'm okay with that one.
It is just that the whole thing seems wrong :)

Again, I'm definitely not arguing for dropping it right now, but we
either plan to do this some other way, or we don't. If we do, we can
start some discussion/review in this area.

The argument "it only affects the udeb" is lame :) Udeb does not need
to suffer - neither this one nor any other udeb, and actually it does
not only affect udeb, it affect busybox as a whole, and the upstream
change which we revert is there for a reason :)

Let's upload the thing and see what happen.

I'm ready to help and to bring it up if it falls into pieces :)

Thanks!

/mjt

Re: ifupdown/dhcp

[Michael Tokarev]

08.05.2022 18:24, Michael Stone wrote:

[apologies to package aliases getting this twice due to autocomplete fail]

I've been trying to make sense of the NEWS item in isc-dhcp-client (that alternatives are needed) in combination with the functionality of ifupdown 
and what the implications are for debian upgrades generally.


isc-dhcp-client as of the last upgrade is telling users to stop using it (the 
default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian systems) has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a 
virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a 
working configuration managed by ifupdown if installed, as it will try to take over interfaces currently set, e.g., to manual). This seems suboptimal 
at best.


I believe that ifupdown will attempt to use udhcpd if installed, which should be a mostly-transparent change (except for the potential loss of lease 
information and any customization of dhclient scripts) but it isn't even on the ifupdown recommends list.


Yes ifupdown knows about udhcpd. I dunno how seriuos this one is, the udhcpcd 
from busybox.
We use it in many different cases locally, and a few times I used it on a 
regular linux
client in various public networks, it is scriptable (it relies on the script to 
do the
actual work).  It is maintained, - well, hopefully, - and in debian, I 
maintained this
package for quite some years locally before, next stepped up as debian 
maintainer of
busybox package, and continue to maintain it locally for another several years. 
Recently
I thought about giving it another try to make it in good shape in debian, and 
others
are doing their work there too.

busybox is recommended by initramfs-tools, so it is installed on all debian 
systems
where install-recommends is not explicitly set to false, so it is always 
available,
more or less (the udhcpcd package is just a symlink to busybox).

But I never really thought about it as an alternative to "big" dhcp client. I 
dunno
why, maybe because I always treated busybox as a "small brother" not ready for
anything serious.

Overall it just works, especially after some tweaks to its script.  Maybe I 
should
give it another try too, I dunno.

What's up with ISC dhclient?

Thanks,

/mjt

busybox upload and further maintenance

[Michael Tokarev]

Hi!

Quite some years ago I stepped down as a busybox maintainer, in a somewhat
scandalous way even, and the details of that story are now started escaping
my memory.  At any rate, I become older, much less touchy than before, and
that time wasn't my easiest period of my life which might have prompted
something unwanted.  I don't remember who was wrong and who was right, if
I you think I did some wrong, please accept my apologies. It definitely
was not my intention to harm anyone, it was just other issues I had at
that time.

Today I thought I'd give busybox another try, if you please.  Just like I
maintained it locally for many years before I become bb maintainer, I
continue to maintain it locally after stepping down (and after nothing
in it happened for years again).

I looked at the current packaging, - Chris Boot did a good job there,
it seems.  It is not an easiest package wrt the amount of bug reports
in there, one has to be brave enough to do some work with it :)

I don't understand what is holding an upload right now, -- the
salsa busybox repository is more than 3 months old now.  I think it
is ready for an upload, - I think we should do it and deal with any
issues which may come.

I'd only do some minor touches there which I noticed immediately -
like, enabling the tr equivalence classes for the static busybox
build too, just like it is done for the regular deb.

In d/patches/ there's a hackish patch temp-deb-installer-hack.patch
which seriously needs addressing I think (not in this upload though), --
has anything been done in this direction, to get values from the
kernel command line in some more sane place than shell environment?

I'm still not familiar with d-i and its internals, so I need some
help there. At least some discussion should be happening, I think,
because this seems to be a serious change for the d-i.  Yet keeping
this patch does not seem to be a good idea.

So, to sum it up the tl;dr way:

- is it okay for you if I help with bb, with its upload and with
  further maintenance?

- is there anything that is holding the upload now which I'm not
  aware of?

- do we have anything in the d-i kernel command line processing
  front, in moving stuff from $env-vars to some saner place?

Thank you!

/mjt

ifupdown/dhcp

[Michael Stone]

[apologies to package aliases getting this twice due to autocomplete fail]

I've been trying to make sense of the NEWS item in isc-dhcp-client 
(that alternatives are needed) in combination with the functionality 
of ifupdown and what the implications are for debian upgrades 
generally.


isc-dhcp-client as of the last upgrade is telling users to stop using 
it (the default dhcp client for debian).


ifupdown (the traditional tool for managing networking on debian 
systems) has a Recommends on "isc-dhcp-client | dhcp-client". 
"dhcp-client" is a virtual package provided by "dhcpcanon" (version 
0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and 
"dhcpcd5" (which will trash a working configuration managed by 
ifupdown if installed, as it will try to take over interfaces 
currently set, e.g., to manual). This seems suboptimal at best.


I believe that ifupdown will attempt to use udhcpd if installed, which 
should be a mostly-transparent change (except for the potential loss 
of lease information and any customization of dhclient scripts) but it 
isn't even on the ifupdown recommends list.


ifupdown also (used to?) use pump, but that package went away a long 
time ago.


So what's the path forward, maintaining compatibility and not breaking 
systems upgrading from current stable? Do we come up with a dhcpcd5 
variant that *only* touches interfaces it is directed to touch via 
/etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" 
virtual package and/or make it the default for ifupdown? Do we fork 
isc's dhcp suite and just continue to use dhclient? Revive pump? 
Something else?

ifupdown/dhcp

[Michael Stone]

I've been trying to make sense of the NEWS item in isc-dhcp-client (that 
alternatives are needed) in combination with the functionality of 
ifupdown and what the implications are for debian upgrades generally.


isc-dhcp-client as of the last upgrade is telling users to stop using it 
(the default dhcp client for debian).


ifupdown (the traditional tool for managing networking on debian 
systems) has a Recommends on "isc-dhcp-client | dhcp-client". 
"dhcp-client" is a virtual package provided by "dhcpcanon" (version 
0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and 
"dhcpcd5" (which will trash a working configuration managed by ifupdown 
if installed, as it will try to take over interfaces currently set, 
e.g., to manual). This seems suboptimal at best.


I believe that ifupdown will attempt to use udhcpd if installed, which 
should be a mostly-transparent change (except for the potential loss of 
lease information and any customization of dhclient scripts) but it 
isn't even on the ifupdown recommends list.


ifupdown also (used to?) use pump, but that package went away a long 
time ago.


So what's the path forward, maintaining compatibility and not breaking 
systems upgrading from current stable? Do we come up with a dhcpcd5 
variant that *only* touches interfaces it is directed to touch via 
/etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual 
package and/or make it the default for ifupdown? Do we fork isc's dhcp 
suite and just continue to use dhclient? Revive pump? Something else?

AW: update possible?

[Schwibinger Michael]

Good morning.
Thank You.
Im sorry.
All my friends do user WIN
or kicked LINUX off and do use WIN.

Regards Sophie



Von: rhkra...@gmail.com 
Gesendet: Mittwoch, 4. Mai 2022 22:53
An: Schwibinger Michael 
Betreff: re: update possible?

Sophie,

(Intenionally writing directly, not to the list.)

Do you feel like you're making any progress?

It doesn't sound like it to me, but maybe I am not interpreting things
corectly.

I would tend to make the same or similar suggestion to Thomas Schmitt's, that
is, find somebody to help you "in person".

Look for a local LUG (Linux User Group) and contact them and see if yu can
either take your computer to one of their meetings for help, or (especially if
there is not a nearby LUG, wirte to them and ask if one of their members lives
near you and would be willing to help.

Good luck!

Randy Kramer

WG: Cannot boot //Questions //Where else can I ask? Part III

[Schwibinger Michael]

Von: Schwibinger Michael 
Gesendet: Samstag, 23. April 2022 12:37
An: Andrew M.A. Cater 
Betreff: AW: Cannot boot //Questions //Where else can I ask? Part III



Hello Andrew!

What did I do wrong.


This email came:


You have added to the subscriber list of:

debian-boot@lists.debian.org

the following mail address:

h...@hotmail.com

Regards
Sophie




Von: Andrew M.A. Cater 
Gesendet: Samstag, 23. April 2022 12:30
An: Schwibinger Michael 
Betreff: Re: Cannot boot //Questions //Where else can I ask? Part III

On Sat, Apr 23, 2022 at 11:57:45AM +, Schwibinger Michael wrote:
>
>
> debian-boot@lists.debian.org
>
> Hello Andrew!
>
> Hello group!
>
>
> Thank You for Your friendly help.
>
>
> What did I do: (UPDATE 9 to 10)
>
>
>
> Edit the file /etc/apt/sources.list using a text editor and replace each 
> instance of stretch with buster.
> Update the packages index on Debian Linux, run:
> sudo apt update
> Prepare for the operating system upgrade, run:
> sudo apt upgrade
> Finally, update Debian 9 to Debian 10 buster by running:
> sudo apt full-upgrade
>
>
> Afterwards
> boot
> Failed
> Panic.
>
> Now I do use revovery.
>
> During booting I can choose
> recovery
>
>
> We do backup every evening.
> Thank You.
>
>
> Because Debian 10 is not working
> we did update to 11.
>
> a Same problem.
>
> b Update did work now we have Debian 11.
>
>
>
>
> How can use an another email debian list.
> Can You send me the subscribe task?
>
> I did not send upgrade
> its to much text,
> but I did save it in a txt file.
>
> But I think
> it did work fine.
>
>
> Please send more questions.
>
>
>
> Regrds
> Sophie
>
>
> Happy weekend
>
>
>

Hello Sophie,

It seems that your messages do not get to debian-boot but maybe
only to me: maybe you are not subscribed.

You almost certainly need:

https://www.debian.org/MailingLists/

and you send a mail to

debian-user-requ...@lists.debian.org

with a subject of

subscribe

to subscribe to the list. I did send you a list of questions earlier
which went directly to you, I think.

If you can summarise the situation so far, we can pick up the discussion
on debian-user

With every good wish - have a good weekend yourself.

Andy Cater
>
>
>
>
>
> here is:
>
>  uname -a and update
>
>
>
> ~$ uname -a
> Linux ah 4.9.0-18-686-pae #1 SMP Debian 4.9.303-1 (2022-03-07) i686 GNU/Linux
>
>
>
> ~$ cat /etc/debian_version
> 11.2
> :~$ su -
> Passwort:
>
>
>
>
> :~# apt-get update
> OK:2 http://deb.debian.org/debian bullseye InRelease
> Ign:3 http://security.debian.org/debian-security bullseye/updates InRelease
> Ign:4 http://repo.vivaldi.com/stable/deb stable InRelease
> Holen:5 http://deb.debian.org/debian bullseye-updates InRelease [39,4 kB]
> Holen:6 http://dl.google.com/linux/chrome/deb stable InRelease [1.811 B]
> Fehl:7 http://security.debian.org/debian-security bullseye/updates Release
>   404  Not Found [IP: 2a04:4e42:62::644 80]
> Holen:8 http://repo.vivaldi.com/stable/deb stable Release [3.840 B]
> Holen:9 http://repo.vivaldi.com/stable/deb stable Release.gpg [833 B]
> Holen:1 https://deb.opera.com/opera stable InRelease [2.590 B]
> Fehl:6 http://dl.google.com/linux/chrome/deb stable InRelease
>   Die folgenden Signaturen konnten nicht überprüft werden, weil ihr 
> öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 78BD65473CB3BD13
> Fehl:9 http://repo.vivaldi.com/stable/deb stable Release.gpg
>   Die folgenden Signaturen konnten nicht überprüft werden, weil ihr 
> öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY FEB6023DC27AA466
> Fehl:1 https://deb.opera.com/opera stable InRelease
>   Die folgenden Signaturen konnten nicht überprüft werden, weil ihr 
> öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY DD3C368A8DE1B7A0
> Paketlisten werden gelesen… Fertig
> E: Das Depot »http://security.debian.org/debian-security bullseye/updates 
> Release« enthält keine Release-Datei.
> N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art 
> durchgeführt werden, daher ist es standardmäßig deaktiviert.
> N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren 
> Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
> W: GPG-Fehler: http://dl.google.com/linux/chrome/deb stable InRelease: Die 
> folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher 
> Schlüssel nicht verfügbar ist: NO_PUBKEY 78BD65473CB3BD13
> E: Das Depot »http://dl.google.com/linux/chrome/deb stable InRelease« ist 
> nicht signiert.
> N: Eine Aktualisierung von solch einem Depot kann nicht 

AW: Cannot boot //Questions //Where else can I ask? Part III

[Schwibinger Michael]

debian-boot@lists.debian.org

Hello Andrew!

Hello group!


Thank You for Your friendly help.


What did I do: (UPDATE 9 to 10)



Edit the file /etc/apt/sources.list using a text editor and replace each 
instance of stretch with buster.
Update the packages index on Debian Linux, run:
sudo apt update
Prepare for the operating system upgrade, run:
sudo apt upgrade
Finally, update Debian 9 to Debian 10 buster by running:
sudo apt full-upgrade


Afterwards
boot
Failed
Panic.

Now I do use revovery.

During booting I can choose
recovery


We do backup every evening.
Thank You.


Because Debian 10 is not working
we did update to 11.

a Same problem.

b Update did work now we have Debian 11.




How can use an another email debian list.
Can You send me the subscribe task?

I did not send upgrade
its to much text,
but I did save it in a txt file.

But I think
it did work fine.


Please send more questions.



Regrds
Sophie


Happy weekend








here is:

 uname -a and update



~$ uname -a
Linux ah 4.9.0-18-686-pae #1 SMP Debian 4.9.303-1 (2022-03-07) i686 GNU/Linux



~$ cat /etc/debian_version
11.2
:~$ su -
Passwort:




:~# apt-get update
OK:2 http://deb.debian.org/debian bullseye InRelease
Ign:3 http://security.debian.org/debian-security bullseye/updates InRelease
Ign:4 http://repo.vivaldi.com/stable/deb stable InRelease
Holen:5 http://deb.debian.org/debian bullseye-updates InRelease [39,4 kB]
Holen:6 http://dl.google.com/linux/chrome/deb stable InRelease [1.811 B]
Fehl:7 http://security.debian.org/debian-security bullseye/updates Release
  404  Not Found [IP: 2a04:4e42:62::644 80]
Holen:8 http://repo.vivaldi.com/stable/deb stable Release [3.840 B]
Holen:9 http://repo.vivaldi.com/stable/deb stable Release.gpg [833 B]
Holen:1 https://deb.opera.com/opera stable InRelease [2.590 B]
Fehl:6 http://dl.google.com/linux/chrome/deb stable InRelease
  Die folgenden Signaturen konnten nicht überprüft werden, weil ihr 
öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 78BD65473CB3BD13
Fehl:9 http://repo.vivaldi.com/stable/deb stable Release.gpg
  Die folgenden Signaturen konnten nicht überprüft werden, weil ihr 
öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY FEB6023DC27AA466
Fehl:1 https://deb.opera.com/opera stable InRelease
  Die folgenden Signaturen konnten nicht überprüft werden, weil ihr 
öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY DD3C368A8DE1B7A0
Paketlisten werden gelesen… Fertig
E: Das Depot »http://security.debian.org/debian-security bullseye/updates 
Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art 
durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren 
Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
W: GPG-Fehler: http://dl.google.com/linux/chrome/deb stable InRelease: Die 
folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher 
Schlüssel nicht verfügbar ist: NO_PUBKEY 78BD65473CB3BD13
E: Das Depot »http://dl.google.com/linux/chrome/deb stable InRelease« ist nicht 
signiert.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art 
durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren 
Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
W: Während der Überprüfung der Signatur trat ein Fehler auf. Das Depot wurde 
nicht aktualisiert und die vorherigen Indexdateien werden verwendet. 
GPG-Fehler: http://repo.vivaldi.com/stable/deb stable Release: Die folgenden 
Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel 
nicht verfügbar ist: NO_PUBKEY FEB6023DC27AA466
W: GPG-Fehler: https://deb.opera.com/opera stable InRelease: Die folgenden 
Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel 
nicht verfügbar ist: NO_PUBKEY DD3C368A8DE1B7A0
E: Das Depot »http://deb.opera.com/opera stable InRelease« ist nicht signiert.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art 
durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren 
Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).






















Von: Andrew M.A. Cater 
Gesendet: Samstag, 23. April 2022 10:19
An: Schwibinger Michael 
Betreff: Re: Cannot boot //Questions //Where else can I ask?

On Sat, Apr 23, 2022 at 05:44:34AM +, Schwibinger Michael wrote:
>
> 
> Von: Schwibinger Michael 
> Gesendet: Donnerstag, 21. April 2022 13:16
> An: Andrew M.A. Cater 
> Betreff: AW: Cannot boot //Questions
>
> Hello Andrew
>
> Thank You
>
> Can You help me.
>
> I did update Debian from 9 to 10.
>
> Now I can only boot in recovery mode.
>
>
> What did I do.
> I copied the tasks from www
&

AW: Cannot boot //Questions //Where else can I ask?

[Schwibinger Michael]

Von: Schwibinger Michael 
Gesendet: Donnerstag, 21. April 2022 13:16
An: Andrew M.A. Cater 
Betreff: AW: Cannot boot //Questions

Hello Andrew

Thank You

Can You help me.

I did update Debian from 9 to 10.

Now I can only boot in recovery mode.


What did I do.
I copied the tasks from www
and the I wrote in the terminal the tasks.

Then I tried to reboot.
PANIC occured.

What I shall send on kind of information .

Thank You

Sophie

DEBIAN did do the update.



Von: Andrew M.A. Cater 
Gesendet: Donnerstag, 21. April 2022 12:51
An: debian-boot@lists.debian.org 
Betreff: Re: Cannot boot

On Thu, Apr 21, 2022 at 06:34:45AM +, Schwibinger Michael wrote:
> Hello Group
> We did update Debian LXDE 32
> and now we cannot boot.
> Can somebody help?
> Regards
> Sophie

Hello Sophie,

You may find it easier to ask this question on the Debian user mailing list.

Which version of Debian did you install - and from where dit you get the
installation media.

"Cannot boot" is very wide: can you be more specific as to exactly what
does or doesn't happen, please?

Follow up to the debian-user list, maybe.

With every good wish, as ever,

Andrew Cater

Cannot boot

[Schwibinger Michael]

Hello Group
We did update Debian LXDE 32
and now we cannot boot.
Can somebody help?
Regards
Sophie

Bug#1009309: udhcpc: allow usage without busybox

[Michael Tokarev]

13.04.2022 09:31, Helmut Grohne wrote:

Control: tags -1 + moreinfo

On Wed, Apr 13, 2022 at 09:13:58AM +0300, Michael Tokarev wrote:

No, as far as I understand. B/c udhcpc package lacks the main binary
if there's no busybox... ;)

Can you explain please? :)


Head -> table. I now understand why udhcpc is so small. Thank you for
your kind reply. There is nothing to change here. I'll look into the
reverse (and usual) solution to space saving: replace everything else
with busybox.


That was good Helmut!  Thank you!


On a related note, I have been wondering whether we could somehow put
the integration of busybox on more solid footing. A possible route could
be adding tiny symlink packages e.g. iproute2-minimal containing ip,
kmod-minimal containing lsmod and friends or procps-minimal containing
top et al. These would have to conflict with iproute2, kmod and procps
respectively as they're sharing paths. To make that actually useful,
downstream packages could update their depends to foo | foo-minimal when
they are known to work with busybox. If toybox wants to join, -minimal
would refer to the minimal baselines provided by both busybox and
toybox. It's a lot of small packages and metadata though. I'm not
convinced yet and merely sharing thoughts. Properly minimizing Debian
chroots with busybox is not a "it just works" experience yet.


I thought about this back when I stepped on as busybox maintainer a few
years back.  Busybox isn't really suitable as a full-blown implementation
for many system utilities. For one, quite some things on the system will
break when you replace something with busybox, due to maintscripts, or
startup scripts, whatever, usage of options/features/lack-of-bugs of the
busybox's large brothers. Eg, file^Wcoreutils or [mg]awk provides much
more features than busybox counterparts, and these features are being
used in debian.  This isn't difficult to fix in most places but you
know the drill with cross-compile, how slow this process is :)

But busybox is basically not maintained in Debian. I tried to at least
reduce the number of active bug reports (there were many of them),
updated version to current one (previous update was a few versions
behind), tried to sync different configuration with each other and
with reality.. until something happened a few debian releases ago
and I was pissed off and stepped down.  I don't even remember what
happened, just a vague memory of someone uploading busybox backing
up changes I did and refusing my changes to go, or some such..  So
after that, busybox basically froze again.  I still maintain it
locally for our needs just like I did before, but I don't do that
in Debian anymore.  Maybe I should try again...

/mjt

Bug#1009309: udhcpc: allow usage without busybox

[Michael Tokarev]

11.04.2022 15:21, Helmut Grohne wrote:

Source: busybox
Version: 1:1.30.1-7
Severity: wishlist
Tags: patch

Hi Aurelien,

would it be possible to avoid the udhcpc -> busybox dependency? It may
seem strange to remove busybox in a quest to reduce file system usage at
first, but if you need iproute2 for other reasons, it should be fine at
providing what udhcpc needs. I'm attaching a patch so you can judge the
impact.


Helmut, I'm not sure I follow you here. udhcpc itself is provided by
bysybox. There's no udhcpc without busybox. udhcpc package is just a
set of support files for busybox's udhcpc applet. This is exactly why
I implemented it this way in the dhcp script: we're absolutely sure
busybox implementations of awk and ip are always here, since without
these there would be udhcpc.


If that's not a reasonable move forward, how about demoting the
dependency to Recommends? Admittedly, the case of using udhcpc without


No, as far as I understand. B/c udhcpc package lacks the main binary
if there's no busybox... ;)

Can you explain please? :)

/mjt

Bug#1009134: installation-reports: installation went well

[Michael Lee]

Package: installation-reports
Severity: minor
Tags: ipv6

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: network
Image version: ???
Date: 2019>

Machine: Intel i7
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:




Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u3"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux Clyde 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DMI 
[8086:d131] (rev 11)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5000]
lspci -knn: 00:03.0 PCI bridge [0604]: Intel Corporation Core Processor PCI 
Express Root Port 1 [8086:d138] (rev 11)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Core Processor 
System Management Registers [8086:d155] (rev 11)
lspci -knn: 00:08.1 System peripheral [0880]: Intel Corporation Core Processor 
Semaphore and Scratchpad Registers [8086:d156] (rev 11)
lspci -knn: 00:08.2 System peripheral [0880]: Intel Corporation Core Processor 
System Control and Status Registers [8086:d157] (rev 11)
lspci -knn: 00:08.3 System peripheral [0880]: Intel Corporation Core Processor 
Miscellaneous Registers [8086:d158] (rev 11)
lspci -knn: 00:10.0 System peripheral [0880]: Intel Corporation Core Processor 
QPI Link [8086:d150] (rev 11)
lspci -knn: 00:10.1 System peripheral [0880]: Intel Corporation Core Processor 
QPI Routing and Protocol Registers [8086:d151] (rev 11)
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 
Series Chipset USB Universal Host Controller [8086:3b3b] (rev 06)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 5 Series/3400 
Series Chipset USB Universal Host Controller [8086:3b3e] (rev 06)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.2 USB controller [0c03]: Intel Corporation 5 Series/3400 
Series Chipset USB Universal Host Controller [8086:3b3f] (rev 06)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 5 Series/3400 
Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5006]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series 
Chipset High Definition Audio [8086:3b56] (rev 06)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:a102]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series 
Chipset PCI Express Root Port 1 [8086:3b42] (rev 06)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series 
Chipset PCI Express Root Port 4 [8086:3b48] (rev 06)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series 
Chipset PCI Express Root Port 5 [8086:3b4a] (rev 06)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series 
Chipset PCI Express Root Port 6 [8086:3b4c] (rev 06)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.6 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series 
Chipset PCI Express Root Port 7 [8086:3b4e] (rev 06)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 

Bug#1000239: Rescue system won't find root partition, but insists on /usr

[Michael Biebl]

Am 03.12.2021 um 22:08 schrieb Nicholas D Steeves:

2. Reassign to src:rescue, and fix the rescue system.


Looks like a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769738

Bug#994905: override: systemd-timesyncd:admin/standard

[Michael Biebl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: debian-boot@lists.debian.org, 
pkg-systemd-maintain...@lists.alioth.debian.org, debian-rele...@lists.debian.org

Hi FTP team,

I just uploaded systemd 247.9-2 to fix #986651 [0] and #993947 [1]
In this upload, I demoted systemd-timesyncd from a Depends to
Recommends. As discussed in the above bug report, to ensure that
systemd-timesycnd is still installed in a default d-i based
installation (including the standard task), I'd like to see the priority
of systemd-timesyncd bumped accordingly.

This is similar to what's has been done to libpam-systemd in [2]

I'd like to make this change for both unstable/testing and stable. I've
CCed the debian-release mailing list accordingly for their input.


Regards,
Michael

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986651
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993947
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803184

Re: Bug#983357: Netinst crashes xen domU when loading kernel

[Michael Biebl]

Hi Phillip

Am 24.05.2021 um 06:19 schrieb Cyril Brulebois:

trigger to cold plug all devices.  Both scripts are set -e.  The Xen
Virtual Keyboard driver and at least one other driver have always failed
to trigger due to having absurdly long modalias, but the error used to
be ignored.  The kernel now returns the error to udevadm


So this is a change in behaviour in the kernel?
What happens if you boot the installed system? Does udevadm trigger fail 
there as well?


I feel a bit uneasy changing the udev start script this late in the 
release cycle (especially when it appears like covering up an issue 
someplace else).


I'll let Marco make the judgement on this though, as he has the most 
experience with those udev udeb start scripts as the original author.


Michael

Bug#987441: debian-installer: D-I must get ready for Bullseye

[Michael Biebl]

Hi kibi

On Fri, 23 Apr 2021 22:57:40 +0200 Cyril Brulebois  wrote:

>  - broken rescue mode

Is this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952450 or
something else?
I.e. do you consider #952450 a blocker for d-i?

Regards,
Michael


signature.asc
Description: This is a digitally signed message part

Re: Bug#986758: unblock: systemd/247.3-5

[Michael Biebl]

Am 14.04.21 um 14:27 schrieb Ivo De Decker:

Control: tags -1 confirmed d-i

Hi,

On Mon, Apr 12, 2021 at 08:54:51PM +0200, Michael Biebl wrote:

control: retitle -1 unblock: systemd/247.3-5


This look ok. Kibi was already in Cc for the unblock-udeb (the original 

mail

is quoted below).



Oops, I mixed up the order of the git tags when generating the debdiff. 
So in the diff, please replace + with - and vice versa.
I think this mistake was quite obvious, that said, a corrected debdiff 
is attached.


Regards,
Michael

diff --git a/debian/changelog b/debian/changelog
index 0588fec..22a8ad2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,27 @@
+systemd (247.3-5) unstable; urgency=medium
+
+  * udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks.
+As systemd-udevd no longer sets them up itself, we create them manually
+after mounting devtmpfs. This avoids breaking applications which expect
+those symlinks. (Closes: #975018)
+
+ -- Michael Biebl   Mon, 12 Apr 2021 20:21:24 +0200
+
+systemd (247.3-4) unstable; urgency=medium
+
+  [ Luca Boccassi ]
+  * Backport patch to fix assert with invalid LoadCredentials=
+Regression introduced in v247, fixed in v249, see:
+https://github.com/systemd/systemd/issues/19178
+(Closes: #986302)
+
+  [ Michael Biebl ]
+  * network: Delay addition of IPv6 Proxy NDP addresses.
+Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
+networkd adds them". (Closes: #985510)
+
+ -- Michael Biebl   Sun, 11 Apr 2021 16:06:46 +0200
+
 systemd (247.3-3) unstable; urgency=medium
 
   * pkg-config: make prefix overridable again (Closes: #984763)
diff --git a/debian/extra/start-udev b/debian/extra/start-udev
index 6048925..0a8b284 100755
--- a/debian/extra/start-udev
+++ b/debian/extra/start-udev
@@ -6,6 +6,11 @@ fi
 
 if ! grep -E -q "^[^[:space:]]+ /dev devtmpfs" /proc/mounts; then
 mount -n -o mode=0755 -t devtmpfs devtmpfs /dev
+# Setup a few /dev symlinks, see #975018
+[ ! -h /dev/fd ] && ln -s /proc/self/fd /dev/fd
+[ ! -h /dev/stdin ] && ln -s /proc/self/fd/0 /dev/stdin
+[ ! -h /dev/stdout ] && ln -s /proc/self/fd/1 /dev/stdout
+[ ! -h /dev/stderr ] && ln -s /proc/self/fd/2 /dev/stderr
 fi
 
 SYSTEMD_LOG_LEVEL=notice /lib/systemd/systemd-udevd --daemon 
--resolve-names=never
diff --git 
a/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch 
b/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
new file mode 100644
index 000..c9e3500
--- /dev/null
+++ b/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
@@ -0,0 +1,34 @@
+From: Luca Boccassi 
+Date: Thu, 1 Apr 2021 22:18:29 +0100
+Subject: LoadCredentials: do not assert on invalid syntax
+
+LoadCredentials=foo causes an assertion to be triggered, as we
+are not checking that the rvalue's right hand side part is non-empty
+before using it in unit_full_printf.
+
+Fixes #19178
+
+# printf [Service]nLoadCredential=passwd.hashed-password.rootn > hello.service
+# systemd-analyze verify ./hello.service
+...
+Assertion 'format' failed at src/core/unit-printf.c:232, function 
unit_full_printf(). Aborting.
+Aborted (core dumped)
+
+(cherry picked from commit f7a6f1226e800f7695c2073675523062ea697aa4)
+---
+ src/core/load-fragment.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
+index 4964249..5b66fb1 100644
+--- a/src/core/load-fragment.c
 b/src/core/load-fragment.c
+@@ -4569,7 +4569,7 @@ int config_parse_load_credential(
+ r = extract_first_word(, , ":", 
EXTRACT_DONT_COALESCE_SEPARATORS);
+ if (r == -ENOMEM)
+ return log_oom();
+-if (r <= 0) {
++if (r <= 0 || isempty(p)) {
+ log_syntax(unit, LOG_WARNING, filename, line, r, "Invalid 
syntax, ignoring: %s", rvalue);
+ return 0;
+ }
diff --git 
a/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch 
b/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch
index 466a232..1b5b03d 100644
--- a/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch
+++ b/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch
@@ -16,7 +16,7 @@ Closes: #981407
  3 files changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
-index 4964249..2d48783 100644
+index 5b66fb1..df5669a 100644
 --- a/src/core/load-fragment.c
 +++ b/src/core/load-fragment.c
 @@ -372,6 +372,7 @@ static int patch_var_run(
diff --git 
a/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch 
b/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch
new file mode 100644
index 000..055c598
--- /dev/null
+++ b/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch
@@ -0,0 +1,86 @@
+From: "Kevi

Re: Bug#986758: unblock: systemd/247.3-5

[Michael Biebl]

control: retitle -1 unblock: systemd/247.3-5

Am 11.04.21 um 18:48 schrieb Luca Boccassi:

Please unblock package systemd

As requested by Michael, opening unblock ticket. Debdiff attached. Two
high-impact patches are backported from upstream and should be included
in Bullseye.


Thanks Luca!


* Backport patch to fix assert with invalid LoadCredentials=
   Regression introduced in v247, fixed in v249, see:
   https://github.com/systemd/systemd/issues/19178
   (Closes: #986302)

* network: Delay addition of IPv6 Proxy NDP addresses.
   Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
   networkd adds them". (Closes: #985510)

The first patch fixes a crash when a malformed option is set in any
unit.

unblock systemd/247.3-4


I decided to make a 247.3-5 upload to fix #975018 as well:


udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks

As systemd-udevd no longer sets them up itself, we create them manually

after mounting devtmpfs. This avoids breaking applications which expect



Somehow this issue did not show up on the systemd bug tracker, so I 
completely forgot about it. Apologies for that.


This fixes a regression which e.g. broke fetch-url and triggered a 
workaround in debian-installer-utils_1.134:



   [ Raphaël Hertzog ]
   * Use /proc/self/fd/4 instead of /dev/fd/4 to unbreak fetch-url with 

recent

 udev versions that no longer setup the /dev/fd symlink. Closes: #967546



I'd rather see this fixed for good. It's possible that other 
applications expect those symlinks as well.


This does affect udev-udeb, so kibi's ack would be appreciated.

Thanks for considering,
Michael


unblock systemd/247.3-5
diff --git a/debian/changelog b/debian/changelog
index 22a8ad2..0588fec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,27 +1,3 @@
-systemd (247.3-5) unstable; urgency=medium
-
-  * udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks.
-As systemd-udevd no longer sets them up itself, we create them manually
-after mounting devtmpfs. This avoids breaking applications which expect
-those symlinks. (Closes: #975018)
-
- -- Michael Biebl   Mon, 12 Apr 2021 20:21:24 +0200
-
-systemd (247.3-4) unstable; urgency=medium
-
-  [ Luca Boccassi ]
-  * Backport patch to fix assert with invalid LoadCredentials=
-Regression introduced in v247, fixed in v249, see:
-https://github.com/systemd/systemd/issues/19178
-(Closes: #986302)
-
-  [ Michael Biebl ]
-  * network: Delay addition of IPv6 Proxy NDP addresses.
-Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
-networkd adds them". (Closes: #985510)
-
- -- Michael Biebl   Sun, 11 Apr 2021 16:06:46 +0200
-
 systemd (247.3-3) unstable; urgency=medium
 
   * pkg-config: make prefix overridable again (Closes: #984763)
diff --git a/debian/extra/start-udev b/debian/extra/start-udev
index 0a8b284..6048925 100755
--- a/debian/extra/start-udev
+++ b/debian/extra/start-udev
@@ -6,11 +6,6 @@ fi
 
 if ! grep -E -q "^[^[:space:]]+ /dev devtmpfs" /proc/mounts; then
 mount -n -o mode=0755 -t devtmpfs devtmpfs /dev
-# Setup a few /dev symlinks, see #975018
-[ ! -h /dev/fd ] && ln -s /proc/self/fd /dev/fd
-[ ! -h /dev/stdin ] && ln -s /proc/self/fd/0 /dev/stdin
-[ ! -h /dev/stdout ] && ln -s /proc/self/fd/1 /dev/stdout
-[ ! -h /dev/stderr ] && ln -s /proc/self/fd/2 /dev/stderr
 fi
 
 SYSTEMD_LOG_LEVEL=notice /lib/systemd/systemd-udevd --daemon 
--resolve-names=never
diff --git 
a/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch 
b/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
deleted file mode 100644
index c9e3500..000
--- a/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From: Luca Boccassi 
-Date: Thu, 1 Apr 2021 22:18:29 +0100
-Subject: LoadCredentials: do not assert on invalid syntax
-
-LoadCredentials=foo causes an assertion to be triggered, as we
-are not checking that the rvalue's right hand side part is non-empty
-before using it in unit_full_printf.
-
-Fixes #19178
-
-# printf [Service]nLoadCredential=passwd.hashed-password.rootn > hello.service
-# systemd-analyze verify ./hello.service
-...
-Assertion 'format' failed at src/core/unit-printf.c:232, function 
unit_full_printf(). Aborting.
-Aborted (core dumped)
-
-(cherry picked from commit f7a6f1226e800f7695c2073675523062ea697aa4)

- src/core/load-fragment.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
-index 4964249..5b66fb1 100644
 a/src/core/load-fragment.c
-+++ b/src/core/load-fragment.c
-@@ -4569,7 +4569,7 @@ int config_parse_load_credential(
- r = extract_first_word(, , ":", 
EXTRACT_DONT_COALESCE_SEPARATORS);
- if (r == -ENOMEM)
- return log_oom();
--if (r <= 0) {
-+if (r 

Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked

[Michael Biebl]

On Mon, 24 Feb 2020 17:38:53 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?=
 wrote:
> Package: user-setup
> Version: 1.83
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> 
> Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
> the systemd-sulogin-shell binary run by rescue.service and
> emergency.service now adds the --force flag for the sulogin call
> when SYSTEMD_SULOGIN_FORCE is set to 1 in the environment.
> 
>
https://github.com/systemd/systemd/commit/33eb44fe4a8d7971b5614bc4c2d90f8d91cce66c
> explains that the expectation is that distributions should now
> put service override files to set this environment variable.
> 
> Thus user-setup should create the appropriate configuration file when
> the root account is not configured. Maybe this should be controlled
> by some low priority debconf question as the password-less login through
> the rescue boot entry can be seen as a security issue by some.
> 

There is https://salsa.debian.org/ah/user-setup/commits/wip/rootpassword
thanks to Andreas.

I'd suggest that people caring about that issue submit this as proper MR.

Regards,
Michael


signature.asc
Description: This is a digitally signed message part

Bug#985096: unblock: systemd/247.3-3

[Michael Biebl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org, 
debian-boot@lists.debian.org, k...@debian.org

Please unblock package systemd

I'd like to see systemd 247.3 unblocked.
It contains a number of fixes which are not critical but which I
consider polishing. Given the importance of the systemd package, I think
those changes are worthwile.

An annotated changelog follows:

systemd (247.3-3) unstable; urgency=medium

  * pkg-config: make prefix overridable again (Closes: #984763)

https://salsa.debian.org/systemd-team/systemd/-/commit/deaf89e4cbb5d1347a1e17f782df2e56ee58e42c
cherry-pick from upstream, low risk change, was explicitly requested for
development environments like jhbuild

  * Downgrade a couple of warnings to debug.
If a package still ships only a SysV init script or if a service file or
tmpfile uses /var/run, downgrade those messages to debug. We can use
lintian to detect those issues.
For service files and tmpfiles in /etc, keep the warning, as those files
are typically added locally and aren't checked by lintian.
(Closes: #981407)

https://salsa.debian.org/systemd-team/systemd/-/commit/0c6d90f783093fc255e529f8a33b2ed2a8e6c2d6
given that it only downgrades a couple of warnings, low regression
potential.

  * core: fix mtime calculation of dropin files
(Closes: #975289)

https://salsa.debian.org/systemd-team/systemd/-/commit/39391c55cf5cee23f934e8ee29c9613ff4d33ed0
cherry-pick from upstream, probably the highest regression potential
from all changes. Fixes an annoying issue where systemd would
incorrectly report, that a .service file with .drop-in config was
modified on disk and requires a daemon-reload.

  * analyze: slightly reword PrivateTmp= message
(Closes: #931753)

https://salsa.debian.org/systemd-team/systemd/-/commit/2ab3ec0387b12be15a2b61d3edc90929ec64d6a2
cherry-pick from upstream, trivial documentation update


 * rules: move ID_SMARTCARD_READER definition to a <70 configuration
(Closes: #978011)

https://salsa.debian.org/systemd-team/systemd/-/commit/7d68acb67f2ff402fb764664a3b686ff7df424ae
cherry-pick from upstream, trivial change

  * table: drop trailing white spaces of the last cell in row
(Closes: #980820)

https://salsa.debian.org/systemd-team/systemd/-/commit/7018915f046893bb013ac7fa09f3c95824e3cbc3
cherry-pick from upstream, fixes a regression compared to v241, i.e. the
current version in buster. It's more of a cosmetic issue, but the change
is rather small and if by chance it helps to fix scripts which parse the
output of systemd's tools, then it's probably worthwile to have this
change.

 -- Michael Biebl   Sat, 06 Mar 2021 22:32:14 +0100

We run a rather extensive test-suite and a we also have a lot of reverse
dependencies which were triggered by the upload, so the chances of a
(major) regression are small.

Full debdiff is attached. I've CCed kibi/debian-boot, since we build a
udeb.


Thanks for considering. If there are chances above which you don't
consider appropriate, please let me know and I will revert them in a -4
upload.

Regards,
Michael


unblock systemd/247.3-3
diff --git a/debian/changelog b/debian/changelog
index d1b21bb..0588fec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,37 @@
+systemd (247.3-3) unstable; urgency=medium
+
+  * pkg-config: make prefix overridable again (Closes: #984763)
+  * Revert "units: turn off DNSSEC validation when timesyncd resolves
+hostnames"
+Support for SYSTEMD_NSS_RESOLVE_VALIDATE=0 requires the changes from
+https://github.com/systemd/systemd/pull/17823 for the dnssec bypass
+logic. Those are rather invasive changes and not suitable for a stable
+backport.
+
+ -- Michael Biebl   Thu, 11 Mar 2021 18:09:35 +0100
+
+systemd (247.3-2) unstable; urgency=medium
+
+  * Downgrade a couple of warnings to debug.
+If a package still ships only a SysV init script or if a service file or
+tmpfile uses /var/run, downgrade those messages to debug. We can use
+lintian to detect those issues.
+For service files and tmpfiles in /etc, keep the warning, as those files
+are typically added locally and aren't checked by lintian.
+(Closes: #981407)
+  * core: fix mtime calculation of dropin files
+(Closes: #975289)
+  * analyze: slightly reword PrivateTmp= message
+(Closes: #931753)
+  * rules: move ID_SMARTCARD_READER definition to a <70 configuration
+(Closes: #978011)
+  * units: turn off DNSSEC validation when timesyncd resolves hostnames
+(Closes: #898530)
+  * table: drop trailing white spaces of the last cell in row
+(Closes: #980820)
+
+ -- Michael Biebl   Sat, 06 Mar 2021 22:32:14 +0100
+
 systemd (247.3-1) unstable; urgency=medium
 
   [ Michael Biebl ]
diff --git a/debian/patches/analyze-slightly-reword-PrivateTmp-message.patch 
b/debian/patches/analyze-slightly-reword-PrivateTmp-m

Re: Bug#983197: debootstrap: autopkgtest regression under autopkgtest-virt-qemu

[Michael Tokarev]

22.02.2021 13:00, Simon McVittie wrote:

Control: reassign -1 src:debootstrap 1.0.123
Control: retitle -1 debootstrap: autopkgtest regression under 
autopkgtest-virt-qemu

[]

not ok 19 - unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version /dev/null
not ok 20 - script(1) should work under (fake) schroot


Can it be #983087 ?

Thanks,

/mjt

Re: Bug#981345: buster-pu: package systemd/241-7~deb10u6

[Michael Biebl]

Am 30.01.21 um 09:42 schrieb Cyril Brulebois:

Michael Biebl  (2021-01-29):

CCed kibi/debian-boot, as usual.

The udev package should not be affected, as the above change only
affects the journal, which is not used in d-i.

The regression potential is rather low. The fix itself is a
cherry-pick from upstream and has been part of sid/testing since
quite a while.


Sure thing, fine with me!




Uploaded. Thanks all for the quick replies.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981345: buster-pu: package systemd/241-7~deb10u6

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org, k...@debian.org, 
debian-boot@lists.debian.org

Hi,

I'd like to make a stable upload for systemd fixing #975561:

  journal: do not trigger assertion when journal_file_close() get NULL

The rest is autopkgtest updates, as the current state is a bit sad [1]
on stable.

The full (annotated) changelog is

systemd (241-7~deb10u6) buster; urgency=medium

  * journal: do not trigger assertion when journal_file_close() get NULL
(Closes: #975561)

https://salsa.debian.org/systemd-team/systemd/-/commit/42f62d560748cf79353d0a66d1ccf49517f951d3

* test-bpf: skip test when run inside containers.
The test reliably fails inside LXC and Docker when run on a new enough
kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
issue and apparently there is no real interest to get this fixed, so
let's skip this test.

https://salsa.debian.org/systemd-team/systemd/-/commit/de5350a0090a51ba391baf57e5d3e549bf126a6b

  * autopkgtest: mark networkd-test.py as flaky.
See https://github.com/systemd/systemd/issues/18357
and https://github.com/systemd/systemd/issues/18196

https://salsa.debian.org/systemd-team/systemd/-/commit/996babe874059cc70f54f4edbd3e00a46a208bb7


CCed kibi/debian-boot, as usual.
The udev package should not be affected, as the above change only
affects the journal, which is not used in d-i.
The regression potential is rather low. The fix itself is a cherry-pick
from upstream and has been part of sid/testing since quite a while.


Regards,
Michael


[1] https://ci.debian.net/packages/s/systemd/


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 8c3b276..61dcee2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+systemd (241-7~deb10u6) buster; urgency=medium
+
+  * journal: do not trigger assertion when journal_file_close() get NULL
+(Closes: #975561)
+  * test-bpf: skip test when run inside containers.
+The test reliably fails inside LXC and Docker when run on a new enough
+kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
+issue and apparently there is no real interest to get this fixed, so
+let's skip this test.
+  * autopkgtest: mark networkd-test.py as flaky.
+See https://github.com/systemd/systemd/issues/18357
+and https://github.com/systemd/systemd/issues/18196
+
+ -- Michael Biebl   Fri, 29 Jan 2021 15:16:06 +0100
+
 systemd (241-7~deb10u5) buster; urgency=medium
 
   * basic/cap-list: parse/print numerical capabilities (Closes: #964926)
diff --git a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch 
b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
index 231158c..78c2d01 100644
--- a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
+++ b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
@@ -30,7 +30,7 @@ index 2791678..3a9e20a 100644
  systemd.journald.forward_to_syslog,
  systemd.journald.forward_to_kmsg,
 diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index 2a960eb..7fe0f82 100644
+index ba0b35d..cd45212 100644
 --- a/src/journal/journald-server.c
 +++ b/src/journal/journald-server.c
 @@ -1835,6 +1835,7 @@ int server_init(Server *s) {
diff --git 
a/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
 
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
new file mode 100644
index 000..9cb536b
--- /dev/null
+++ 
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
@@ -0,0 +1,46 @@
+From: Yu Watanabe 
+Date: Tue, 28 May 2019 12:40:17 +0900
+Subject: journal: do not trigger assertion when journal_file_close() get NULL
+
+We generally expect destructors to not complain if a NULL argument is passed.
+
+Closes #12400.
+
+(cherry picked from commit c377a6f3ad3d9bed4ce7e873e8e9ec6b1650c57d)
+---
+ src/journal/journal-file.c| 3 ++-
+ src/journal/journald-server.c | 7 ++-
+ 2 files changed, 4 insertions(+), 6 deletions(-)
+
+diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
+index 56827f9..04cf1ef 100644
+--- a/src/journal/journal-file.c
 b/src/journal/journal-file.c
+@@ -335,7 +335,8 @@ bool journal_file_is_offlining(JournalFile *f) {
+ }
+ 
+ JournalFile* journal_file_close(JournalFile *f) {
+-assert(f);
++if (!f

Bug#689528: please add virtio support for cdrom at install time

[Michael Tokarev]

22.01.2020 09:18, Witold Baryluk wrote:

Package: debian-installer
Followup-For: Bug #689528

Dear Maintainer,

any progress on this, I still have this issue.


Out of curiosity, _why_ this is necessary?
For the install time, isn't it trivial to use regular ide/sata cdrom
drive or an usb flash instead of more exotic ways? Most of the time
cdrom is only needed for the installation, later on you can either
remove it entirely or switch it to virtio if needed.

We did lots of installations of various systems out there in qemu/kvm,
and we always use most common devices during this time.

Thanks,

/mjt

Re: Bug#965028: systemd: journalctl does not work for normal users at all

[Michael Biebl]

Control: reassign -1 user-setup
Control: retitle -1 add admin user to group systemd-journal

I'm going to reassign this bug report to user-setup which I think is the
debian-installer component responsible for setting up the initial group
memberships.

Whether such a change is suitable for a stable release is up to the
user-setup maintainers to decide.

Regards,
Michael


Am 19.07.20 um 01:02 schrieb Daniel Blaschke:
> If adm is the only group necessary for log-access in bullseye, then it's
> probably all good.
> It would however be nice to see a fix also in buster (ie busters debian
> installer at the next point release).
>  Cheers,
> Daniel
> 
> On Thu, 16 Jul 2020, Michael Biebl wrote:
> 
>> Am 15.07.20 um 12:52 schrieb Michael Biebl:
>>> Am 15.07.20 um 01:19 schrieb Daniel Blaschke:
>>>> OK, so now it works after rebooting - logging out and back in was not
>>>> enough after adding myself to the groups apparently; sorry for the
>>>> noise.
>>>> Could this bug perhaps be reassigned to the debian-installer?
>>>> Kind of think the primary admin user (which is set up during a fresh
>>>> install) should be added to those groups by default.
>>>
>>> I think with bullseye this issue is mostly moot as a persistent journal
>>> is now the default and the /var/log/journal directory has an ACL with
>>> read permissions for the "adm" group and the admin user is already added
>>> to this group.
>>>
>>> buster:
>>>
>>> # getfacl /run/log/journal/
>>> getfacl: Removing leading '/' from absolute path names
>>> # file: run/log/journal/
>>> # owner: root
>>> # group: systemd-journal
>>> # flags: -s-
>>> user::rwx
>>> group::r-x
>>> other::r-x
>>>
>>> bullseye:
>>>
>>> # getfacl /var/log/journal/
>>> getfacl: Removing leading '/' from absolute path names
>>> # file: var/log/journal/
>>> # owner: root
>>> # group: systemd-journal
>>> # flags: -s-
>>> user::rwx
>>> group::r-x
>>> group:adm:r-x
>>> mask::r-x
>>> other::r-x
>>> default:user::rwx
>>> default:group::r-x
>>> default:group:adm:r-x
>>> default:mask::r-x
>>> default:other::r-x
>>>
>>
>> Do you see any value in adding users to the more explicit
>> systemd-journal group? If not, I'd just close this bug report.
>>
>> Regards,
>> Michael
>>
>>




signature.asc
Description: OpenPGP digital signature

Re: Bug#956216: buster-pu: package systemd/241-7~deb10u3

[Michael Biebl]

Am 25.04.20 um 21:41 schrieb Adam D. Barratt:
> On Wed, 2020-04-08 at 16:11 +0200, Michael Biebl wrote:
> I'd be OK with that, but this will need a KiBi-ack, so CCing and
> tagging accordingly.

After talking to KiBi on IRC, we decided to include the fix for #958397
as well. I kept the changes minimal and only included 60-rules in
udev-udeb and the initramfs.

We might consider a different, opt-out approach for udev-rules in the
future as suggested by Steve [1] and Marco [2]. But that's probably too
invasive for a stable upload.

Updated debdiff is attached. The changes to the previous debdiff can be
found at
https://salsa.debian.org/systemd-team/systemd/-/commit/4b7f1d2b1763574cfc9ef43e728045518d440c1a


Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958397#12
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958397#22
diff --git a/debian/changelog b/debian/changelog
index 1d263f7..14ef57f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+systemd (241-7~deb10u4) buster; urgency=medium
+
+  * polkit: when authorizing via PolicyKit re-resolve callback/userdata
+instead of caching it.
+This fixes a heap use-after-free vulnerability in systemd, when
+asynchronous PolicyKit queries are performed while handling DBus messages.
+CVE-2020-1712 (Closes: #950732)
+  * Install 60-block.rules in udev-udeb and initramfs-tools.
+The block device rules were split out from 60-persistent-storage.rules
+into its own rules file in v220. Those rules ensure that change events
+are emitted and the udev db is updated after metadata changes.
+Thanks to Pascal Hambourg (Closes: #958397)
+
+ -- Michael Biebl   Mon, 27 Apr 2020 19:02:57 +0200
+
 systemd (241-7~deb10u3) buster; urgency=medium
 
   * core: set fs.file-max sysctl to LONG_MAX rather than ULONG_MAX.
diff --git a/debian/extra/initramfs-tools/hooks/udev 
b/debian/extra/initramfs-tools/hooks/udev
index 6305d09..bbbd351 100755
--- a/debian/extra/initramfs-tools/hooks/udev
+++ b/debian/extra/initramfs-tools/hooks/udev
@@ -28,7 +28,8 @@ if [ -d /etc/systemd/network ]; then
 fi
 
 mkdir -p "$DESTDIR/lib/udev/rules.d/"
-for rules in 50-firmware.rules 50-udev-default.rules 
60-persistent-storage.rules \
+for rules in 50-firmware.rules 50-udev-default.rules \
+60-block.rules 60-persistent-storage.rules \
 61-persistent-storage-android.rules 71-seat.rules 
73-special-net-names.rules \
 73-usb-net-by-mac.rules 75-net-description.rules \
 80-net-setup-link.rules 80-drivers.rules; do
diff --git a/debian/patches/Fix-typo-in-function-name.patch 
b/debian/patches/Fix-typo-in-function-name.patch
new file mode 100644
index 000..4f3c521
--- /dev/null
+++ b/debian/patches/Fix-typo-in-function-name.patch
@@ -0,0 +1,77 @@
+From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= 
+Date: Tue, 4 Feb 2020 18:39:04 +0100
+Subject: Fix typo in function name
+
+(cherry picked from commit bc130b6858327b382b07b3985cf48e2aa9016b2d)
+(cherry picked from commit b4eb8848240c3540180e4768216a0b884a5ed783)
+(cherry picked from commit f14fa558ae9e139c94ee3af4a1ef1df313b2ff66)
+(cherry picked from commit dd8aa0871d9cafa60a916d4ec01dd82d64edf7ed)
+---
+ TODO| 2 +-
+ src/libsystemd/sd-bus/bus-message.h | 2 +-
+ src/libsystemd/sd-bus/sd-bus.c  | 8 
+ src/shared/bus-polkit.c | 2 +-
+ 4 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/TODO b/TODO
+index 462db57..327fead 100644
+--- a/TODO
 b/TODO
+@@ -138,7 +138,7 @@ Features:
+ 
+ * the a-posteriori stopping of units bound to units that disappeared logic
+   should be reworked: there should be a queue of units, and we should only
+-  enqeue stop jobs from a defer event that processes queue instead of
++  enqueue stop jobs from a defer event that processes queue instead of
+   right-away when we find a unit that is bound to one that doesn't exist
+   anymore. (similar to how the stop-unneeded queue has been reworked the same
+   way)
+diff --git a/src/libsystemd/sd-bus/bus-message.h 
b/src/libsystemd/sd-bus/bus-message.h
+index 7fd3f11..849d638 100644
+--- a/src/libsystemd/sd-bus/bus-message.h
 b/src/libsystemd/sd-bus/bus-message.h
+@@ -211,4 +211,4 @@ int bus_message_remarshal(sd_bus *bus, sd_bus_message **m);
+ 
+ void bus_message_set_sender_driver(sd_bus *bus, sd_bus_message *m);
+ void bus_message_set_sender_local(sd_bus *bus, sd_bus_message *m);
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m);
++int sd_bus_enqueue_for_read(sd_bus *bus, sd_bus_message *m);
+diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
+index 94380af..c20adcf 100644
+--- a/src/libsystemd/sd-bus/sd-bus.c
 b/src/libsystemd/sd-bus/sd-bus.c
+@@ -4145,7 +4145,7 @@ _public_ int sd_bus_get_close_on_exit(sd_bus *bus) {
+ return bus->close_on_exit;
+ }
+ 
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m) {
++int sd_bus_enqueu

Re: Bug#958397: Missing 60-block.rules breaks grub-installer

[Michael Biebl]

Am 21.04.2020 um 16:34 schrieb Steve McIntyre:
> To be honest, I'm curious if there's a good reason to not just include
> all the udeb rules files in the udev-udeb package? That would fix this

I guess you meant udev rules files.

> bug and save us from any potential future possible reshuffles. It's
> not like they're very large.

We'd probably have to check them, if e.g. they need special system
groups, call external tools etc.
The udev-udeb (and initramfs-tools integration) was mostly taken over
as-is from the old udev package. So Marco might know more why the
initramfs hook and udev-udeb use a more limited set of udev rules.

> Happy to send a patch to modify debian/udev-udeb.install if that will
> help. It would be lovely to also get the same fix backported to Buster
> (and even Stretch!) if you're ok with that.

This sounds indeed like something that should be fixed in stable. If the
proposed change is confirmed to fix those mentioned issues: I do have an
open pu request for buster (#956216). I could update that and with a bit
of luck get that into 10.4.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#956216: buster-pu: package systemd/241-7~deb10u3

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I'd like to make a stable/buster upload for systemd fixing CVE-2020-1712
https://security-tracker.debian.org/tracker/CVE-2020-1712
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950732

After talking to the security team (namely Salvatore), we decided to fix
this issue via a stable upload.

The debdiff is a bit on the larger side, unfortunately.
Salvatore made a smaller backport avoiding some of the refactorings
that were done upstream
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/69

I decided to go with the backport provided by upstream that was done for
the v241-stable branch mainly for two reasons:
- It makes potential future cherry-picks easier
- Doing our own backport has the potential to introduce Debian specific
  bugs

That said, if you prefer the more minimal backport from Salvatore,
please let me know and I'll redo the upload accordingly.

The changes are available at
https://salsa.debian.org/systemd-team/systemd/-/commits/debian/buster-proposed/

The debdiff is attached.

udev should not be affected (I've CCed kibi for his review/ACK)

Regards,
Michael


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 1d263f7..f8b017d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+systemd (241-7~deb10u4) buster; urgency=medium
+
+  * polkit: when authorizing via PolicyKit re-resolve callback/userdata
+instead of caching it.
+This fixes a heap use-after-free vulnerability in systemd, when
+asynchronous PolicyKit queries are performed while handling DBus messages.
+(CVE-2020-1712, Closes: #950732)
+
+ -- Michael Biebl   Wed, 08 Apr 2020 15:58:24 +0200
+
 systemd (241-7~deb10u3) buster; urgency=medium
 
   * core: set fs.file-max sysctl to LONG_MAX rather than ULONG_MAX.
diff --git a/debian/patches/Fix-typo-in-function-name.patch 
b/debian/patches/Fix-typo-in-function-name.patch
new file mode 100644
index 000..4f3c521
--- /dev/null
+++ b/debian/patches/Fix-typo-in-function-name.patch
@@ -0,0 +1,77 @@
+From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= 
+Date: Tue, 4 Feb 2020 18:39:04 +0100
+Subject: Fix typo in function name
+
+(cherry picked from commit bc130b6858327b382b07b3985cf48e2aa9016b2d)
+(cherry picked from commit b4eb8848240c3540180e4768216a0b884a5ed783)
+(cherry picked from commit f14fa558ae9e139c94ee3af4a1ef1df313b2ff66)
+(cherry picked from commit dd8aa0871d9cafa60a916d4ec01dd82d64edf7ed)
+---
+ TODO| 2 +-
+ src/libsystemd/sd-bus/bus-message.h | 2 +-
+ src/libsystemd/sd-bus/sd-bus.c  | 8 
+ src/shared/bus-polkit.c | 2 +-
+ 4 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/TODO b/TODO
+index 462db57..327fead 100644
+--- a/TODO
 b/TODO
+@@ -138,7 +138,7 @@ Features:
+ 
+ * the a-posteriori stopping of units bound to units that disappeared logic
+   should be reworked: there should be a queue of units, and we should only
+-  enqeue stop jobs from a defer event that processes queue instead of
++  enqueue stop jobs from a defer event that processes queue instead of
+   right-away when we find a unit that is bound to one that doesn't exist
+   anymore. (similar to how the stop-unneeded queue has been reworked the same
+   way)
+diff --git a/src/libsystemd/sd-bus/bus-message.h 
b/src/libsystemd/sd-bus/bus-message.h
+index 7fd3f11..849d638 100644
+--- a/src/libsystemd/sd-bus/bus-message.h
 b/src/libsystemd/sd-bus/bus-message.h
+@@ -211,4 +211,4 @@ int bus_message_remarshal(sd_bus *bus, sd_bus_message **m);
+ 
+ void bus_message_set_sender_driver(sd_bus *bus, sd_bus_message *m);
+ void bus_message_set_sender_local(sd_bus *bus, sd_bus_message *m);
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m);
++int sd_bus_enqueue_for_read(sd_bus *bus, sd_bus_message *m);
+diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
+index 94380af..c20adcf 100644
+--- a/src/libsystemd/sd-bus/sd-bus.c
 b/src/libsystemd/sd-bus/sd-bus.c
+@@ -4145,7 +4145,7 @@ _public_ int sd_bus_get_close_on_exit(sd_bus *bus) {
+ return bus->close_on_exit;
+ }
+ 
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m) {
++int sd_bus_enqueue_for_read(sd_bus *bus, sd_bus_message *m) {
+ int r;
+ 
+ assert_return(bus, -EINVAL);
+@@ -4157,9 +4157,9 @@ int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message 
*m) {
+ if (!BUS_IS_OPEN(bus->state))
+ return -EN

Bug#954463: override: gir1.2-nemo-3.0:introspection/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Please change the section from libdevel to introspection

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

[Michael Büsch]

On Sun, 16 Feb 2020 23:52:27 +0900
Hideki Yamane  wrote:

> > $ sudo debootstrap --arch=armhf --foreign --verbose 
> > --keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg 
> > buster /tmp/debootstrap-test/ 
> > http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/  
> 
>  Please try without --verbose, I guess its option is something wrong with.


whoa yes. That helps indeed:


0/mb@wiggum:~$ sudo rm -rf /tmp/debootstrap-test
0/mb@wiggum:~$ sudo debootstrap --arch=armhf --foreign 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A0DA38D0D76E8B5D638872819165938D90FDDD2E)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian...
I: Retrieving adduser 3.118
I: Validating adduser 3.118
I: Retrieving apt 1.8.2
I: Validating apt 1.8.2
I: Retrieving apt-utils 1.8.2
I: Validating apt-utils 1.8.2
I: Retrieving base-files 10.3+rpi1+deb10u3
I: Validating base-files 10.3+rpi1+deb10u3
I: Retrieving base-passwd 3.5.46
I: Validating base-passwd 3.5.46
I: Retrieving bash 5.0-4
^CE: Interrupt caught ... exiting


Thanks :)

-- 
Michael


pgp3z3uWmHDxQ.pgp
Description: OpenPGP digital signature

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

[Michael Büsch]

On Sun, 16 Feb 2020 14:47:37 +0100
Geert Stappers  wrote:

> On Sun, Feb 16, 2020 at 12:14:28PM +0100, Michael Büsch wrote:
> > A different command has been used to "reproduce" this problem.  
> 
> Please elaborate that.


The option --no-check-gpg has been used.


> > So I currently don't consider the unreproducible flag for this bug as 
> > valid.  
> 
> With the keyring file inplace, I had a succesfull "build".
> To me is the bugreport UNreproducible.
> 
> I have no idea how to dive deeper into this.


Ok. With the same options used, that statement is valid.

I'm not sure what's going on.
Did you delete the contents of /tmp/debootstrap-test/ before trying?
If that directory contains leftovers from a previous successful
attempt (even if interrupted), the problem does not occur.

Here's an example with a specific mirror instead of mirrordirector:


$ sudo rm -rf /tmp/debootstrap-test/
$ sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/dists/buster/Release
$ sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian/
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file 
http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian/dists/buster/Release
$ sudo dpkg -i debootstrap_1.0.116_all.deb 
dpkg: warning: downgrading debootstrap from 1.0.117 to 1.0.116
(Reading database ... 524483 files and directories currently installed.)
Preparing to unpack debootstrap_1.0.116_all.deb ...
Unpacking debootstrap (1.0.116) over (1.0.117) ...
Setting up debootstrap (1.0.116) ...
Processing triggers for man-db (2.9.0-2) ...
$ sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian/
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A0DA38D0D76E8B5D638872819165938D90FDDD2E)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on 
http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian...
^CE: Interrupt caught ... exiting


As you can see with the old version 1.0.166 it works fine with this mirror.


> And I do hope that bugreporter is aware that BR got human attention.

Erm, yes?

-- 
Michael


pgp_cb6CbYwzU.pgp
Description: OpenPGP digital signature

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

[Michael Büsch]

A different command has been used to "reproduce" this problem.
So I currently don't consider the unreproducible flag for this bug as
valid.

Please get the key from here:

http://mirrordirector.raspbian.org/raspbian//pool/main/r/raspbian-archive-keyring/raspbian-archive-keyring_20120528.2.tar.gz
SHA256: fdf50f775b60901a2783f21a6362e2bf5ee6203983e884940b163faa1293c002

Commands:

wget 
http://mirrordirector.raspbian.org/raspbian//pool/main/r/raspbian-archive-keyring/raspbian-archive-keyring_20120528.2.tar.gz
tar xf raspbian-archive-keyring_20120528.2.tar.gz
gpg --dearmor raspbian-archive-keyring-20120528.2/raspbian.public.key
sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ http://mirrordirector.raspbian.org/raspbian/


Result with debootstrap 1.0.116:
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A0DA38D0D76E8B5D638872819165938D90FDDD2E)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://mirrordirector.raspbian.org/raspbian...
I: Retrieving adduser 3.118
I: Validating adduser 3.118
I: Retrieving apt 1.8.2
I: Validating apt 1.8.2
I: Retrieving apt-utils 1.8.2
^CE: Interrupt caught ... exiting


Result with debootstrap 1.0.117:
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file 
http://mirrordirector.raspbian.org/raspbian/dists/buster/Release


-- 
Michael


pgpFMa2mPP4wf.pgp
Description: OpenPGP digital signature

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

[Michael Büsch]

Package: debootstrap
Version: 1.0.117
Severity: important

Since debootstrap 1.0.117 Raspbian bootstrap fails with the following error
message:

$ debootstrap --arch=armhf --foreign --verbose --keyring=keyrings/raspbian-
archive-keyring.gpg buster /tmp/debootstrap-test
http://mirrordirector.raspbian.org/raspbian/
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file
http://mirrordirector.raspbian.org/raspbian/dists/buster/Release



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.19-1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#950166: buster-pu: package systemd/241-7~deb10u3

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

first of all, apologies, that this pu request comes rather late.
I first didn't plan to prepare a release for 10.3, but today #930178 was
reassigned to systemd, which reminded me, that this is an issue we
should fix for stable. So here it goes:

I'd like to fix the following two issues in systemd:


systemd (241-7~deb10u3) buster; urgency=medium

  * core: set fs.file-max sysctl to LONG_MAX rather than ULONG_MAX.
Since kernel 5.2 (but also stable kernels like 4.19.53) the kernel
thankfully returns proper errors when we write a value out of range to
the sysctl. Which however breaks writing ULONG_MAX to request the
maximum value. Hence let's write the new maximum value instead,
LONG_MAX. (Closes: #945018)

https://salsa.debian.org/systemd-team/systemd/commit/673e108907baf1a242c4842ace6e9e3a23b11d52

Upstream cherry-pick, fixed in unstable/testing. Rather straight-forward
fix. I wasn't planning doing a stable upload for this issue alone but
only in combination with other fixes.

  * core: change ownership/mode of the execution directories also for static
users.
This ensures that execution directories like CacheDirectory and
StateDirectory are properly chowned to the user specified in User= before
launching the service. (Closes: #919231)

https://salsa.debian.org/systemd-team/systemd/commit/e9c8637d06e373430b8986643cfb537a23b0b1fd

This is an upstream cherry-pick from 
https://github.com/systemd/systemd/pull/12005
I'm a bit undecided whether to cherry-pick all changes from this PR
(which look like worthwile changes to have) or only commit
206e9864de460dd79d9edd7bedb47dee168765e1.

I decided for the latter for now, as it keeps the changes minimal and
seems to fix the issue at hand. That said, would welcome your feedback
here. Would you prefer that we pull in the complete upstream PR #12005
or keep the changes minimal?

PR #12005 is part of v242, i.e. fixed in unstable/testing.


Those changes don't touch udev, but will need an ack from kibi (which
I've CCed).

Regards,
Michael

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index f63e21d..1d263f7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+systemd (241-7~deb10u3) buster; urgency=medium
+
+  * core: set fs.file-max sysctl to LONG_MAX rather than ULONG_MAX.
+Since kernel 5.2 (but also stable kernels like 4.19.53) the kernel
+thankfully returns proper errors when we write a value out of range to
+the sysctl. Which however breaks writing ULONG_MAX to request the
+maximum value. Hence let's write the new maximum value instead,
+LONG_MAX. (Closes: #945018)
+  * core: change ownership/mode of the execution directories also for static
+users.
+This ensures that execution directories like CacheDirectory and
+StateDirectory are properly chowned to the user specified in User= before
+launching the service. (Closes: #919231)
+
+ -- Michael Biebl   Wed, 29 Jan 2020 19:07:53 +0100
+
 systemd (241-7~deb10u2) buster; urgency=medium
 
   * core: never propagate reload failure to service result.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index b0e0001..9591e25 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,7 +1,8 @@
 [DEFAULT]
 pristine-tar = True
 patch-numbers = False
-debian-branch = buster
+debian-branch = debian/buster
+upstream-branch = upstream/latest
 
 [dch]
 full = True
diff --git 
a/debian/patches/core-change-ownership-mode-of-the-execution-directories-a.patch
 
b/debian/patches/core-change-ownership-mode-of-the-execution-directories-a.patch
new file mode 100644
index 000..6f8b0fc
--- /dev/null
+++ 
b/debian/patches/core-change-ownership-mode-of-the-execution-directories-a.patch
@@ -0,0 +1,85 @@
+From: Lennart Poettering 
+Date: Thu, 14 Mar 2019 17:19:30 +0100
+Subject: core: change ownership/mode of the execution directories also for
+ static users
+
+It's probably unexpected if we do a recursive chown() when dynamic users
+are used but not on static users.
+
+hence, let's tweak the logic slightly, and recursively chown in both
+cases, except when operating on the configuration directory.
+
+Fixes: #11842
+(cherry picked from commit 206e9864de460dd79d9edd7bedb47dee168765e1)
+---
+ src/core/execute.c | 47 ++-
+ 1 file changed, 26 insertions(+), 21 deletions(-)
+
+diff --git a/src/core/execute.c b/src/core/execute.c
+index 5486e37..5c3930e 100644
+--- a/src/core/execute.c
 b/src

Re: daily images not deploying?

[Michael Kesper]

Hi Vincent,

On 05.11.19 02:06, McIntyre, Vincent (CASS, Marsfield) wrote:
> I was trying to retrieve
> 
> http://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/
> 
> and got a 404.
...
> PS I now see the build_netboot.log (and others) contains this failure:
> 
>   The following packages have unmet dependencies:
>haveged-udeb : Depends: libhavege2 (>= 1.9.8) but it is not installable
>   E: Unable to correct problems, you have held broken packages.

Please have a look at https://lists.debian.org/debian-boot/2019/11/msg00045.html

Bye
Michael




signature.asc
Description: OpenPGP digital signature

Re: Bug#880122: Bug#939798: floppy support in d-i

[Michael Kesper]

Hi all,

On 04.11.19 12:34, John Paul Adrian Glaubitz wrote:
> On 11/4/19 12:06 PM, Holger Levsen wrote:
>> On Sun, Nov 03, 2019 at 11:27:07PM +0100, John Paul Adrian Glaubitz wrote:
>>> And I just saw the "argument". The argument was "It's 2018". That's not
>>> an argument.
>>  
>> the longer form of the argument is: it's 2018 and except for 100 people
>> on this planet, noone is using floppies anymore.
> 
> Yes, and it's 2018 and except for a handful of people, no one is browsing
> the internet on a PC anymore. I don't see how this is an argument.
> 
>> "cognitive strain" is another argument. 90% of the people installing a
>> computer today have no idea what a floppy (disk) is. (for those who
>> don't know, it's the icon for saving a file.)
> 
> I don't really see the problem here. And I would like to see a source
> for that 90% claim. I don't think anyone who is able to install Debian
> using debian-installer doesn't know what a floppy is. Anyone who is capable
> of creating a bootable USB flash drive will absolutely know what a floppy
> is.

How should that be true?
 
> I really have the impression that some people are trying with all force
> to smash out support for older architectures and hardware 

No, the support will be kept but without confusing people.

> Debian is certainly not the distribution for Linux beginners so there is
> really no reason to pretend that such changes make any difference
> in user-friendlyness.

Non sequitur.

Bye
Michael



signature.asc
Description: OpenPGP digital signature

Re: Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

[Michael Kesper]

Hi all,

On 28.10.19 15:56, Cyril Brulebois wrote:
> Philipp Wollschlegel  (2019-10-28):
>> On 28.10.19 15:11, Ben Hutchings wrote:
>>> On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote:
>>>> Bugreport against kernel version mismatch, when using outdated or broken 
>>>> netboot images:
>>
>> This isn't a package / message  problem, this is a process problem.
...
> That's not true for stable or oldstable. Also, we ship netboot images in
> packages, use that and be happy?
> 
> If users are tracking testing or unstable, well, yes; those
> distributions are WIP.
> 
> But the script you quoted seems to be about buster, so using d-i-n-i
> packages should be a no-brainer.
> 
>   https://tracker.debian.org/pkg/debian-installer-netboot-images

But even those packages do not contain the kernel modules without which the
installation can't work.
So as soon as there's a kernel upgrade due to security reasons, you got to
make sure to update your tftp files.
This adds a whole new layer of abstraction (Jenkins jobs etc.) to an already
complicated process: The basic install process just is not self-contained
as it is the case with even the netboot CD/usb image.

My 2 cents
Michael




signature.asc
Description: OpenPGP digital signature

Bug#942446: buster-pu: package systemd/241-7~deb10u2

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I'd like to make a stable upload for systemd, fixing various issues,
including a CVE.

A full debdiff is attached, an annotated changelog follows.

I've also CC d-i/kibi, as we build a udeb.
I don't think we have any changes that affect the installer, that said,
a test run/review by kibi would be very much appreciated.

systemd (241-7~deb10u2) buster; urgency=medium

  * core: never propagate reload failure to service result.
Fixes a regression introduced in v239 where the main process of a
service unit gets killed on reload if ExecReload fails. (Closes: #936032)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936032
https://salsa.debian.org/systemd-team/systemd/commit/3802da815587058dedc75e7fec7e1de993a6c549

  * shared/seccomp: add sync_file_range2.
Some architectures need the arguments to be reordered because of alignment
issues. Otherwise, it's the same as sync_file_range.
Fixes sync_file_range failures in nspawn containers on arm, ppc.
(Closes: #935091)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935091
https://salsa.debian.org/systemd-team/systemd/commit/e050f84ccbf3f6c689c706fdf7a5d759b8a49d60

  * core: factor root_directory application out of apply_working_directory.
Fixes RootDirectory not working when used in combination with User.
(Closes: #939408)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939408
https://salsa.debian.org/systemd-team/systemd/commit/0686cb963a02990f5b9c3e04c3da6a7c44a1e96c

  * shared/bus-util: drop trusted annotation from
bus_open_system_watch_bind_with_description().
This ensures that access controls on systemd-resolved's D-Bus interface
are enforced properly.
(CVE-2019-15718, Closes: #939353)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939353
https://salsa.debian.org/systemd-team/systemd/commit/d1cd6601c96c8b00e35ab84142a628f5838b5473

  * login: add a missing error check for session_set_leader()
Fixes assertion due to insufficient function return check.
(Closes: #939998)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939998
https://salsa.debian.org/systemd-team/systemd/commit/6ffdf1f33fc11aeafdcd5b62e3083d40fd43b36e

  * d/e/r/73-usb-net-by-mac.rules: import net.ifnames only for network devices
(Closes: #934589)
  * d/e/r/73-usb-net-by-mac.rules: skip if iface name was provided by user-space

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934589
https://salsa.debian.org/systemd-team/systemd/commit/933b0b9c546bcc0c1ff5cdfec8b528ac80926622
https://salsa.debian.org/systemd-team/systemd/commit/93da42a3ecfee7731ddb843aec307f84f3843788

  * namespace: make MountFlags=shared work again (Closes: #939551)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939551
https://salsa.debian.org/systemd-team/systemd/commit/ee6f86d86cb791a09b9de6b43f8fa5f832c757e2

  * mount/generators: do not make unit wanted by its device unit.
Among other things, this fixes StopWhenUnneeded=true being broken for
mount units. (Closes: #941758)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941758
https://salsa.debian.org/systemd-team/systemd/commit/e1be83ad48df9743cabc0c23c086f6f53e8eb46d

 -- Michael Biebl   Wed, 16 Oct 2019 15:24:54 +0200


All patches are cherry-picks from upstream, all bugs have been fixed
in sid/bullseye, so have seem some wider testing without any reported
regressions so far.

Regards,
Michael

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 498f68a..f63e21d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,34 @@
+systemd (241-7~deb10u2) buster; urgency=medium
+
+  * core: never propagate reload failure to service result.
+Fixes a regression introduced in v239 where the main process of a
+service unit gets killed on reload if ExecReload fails. (Closes: #936032)
+  * shared/seccomp: add sync_file_range2.
+Some architectures need the arguments to be reordered because of alignment
+issues. Otherwise, it's the same as sync_file_range.
+Fixes sync_file_range failures in nspawn containers on arm, ppc.
+(Closes: #935091)
+  * core: factor root_directory application out of apply_working_directory.
+Fixes RootDirectory not working when used in combination with User.
+(Closes: #939408)
+  * shared/bus-util: drop trusted annotation from
+bus_open_system_watch_bind_with_description().
+This ensures that access controls on systemd-resolved's D-Bus interface

Re: how to setup a small local Debian mirror to install a VM without an internet access

[Michael Kesper]

Hi Fred,

On 04.10.19 09:52, Fred Boiteux wrote:
> Meanwhile, I've tried to understand what is going on : on my VM being 
> installed, stuck because the standard 'locales' package can't be installed, 
> as the given repository is not signed and then ignored, I've done this : I've 
> connected to the VM with SSH, then I've done a 'chroot /target' to check what 
> is going on. Trying to install the locales packages don't actually work :
> 
>   # apt-get install locales
>   Reading package lists... Done
>   Building dependency tree... Done
>   Package locales is not available, but is referred to by another package.
>   This may mean that the package is missing, has been obsoleted, or
>   is only available from another source
>   E: Package 'locales' has no installation candidate
> 
> 
> Trying an apt update gives the same error message than in the previous log :
> 
>   # apt update
>   Ign:1 http://192.168.254.254/buster_debian_installer buster InRelease
>   Get:2 http://192.168.254.254/buster_debian_installer buster Release [33.5 
> kB]  Ign:3 http://192.168.254.254/buster_debian_installer buster 
> Release.gpg
>   Reading package lists... Done
>   E: The repository 'http://192.168.254.254/buster_debian_installer buster 
> Release' is not signed.
>   N: Updating from such a repository can't be done securely, and is therefore 
> disabled by default.
>   N: See apt-secure(8) manpage for repository creation and user configuration 
> details.
> 
> I've checked the apt config :
> 
>   # cat target/etc/apt/apt.conf.d/00AllowUnauthenticated
>   APT::Get::AllowUnauthenticated "true";
>   Aptitude::CmdLine::Ignore-Trust-Violations "true";
> 
> 
> And looking (on a working Buster system) the apt-secure manual page suggest 
> me to add following line in this conf file :
> 
> Acquire::AllowInsecureRepositories "true";
> 
> 
> With this config item, the « apt update » runs well, the error message 
> becomes a warning message :

I think it would be better to sign your archive instead.
With your modification you would completely disable checking GPG signatures for 
every repository (who checks warnings?)
Sadly, the Debian wiki is full of outdated setups but I cannot find a stringent 
howto for setting up a trusted repo.

Reprepro seem like a possible way to go.
It overcomes another misfeature of these minimal repositories: You cannot pin 
packages to versions
of this repository but have to set them on hold, else you always risk getting 
packages from Debian proper.

My 2 cents
Michael



signature.asc
Description: OpenPGP digital signature

Re: pxe booting qemu

[Michael Kesper]

Hi John,

On 23.09.19 10:27, john doe wrote:
> I'm currently using the netinst.iso file to install Debian as a guest VM
> using Qemu.
> This approach works fine if you want to install multiple VM on the same
> host.
> My goal with using PXE booting is to test how to install from the
> network using Qemu, that way, I can get everything the way I like before
> implementing PXE booting on my network.

I'd start with a real tftp server on a Debian box (You wrote that you were on 
windows).
Configuration of tftp server with qemu and without are different and
probably so different that it makes no sense to try the qemu one first.
 
> What I want is:
> - Fully install Debian from the network using a preseed file (the less I
> do on the host on which I want to install Debian the better)

preseed.cfg is the next step. You need to be able to get your boot media
via network first.
 
> What I don't want:
> - Using a phisical media (usb key, cd/dvd rom ...)
> 
> As far as I understand it, PXE booting is the only way to avoid using a
> usb key to install Debian, is that correct?

Yes.

But in my opinion it's better to start from solid grounds: 
A reliable DHCP and TFTP server on a Debian system.
Best if you start in a seperate network (or at least network segment) so you
don't risk influencing your productive systems.
Maybe it's even easier to start with an integrated solution like
fai, I didn't try that yet.

Oh, and by the way: If you try to pxeboot via UEFI, many tutorials etc.
are plain wrong: You don't use pxelinux.0 in that case at all!
You'll be loading bootnetx64.efi which then will load grubnetx64.efi.
This enables (but does not depend on) secure boot.

This guide is relatively good because you can verify that each step worked.
No mentioning of UEFI pxe boot, though:

https://wiki.debian.org/PXEBootInstall

NB also this (from that guid):

If the kernel in the netboot image gets out of sync with the kernel module 
packages, 
then the modules won't load and the install will fail,
the usual symptoms are that messages about "missing symbols" appear
in the ctrl-alt-f4 console.

To fix this, update the kernel and initrd on the netboot server.

About UEFI PXE, hava look at this thread:
https://lists.debian.org/debian-boot/2019/02/msg00285.html

FAI: http://fai-project.org/features/

Best wishes
Michael



signature.asc
Description: OpenPGP digital signature

Re: pxe booting qemu

[Michael Kesper]

Hi John,

On 22.09.19 09:47, john doe wrote:
> Hi,
> 
> I'm trying to install Debian 10.1 using pxe and qemu.

Is pxe booting a strong requirement for you?
It's much easier to start booting from a cdrom image.

A "netinst" image is sufficient:
https://www.debian.org/CD/netinst/

Bye
Michael



signature.asc
Description: OpenPGP digital signature

Bug#936050: please add systemctl daemon-reload hint to /etc/fstab

[Michael Biebl]

Package: debian-installer
Followup-For: Bug #936050

Makes sense.

Thanks for bringing this up, Marc.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Adding flexibility to Debian Installer paths

[Michael Kesper]

Hi all,

I was wondering whether it would be possible to add some more flexibility to
the paths of Debian installer as used by e.g. netboot.tar.gz for PXE install.
At the moment, it's not trivially possible to offer e.g. Debian 10 and 9 or 11
at the same time for tftpboot as paths are hardcoded as e.g.:

grub.cfg (excerpt):

menuentry --hotkey=s 'Install with speech synthesis' {
set background_color=black
linux/debian-installer/amd64/linux vga=788 speakup.synth=soft --- quiet
initrd   /debian-installer/amd64/initrd.gz
 ^ can there really be only one?
}

which I turned for my purposes into:

menuentry --hotkey=s 'Install with speech synthesis' {
set background_color=black
linux/debian-10/debian-installer/amd64/linux vga=788 speakup.synth=soft 
--- quiet
initrd   /debian-10/debian-installer/amd64/initrd.gz
 ^^ So we can have debian-9, debian-11 etc.
}

Having to change all affected places after downloading the bootfiles can be 
error prone
and should be avoidable, I think.

Best wishes
Michael



signature.asc
Description: OpenPGP digital signature

Bug#933511: partman-base: reformatting md raid 0.90 metadata does not delete metadata

[Michael Hudson-Doyle]

The patch attached to this mail is better.

On Wed, 31 Jul 2019 at 14:12, Michael Hudson-Doyle <
michael.hud...@ubuntu.com> wrote:

> Source: partman-base
> Severity: normal
> Tags: d-i patch
>
> Dear Maintainer,
>
> As reported in
>
> https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1828558
>
> installing over a drive previously used as a md raid can leave a system
> that does not boot.  I tried and failed to convince parted upstream this
> was their bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853) so
> it probably makes sense to fix it in parted_server instead.
>
> I'm attaching a WIP patch to this report. I'll probably upload something
> like this to Ubuntu once I've tested it a bit.
>
> Cheers,
> mwh
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic-updates
>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
> 'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-55-generic (SMP w/4 CPU cores)
> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
diff --git a/Makefile.am b/Makefile.am
index f93bf8e..e8027ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,7 +2,8 @@ bin_PROGRAMS = parted_server parted_devices partmap
 bin_SCRIPTS = partman partman-command partman-commit
 
 parted_server_SOURCES = parted_server.c
-parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS)
+parted_server_CPPFLAGS = $(blkid_CFLAGS)
+parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS) $(blkid_LIBS)
 
 parted_devices_SOURCES = parted_devices.c
 parted_devices_LDADD = $(libparted_LIBS)
diff --git a/configure.ac b/configure.ac
index 987cc4d..3d081ff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,6 +7,7 @@ AC_DEFINE([_POSIX_C_SOURCE], [200809L], [Define the POSIX version])
 AC_PROG_CC
 
 PKG_CHECK_MODULES([libparted], [libparted])
+PKG_CHECK_MODULES([blkid], [blkid])
 
 AC_ARG_VAR([libparted_fs_resize_LIBS], [linker flags for libparted-fs-resize])
 AC_MSG_CHECKING([for libparted >= 3.1])
diff --git a/parted_server.c b/parted_server.c
index 41784b7..5c75684 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
Logging
@@ -1360,6 +1361,61 @@ is_system_with_firmware_on_disk()
 return result;
 }
 
+/*
+ * wipe all superblocks libblkid knows about from a device
+ * (condensed from wipefs in util-linux)
+ */
+static int
+do_wipe(char *devname)
+{
+blkid_probe pr = NULL;
+int fd = -1;
+int r = -1;
+
+fd = open(devname, O_RDWR);
+
+if (fd < 0) {
+log("open(%s) failed errno %d", devname, errno);
+goto error;
+}
+
+log("do_wipe open(%s), %d", devname, fd);
+
+
+pr = blkid_new_probe();
+if (!pr || blkid_probe_set_device(pr, fd, 0, 0) != 0) {
+log("setting up probe failed");
+goto error;
+}
+
+blkid_probe_enable_superblocks(pr, 1);
+blkid_probe_set_superblocks_flags(pr, BLKID_SUBLKS_MAGIC |  /* return magic string and offset */
+  BLKID_SUBLKS_TYPE |   /* return superblock type */
+  BLKID_SUBLKS_BADCSUM);/* accept bad checksums */
+
+blkid_probe_enable_partitions(pr, 1);
+blkid_probe_set_partitions_flags(pr, BLKID_PARTS_MAGIC |
+ BLKID_PARTS_FORCE_GPT);
+
+while (blkid_do_probe(pr) == 0) {
+char *type = "unknown";
+if (blkid_probe_lookup_value(pr, "TYPE", , NULL) < 0)
+blkid_probe_lookup_value(pr, "PTTYPE", , NULL);
+log("wiping superblock of type %s", type);
+if (blkid_do_wipe(pr, 0) != 0) {
+log("wiping failed");
+}
+}
+
+fsync(fd);
+r = 0;
+  error:
+if (fd >= 0)
+close(fd);
+blkid_free_probe(pr);
+return r;
+}
+
 void
 command_commit()
 {
@@ -1382,8 +1438,25 @@ command_commit()
 }
 
 open_out();
-if (disk != NULL && named_is_changed(device_name))
-ped_disk_commit(disk);
+if (disk != NULL) {
+/* ped_disk_clobber does not remove all superblock information
+ * -- in particular it does not wipe mdraid 0.90 metadata,
+ *

Re: Download of old CD images not possible?

[Michael Kesper]

Hi all,

On 01.08.19 11:46, Samuel Thibault wrote:
> Michael Kesper, le jeu. 01 août 2019 11:40:59 +0200, a ecrit:
>> There seems to be currently no way to download other
>> CD images than current and current-live:
>>
>> https://cdimage.debian.org/debian-cd/
>> There are no links to oldstable or oldoldstable and no paths to other 
>> releases.
> 
> They are in the archive: https://cdimage.debian.org/cdimage/archive/

Ok but this is not mentioned anywhere on the download pages.
-> Documentation bug?

Michael



signature.asc
Description: OpenPGP digital signature

Download of old CD images not possible?

[Michael Kesper]

[Sorry if this should be posted on another list]

There seems to be currently no way to download other
CD images than current and current-live:

https://cdimage.debian.org/debian-cd/

Parent Directory-
[DIR]   10.0.0-live/2019-07-06 13:20-
[DIR]   10.0.0/ 2019-07-06 20:49-
[DIR]   current-live/   2019-07-06 13:20-
[DIR]   current/2019-07-06 20:49-
[DIR]   project/2005-05-23 18:50-
[ARC]   ls-lR.gz

There are no links to oldstable or oldoldstable and no paths to other releases.

Bye
Michael



signature.asc
Description: OpenPGP digital signature

Bug#933511: partman-base: reformatting md raid 0.90 metadata does not delete metadata

[Michael Hudson-Doyle]

Source: partman-base
Severity: normal
Tags: d-i patch

Dear Maintainer,

As reported in

https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1828558

installing over a drive previously used as a md raid can leave a system
that does not boot.  I tried and failed to convince parted upstream this
was their bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853) so
it probably makes sense to fix it in parted_server instead.

I'm attaching a WIP patch to this report. I'll probably upload something
like this to Ubuntu once I've tested it a bit.

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-55-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/Makefile.am b/Makefile.am
index f93bf8e..e8027ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,7 +2,8 @@ bin_PROGRAMS = parted_server parted_devices partmap
 bin_SCRIPTS = partman partman-command partman-commit
 
 parted_server_SOURCES = parted_server.c
-parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS)
+parted_server_CPPFLAGS = $(blkid_CFLAGS)
+parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS) 
$(blkid_LIBS)
 
 parted_devices_SOURCES = parted_devices.c
 parted_devices_LDADD = $(libparted_LIBS)
diff --git a/configure.ac b/configure.ac
index 987cc4d..3d081ff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,6 +7,7 @@ AC_DEFINE([_POSIX_C_SOURCE], [200809L], [Define the POSIX 
version])
 AC_PROG_CC
 
 PKG_CHECK_MODULES([libparted], [libparted])
+PKG_CHECK_MODULES([blkid], [blkid])
 
 AC_ARG_VAR([libparted_fs_resize_LIBS], [linker flags for libparted-fs-resize])
 AC_MSG_CHECKING([for libparted >= 3.1])
diff --git a/debian/changelog b/debian/changelog
index 51396e4..47c7341 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+partman-base (206ubuntu4~ppa4) eoan; urgency=medium
+
+  * parted_server.c: Wipe all known superblocks from device in
+command_new_label. (LP: #1828558)
+
+ -- Michael Hudson-Doyle   Tue, 30 Jul 2019 
10:18:37 +1200
+
 partman-base (206ubuntu3) eoan; urgency=medium
 
   * Revert previous upload, it is intentional to use non-part names, to
diff --git a/debian/control b/debian/control
index 2556d5d..e5d08a7 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: standard
 Maintainer: Ubuntu Installer Team 
 XSBC-Original-Maintainer: Debian Install System Team 

 Uploaders: Anton Zinoviev , Colin Watson 
, Christian Perrier , Max Vozeler 

-Build-Depends: debhelper (>= 9), dh-autoreconf, dh-di (>= 2), pkg-config, 
po-debconf (>= 0.5.0), libparted-dev (>= 2.2)
+Build-Depends: debhelper (>= 9), dh-autoreconf, dh-di (>= 2), pkg-config, 
po-debconf (>= 0.5.0), libparted-dev (>= 2.2), libblkid-dev
 XS-Debian-Vcs-Browser: https://salsa.debian.org/installer-team/partman-base
 XS-Debian-Vcs-Git: https://salsa.debian.org/installer-team/partman-base.git
 
diff --git a/parted_server.c b/parted_server.c
index 41784b7..bfff500 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
Logging
@@ -1864,6 +1865,57 @@ command_change_file_system()
 oprintf("OK\n");
 }
 
+/*
+ * wipe all superblocks libblkid knows about from a device
+ * (condensed from wipefs in util-linux)
+ */
+static int
+do_wipe(char *devname)
+{
+blkid_probe pr = NULL;
+int fd = -1;
+int r = -1;
+
+fd = open(devname, O_RDWR | O_EXCL);
+
+log("do_wipe open(%s), %d", devname, fd);
+
+if (fd < 0)
+goto error;
+
+pr = blkid_new_probe();
+if (!pr || blkid_probe_set_device(pr, fd, 0, 0) != 0) {
+log("setting up probe failed");
+goto error;
+}
+
+blkid_probe_enable_superblocks(pr, 1);
+blkid_probe_set_superblocks_flags(pr, BLKID_SUBLKS_MAGIC |  /* 
return magic string and offset */
+  BLKID_SUBLKS_TYPE |   /* 
return superblock type */
+  BLKID_SUBLKS_BADCSUM);/* 
accept bad checksums */
+
+blkid_probe_enable_partitions(pr, 1);
+blkid_probe_set_partitions_flags(pr, BLKID_PARTS_MAGIC |
+ BLKID_PARTS_FORCE_GPT);
+
+while (blkid_do_probe(pr) == 0) {
+char *type = "unknown";
+blkid_probe_lookup_value(pr, "TYPE", , NULL);
+ 

Bug#933125: buster-pu: package systemd/241-5+deb10u1

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I'd like to make a stable upload for systemd, fixing the following
issues:

systemd (241-5+deb10u1) buster; urgency=medium

  * ask-password: Prevent buffer overflow when reading from keyring.
Fixes a possible memory corruption that causes systemd-cryptsetup to
crash either when a single large password is used or when multiple
passwords have already been pushed to the keyring. (Closes: #929726)

https://salsa.debian.org/systemd-team/systemd/commit/3baec22e1fcd89a3b6d93d9a3e59bf7fa7114714

  * Clarify documentation regarding %h/%u/%U specifiers.
Make it clear, that setting "User=" has no effect on those specifiers.
Also ensure that "%h" is actually resolved to "/root" for the system
manager instance as documented in the systemd.unit man page.
(Closes: #927911)

https://salsa.debian.org/systemd-team/systemd/commit/fef3138711bd858d1718b458d257fa73317d532d

  * network: Behave more gracefully when IPv6 has been disabled.
Ignore any configured IPv6 settings when IPv6 has been disabled in the
kernel via sysctl. Instead of failing completely, continue and log a
warning instead. (Closes: #929469)

https://salsa.debian.org/systemd-team/systemd/commit/2f37176282a3f02d8839158441ba70fe3975d2b0

  * network: Fix failure to bring up interface with Linux kernel 5.2.
Backport two patches from systemd master in order to fix a bug with 5.2
kernels where the network interface fails to come up with the following
error: "enp3s0: Could not bring up interface: Invalid argument"
(Closes: #931636)

https://salsa.debian.org/systemd-team/systemd/commit/cce6b9e2c23c315659147cb28ad1a8947995a997

  * Use /usr/sbin/nologin as nologin shell.
In Debian the nologin shell is installed in /usr/sbin, not /sbin.
(Closes: #931850)

https://salsa.debian.org/systemd-team/systemd/commit/b0c697c519b731094d4ad11ae59afd76c1901aae

  [ Mert Dirik ]
  * 40-systemd: Don't fail if SysV init script uses set -u and $1 is unset
(Closes: #931719)

https://salsa.debian.org/systemd-team/systemd/commit/3f1c8e9d4c9bc5f49a13b2415f8f8845423f347f

241-5+deb10u1 is identical to 241-7 which has been uploaded to
unstable/bullseye and we haven't received any regression reports so far.

None of those changes should touch udev-udeb, i.e. d-i.
That said, I've added kibi/debian-boot to CC for his ack.

Regards,
Michael


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index ed55c95..a421cb9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,33 @@
+systemd (241-5+deb10u1) buster; urgency=medium
+
+  * ask-password: Prevent buffer overflow when reading from keyring.
+Fixes a possible memory corruption that causes systemd-cryptsetup to
+crash either when a single large password is used or when multiple
+passwords have already been pushed to the keyring. (Closes: #929726)
+  * Clarify documentation regarding %h/%u/%U specifiers.
+Make it clear, that setting "User=" has no effect on those specifiers.
+Also ensure that "%h" is actually resolved to "/root" for the system
+manager instance as documented in the systemd.unit man page.
+(Closes: #927911)
+  * network: Behave more gracefully when IPv6 has been disabled.
+Ignore any configured IPv6 settings when IPv6 has been disabled in the
+kernel via sysctl. Instead of failing completely, continue and log a
+warning instead. (Closes: #929469)
+  * network: Fix failure to bring up interface with Linux kernel 5.2.
+Backport two patches from systemd master in order to fix a bug with 5.2
+kernels where the network interface fails to come up with the following
+error: "enp3s0: Could not bring up interface: Invalid argument"
+(Closes: #931636)
+  * Use /usr/sbin/nologin as nologin shell.
+In Debian the nologin shell is installed in /usr/sbin, not /sbin.
+(Closes: #931850)
+
+  [ Mert Dirik ]
+  * 40-systemd: Don't fail if SysV init script uses set -u and $1 is unset
+(Closes: #931719)
+
+ -- Michael Biebl   Fri, 26 Jul 2019 21:32:04 +0200
+
 systemd (241-5) unstable; urgency=medium
 
   * Revert "Add check to switch VTs only between K_XLATE or K_UNICODE"
diff --git a/debian/extra/init-functions.d/40-systemd 
b/debian/extra/init-functions.d/40-systemd
index 4fa9b9c..e944acb 100644
--- a/debian/extra/init-functions.d/40-systemd
++