Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu
Diederik de Haas writes: > On Friday, 13 May 2022 09:35:49 CEST Johannes Schauer Marin Rodrigues wrote: >> 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. >> >> Unfortunately 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? > > Looks rather similar to https://bugs.debian.org/678694 ... 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. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu
Hi Phil, Quoting Philip Hands (2022-05-13 11:52:05) > Johannes Schauer Marin Rodrigues writes: > > I'm confused. Shouldn't preseed_fetch try to obtain the setup-testbed > > relative to the preseed file it just obtained? > > preseed_fetch gets things relative to the place the previous > preseed_fetch got things from, which is one step later than you are > expecting because it has not really been setup while you're in the > context of the initial preseed.cfg. > > See: > https://salsa.debian.org/installer-team/preseed/-/blob/master/README.preseed_fetch > > The point is that you need to have done a preseed/include or a > preseed/run (which can be relative paths) in order to have populated the > previous download path, whereas I think you are trying to run the > preseed_fetch while we're still on the first time through the code, in > the loop above this line: > > > https://salsa.debian.org/installer-team/preseed/-/blob/master/preseed.sh#L120 > > I guess there should be some documentation that's easier to find than > the above README, to say that you should not use relative paths for > preseed_fetch from the early_command (and possibly the late_command?) in > preseed.cfg itself, but only from within files that were grabbed via at > least one preseed/run or preseed/include -- or something like that. 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. > Here's another example that may be instructive: > > https://hands.com/d-i/bug/846002/ > > (which is referred to here: https://bugs.debian.org/846002#304 ) 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 seem to have learnt to avoid doing anything interesting in preseed.cfg > itself -- assuming that's not already mentioned somewhere, if you have a > suggestion for where that tip could have been placed to have been helpful to > you, please report a bug against the relevant documentation. 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 signature.asc Description: signature
Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu
On Friday, 13 May 2022 09:35:49 CEST Johannes Schauer Marin Rodrigues wrote: > 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. > > Unfortunately 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? Looks rather similar to https://bugs.debian.org/678694 ... signature.asc Description: This is a digitally signed message part.
Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu
Hi Phil, Quoting Philip Hands (2022-05-12 13:40:51) > BTW I somehow failed to notice that you were pointing preseed/url at the > example-preseed.cfg when I ran that locally. > > Given that you're already relying on a network preseed, you should just > put a copy of that somewhere you control, and make all the changes that > you are trying to put on the command line into your preseed.cfg instead, > and it should work fine. > > Also, you can save some more command line characters by using aliases: > > https://d-i.debian.org/manual/en.amd64/apbs02.html#preseed-aliases > > If you wanted to make your preseed setup clever enough to handle > different arch's differently, from the same preseed files, then there > are some examples of scripting here that may provide inspiration: > > https://hands.com/d-i/ > > (it's not got arch specific stuff, but it does demonstrate that you go > wild with scripting, if you want to) thank you, that's a great resource! I don't think I need full-blown framework 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 signature.asc Description: signature
Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu
Hi, Quoting Philip Hands (2022-05-12 10:14:46) > > 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? > > It seems that you are hitting a limit on the length of the command line. > > If you flip to one of the shells (Ctrl-A Ctrl-A 2) and do: > > cat /proc/cmdline Ah thank you! I probably missed that in the docs (this is probably screen running?). This is very helpful. :) > you'll see that most of your kernel commandline is missing. I'd guess > that's a limitation of mips64el. Probably best to specify a preseed > file in order to get round this limitation, either by url, or you could > try this: > > > https://wiki.debian.org/DebianInstaller/Preseed/EditIso#Adding_a_Preseed_File_to_the_Initrd 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 signature.asc Description: signature
Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu
Package: installation-reports Severity: normal X-Debbugs-Cc: jo...@debian.org 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 │ ││ │ │ ││ └┘ moves; selects; 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
