Re: busybox: temp-deb-installer-hack.patch once again

[Holger Wansing]

Am 12. Juli 2026 11:21:50 MESZ schrieb Michael Tokarev :
>
>But for now, s/set/env/ in this line will do.

So, any objections against this?


Holger

-- 
Sent from /e/ OS on Fairphone3

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

On 7/12/26 11:35, Michael Tokarev wrote:

On 7/12/26 10:55, Michael Tokarev wrote:


So it looks lie we have, apparently, a single place in d-i which
preseeds the debconf vars from environment and the preseed.cfg
file, which uses `set', where it should be using `env' instead.


and indeed this is the case.  preseed, env2debconf:

for line in $(set); do

changing this to

for line in $(env); do

makes the kernel parameters to be recognized as preseed variables
again, with unpatched busybox.


And here, instead of using env or set, it should be possible to use
`cat /proc/cmdline' instead, to avoid all nonstandard/questionable
behavior.  Including hostname= which will be in cmdline but not in
environment (see the first part of env2debconf).  I guess it is the
way to go here.

But for now, s/set/env/ in this line will do.

Thanks,

/mjt

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

On 7/12/26 10:55, Michael Tokarev wrote:


So it looks lie we have, apparently, a single place in d-i which
preseeds the debconf vars from environment and the preseed.cfg
file, which uses `set', where it should be using `env' instead.


and indeed this is the case.  preseed, env2debconf:

for line in $(set); do

changing this to

for line in $(env); do

makes the kernel parameters to be recognized as preseed variables
again, with unpatched busybox.

This is the only place, it looks like, where we had a problem.

Should I file a bug against preseed, or fix it myself, or someone
else can do it?

After removing the hacks from busybox, it will break older preseed.

Thanks!

/mjt

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

I finally found it.

kernel variables actually works.

But the prob is the other part of the upstream commit which we're
reverting.  The part which exports funny variables need not be
reverted (and the di-hack.patch is not needed on top).  But the
first part, in showenv(), is needed.

The difference is the `set' builtin.  With our d-i hack/patches,
`set' shows the fun variables.  But without, it isn't.  Unlike
`env' which shows it either way.

Bash behaves the same vay: it accepts and exports the funny
variables, but it's `set' built-in doesn't show them.

(Well, busybox's set shows only parts of the variable names,
which seems like a bug, but it's a different story).

So it looks lie we have, apparently, a single place in d-i which
preseeds the debconf vars from environment and the preseed.cfg
file, which uses `set', where it should be using `env' instead.

And after fixing that place, everything should work.

Where that place is?

If anything, the DI_HACK is definitely not needed.

Thanks,

/mjt

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

On 7/12/26 10:16, Michael Tokarev wrote:


Now, I guess I should add some kernel parameters.


RTFM helps.  Installed a web-server, created ps.cfg in it with the following:

d-i netcfg/get_hostname string it-works-now
d-i rescue/enable boolean true

and added `url=http://192.168.101.18/ps.cfg' to the kernel command line.

The file is read but apparently the settings are ignored, exactly as the
already mentioned bug report says.

So no, something *is* broken here.  But it is not the place where the
variable is exported.

Ok, lemme dig further..

/mjt

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

On 7/12/26 08:59, Jose R Rodriguez wrote:

Thank you very much for the tips!


apt-get install debian-installer

..

fakeroot make build_netboot 2>&1 | tee -a ../make.log


This fails in the middle:

cp: cannot stat '/usr/lib/grub/x86_64-efi/*.lst': No such file or directory

Apparently, grub-efi-amd64-bin package should be in build depends for
this to work.

After installing it, I got the resulting mini.iso.

Booting it in qemu/kvm works.

Now, I guess I should add some kernel parameters.

I tried the suggested netcfg/get_hostname=it-works-now (on the kernel command 
line), -
it still asks me about the hostname, offering the default "debian".  However, 
the
variable is here (on the text console, env shows it, including child processes 
so
it's definitely here).  The same for rescue/enable=true - I see no difference 
in d-i
behavior with or without this kernel parameter.

src:rescue uses db_get rescue/enable.
How does these parameters makes into debconf?  Is it using kernel command line 
for
this stuff?

I never used debian-installer so far :)

Thanks,

/mjt

Re: busybox: temp-deb-installer-hack.patch once again

[Jose R Rodriguez]

On 2026-07-11 15:31, Michael Tokarev wrote:

On 7/12/26 00:11, Michael Tokarev wrote:

On 7/12/26 00:03, Chris Boot wrote:


 >   So if you build a busybox without the hack, try > passing e.g. 
"netcfg/get_hostname=it-works-now" to d-i and see what you get. I seem 
to remember it was about as simple as that, and it certainly may
have been changed or been fixed in more recent versions of busybox or 
d-i.


Yeah.  The only problem is that I don't know how to build
d-i - I never looked this way, ever.  This might be quite
a problem for me :)

Have some guide for me? :)  Or maybe you can try building
it yourself with the "fixed" busybox?


So I did a simple test: I created an initrd with this new
busybox version (without the two patches in question), added
a few funny kernel variables, and dropped to the shell.  And
indeed, these variables with dashes and slashes and other
interesting chars are shown in the environment of ash, and
are passed to child processes as well.

I dunno still, maybe things wont work somewhere in the d-i,
but as I stated above, I don't know how to build it.


apt-get install debian-installer

apt-get source debian-installer

cd debian-installer-20250803+deb13u6/

apt build-dep debian-installer

dpkg-checkbuilddeps

aptitude install -R [missing packages]

< https://wiki.debian.org/DebianInstaller/Build >

cd build

make (will give you a list of build targets)

Place your busybox UDEB under localudebs/

Assuming you select build_netboot as AMD64 target:

Reference your named busybox UDEB in file pkg-lists/netboot/amd64.cfg

Then begin your d-i build:

fakeroot make build_netboot 2>&1 | tee -a ../make.log

(any failures will be at ../make.log for you to examine)

This is the 'lowdown' on how to build your d-i ;-)



Thanks,

/mjt


--
Best Professional Regards.

--
Jose R R
http://metztli.it
-
Download Metztli Reiser4: Debian Trixie w/ Linux 5.17.15-3 AMD64
-
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

On 7/12/26 00:11, Michael Tokarev wrote:

On 7/12/26 00:03, Chris Boot wrote:


 >   So if you build a busybox without the hack, try > passing e.g. "netcfg/get_hostname=it-works-now" to d-i and see what you get. I seem to remember 
it was about as simple as that, and it certainly may

have been changed or been fixed in more recent versions of busybox or d-i.


Yeah.  The only problem is that I don't know how to build
d-i - I never looked this way, ever.  This might be quite
a problem for me :)

Have some guide for me? :)  Or maybe you can try building
it yourself with the "fixed" busybox?


So I did a simple test: I created an initrd with this new
busybox version (without the two patches in question), added
a few funny kernel variables, and dropped to the shell.  And
indeed, these variables with dashes and slashes and other
interesting chars are shown in the environment of ash, and
are passed to child processes as well.

I dunno still, maybe things wont work somewhere in the d-i,
but as I stated above, I don't know how to build it.

Thanks,

/mjt

Re: busybox: temp-deb-installer-hack.patch once again

[Chris Boot]

Hi both,

On 11/07/2026 20:47, Cyril Brulebois wrote:

Michael Tokarev  (2026-07-11):

Re-reading #925979 again, it feels like at the time, things were in
hurry for the upcoming buster release, and "something" went wrong.
But I really don't see where the breakage might come from, - it is
just wrong.  Upstream busybox without the hacks Just Works, and it
works better than our hacked version (because of the changes in
showenv() to display the "bad" variabled).

Maybe that was the issue here? -- somewhere in d-i it compared the
output of `set` with something?  But it is very unlikel.


The regular upstream version should work just fine...


I think it should be okay to drop the two patches now and see what
happens next.

I'll do that in a couple days, if no one objects.


I don't have enough time or energy to look back at what happened exactly
at the time, but I'm pretty sure something broke in some obvious
fashion, and that whatever I implemented (even if it looks weird now)
restore whatever was broken.


From memory, what broke was passing d-i preseed options that contain a 
slash as kernel arguments. So if you build a busybox without the hack, 
try passing e.g. "netcfg/get_hostname=it-works-now" to d-i and see what 
you get. I seem to remember it was about as simple as that, and it 
certainly may have been changed or been fixed in more recent versions of 
busybox or d-i.


Cheers,
Chris

--
Chris Boot
bo...@debian.org

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

On 7/12/26 00:03, Chris Boot wrote:


 From memory, what broke was passing d-i preseed options that contain a slash 
as kernel arguments.


Yes, this is what #925979 is about.  The problem is that I
don't see this happening now, nor was happening with the
version at the time (without the d-i-env-hack) - I built the
older busybox to see how it worked - it allows having
variables/with-slashes just fine.

See the resulting diff -- in there, the upstream codepath
which allows funny variable names is being taken only in d-i
mode, while in non-d-i mode, this is disallowed.  Our patch
*restricted* funny-named variables usage compared with the
upstream version.

>   So if you build a busybox without the hack, try > passing e.g. "netcfg/get_hostname=it-works-now" to d-i and see what you get. I seem to remember 
it was about as simple as that, and it certainly may

have been changed or been fixed in more recent versions of busybox or d-i.


Yeah.  The only problem is that I don't know how to build
d-i - I never looked this way, ever.  This might be quite
a problem for me :)

Have some guide for me? :)  Or maybe you can try building
it yourself with the "fixed" busybox?

Thanks,

/mjt

Re: busybox: temp-deb-installer-hack.patch once again

[Cyril Brulebois]

Hi,

Michael Tokarev  (2026-07-11):
> Re-reading #925979 again, it feels like at the time, things were in
> hurry for the upcoming buster release, and "something" went wrong.
> But I really don't see where the breakage might come from, - it is
> just wrong.  Upstream busybox without the hacks Just Works, and it
> works better than our hacked version (because of the changes in
> showenv() to display the "bad" variabled).
> 
> Maybe that was the issue here? -- somewhere in d-i it compared the
> output of `set` with something?  But it is very unlikel.
> 
> > The regular upstream version should work just fine...
> 
> I think it should be okay to drop the two patches now and see what
> happens next.
> 
> I'll do that in a couple days, if no one objects.

I don't have enough time or energy to look back at what happened exactly
at the time, but I'm pretty sure something broke in some obvious
fashion, and that whatever I implemented (even if it looks weird now)
restore whatever was broken.

Because I don't have an infinite amount of time, and because I cannot
get involved with every bit of code that ends up in d-i, I know I tend
to be overly conservative in general, but particularly near the end of a
given release cycle. In that case, unless I have a strong incentive to
do otherwise, I give priority to whatever existed before and wasn't
known to be badly broken (i.e. maintaining or restoring the status quo),
and it's very possible that doing so isn't the best approach on the long
run because doing so render future improvements ineffective. But that's
the best I can do, especially under time constraints. I've only skimmed
over your messages, but it seems possible that is leading to what you
call “mess” today.

Since your tests look fine, your plan looks sane to me: it's a good time
to clean everything up, check whether we get big bad regressions (old or
new). Plenty of room to investigate/adjust if needed.

Sorry for the mess, thanks for that analysis and your work on busybox in
general, and for the coordination.


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


signature.asc
Description: PGP signature

Re: busybox: temp-deb-installer-hack.patch once again

[Michael Tokarev]

On 7/11/26 20:59, Michael Tokarev wrote:
...

What the mess.

So I really wonder where this bug #925979 come from.

Now, by reverting the mentioned busybox commit, we change one more
place, in showvars(), where - after reverting - only the "valid"
names are shown, the rest are filtered.

Cyrill, can you think how #925979 happened?  How about trying d-i
with busybox without these two patches applied?


Re-reading #925979 again, it feels like at the time, things were in
hurry for the upcoming buster release, and "something" went wrong.
But I really don't see where the breakage might come from, - it is
just wrong.  Upstream busybox without the hacks Just Works, and it
works better than our hacked version (because of the changes in
showenv() to display the "bad" variabled).

Maybe that was the issue here? -- somewhere in d-i it compared the
output of `set` with something?  But it is very unlikel.


The regular upstream version should work just fine...


I think it should be okay to drop the two patches now and see what
happens next.

I'll do that in a couple days, if no one objects.

Thanks,

/mjt