* What led up to the situation?

  Tested with weekly build image (2025-02-24)

https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-
amd64-netinst.iso

  Using netinst.iso, it hangs when scanning the mirror frequently.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

  Bad case:

    Debian archive mirror country: choose "Japan"
    Then choose mirror "deb.debian.org"

  Bad case:

    Debian archive mirror country: choose "United States"
    Then choose mirror "ftp.us.debian.org"

  Good case:

    Debian archive mirror country: choose "Japan"
    Then choose mirror "ftp.jp.debian.org"

* What was the outcome of this action?

  It tends to stall with "Scanning the mirror..." message.

  It is reasonable taking time to choose appropriate mirror,
  but no response for a long time.
  It brings weird user experience.

  I don't know whether it might be region specific issue.

* What outcome did you expect instead?

  If it does not stall, please show something updated message time to
  time.
  It is hard to wait with only "Scanning the mirror..." even though the
  problem is arised from mirror.

Regards,

Hi,

Am 1. März 2025 14:28:52 MEZ schrieb Kentaro Hayashi <kenhys@xdump.org>:

I cannot reproduce your findings here.

Apparently an regional or temporary issue, yes.



Holger

Hi,

Surely it might be region specific or temporary issue.

According to
Debian mirror status [1], mirrors.xtom.jp was timed-out
at that time, but it was resolved now.

I've tried again and this issue is still reproducible even though mirror
status was resolved.

[1] https://mirror-master.debian.org/status/mirror-status.html

I've collected syslog.
If the problem was reproduced, it takes 20 or 30 minites to be
processed.
It seems that choose-mirror causes this edge case.

Case 1:

  Mar  2 09:54:30 choose-mirror[22395]: DEBUG: command: wget
--no-verbose http://ftp.us.debian.org/debian/dists/trixie/Release -O - | grep -E 
'^(Suite|Codename|Architectures):'
  Mar  2 09:55:24 init: starting pid 453, tty '/dev/tty2': '-/bin/sh'
  Mar  2 10:01:15 choose-mirror[22395]: DEBUG: command: wget
--no-verbose http://ftp.us.debian.org/debian/dists/testing/Release -O - | grep -E
 '^(Suite|Codename|Architectures):'
  Mar  2 10:08:02 choose-mirror[22395]: INFO: suite/codename set to:
testing/trixie
  Mar  2 10:08:02 choose-mirror[22395]: DEBUG: command: wget
--no-verbose http://ftp.us.debian.org/debian//dists/trixie/main/binary-amd64/Release -O - | grep ^Architecture:
  Mar  2 10:14:48 /bin/in-target: warning: /target/etc/mtab won't be
updated since it is a symlink.


Case 2:

  Mar  2 10:39:16 choose-mirror[22461]: DEBUG: command: wget
--no-verbose http://deb.debian.org/debian/dists/trixie/Release -O - | grep -E '^(
Suite|Codename|Architectures):'
  Mar  2 10:48:17 choose-mirror[22461]: DEBUG: command: wget
--no-verbose http://deb.debian.org/debian/dists/testing/Release -O - | grep -E '^(Suite|Codename|Architectures):'
  Mar  2 10:57:18 choose-mirror[22461]: INFO: suite/codename set to:
testing/trixie
  Mar  2 10:57:18 choose-mirror[22461]: DEBUG: command: wget
--no-verbose http://deb.debian.org/debian//dists/trixie/main/binary-amd64/Release -O - | grep ^Architecture:
  Mar  2 11:06:18 /bin/in-target: warning: /target/etc/mtab won't be
updated since it is a symlink.
  Mar  2 11:06:24 in-target:
  Get:1 http://deb.debian.org/debian trixie InRelease [175 kB]


Regards,

This bug occurs with the following conditions are met:

1. IPv4 and IPv6 was configured with netcfg
2. But, IPv6 connectivity is something broken
3. choose-mirror uses wget without timeout

In above case, wget tries to connect with IPv6
first and timeout when 900 seconds has passed.

The default timeout of wget is too long, so
it seems that installer was stalled.

Thus if IPv4: OK and IPv6 OK, there is no problem. (expected)
If actual connectivity about IPv4 is OK but IPv6 is NG, it make d-i
useless.

This seems very edge case, but if it can be fallback to IPv4
appropriately (wget --inet4-only or --prefer-family=IPv4),
during choose-mirror process, that situation will be improved.

Regards,

I've got that when installing Debian with bridge mode with WiFi
interface on Virtualbox guest,
IPv6 connectivity was broken unexpectedly.

This bug was well-known and not fixed for a long time.

  Bridge mode with WiFi interface: IPv6 does not work via router
https://www.virtualbox.org//ticket/22153

So, changed severity to normal.

(When using installer on VM, it might affect to tester/developer)

Regards,