Processed: Bug #928931: more info + patch

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +patch
Bug #928931 [debian-installer] debian-installer: apt-setup/local0/key fails on 
buster because gnupg is not installed
Added tag(s) patch.

-- 
928931: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928931
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928931: Bug #928931: more info + patch

[Raphaël Halimi]

Control: tags -1 +patch

Hi,

I don't mean to rush you, but I noticed that this bug is still not fixed
in d-i RC2.

My current workaround is to add a hook in base-installer.d (because it
has to be done just before apt gets configured) to replace
/usr/lib/apt-setup/generators/60local with a version including a line to
install gnupg before "apt-key add" is called (patch included).

(the modification can also be done manually during the base system
installation phase, but it is error-prone, has to be done very quickly
at the right moment, and of course completely defeats the purpose of an
unattended installation)

I noticed that gnupg used to be Priority: important, whereas it's now
Priority: optional.

If installing gnupg is what it takes to fix the bug, IMHO it should be
done; anyway, with this patch, it would be installed only if a local
repository with a GnuPG key is used at all.

I hope this fix (or another one of your own choice) will make it to d-i
before release.

Regards,

-- 
Raphaël Halimi
--- 60local.orig	2018-08-10 21:20:36.0 +0200
+++ 60local	2019-06-29 10:36:46.0 +0200
@@ -35,6 +35,7 @@
 		while :; do
 			if fetch-url "$key" "$ROOT/tmp/key$i.pub"; then
 # add it to the keyring
+$chroot $ROOT apt-get --yes --no-install-recommends install gnupg
 $chroot $ROOT apt-key add "/tmp/key$i.pub"
 rm -f "$ROOT/tmp/key$i.pub"
 break


signature.asc
Description: OpenPGP digital signature

Bug#851774: Bug#928931: Bug #928931: more info + patch

[Cyril Brulebois]

Hi Raphaël,

Raphaël Halimi  (2019-06-29):
> I don't mean to rush you, but […]

Hrm.

> My current workaround is to add a hook in base-installer.d (because it
> has to be done just before apt gets configured) to replace
> /usr/lib/apt-setup/generators/60local with a version including a line
> to install gnupg before "apt-key add" is called (patch included).
> 
> (the modification can also be done manually during the base system
> installation phase, but it is error-prone, has to be done very quickly
> at the right moment, and of course completely defeats the purpose of
> an unattended installation)
> 
> I noticed that gnupg used to be Priority: important, whereas it's now
> Priority: optional.
> 
> If installing gnupg is what it takes to fix the bug, IMHO it should be
> done; anyway, with this patch, it would be installed only if a local
> repository with a GnuPG key is used at all.

Well, I proposed doing so a while ago but that didn't happen. Looking at
the current gnupg package, it's not about installing just a single,
extra package:

Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= 
2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< 
2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= 
2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), 
gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< 
2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2)

I'm also not sure what part of dirmngr and/or gpg-agent are going to
stay around running, after calling “apt-key add” with gnupg installed.

Testing that was conceivable a couple of weeks/months back; a few days
before an archive freeze, not so much.

Plus, we've got a MR against apt-setup now, see #851774. It's also come
late and nobody reviewed it yet. Plus, the other, serious bug report was
marked as buster-ignore by a release team member, so there's no *need*
to fix this before buster.

> I hope this fix (or another one of your own choice) will make it to
> d-i before release.

All in all, it looks like we're instead going to consider the MR at the
beginning of the bullseye release cycle, and backport the fix to buster
if it proves to be working fine.

Letting the other bug and Moritz know through cc.


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


signature.asc
Description: PGP signature

Re: Bug#930856: autopkgtest-build-qemu: captures something from host

[Dmitry Bogatov]

[ After futher investigation, this command fails with same error directly,
 without autopkgtest, so reassigning ]

control: reassing -1 debootstrap
control: retitle -1 debootstrap uses wrong keyring

Dear maintainer of debootstrap, I can't create chroot due following error:

  # debootstrap --variant - unstable /tmp/foo.dir http://deb.debian.org
  I: Checking Release signature
  E: Release signed by unknown key (key id 04EE7237B7D453EC)
 The specified keyring /usr/share/keyrings/devuan-archive-keyring.gpg may 
be incorrect or out of date.
 You can find the latest Debian release key at 
https://ftp-master.debian.org/keys.html

Note that APT tries to use Devuan keyring to validate Debian release and
fail. How does `debootstrap' decides, which keyring to use?

I am aware about --keyring option, original bug was about
`autopkgtest-build-qemu', which invokes debootstrap through several
layers and does not allow passing additional arguments to `debootstrap'.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Re: Bug#930856: autopkgtest-build-qemu: captures something from host

[Bastian Blank]

On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote:
> Note that APT tries to use Devuan keyring to validate Debian release and
> fail. How does `debootstrap' decides, which keyring to use?

"dpkg -s debootstrap"?  How did that keyring get on the system in the
first place?

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4

Re: Buster rc2 gnome installation

[Ben Hutchings]

On Fri, 2019-06-28 at 20:52 +, Christopher Patrick wrote:
> Ever since Debian rc1 installer when I try to install Debian Buster
> it installs gnome correctly till I reboot and it stalls by say g
> resuming from hibernate,but it's never been booted to hibernate. I
> cannot even get to a tty terminal.

I don't think it's resuming from hibernate; this is #928736.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.



signature.asc
Description: This is a digitally signed message part

Bug#927165: debian-installer: improve support for LUKS

[Roger Shimizu]

On Tue, Jun 11, 2019 at 12:06 AM Guilhem Moulin  wrote:
>
> Hi there,
>
> On Mon, 15 Apr 2019 at 23:24:19 +0200, Cyril Brulebois wrote:
> >>> One could argue that cryptodisk support has never been supported by
> >>> d-i anyway,
> >>
> >> Yup, and I suppose that's why I overlooked this in my mail to
> >> debian-boot :-P  Jonathan Carter had a similar report last week
> >>
> >> https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2019-April/008196.html
> >
> > While I'm usually fine to dismiss some bug reports as “it's unsupported,
> > sorry”, making users' life harder doesn't seem really reasonable… :/
>
> During last week's gathering at MiniDebConf Hamburg we (cryptsetup package
> maintainer + KiBi) talked and came up with the following guide/notes:
>
> https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

Thank for the above doc, which is quite easy understanding and straightforward!
I didn't notice this until it's mentioned by release announcement of
D-I RC2 [1].

I confirmed with /boot set up in LUKS1, everything works fine.
It‘d configure non encrypted /boot when in D-I, then after finishing
D-I, and reboot to system, manually make LUKS1 for /boot partition.

However, I found adding:
  GRUB_PRELOAD_MODULES="luks cryptodisk"
to /etc/default/grub is not necessary.
  GRUB_ENABLE_CRYPTODISK=y
is the only setting need to append manually.
(/etc/fstab /etc/crypttab need to be edited for sure)

Thanks again for your effort on the guide/notes above!

[1] https://lists.debian.org/debian-devel-announce/2019/06/msg5.html
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1