To recreate this issue... boot the latest Debian 13 netinst ISO and at the boot menu hit escape then at the boot: prompt type in... installgui modules=ppp-udeb Then d-i will start and after choosing language etc... it'll try to find any see PPPoE concentrators and now (since bug #1070753 was fixed!) it will actually work! However after giving it a username/password it'll try to run the things needed to actually connect and fail. /var/log/syslog shows (after executing a shell from d-i) this... pppd[2760]: Could not load legacy provider, could not load the shared library ppp-udeb: Could not load legacy provider, could not load the shared library ppp-udeb: main-menu[332]: WARNING **: Configuring 'ppp-udeb' failed with error code 1 So it seems to be more fundamentally broken than before :) Any ideas if this is something simple? Maybe addressable for the next netinst ISO of 13.4 ?
Control: found -1 2.5.2-1+1 - Select Advanced options > Expert install. - In Load installer components, select ppp-udeb. - Execute a shell. - Run "pppd -v" With strace, I see: openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/ossl-modules/legacy.so" but this openssl library is missing in installer udebs. AFAICS bookworm pppd-udeb 2.4.9 did not need it. After adding the library in the installer, the error disappears and pppd seems to run but I have no PPPoE concentrator to fully test.
Well I can confirm that if I execute a shell and run... ar p /cdrom/pool/main/o/openssl/openssl-provider-legacy_*.deb data.tar.xz|xzcat|tar xf - ./usr/lib/ -C/ Then the missing library is in the right place and PPPoE works normally
Presuming the d-i / netinst experience undergoes any kind of continuous integration tests... is using PPPoE part of those tests? It just feels both oddly very well documented ... https://www.debian.org/releases/stable/amd64/apds05.en.html ... yet simultaneously unloved ? I never got why this is an optional module anyway? Why not just make it part of the network autoconfiguration step? i.e. if local-link/ipv6-autoconf/dhcp has failed then look for a PPPoE AC instead (which now thanks to bug #1070753 takes a mere blip of time)... and if one is found then ask for user/pass. Or if you don't want it part of the autoconfiguration, then after that has failed and you've currently got the option to 'retry', or 'retry with a dhcp hostname', or 'configure manually'... just add a new option... 'Retry network autoconfiguration with PPPoE' Seem feasible? I know PPPoE isn't massively popular in places like the US, but in the UK and Europe it is widely used by many an ISP.
This bug renders the package unusable so shouldn't the severity be raised to "grave" ? Maybe because unlike "pure" d-i packages it is not maintained by the d-i team, being part of the ppp source package ? PPPoE requires a username and password, it cannot be autoconfigured. By the way, this bug [1] has not been closed yet even though the reported issue is fixed. Same with bug #1005142 [2] which reported the now fixed "pppoe-discovery -A" issue. already suggested something similar almost two decades ago. [1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070753> [2] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005142> [3] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403963>