qemu-debootstrap inserts debian repos into the chroot

I tried several combinations:
$ sudo qemu-debootstrap --no-check-gpg --arch=armhf jessie ./test-root-jessie-raspian http://mirrordirector.raspbian.org/raspbian
$ sudo qemu-debootstrap --no-check-gpg --arch=armhf jessie ./test-root-jessie
$ sudo qemu-debootstrap --no-check-gpg --arch=armhf jessie ./test-root-jessie-mirrorset http://httpredir.debian.org/debian/
$ sudo qemu-debootstrap --no-check-gpg --arch=armhf trusty ./test-root-trusty

All jessie ones have
deb http://httpredir.debian.org/debian jessie main
The Trusty has
deb http://ports.ubuntu.com/ubuntu-ports trusty main

As far as I understood your report you'd have expected to see http://mirrordirector.raspbian.org/raspbian there right?

AFAIK the distribution defines the keyring.
And as you already pointed out:
I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian

Maybe that is it:
$ sudo qemu-debootstrap --no-check-gpg --arch=armhf jessie ./test-root-jessie-raspian-keyset --keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg http://mirrordirector.raspbian.org/raspbian

But then this is happening at --second-stage and since this is defined as:
  --second-stage
      Complete the bootstrapping process. Other arguments are generally not needed.
It gets no further arguments when called e.g.:
I: Running command: chroot ./test-root-jessie-raspian-keyset /debootstrap/debootstrap --second-stage
I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian

The failing check on key and fallback is in "/usr/share/debootstrap/functions".
The one that is interesting is copied into $tgtdir)/deboostrap/
So modifying that for debugging a bit.

Breaking that down:
  $ mkdir test-root-jessie-raspian-stepbystep
  $ debootstrap --arch armhf --foreign --no-check-gpg --keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg jessie ./test-root-jessie-raspian-stepbystep http://mirrordirector.raspbian.org/raspbian
  # modify for debugging
  $ sudo cp /usr/bin/qemu-arm-static ./test-root-jessie-raspian-stepbystep/usr/bin/
  $ chroot ./test-root-jessie-raspian-keyset /debootstrap/debootstrap --second-stage

Deconstructing whats going on there.
- First of all the issue is reproducible there
- Setting the keyring in stage 2 fails as that needs gpgv (intended to run in stage 1 only)
- setting --no-check-gpg in stage 2 fails as well
- the raspbian keyring only comes later when the respective file is installed (raspbian-archive-keyring)

I also tried with a modified debootrap script for raspbian, but that failed me as well.
I'm out of ideas - but I'm pretty much (>80%) convinced that this is far more a deboostrap bug than of the qemu-debootrap wrapper.

Yet my debootrap-foo is limited, adding a proper bug task and look forward for deboostrap experts to do some magic.

Yes, I expected the chroot to end up with the mirror I asked for in the sources.list. This is the behaviour with a normal debbotstrap invocation.

This doesn't actually have anything to do with the keyring file at all.

The reason this happens is because there is no mechanism for the first stage to tell the second stage what mirror to use, nor any way for it to be passed in as an argument on the command line when running the second stage. If you try to set a mirror, debootstrap explicitly ignores it, setting the variable to "null:".

The reason why Ubuntu does not have this problem is because they have overridden the mirror URLs in their suite scripts, eg /usr/share/debootstrap/scripts/trusty, the very first lines. Debian suite scripts do not do this, and so they end up using the URL hard coded into debootstrap since there is no other way to override it.

Since Raspbian re-uses the Debian suite scripts unmodified, it ends up getting the Debian repositories when doing foreign bootstrap. As a workaround you can simply fix them manually after the second stage runs, because they aren't used for anything and sources.list only gets written with the wrong value after the second stage has unpacked and configured everything.

Hi Alistair,
yes that matches 100% what I have found and is the reason I added a bug task for debootstrap.
Sorry if I didn't sum it up so well, but yeah - I agree that the root cause is the lack of an ability to pass such info to second stage (or alternatively that second stage knows how to handle better what it finds from first stage in such cases).

I kept the qemu-debootstrap task since if debootstrap develops something to be passed to second stage that needs modification of the second stage call that would have to be changed there.

Thinking about it, it actually wouldn't make too much sense to fix that in the Ubuntu Delta of the two packages.

This bug is present in Debian too. So it would be best fixed in Debian, and then Ubuntu will pick it up on the next merge.

Would you mind filing bug(s) with Debian please?

Mention the Bug numbers here and we can link them, so we will get an auto-update once there is anything to consider for backporting/merging.

Was there a bug filed upstream and if so, can you please share the ticket number/link to ticket?
Couldn't really find a corresponding bug at https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=qemu-user-static.

Thanks.

Status changed to 'Confirmed' because the bug affects multiple users.