Hi,

steps to reproduce:

qemu-img create -f qcow2 disk.qcow 4G
curl https://deb.debian.org/debian/dists/bullseye/main/installer-mips64el/current/images/malta/netboot/initrd.gz > initrd.gz
curl https://deb.debian.org/debian/dists/bullseye/main/installer-mips64el/current/images/malta/netboot/vmlinuz-5.10.0-13-5kc-malta > linux
/usr/bin/time -v qemu-system-mips64el -M malta -cpu 5KEc -nographic -no-reboot -m 1G -initrd initrd.gz -kernel linux -append 'auto-install/enable=true debconf/priority=critical preseed/url=http://www.debian.org/releases/stable/example-preseed.txt netcfg/get_hostname=hostname netcfg/get_domain=domain passwd/root-password=r00tme passwd/root-password-again=r00tme passwd/user-fullname=user passwd/username=user passwd/user-password=insecure passwd/user-password-again=insecure pkgsel/run_tasksel=false popularity-contest:popularity-contest/participate=false grub-installer/bootdev=/dev/sda --- console=ttyS0' -hda disk.qcow

This stops at the following screen:

[            (1*installer)  2 shell  3 shell  4- log           ][ May 12  6:27 ]



     ┌────────────────┤ [!!] Set up users and passwords ├─────────────────┐
     │                                                                    │
     │ Please enter the same root password again to verify that you have  │
     │ typed it correctly.                                                │
     │                                                                    │
     │ Re-enter password to verify:                                       │
     │                                                                    │
     │ __________________________________________________________________ │
     │                                                                    │
     │ [ ] Show Password in Clear                                         │
     │                                                                    │
     │     <Go Back>                                       <Continue>     │
     │                                                                    │
     └────────────────────────────────────────────────────────────────────┘





<Tab> moves; <Space> selects; <Enter> activates buttons


So for some reason passwd/root-password-again is ignored. Above recipe
works fine for other architectures and for some reason stops with above
prompt on mips64el. Why?

Thanks!

cheers, josch

Hi,

Quoting Philip Hands (2022-05-12 10:14:46)

Ah thank you! I probably missed that in the docs (this is probably screen
running?). This is very helpful. :)

Ouch... that's a very unexpected architecture specific limitation. Thanks a lot
for your very quick help!

I wasn't sure where to direct my d-i "bug" reports to. Context is, that I'm
running d-i inside qemu to create bootable disk images that can then be used
with autopkgtest-virt-qemu. So far amd64, i386, ppc64el and arm64 work well.
I'm running into problems with the network interface on s390x but I'm maybe
just driving QEMU wrongly.

I assume that somebody is already running d-i in QEMU for multiple
architectures somewhere as part of some d-i CI infrastructure? If that already
exists, I'd welcome a pointer because I'm probably re-inventing the wheel here.
:)

Otherwise, feel free to close this bug report.

Thanks!

cheers, josch

Hi Phil,

Quoting Philip Hands (2022-05-12 13:40:51)
but reading the code made me learn about more things I can do with d-i. I'm
running into a problem though and maybe I can pick your brain a bit:

So I want to download a script (I'm running my own HTTP server) and execute it
at the end of the installation. I'm currently having this in my
d-i/bullseye/preseed.cfg:

d-i preseed/early_command string preseed_fetch setup-testbed /tmp/setup-testbed
d-i preseed/late_command string /tmp/setup-testbed /target

If I understand the docs of preseed_fetch correctly, then this should fetch the
setup-testbed script from a path relative to where it got the preseed file
from. Thanks to https://hands.com/d-i/ I now am just using

preseed/url=http://10.0.2.2:8000

Unfortunately (and thanks for pointing me to the keyboard shortcuts to access
the log) this results in the following:

May 13 07:26:28 preseed: successfully loaded preseed file from http://10.0.2.2:8000/d-i/bullseye/./pres
May 13 07:26:28 preseed: running preseed command preseed/early_command: preseed_fetch setup-testbed /tm
May 13 07:26:28 log-output: /bin/fetch-url: .: line 35: can't open '/usr/lib/fetch-url//setup-testbed':

I'm confused. Shouldn't preseed_fetch try to obtain the setup-testbed relative
to the preseed file it just obtained?

Thanks again!

cheers, josch

Looks rather similar to https://bugs.debian.org/678694 ...

Hi Phil,

Quoting Philip Hands (2022-05-13 11:52:05)

I found and read README.preseed_fetch just fine, so I don't think it's a
problem of find-ability of the docs. But the README should maybe contain the
things you said above and maybe even an example as you reference below. From my
reading of README.preseed_fetch I did not understand this limitation.

Ah yes, that worked! I documented the solution in my reply to #678694 and will
keep using that. It feels a bit odd to download a one-line script which does
nothing else than downloading yet another script but since it's automated I
guess I don't care. :)

I think README.preseed_fetch is fine as I was able to find it via searching for
preseed_fetch via codesearch.debian.net. I think it just needs the bits that
you explained to me above copypasted into it.

Thanks again!

cheers, josch

Diederik de Haas <didi.debian@cknow.org> writes:

True -- it's probably time to fix that ...

I my immediate reaction to the suggested patch is that there may well be
some problem with always overwriting the file, and if so, that such a
problem probably only becomes apparent when combining relative and
absolute paths in particular orders.

I would assume that even if that is the case, it should be OK to write
the file if it does not already exist, which ought to be enough to fix
this issue.

Cheers, Phil.