Boot method: USB
Image version: https://cdimage.debian.org/cdimage/trixie_di_alpha1/amd64/iso-cd/debian-trixie-DI-alpha1-amd64-netinst.iso
Date: <Date and time of the install>

Machine: Thinkpad P1 Gen7
Partitions: irrelevant


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

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

Comments/Problems:

The installer seems to have treated the WiFi interface as a wired one,
i.e. did not ask for the SSID, and nor for the password.
Then immediately tried using DHCP to configure the interface, which did
not work because it was not associated with an AP.

I noticed after filing that report #1095302 is even better, apart from its
submitter not being sure if WiFi should work in the installer. I'm sure it
should, because it worked flawlessly on an older ThinkPad P1 for me.

Marcin

configuration component, netcfg, does not support wifi 7.
Do you wish to merge the two bugs ?
It implies to lower the priority of this one from "important" to "normal".

[Please send replies to the bug mail address, not only mine]
merge and reassign the two bugs to netcfg. If anyone objects, the
priority can be lowered.

To d-i people: adding nl80211 and wifi 7 support to netcfg looks like a
big task and I guess it is way too late to do it before Trixie release.
However wouldn't it be desirable to mark wifi 7 controllers as
unsupported in netcfg and in the installation guide in order to limit
user frustration ?

I should also note that the touchpad did not work for me in the graphical
installer. The trackpoint does, but no amount of function or Fn+function
key pressing was able to make the touchpad come to life.
Not sure if it's best to file a separate bug about this fact.

Does the touchpad work in the installed system ?
If yes, it could be a missing kernel module in the installer.

Yes please, if a bug was not already filed for the same issue. It has
nothing to do with netcfg.

Hi Marcin,

Marcin Owsiany <marcin@owsiany.pl> (2025-04-24):

That'd be nice, please make sure to include `lsmod` from the installed
system in there, alongside the /var/log/installer/syslog (compressed).

Thanks already.


Cheers,

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-24):

The difference between normal and important is a matter of opinion, and
that doesn't really factor in what we're going to do about these bug
reports anyway. Important looks good to me.

(Also, when a submitter considers their bug to be covered by another bug
report, an option would be to close their bug, mentioning that's a
duplicate of another one, or that the other one is more complete,
precise, etc.)

ISTR someone asking for help to implement/test that, but I couldn't deal
with that at the time (or now), but I had some vague hopes to look into
it (either assisting or hacking myself) “in the near future”. I'm not
sure how prevalent Wi-Fi 7 is at the moment, but it seems to me this is
definitely something we should tackle, and that might be worth
considering as a backport to Trixie (via point releases) (1) if and when
support has landed and has been tested, and (2) if backporting doesn't
seem crazy (code/packaging change wise, and risk wise).

If we can easily spot unsupported cards and not offer them at all
(ignore entirely, with explicit log lines in syslog?) and also document
that in the installation guide, that'd be nice to have. Best if that can
land in 13.0; OK if that lands in 13.n, n>0. (Until support comes along
and is considered for a possible backport as detailed above.)


Cheers,

Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104057

Marcin

I get the impression most laptops shipping now are wifi 7.  Most machines
I have seen in the last year had had it at least.

I can certainly test it.  I asked a few months ago about how a desired
implementation should be done, but got no response from anyone to the
question.  Given the new interface is netlink based, and there already is
libnl in the installer, I don't think it would be a big change package
wise, but it would need netcfg to add support for making netlink calls
to control wifi 7 devices (and optionally wifi 6 devices I suppose).

Certainly the current installer behaviour is confusing since the driver
loads, then it treats it like a wired port which doesn't work because wifi
7 drivers require using the new interface which netcfg doesn't support.
So you see the network device present but it doesn't ask about wifi
settings it just tries to do dhcp and fails.

It was my first new laptop in 12 years, I wasn't sure. :)

Having since looked at the code it clearly should work, but not with
wifi 7 devices that require the netlink configuration interface.

Yes it does.

Lennart Sorensen <lsorense@csclub.uwaterloo.ca> (2025-04-25):

That's a useful data point, thanks.

I'm not sure I can commit to giving it a try, but it might be worth
pinging the DPL to get some test machines sent out.

I suppose you were the or one of the person(s) I was thinking about.
Again, sorry about that. (You'll get a little more info out of band.)

Yeah, the initial brainstorming I've seen a while back seemed rather
encouraging.

Yeah, I gathered that from earlier mails, but I suppose it's nice to
have a little reminder of the actual confusion, that can be picked up by
documentation writers for example.


Cheers,

Unsupported wireless interface detection could use nl80211 (not trivial,
link with libnl) or try to use some heuristics based on information
available in sysfs, maybe something like:

if /sys/class/net/$[interface}/wireless exists
or /sys/class/net/$[interface}/uevent contains "DEVTYPE=wlan"
or /sys/class/net/$[interface}/type = "801" (802.11)

Lennart or Marcin, can you check if any of these conditions match your
Wi-Fi 7 interface ?

On the user interface side, what would be best ?
- Silently ignore unsupported interfaces ? (but the user may wonder why
the interface is not showing)
- Or warn the user that the wireless interface is not supported yet ?
(with a new debconf template, implies translation effort).

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-29):

I think I answered that in my previous answer?

Log + documentation, yes.

At this stage? That really doesn't look like either reasonable or feasible.


Cheers,

wt., 29 kwi 2025 o 00:11 Pascal Hambourg <pascal@plouf.fr.eu.org>
napisał(a):

I'm assuming this is pseudocode?

These commands yield the same output on both P1 Gen7 (WiFi 7 I assume) and
P1 Gen3 (I assume not WiFi 7, because wifi worked in netcfg back when I
installed Debian on it):

+ interface=wlp9s0f0
+ ls -ld /sys/class/net/wlp9s0f0/wireless
drwxr-xr-x 2 root root 0 04-29 06:24 /sys/class/net/wlp9s0f0/wireless
+ grep --color DEVTYPE=wlan /sys/class/net/wlp9s0f0/uevent
DEVTYPE=wlan
+ cat /sys/class/net/wlp9s0f0/type
1

Marcin

Hi,

Am 29. April 2025 00:21:37 MESZ schrieb Cyril Brulebois <kibi@debian.org>:

I could think of adding a new template, but not mark it as translatable.
So it's always in English, and does not break translation status.

After Trixie is released, it could then be changed in translatable and translators get it (for Forky and probably trixie point release).


Holger

wt., 29 kwi 2025, 06:29 użytkownik Marcin Owsiany <marcin@owsiany.pl>
napisał:

Eyeballing these device directories from both laptops side by side did not
reveal anything that could be used to distinguish wifi7 from earlier
versions, but maybe I missed something.

I tried packing these directory up to attach to the bug, but the symlink
loops make it hard, and I'd rather not upload the entirety of /sys to the
internet, who knows what might be there...

Marcin

Holger Wansing <hwansing@mailbox.org> (2025-04-29):

Oh, right, sorry, I didn't think of that.

To be honest, at this stage, I'm a little worried about getting the
logic right. If someone managed to have a piece of code that works in
the installed system, I could look into doing whatever is needed to get
it to work inside d-i (dealing with Makefiles, build systems, linking
against libnl or whatever).

If someone had reference(s) of external adapters I could easily shop for
and get delivered to France, that would make the feedback loop shorter
(I'd be able to hack and build and test, instead of hacking and
building, then asking others to test). Additionally/alternatively, given
that's supposed to be widespread, maybe some cheap laptop reference(s)?

(I don't want to have huge piles of hardware at home but it seems worth
it to tackle that Wi-Fi 7 topic, and I can cope with 1-2 extra laptops
if that's OK/cheap enough for either me, my company, or the project.)


Cheers,

Thank you, this is what I expected.

These tests would happen only if the interface does not support legacy
wireless extensions (wext). The logic would be (pseudo-code):

if $interface supports legacy wireless extensions (wext)
   type = supported_wireless
else if /sys/class/net/$interface/wireless exists
      or /sys/class/net/$interface/uevent contains "DEVTYPE=wlan"
      or /sys/class/net/$interface/type = "801" (802.11)
   type = unsupported_wireless
else
   type = wired

<https://salsa.debian.org/pham/netcfg/-/tree/pham/wifi7-1>

It checks sysfs for wireless heuristics.
For this I made netcfg binary call a shell script because it is more
flexible for debugging in the installer.

IF you want to test it, an ISO image is available for a limited time:
<https://salsa.debian.org/pham/netcfg/-/jobs/7509146/artifacts/file/debian/output/debian-202501XX+salsaci+20250429+46-amd64-gtkmini.iso>

This image does not include non-free firmware, so you may need to
provide firmware packages for your hardware such as firmware-iwlwifi on
a separate media or in a FAT partition on the installer media. It has a
6MB FAT partition but it is too small for firmware-iwlfiwi. If you want
to enlarge it or create another partition, you can use fdisk with
options "-w never -W never" to preserve existing metadata.

wt., 29 kwi 2025, 21:57 użytkownik Pascal Hambourg <pascal@plouf.fr.eu.org>
napisał:

Here is what I did:

   1. dd-ed the image onto a USB stick
   2. ran fdisk -w never -W never on it, created a fourth partition of
   500MB, set its type to FAT12
   3. ran mkfs -t vfat on the partition
   4. mounted the official alpha installer image
   5. copied all files from the firmware directory on the official image
   into the new partition
   6. unmounted
   7. Booted the P1 Gen3 laptop, confirmed that I want to load firmware,
   and it showed the available SSIDs, as expected
   8. Booted the P1 Gen7 laptop, confirmed that I want to load firmware,
   and it showed the "No network interfaces detected" screen, as expected
   9. Took a screenshot and also a screenshot of the log virtual console
   with the /lib/netcfg/is_wireless messages, see attached images.

Marcin

Not sure if I made the new two templates non translatable properly,
please check.

Temporary ISO image:
<https://salsa.debian.org/pham/netcfg/-/jobs/7517082/artifacts/file/debian/output/debian-202501XX+salsaci+20250501+53-amd64-gtkmini.iso>

I may be missing something so correct me if I am wrong but IMO you do
not need Wi-Fi 7 hardware to test: you can disable the current check
which uses wext in is_wireless_iface() and use any wireless adapter
whose driver uses nl80211. AFAICS since Linux 6.8 all in-kernel wireless
drivers depend on cfg80211/mac80211.

Am 1. Mai 2025 15:17:54 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

Looks good.


Holger

Hi Marcin,

Am 1. Mai 2025 15:17:54 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

Would you mind testing this image as well?
That would be great.


Thanks
Holger

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-05-01):

If that statement is correct (I have no knowledge so cannot judge),
that's nice. But I really meant to be able to test things that currently
don't work, and make sure they start working after whatever is needed is
implemented.

What to do with other hardware that support different mode of operation
(keep wext for a while, or switch everyone to nl if that just works
without regressions) would be a different topic.

(But I fully understand the overlap, and thanks for pointing this out.)


Cheers,

czw., 1 maj 2025 o 21:16 Holger Wansing <hwansing@mailbox.org> napisał(a):

I gave it a go, it seems to work as intended, see attached screenshots.

A couple of notes that I would have found useful on this screen or related
docs:
- the installed system (network manager etc) might in fact support WiFi7
just fine
- an USB-attached ethernet interface might be a good enough workaround for
installation time

Marcin

both supported and unsupported interfaces are found:

<https://salsa.debian.org/pham/netcfg/-/jobs/7521336/artifacts/file/debian/output/debian-202501XX+salsaci+20250502+57-amd64-gtkmini.iso>

Note: You do not need Wi-Fi 7 hardware to test the user interface. You
can simulate an unsupported wireless interface with an ethernet
interface by booting the installer in expert mode, starting a shell and
editing the script /lib/netcfg/is_wireless with nano before starting the
network configuration step. This is how I test it in a VM with two
ethernet interfaces.

To make all ethernet interface appear as unsupported, insert this after
the first line:

"exit 0"

To make only a specific ethernet interface enpXsYfZ appear as
unsupported, insert this after the first line:

if [ "$1" = enpXsYfZ ]; then exit 0; fi

(you can run "ip link" to show detected network interfaces)

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Fri, 2 May 2025 11:52:02 +0200):

You are talking about a "new (...) version" here, but I cannot find any
such commit. Maybe you forgot to push something?


Holger

Because I amended the last two commits and force-pushed.

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Sun, 4 May 2025 20:26:04 +0200):

Hmm, I thought about a possibility to do it that way, but my guess was
that there should be an indication, that such action happened (like an
additional timestamp or similar).
This is apparently not the case though.
Thanks for teaching me


Holger

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Fri, 2 May 2025 11:52:02 +0200):
do not focus on the "USB-attached ethernet interface" in the template.
Maybe the user already has a wired ethernet interface built into the
laptop, but the user did not take that into account, since using WiFi is
just the preferred option, because it's easier (no need to plug in a cable).


So, something like this:

 You may need to load a specific module for your network card, if you have
 one. For this, go back to the network hardware detection step.
-Else, a USB Ethernet adapter might be a workaround during installation.
+Else, a wired Ethernet connector (built into your machine or externally
+attached via USB) might be a workaround during installation.


Holger

The user will see that template only if no supported interface was
detected. There is no user's choice, unless they chose to disable the
built-in ethernet controller in BIOS settings.

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Sun, 4 May 2025 21:53:06 +0200):

Ah, ok. Sorry for the noise then.

So I think we are ready for a MR?
Any objections, to get this into trixie, as a workaround for WiFi 7 ?



Holger

<https://salsa.debian.org/installer-team/netcfg/-/merge_requests/16>
But this was originally intended as a quick and dirty PoC, not sure it
is ready for production.

Hi,

Am 8. Mai 2025 08:08:46 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

I know this started as a PoC initially, that's why I asked for objections.
IMO it's better than having nothing, and let users run into the issue of not-working wifi, file bugreports and so on.
It would only be temporary code, I hope we will get WiFi-7 support for Forky.


Holger