Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[James Addison]

On Mon, 1 May 2023 at 03:00, Cyril Brulebois  wrote:
> Diederik de Haas  (2023-04-30):
> > I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that
> > is its name in the upstream repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>
> Yes please.

Agreed.

I'm trying to figure out the reason that the kernel module requests
the verbose-style firmware filename (that include spaces) in the first
place.

In the case of the RPi B, the kernel source contains a device-tree
file for the brcm2711, the relevant hardware.

The 'compatible'[1] field of the brcm2711 device-tree structure file
includes the string "raspberrypi,4-model-b" -- matching one of the
files in linux-firmware.git's brcm directory -- but the 'model'[2]
field, containing "Raspberry Pi 4 Model B", could be the one that's
used when the firmware file request is issued when the module loads
(?).

Also, the brcmfmac kernel module code mentions[3] that it can load
board-specific firmware file paths.  I'm not yet sure whether that's
relevant (either now, or in future).

> Diederik de Haas  (2023-04-30):
> > And that's exactly what happens or will happen. Even though the RPi4 
> > filename
> > doesn't contain spaces, there are several in the `brcm` directory that do.
> > I didn't check other directories, but I'd expect that filenames with a 
> > space is
> > NOT an anomaly.

Since more files with that pattern are appearing upstream in
linux-firmware.. yes, slightly reluctantly it does seem that this will
be needed.

On Mon, 1 May 2023 at 03:00, Cyril Brulebois  wrote:
> We won't rewrite hw-detect for bookworm, nor will we make it “shellcheck
> compliant”. Now is definitely not the time to deal with such things, and
> yes I'm going to call system files (e.g. package-shipped) with spaces an
> anomaly.
>
> People are much than welcome to put energy into making hw-detect more
> robust in the future, but even knowing some bits about it, it's some
> kind of a maze and I *really* don't want to lose any feature for the
> generic cases (non-crazy filenames).

I'd generally agree with all that.  For robustness, and when it's safe
to, it'd be nice to resolve both issues (firstly to ensure that the
correct firmware filename is being requested in these cases -- maybe
it already is, I'm still trying to determine whether that's a bug --
and secondly to support spaces in firmware filenames in hw-detect).

[1] - 
https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L9

[2] - 
https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L10

[3] - 
https://elixir.bootlin.com/linux/v6.1/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c#L772

Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[James Addison]

Source: preseed
Followup-For: Bug #1031643
X-Debbugs-Cc: car...@debian.org, a...@debian.org, freyerm...@physik.uni-bonn.de

Hi folks,

This is nitpicky, but I think there is an important-ish further detail to
report.

The fix applied does repopulate the 'hostname' variable so that env2debconf can
read from it and place it into the 'netcfg/get_hostname'[1] preseed variable; so
far, so good.


However: the hostname in the running Debian installer masks the intended
behaviour of 'netcfg/get_hostname', because netcfg's DHCP logic prefers[2]
to read the running system's hostname, when it is non-empty.

I've confirmed this behaviour by netbooting from the Bookworm RC 2 installer;
DHCP configuration of a hostname is ignored when the command-line hostname is
present.

(note: a similar setting, 'netcfg/hostname' is available that takes precedence
over DHCP[2] hostname values, but it's a separate setting, and is not our
documented[3] behaviour of the 'hostname' preseed alias)


Suggestions:

This was found following some related documentation discussion[4] on Salsa.  In
that discussion, Martin Samuelsson suggests a fix that I think should work:

We should (un)set the d-i system's hostname to the 'empty' hostname early in
the installer session.

That could happen in env2debconf -- or it could be placed even earlier in the
installer scripts (since it's only relatively recently that Linux 6.0 began
reading a hostname, we should be confident that d-i works OK without one
configured).

I'm doing some testing to confirm the fix currently.

Thanks,
James

[1] - https://sources.debian.org/src/netcfg/1.185/dhcp.c/#L578

[2] - 
https://sources.debian.org/src/netcfg/1.185/debian/netcfg-common.templates/?hl=145#L160

[3] - 
https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-aliases

[4] - 
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/25

Bug#1035305: Re: Bug#1035305: Bugs on Debian 12 RC2

[pham...@bluewin.ch]

Hello Cyril,
Apart from what I quoted to you, the installer works correctly.
However, there is another major bug (excluding installation) that I noticed, 
the command lines below do not work with this RC2, they generate a whole series 
of errors:
add-apt-repository "deb https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu 
lunar main" && apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 
0AB215679C571D1C8325275B9BDB3D89CE49EC21 && apt update && apt install firefox -y
add-apt-repository "deb https://ppa.launchpad.net/vincent-vandevyvre/vvv/ubuntu 
lunar main" && apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 
7CAA00CD3DCA73E24812D646A5ADEEFF89F92A1A && apt update && apt install qarte -y
I would have been delighted if progress had been made on the other points I 
raised (WPA3 support and boot files installing on the /boot/efi partition of 
Windows and not Debian). But reading you I'm afraid it won't happen in Debian 
12, which I deeply regret ;-(
I am also very surprised that the Nvidia drivers have not been integrated into 
this RC2. This greatly limits the possibility of migrating to this RC2 to 
perform more in-depth tests with machines with only one Nvidia card available.
Best regards and good continuation to you.
This message has been translated from French to English via google translate.
Philippe
Message d'origine
De : k...@debian.org
Date : 30/04/2023 - 16:59 (E)
À : 1035...@bugs.debian.org
Cc : pham...@bluewin.ch
Objet : Re: Bug#1035305: Bugs on Debian 12 RC2
Control: retitle -1 Bugs on Debian 12 RC2
Control: submitter -1 pham...@bluewin.ch
Hi Philippe,
pham...@bluewin.ch 
 (2023-04-29):
> Configure network: [ X]
> 
> - WAP3 support from the installer is required. My Laptop (Dell XPS
> 9520) does not have an RJ-45 connection, it only has Wifi available
> like many machines today. My router is configured in WAP3 only... This
> complicates things a lot during installation.
To reiterate my answer from debian-boot@ earlier[1], we don't support
WPA3 in the installer yet (now tracked via #1035306[2]). Be it within the
installer or outside it, a custom workaround when native connectivity
isn't working (for whatever reason) is using an USB-to-Ethernet adapter.
  1. https://lists.debian.org/debian-boot/2023/04/msg00351.html
  2. https://bugs.debian.org/1035306
> - The problem to solve which is present in all intermediate versions
> of Debian is related to sources.list. It lacks the following
> information :
> 
> # Bookworm base repository
> deb https://deb.debian.org/debian bookworm main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm main non-free-firmware
> #
> # Bookworm-updates
> deb https://deb.debian.org/debian bookworm-updates main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm-updates main non-free-firmware
> # 
> # Security updates
> deb https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> deb-src https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> #
> # Proposed-updates (versions intermédiaires)
> # deb https://deb.debian.org/debian bookworm-proposed-updates main contrib 
> non-free-firmware
> # deb-src https://deb.debian.org/debian bookworm-proposed-updates main 
> contrib non-free-firmware
I suspect this is a “just” a side-effect of having no network in the
installer (lack of WPA3 and no alternative connectivity); the problem I
was alluding to earlier was the absence of bookworm-updates specifically
(fixed in RC 2), and that's indeed a separate topic.
> - Under Cinnamon if I deactivate the Wifi network via the taskbar, at
> the next boot it is automatically reactivated (installation on an
> external hard drive for testing). After an installation on the
> internal ssd of my laptop, the problem no longer occurs !?
I'll let others comment here, this seems weird to me.
> Install boot loader: [ X]
Dual-/multi-booting isn't my area.
> Overall install: [X ]
> 
> - After testing RC2 on my workstation, I have problems installing
> Nvidia graphics drivers for my RTX 3080. Nvidia detect does not seem
> to be present and Nvidia-drivers refuses to install, it only shows the
> available version n c isn't the right one ??
> 
> - The 'reboot' command does not work in simple user, only in root ;-(
Those are definitely not installer-related topics; the former should
probably be a bug report against one of the nvidia package; the latter
isn't a bug.
Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[Cyril Brulebois]

Hi,

James Addison  (2023-05-01):
> Source: preseed
> Followup-For: Bug #1031643
> X-Debbugs-Cc: car...@debian.org, a...@debian.org, 
> freyerm...@physik.uni-bonn.de
> 
> Hi folks,
> 
> This is nitpicky, but I think there is an important-ish further detail
> to report.

Thanks for following up on the bug report, definitely an improvement
over the MR, but I meant it when I said filing a bug report would be
best. The root cause is the same, that's a *different* issue though.

> Suggestions:
[…]
> This was found following some related documentation discussion[4] on
> Salsa.  In that discussion, Martin Samuelsson suggests a fix that I
> think should work:
> 
> We should (un)set the d-i system's hostname to the 'empty' hostname
> early in the installer session.
> 
> That could happen in env2debconf -- or it could be placed even earlier
> in the installer scripts (since it's only relatively recently that
> Linux 6.0 began reading a hostname, we should be confident that d-i
> works OK without one configured).
> 
> I'm doing some testing to confirm the fix currently.

At this stage, I'd rather consider for a minimal-impact fix, that is
unsetting only when it matches the particular setting that's been
documented since at least 2004 via svn r21378 (unassigned-hostname).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1035346: debian-installer: Failure to eject or recognize external media ejected

[bud]

Package: debian-installer
Version: bookworm
Severity: important
Tags: d-i
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Normal installation, full DVD set, USB (external) burner/reader
I selected Graphical mode but mostly used the keyboard
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Prior to this installation I was jumping the gun and pressing Continue as soon 
as the new disk was inserted. This got into a situation where I could not 
recover. There was no Back button and manually removing the disk and 
ineffective. This is emblematic of debian-installer's problem. I tried to 
submit this bug as grave but got no email response and cannot find the report.

This time I waited for each inserted disk to settle, as one would wait for apt; 
 before the system does not show the new volume has mounted, apt is likely to 
spit out another request for a media change.

If immediately pressing Enter after closing the disk's door, d-i usually worked 
but, for instance, the previous attempt d-i stalled on disk 3, where Back and 
Continue buttons did nothing and waiting or manually ejection did nothing. 
Power down is the only option. This, again, is something d-i should handle.

This bug is about a failure to recognize a media change at the end of 
installing the userland. Perhaps, fixing this will let the above bugs at least 
limp over the line. d-i asked to use "the drive '/media/cdrom'" and not cdrom0.

I checked every available option and selected LXDM; I tried SDDM earlier with 
similar results. That is, d-i asked for a media swap when done with disk 1.

Just before the GRUB step, d-i asks for a swap back to disk 1 but d-i will not 
recognize the burner's eject button has been pressed. There is a "Go Back" 
button and I had to clicked there twice before the main menu appeared and d-i 
finally recognized the reinserted disk. For good measure, I went back to the 
software installation step, which did nothing except exit normally, at which 
point GRUB did its things without further ado.

d-i will eject the external disk when asking the user to reboot into the new 
system, but everywhere else, misses the target. Maybe a fix here can propagate 
and fix all the problems listed above, some of which have been happening for 
many releases.

   * What was the outcome of this action?

I was able to install bookworm but only in an unexpected fashion.

   * What outcome did you expect instead?

d-i should allow the user to remove the external media practically at will. 
When the eject button is pressed, d-i should recognize that and unmount and 
eject the disk as soon as possible. If a disk is inserted, d-i should recognize 
the new disk as soon as the system mounts it.

-- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[James Addison]

Source: preseed
Version: 1.115
Severity: important
Tags: d-i

Dear Maintainer,

This bugreport is a subset/related-to bug #1031643, also in preseed.

When the 'hostname' preseed alias for 'netcfg/get_hostname' is provided to
Bookworm's RC 2 installer as a kernel command-line argument, the value that
it contains unexpectedly takes higher precedence over a hostname received from
DHCP, contrary to the Installation Guide documentation[1] in combination with
the corresponding netcfg documentation[2].


Conditions:

  * Preseed alias 'hostname' configured on the kernel command-line
  * There is a DHCP server on the installation-target's network that will 
provide a hostname

Expected behaviour:

  * Installer does not ask for installation-target hostname
  * Installation-target hostname is received and configured using DHCP

Actual behaviour:

  * [good] Installer does not ask for hostname
  * [bad] Hostname is configured from the command-line, ignoring the 
DHCP-negotiated hostname.
  * This is similar to 'netcfg/hostname' -- a different setting from 
'netcfg/get_hostname'.



Context:

Since Linux 6.0, a 'hostname=...' parameter provided in the kernel command-line
is no-longer loaded into the init process environment as a variable, but is
instead used to set the hostname of the running system (skipping the
need for userspace tooling to achieve that).

That caused a conflict for the preseed aliases in the Debian Installer, because
one of the aliases is also 'hostname', mapped to 'netcfg/get_hostname'.

The fix applied in #1031643 loads the 'running system hostname' into the
environment if it is non-empty and not equal to '(none)'.  This allows
unattended installs to work again.

The 'netcfg' component that determines the system hostname (prompting for it
from the operator if required) to be installed will prefer a non-empty hostname
(as long as it is not the literal string '(none)') over one provided by DHCP
in this block of code: https://sources.debian.org/src/netcfg/1.185/dhcp.c/#L578

Thanks,
James

[1] - 
https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-aliases

[2] - 
https://sources.debian.org/src/netcfg/1.185/debian/netcfg-common.templates/?hl=145#L160

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[Cyril Brulebois]

Hi James,

And thanks for the report/forward from elsewhere, much appreciated

James Addison  (2023-05-01):
> This bugreport is a subset/related-to bug #1031643, also in preseed.
> 
> When the 'hostname' preseed alias for 'netcfg/get_hostname' is provided to
> Bookworm's RC 2 installer as a kernel command-line argument, the value that
> it contains unexpectedly takes higher precedence over a hostname received from
> DHCP, contrary to the Installation Guide documentation[1] in combination with
> the corresponding netcfg documentation[2].
> 
> 
> Conditions:
> 
>   * Preseed alias 'hostname' configured on the kernel command-line
>   * There is a DHCP server on the installation-target's network that will 
> provide a hostname
> 
> Expected behaviour:
> 
>   * Installer does not ask for installation-target hostname
>   * Installation-target hostname is received and configured using DHCP
> 
> Actual behaviour:
> 
>   * [good] Installer does not ask for hostname
>   * [bad] Hostname is configured from the command-line, ignoring the 
> DHCP-negotiated hostname.
>   * This is similar to 'netcfg/hostname' -- a different setting from 
> 'netcfg/get_hostname'.

Given the proximity of the tentative Bookworm release, my gut feeling
would be to special-case the hostname=unassigned-hostname setting that's
been documented since at least 2004, and limit “unsetting hostname” to
this particular case.

This should:
 1. be good enough for anyone having followed the example preseed from
any point in the past;
 2. and equally importantly: limit possible side-effects.

If that's not the case for (1), we should get bug reports with details
about what people have actually been doing, and whether it makes sense
to unset it unconditionally. If that's the case, we can let this thing
mature in unstable/testing post-Bookworm, and once we're absolutely
certain this isn't going to regress in some other weird way, we can
consider backporting this to Bookworm, via a point release.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1035101: Failed to detect HD if Intel RST-RAID is active

[Cyril Brulebois]

Hi,

Thomas Viehweger  (2023-04-29):
> I am able to do one test...

OK, great!

I've just rebuilt an amd64 netinst image, bundling the extra module inside
(/lib/modules/6.1.0-7-amd64/kernel/drivers/platform/x86/intel/intel-rst.ko)
and I've verified that this module loads fine in a VM.

Whether that works and actually makes the disk visible is for you to report!
(Bonus points if the disk can actually be used, but I realize you might not
want to reinstall entirely, and only check whether the disk detection is
working…)

I've uploaded the test image here, it will go away after 15 days to avoid
hogging disk space on that shared machine:
  https://people.debian.org/~kibi/bug-1035101/


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

[Cyril Brulebois]

Control: reassign -1 xserver-xorg-core-udeb 2:21.1.1-1
Control: affects -1 debian-installer

Hello debian-x,

Cyril Brulebois  (2023-04-27):
> Tracked down to 9c81b8f5b5 upstream:
>   https://cgit.freedesktop.org/xorg/xserver/commit/?id=9c81b8f5b5
> 
> Flipping the switch and wrapping it up in a netboot mini.iso
> debian-installer build led to a successful test (with amd64) by Keith.
> We'll try and confirm the same happens with arm64.
> 
> If you're happy with that approach, feel free to reassign to the udeb,
> and check the udeb-modesetting branch in xorg-server:
>   
> https://salsa.debian.org/xorg-team/xserver/xorg-server/-/commits/udeb-modesetting

Any objections to my merging/uploading this?


> I don't have access to VirtualBox right now, but we've had reports of
> failures there as well, maybe that's the same kind of things.

For completeness:

A friend of mine tested all 3 available options (VBoxVGA, VMSVGA, and
VBoxSVGA) in VirtualBox, on both Windows and Apple hosts, and the
graphical installer worked fine for him in all cases, so it looks like
the VirtualBox reports we've received are about a different issue (and
we're lacking feedback at the moment).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: Re: Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 xserver-xorg-core-udeb 2:21.1.1-1
Bug #1035014 [installation-reports] installation-reports: Graphical installer 
has Xorg "no screens found" error
Bug reassigned from package 'installation-reports' to 'xserver-xorg-core-udeb'.
Ignoring request to alter found versions of bug #1035014 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1035014 to the same values 
previously set
Bug #1035014 [xserver-xorg-core-udeb] installation-reports: Graphical installer 
has Xorg "no screens found" error
Marked as found in versions xorg-server/2:21.1.1-1.
> affects -1 debian-installer
Bug #1035014 [xserver-xorg-core-udeb] installation-reports: Graphical installer 
has Xorg "no screens found" error
Added indication that 1035014 affects debian-installer

-- 
1035014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035014
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1035351: [pre-approval] unblock: ncurses/6.4-3

[Sven Joachim]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Tags: d-i
X-Debbugs-Cc: ncur...@packages.debian.org, debian-boot@lists.debian.org
Control: affects -1 + src:ncurses

I would like to address CVE-2023-29491[1] aka bug #1034372[2] in
Bookworm.

[ Reason ]
Various memory corruption bugs exist when loading specifically crafted
terminfo database files.  This is a security problem in programs running
with elevated privileges, as users are allowed to provide their own
terminfo files under ${HOME}/.terminfo or via the TERMINFO or
TERMINFO_DIRS environment variables.

Backporting the upstream fixes seems to be too risky this late in the
release process, but via a configure option it is possible to prevent
setuid/setgid programs from loading custom terminfo files supplied by
the user, after which the bugs are no longer security relevant.

[ Impact ]
Local users could try privilege escalations in setuid/setgid programs
linked to the tinfo library.  How easily those can be achieved probably
depends on the program.

[ Tests ]
No automatic tests exist.  I have manually verified that programs can no
longer use custom terminfo files if their effective UID or GID differs
from the real one.  Also I have verified that the terminfo database in
the ncurses-{base,term} packages is unchanged from 6.4-2.

[ Risks ]
Users who are relying on their own terminfo files under
${HOME}/.terminfo can no longer use them in setuid/setgid programs and
will have to work around that, e.g. by changing their TERM variable,
using a different terminal emulator or asking their sysadmin for help.

On my systems I did not find any setuid binaries linked to the tinfo
library, but some setgid games in the bsdgames package.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

I have slightly edited the debdiff to exclude spurious changes to the
debian/lib{32,64}tinfo6.symbols files, as these are just symlinks to
libtinfo6.symbols.  See devscripts bug #773762[3].

[ Other info ]
Since ncurses produces udebs, I have CC'ed debian-boot and tagged the
bug accordingly.  There should be no effect on the installer, as I would
expect it to run all programs as root.

Thanks for consideration.

Cheers,
   Sven


1. https://security-tracker.debian.org/tracker/CVE-2023-29491
2. https://bugs.debian.org/1034372
3. https://bugs.debian.org/773762

diff -Nru ncurses-6.4/debian/changelog ncurses-6.4/debian/changelog
--- ncurses-6.4/debian/changelog	2023-01-25 21:21:49.0 +0100
+++ ncurses-6.4/debian/changelog	2023-05-01 17:57:51.0 +0200
@@ -1,3 +1,21 @@
+ncurses (6.4-3) unstable; urgency=medium
+
+  * Configure with "--disable-root-environ" to disallow loading of
+custom terminfo entries in setuid/setgid programs, mitigating the
+impact of CVE-2023-29491 (see #1034372).
+- Update the symbols files for the newly exported symbol
+  _nc_env_access.
+- New patch fix-configure-root-args-option.diff cherry-picked from
+  the 20230415 patchlevel, fixing a copy/paste error which caused
+  the "--disable-root-environ" configure option to pick up code
+  meant to be used by the "--disable-root-args" option instead.
+- New patch debian-env-access.diff, changing the behavior of the
+  "--disable-root-environ" configure option to not restrict programs
+  run by the superuser, equivalent to the "--disable-setuid-environ"
+  option introduced in the 20230423 patchlevel.
+
+ -- Sven Joachim   Mon, 01 May 2023 17:57:51 +0200
+
 ncurses (6.4-2) unstable; urgency=medium

   * Add Breaks against vim-common (<< 2:9.0.1000-2) to ncurses-base
diff -Nru ncurses-6.4/debian/libtinfo5.symbols ncurses-6.4/debian/libtinfo5.symbols
--- ncurses-6.4/debian/libtinfo5.symbols	2023-01-22 17:54:52.0 +0100
+++ ncurses-6.4/debian/libtinfo5.symbols	2023-05-01 11:36:38.0 +0200
@@ -95,6 +95,7 @@
  _nc_curr_col@NCURSES_TINFO_5.0.19991023 6
  _nc_curr_line@NCURSES_TINFO_5.0.19991023 6
  _nc_doalloc@NCURSES_TINFO_5.0.19991023 6
+ _nc_env_access@NCURSES_TINFO_5.2.20001021 6.4-3~
  _nc_err_abort@NCURSES_TINFO_5.0.19991023 6
  _nc_fallback@NCURSES_TINFO_5.0.19991023 6
  _nc_find_entry@NCURSES_TINFO_5.0.19991023 6
diff -Nru ncurses-6.4/debian/libtinfo6.symbols ncurses-6.4/debian/libtinfo6.symbols
--- ncurses-6.4/debian/libtinfo6.symbols	2023-01-22 17:54:52.0 +0100
+++ ncurses-6.4/debian/libtinfo6.symbols	2023-05-01 11:36:38.0 +0200
@@ -94,6 +94,7 @@
  _nc_curr_col@NCURSES6_TINFO_5.0.19991023 6
  _nc_curr_line@NCURSES6_TINFO_5.0.19991023 6
  _nc_doalloc@NCURSES6_TINFO_5.0.19991023 6
+ _nc_env_access@NCURSES6_TINFO_5.2.20001021 6.4-3~
  _nc_err_abort@NCURSES6_TINFO_5.0.19991023 6
  _nc_export_termtype2@NCURSES6_TINFO_6.1.20171230 6.1
  _nc_fallback2@NCURSES6_TINFO_6.1.20171230 6.1
diff -Nru ncurses-6.4/debian/patches/debian-env-access.diff ncurses-6.4/de

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[James Addison]

On Mon, 1 May 2023 at 16:00, Cyril Brulebois  wrote:
> James Addison  (2023-05-01):
> > Conditions:
> >
> >   * Preseed alias 'hostname' configured on the kernel command-line
> >   * There is a DHCP server on the installation-target's network that will 
> > provide a hostname
> >
> > Expected behaviour:
> >
> >   * Installer does not ask for installation-target hostname
> >   * Installation-target hostname is received and configured using DHCP
> >
> > Actual behaviour:
> >
> >   * [good] Installer does not ask for hostname
> >   * [bad] Hostname is configured from the command-line, ignoring the 
> > DHCP-negotiated hostname.
> >   * This is similar to 'netcfg/hostname' -- a different setting from 
> > 'netcfg/get_hostname'.
>
> Given the proximity of the tentative Bookworm release, my gut feeling
> would be to special-case the hostname=unassigned-hostname setting that's
> been documented since at least 2004, and limit “unsetting hostname” to
> this particular case.
>
> This should:
>  1. be good enough for anyone having followed the example preseed from
> any point in the past;
>  2. and equally importantly: limit possible side-effects.
>
> If that's not the case for (1), we should get bug reports with details
> about what people have actually been doing, and whether it makes sense
> to unset it unconditionally. If that's the case, we can let this thing
> mature in unstable/testing post-Bookworm, and once we're absolutely
> certain this isn't going to regress in some other weird way, we can
> consider backporting this to Bookworm, via a point release.

I understand that line of thinking, but we note that we have already
received feedback on Salsa[1] from a user whose Bookworm installation
workflow has been affected, and confirmed that the reported problem
exists.

One datapoint isn't huge, but it's non-zero - and I'd expect that any
installation using the 'hostname' preseed alias in combination with
DHCP-as-hostname-provider would be similarly affected.

The bug here is essentially that the 'hostname' alias used to provide
a fallback value, and in RC 2 d-i is used as the source of the primary
value (ignoring DHCP).  If we know that that change has taken place, I
think that we should either document it, or attempt to restore the
existing behaviour.


The possibility about introducing other regressions with any further
changes is a valid point.. I'm not sure how best to address that,
other than testing the results in various configurations.

It feels to me like 'installer begins running without its own
hostname' was likely a reasonable baseline assumption before Linux 6.0
began reading the same-named 'hostname' parameter, and so as a result
it feels like unsetting the hostname early in the installer
initialization would be safe (maybe even a good idea, to reduce a
source of input variation between install sessions).

[1] - 
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/25

Re: Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Cyril Brulebois]

Hi,

Salvatore Bonaccorso  (2023-04-30):
> [ Other info ]
> As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
> Cyril on this pre-approval request.

Thanks for that.

> Furthermore the attached debdiff still contains the UNRELEASED
> changelog entry, which will be switched for the upload.

ACK.

With both my d-i and release hats: looks good to me, please go ahead.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[James Addison]

Source: preseed
Followup-For: Bug #1031643

As requested, the hostname-param-ignores-DHCP regression bug has been filed
separately: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035349

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[Cyril Brulebois]

James Addison  (2023-05-01):
> I understand that line of thinking, but we note that we have already
> received feedback on Salsa[1] from a user whose Bookworm installation
> workflow has been affected, and confirmed that the reported problem
> exists.

And that user mentioned hostname=unassigned-hostname which would be
addressed if we were to implement what I mentioned?

> One datapoint isn't huge, but it's non-zero - and I'd expect that any
> installation using the 'hostname' preseed alias in combination with
> DHCP-as-hostname-provider would be similarly affected.
> 
> The bug here is essentially that the 'hostname' alias used to provide
> a fallback value, and in RC 2 d-i is used as the source of the primary
> value (ignoring DHCP).  If we know that that change has taken place, I
> think that we should either document it, or attempt to restore the
> existing behaviour.

Given the following comment above the netcfg/get_* lines, I tend to
agree.

# Any hostname and domain names assigned from dhcp take precedence over
# values set here. However, setting the values still prevents the questions
# from being shown, even if values come from dhcp.
d-i netcfg/get_hostname string unassigned-hostname
d-i netcfg/get_domain string unassigned-domain

Initially it looked like specific values were expected to lead to a
particular behaviour, but if we've been encouraging people to expect
*any* fallback values specified there, that's indeed another story.

(I had mentioned before “unassigned-hostname” wasn't to be seen in any
packages but “unassigned-domain”/“unnassigned-domain” definitely have
some specific handling.)

> The possibility about introducing other regressions with any further
> changes is a valid point.. I'm not sure how best to address that,
> other than testing the results in various configurations.
> 
> It feels to me like 'installer begins running without its own
> hostname' was likely a reasonable baseline assumption before Linux 6.0
> began reading the same-named 'hostname' parameter, and so as a result
> it feels like unsetting the hostname early in the installer
> initialization would be safe (maybe even a good idea, to reduce a
> source of input variation between install sessions).

Well, yes. But that isn't what we've been doing for several releases,
and going back to something-that-used-to-be-safe still worries me, esp.
with 12.0 around the corner.

I have some pending yet unrelated things to investigate on the preseed
side; I'm not sure I'll want to be testing each and every possible
combination (esp. tweaking the configuration of the DHCP server behind
the virtualization layer), but I should be able to test the water.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#1035351: [pre-approval] unblock: ncurses/6.4-3

[Cyril Brulebois]

Hallo Sven,

Sven Joachim  (2023-05-01):
> [ Other info ]
> Since ncurses produces udebs, I have CC'ed debian-boot and tagged the
> bug accordingly.  There should be no effect on the installer, as I
> would expect it to run all programs as root.

While I have never looked closely, that assessment seems very plausible
to me; based on this, no objections on the d-i side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[James Addison]

On Mon, 1 May 2023 at 17:53, Cyril Brulebois  wrote:
>
> James Addison  (2023-05-01):
> > I understand that line of thinking, but we note that we have already
> > received feedback on Salsa[1] from a user whose Bookworm installation
> > workflow has been affected, and confirmed that the reported problem
> > exists.
>
> And that user mentioned hostname=unassigned-hostname which would be
> addressed if we were to implement what I mentioned?

Yep, fair point!

> Initially it looked like specific values were expected to lead to a
> particular behaviour, but if we've been encouraging people to expect
> *any* fallback values specified there, that's indeed another story.
>
> (I had mentioned before “unassigned-hostname” wasn't to be seen in any
> packages but “unassigned-domain”/“unnassigned-domain” definitely have
> some specific handling.)

I do see that guestfs-tools references[1] them, and I suppose other
downstream software could do as well.  But within the installer's
components, I don't think that they have any special meaning.

> I have some pending yet unrelated things to investigate on the preseed
> side; I'm not sure I'll want to be testing each and every possible
> combination (esp. tweaking the configuration of the DHCP server behind
> the virtualization layer), but I should be able to test the water.

Totally reasonable, yep.  I'll try to get familiar with the process of
rebuilding the installer's initrd.

Currently I think that a relevant patch should:

  * Unset the hostname, or set the hostname to '(none)', so that the
installer's netcfg ignores[2] and is unaware of an install-time
hostname.
  * Within env2debconf, attempt to find a hostname specified on the
kernel command-line:
* The parameter may appear as a 'hostname=value', or
'hostname?=value' key=value pair.
* The parameter must appear strictly before any '---' delimiter_
in the line.
  * If a hostname was found:
* Create a local 'hostname' variable within the env2debconf'
script containing the hostname's value.
* Ensure that the 'seen' flag is assigned appropriately:
  * The value should be empty if the hostname was matched using
'hostname=value'.
  * The value should be non-empty if the hostname as matched using
'hostname?=value'.
  * If no hostname was found:
* Do nothing.

As I wrote up those criteria, they expanded and became more
complicated than I initially realized, so perhaps there could be
further hidden complexity here.  I'll do my best to prepare and test a
patch anyway.

[1] - 
https://sources.debian.org/src/guestfs-tools/1.48.3-4/customize/hostname.ml/?hl=125#L129

[2] - https://sources.debian.org/src/netcfg/1.185/dhcp.c/?hl=578#L580

Processed: Re: Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 hw-detect: firmware license cannot be accepted anymore
Bug #1033921 [hw-detect] debian-installer: Weekly build of d-i fails to find 
ipw2x00 firmware package
Changed Bug title to 'hw-detect: firmware license cannot be accepted anymore' 
from 'debian-installer: Weekly build of d-i fails to find ipw2x00 firmware 
package'.
> clone -1 -2
Bug #1033921 [hw-detect] hw-detect: firmware license cannot be accepted anymore
Bug 1033921 cloned as bug 1035356
> retitle -2 hw-detect: rework looping over filenames
Bug #1035356 [hw-detect] hw-detect: firmware license cannot be accepted anymore
Changed Bug title to 'hw-detect: rework looping over filenames' from 
'hw-detect: firmware license cannot be accepted anymore'.

-- 
1033921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033921
1035356: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035356
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Cyril Brulebois]

Control: retitle -1 hw-detect: firmware license cannot be accepted anymore
Control: clone -1 -2
Control: retitle -2 hw-detect: rework looping over filenames

Hi,

Pascal Hambourg  (2023-04-17):
> On 17/04/2023 at 17:52, Cyril Brulebois wrote:
> > Pascal Hambourg  (2023-04-17):
> > > > Ugly attached patch works for me as PoC.
> > > > Copy fd 0 into fd 9 (because it looked unused) before entering the
> > > > pipeline, and restore it when running install_firmware_pkg.
> > 
> > I think I'd be happy to take this patch for bookworm, as a workaround…

Let's keep -1 = #1033921 for Bookworm.

> > > Here is another patch for hw-detect moving the install_firmware_pkg()
> > > call outside the pipeline instead of playing with file descriptors.
> > 
> > … before considering a real/better fix after bookworm.

Let's use -2 post-Bookworm. Relatedly, some firmware filenames might
include spaces (why oh why), see #1029843. So we might benefit from
reworking the whole thing at some later point.

> I've never cloned a bug report, so I'd rather leave it to a more
> experienced user.

It's been a long time for me, let's see if that works. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Cyril Brulebois]

Hi,

James Addison  (2023-05-01):
> Also, the brcmfmac kernel module code mentions[3] that it can load
> board-specific firmware file paths.  I'm not yet sure whether that's
> relevant (either now, or in future).

Yeah, both the function you pointed to and the one handling actual
firmware requests seem to know about some alt_fw semantics, with a
fallback. But I'm not diving into that rabbit hole. :)

> Since more files with that pattern are appearing upstream in
> linux-firmware.. yes, slightly reluctantly it does seem that this will
> be needed.

[…]

> I'd generally agree with all that.  For robustness, and when it's safe
> to, it'd be nice to resolve both issues (firstly to ensure that the
> correct firmware filename is being requested in these cases -- maybe
> it already is, I'm still trying to determine whether that's a bug --
> and secondly to support spaces in firmware filenames in hw-detect).

Regarding “plans for the future”, it's worth mentioning #1033921, now
cloned as #1035356. While the former is about license acceptance for
some firmware packages specifically (and about to be fixed for bookworm)
the latter is for longer term, with a proposed patch changing the logic
around iterating over firmware filenames. I'm not saying it's going to
solve spaces-in-filenames as it is, I just thought it'd make sense to
mention it as that touches one relevant part of the hw-detect code.

 1. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1035356;filename=duplicate_stdin_for_debconf.diff;msg=45
 2. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1035356;filename=0001-check-missing-firmware-Fix-firmware-license-acceptan.patch;msg=50


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Salvatore Bonaccorso]

Hi,

On Mon, May 01, 2023 at 06:36:01PM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Salvatore Bonaccorso  (2023-04-30):
> > [ Other info ]
> > As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
> > Cyril on this pre-approval request.
> 
> Thanks for that.
> 
> > Furthermore the attached debdiff still contains the UNRELEASED
> > changelog entry, which will be switched for the upload.
> 
> ACK.
> 
> With both my d-i and release hats: looks good to me, please go ahead.

Thanks Cyril for the review. Just uploaded.

Regards,
Salvatore

Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state

[Paul Seelig]

Package: debian-installer
Severity: grave
X-Debbugs-Cc: think...@rumbero.org

Hi all,

using the xfce4 based RC2 live ISO image[1], on a Thinkpad T480 (16GB RAM/256GB 
NVME/INTEL GRAPHICS ONLY) installation of Debian in an luks encrypted LVM was 
performed.

Apparently, the required cryptsetup-initramfs packages were removed from the 
system during the last instalation stages, rendering the resulting system 
unbootable. 
Manual intervention was required to fix the issue from a live rescue system, 
something a novice user will never be able to accomplish.

The same issue was already note with the prior RC1 variant of this bookworm 
live ISO. It can be reliably reproduced. 
Attached installation logs should be sufficiently verbose about what actually 
happened underneath.

[1] 
https://cdimage.debian.org/cdimage/bookworm_di_rc2-live/amd64/iso-hybrid/debian-live-bkworm-DI-rc2-amd64-xfce.iso

Regards,
P.Seelig

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 
'oldstable-proposed-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state

[Cyril Brulebois]

Hi Paul,

and thanks for the report.

Paul Seelig  (2023-05-02):
> using the xfce4 based RC2 live ISO image[1], on a Thinkpad T480 (16GB
> RAM/256GB NVME/INTEL GRAPHICS ONLY) installation of Debian in an luks
> encrypted LVM was performed.
> 
> Apparently, the required cryptsetup-initramfs packages were removed
> from the system during the last instalation stages, rendering the
> resulting system unbootable.

Oh wow, that looks bad. Unfortunately I'm mostly familiar with the
regular d-i installer, not so much with the live counterpart.

> Manual intervention was required to fix the issue from a live rescue
> system, something a novice user will never be able to accomplish.

Can't agree with you more. (Even with a developer hat, the first time
one gets confronted with a LUKS system that cannot be unlocked leaves
traces… Still remembering that initramfs bug I encountered around 2010,
as if it were yesterday…)

FWIW: While I'm not sure about live images (and I won't check right
now), regular d-i offers a rescue mode which automates the painful
detecting and unlocking steps when it comes to LUKS stuff, so you don't
have to know about cryptsetup luksOpen and friends to get a shell into
the installed system.

> The same issue was already note with the prior RC1 variant of this
> bookworm live ISO. It can be reliably reproduced. 

Helpful data point, thanks.

> Attached installation logs should be sufficiently verbose about what
> actually happened underneath.

Either it was forgotten or dropped by the BTS; please use reply-all,
and attach it compressed (to avoid hitting size limits on either the BTS
side or on the debian-boot ML side).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state

[Cyril Brulebois]

[ Reordering slightly ]

Cyril Brulebois  (2023-05-02):
> Paul Seelig  (2023-05-02):
> > Attached installation logs should be sufficiently verbose about what
> > actually happened underneath.
> 
> Either it was forgotten or dropped by the BTS; please use reply-all,
> and attach it compressed (to avoid hitting size limits on either the
> BTS side or on the debian-boot ML side).

For reference:
 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035360#10
 - 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1035360;filename=installer-logs.tar.xz;msg=10

> > Apparently, the required cryptsetup-initramfs packages were removed
> > from the system during the last instalation stages, rendering the
> > resulting system unbootable.

That's not quite what happened. Instead, the cryptsetup-initramfs wasn't
available to start with:

Apr 30 16:11:44 in-target: Package cryptsetup-initramfs is not available, 
but is referred to by another package.
Apr 30 16:11:44 in-target: E: Package 'cryptsetup-initramfs' has no 
installation candidate

Later on, cryptsetup got removed along with a bunch of live packages.

Presumably, if cryptsetup-initramfs had been successfully installed, it
would have kept cryptsetup around.

Again, I'm not familiar with the live environment, it'd be great if some
with some knowledge about the way it operates and/or the way it's built
could comment on this.

Adding debian-live@ for now, but might be debian-cd@ territory…

Very wild guess: Could cryptsetup-initramfs be missing from live-setup?
  https://salsa.debian.org/images-team/live-setup.git


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature