Salut Sylvain, Sylvain Tgz <tarjaiz...@gmail.com> (2021-05-25): > Fastly mirror by using deb.debian.org > Sorry, I did not specify on my previous message, on syslog log during > the netinst, we can see an issue about certificate. > The error message : Certificate verification failed. The certificate > is NOT trusted. > I think ca-certificate is not loaded/used. > For me it's an issue about missing root certificate. > > I tested with your suggestion to use mirror/protocol=https in command > line and it works fine :).
Alright, thanks for confirming. For the avoidance of doubt, that's definitely a workaround and not a fix. :) It's certainly helpful to test both debootstrap and further operations using HTTPS when testing mini.iso (which is what I've used that for), but that's all. > I try again without mirror/protocol=https and the issue reappears > > To reproduce the issue : > - Start Debian netinst > - Use Graphical expert installation mode > - At the step " configure the package manager" chose https. > - Use default option > Thie issue should be reproductible. > > Could you try ? Yes, I can definitely reproduce the issue, and I think I have figured out what happens. I didn't think too hard about how to fix it yet, though. You're using netinst, so debootstrap uses the ISO to install the base system. Also, unless one has forced mirror/protocol=https at this stage, there's no chance for the user to tell debootstrap https is desired. This means that this code path doesn't help: https://salsa.debian.org/installer-team/debootstrap/-/blob/master/scripts/debian-common#L30-41 and we end up without ca-certificates in /target (where the installed system is being built). Further down the road, apt-setup runs, lets you request https, and the various generators/* scripts run apt-setup-verify to verify the configuration. That command basically runs wget inside /target (through in-target) to verify stuff, and since ca-certificates wasn't installed earlier (good guess!), that cannot work. Now, where to go from here… I think I would call it a bug for apt-setup not to notice we're about to use https and not do anything about it… Maybe it could install ca-certificates from the currently configured source (if any) in that case. As far as I can see from this test run, using the netinst image like you did, /target/etc/apt/sources.list still lists the NETINST image as a cdrom: source, so that should be doable. With other installation images (e.g. netbooting) that might not work… Maybe something like this? if https is configured if ca-certificates is installed in target be happy else if it can be installed install it, be happy else duplicate /etc/ssl/certs from / into /target queue the installation of ca-certificates The “duplicate” part doesn't feel right but it might be better than fail miserably if ca-certificates cannot be installed properly. Of course that could create a discrepancy if ca-certificates-udeb (deployed in the installer image) and ca-certificates get out of sync, and I'm not sure how ca-certificates will react to manually-deployed certificates… Regarding the “queue” part, I *think* there's a way to achieve that but I'm not sure that's true or how it would be done. If there's no generic way to achieve this, it could still be done in a finish-install script (apt-setup already has finish-install.d/10apt-cdrom-setup). I'll wait a little for others to comment on my diagnosis, but I think this could be turned into a bug report against apt-setup 1:0.163; it is very likely that it affects buster as well, and we might want to get the fix into buster. Since this can only (I think, feel free to prove me wrong) be triggered in expert mode, I would probably not block #987441 with it (or do that so that we don't lose track, while not actually blocking 11.0 with it). Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
