Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

2024-02-14 Thread Raphael Hertzog 
On Wed, 14 Feb 2024, Raphael Hertzog wrote:
> i.e. is the the file-loss triggered only by the bad path in the
> dpkg-divert call or is it triggered by the upgrade of dpkg between
> both dpkg-divert calls?
> 
> I thought it was the latter... and that would explain why OpenQA is not
> affected, it likely generates images against the release that it is
> testing.

I have confirmed this. The bad path is not problematic in itself,
dpkg-divert will move the file away and put it back as expected.

I believe it's because dpkg is removing /sbin/start-stop-daemon in favor
of /usr/sbin/start-stop-daemon that we are losing the diverted .REAL file.

Even though this file loss scenario is rare because you need to have
two specific dpkg version in bootstrap-base and pkgsel, it's still worth
fixing because the ineffective diversions means that any dpkg
upgrade in pkgsel will happily overwrite d-i's version of start-stop-daemon
and thus we might start seeing daemons running in the debian-installer
environment.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

2024-02-14 Thread Raphael Hertzog 
(Adding Colin as one of the debian-installer-utils comaintainers)

Hi,

On Tue, 13 Feb 2024, Helmut Grohne wrote:
> I also see that https://openqa.debian.net/ has recent successes. dpkg
> migrated to trixie about two weeks ago. I would have expected that this
> breaks an d-i. Do you have an explanation for why jobs still pass?

FTR, in the Kali bug the case is really special:
1/ a dpkg with /sbin/start-stop-daemon is installed by debootstrap
   (bootstrap-base step)
2/ a dpkg with /usr/sbin/start-stop-daemon is installed (upgraded)
   during the pkgsel step

Could it be possible that if you have the same dpkg version in the
image and in the network repository, then you would not be bitten by
the bug?

i.e. is the the file-loss triggered only by the bad path in the
dpkg-divert call or is it triggered by the upgrade of dpkg between
both dpkg-divert calls?

I thought it was the latter... and that would explain why OpenQA is not
affected, it likely generates images against the release that it is
testing.

> Raphael, can you link this bug to the Kali bug?

Done.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

2024-02-13 Thread Helmut Grohne 
Package: di-utils
Version: 1.148
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + dpkg
Tags: patch
Forwarded: 
https://salsa.debian.org/installer-team/debian-installer-utils/-/merge_requests/11
X-Debbugs-Cc: b...@debian.org, f...@debian.org

Hi,

Raphael kindly pointed me at this Kali Linux bug report:
https://bugs.kali.org/view.php?id=8628
In there, we can see (among other things):

| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename
| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename
| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename

Due to this harmless warning, we learn that /sbin/start-stop-daemon is
being diverted, but dpkg now installs it as /usr/sbin/start-stop-daemon.
We are effectively faced with what DEP17 P3 calls an ineffective
diversion. We later see:

| Feb 8 22:07:08 grub-installer: dpkg: warning: 'start-stop-daemon' not found 
in PATH or not executable
| Feb 8 22:07:08 grub-installer: dpkg: error: 1 expected program not found in 
PATH or not executable
| Feb 8 22:07:08 grub-installer: Note: root's PATH should usually contain 
/usr/local/sbin, /u
| Feb 8 22:07:08 grub-installer: sr/sbin and /sbin

Raphael kindly pointed at chroot-setup.sh from di-utils. There
/sbin/start-stop-daemon is diverted with --rename. Since it is installed
as /usr/sbin/start-stop-daemon, this diversion (and its rename) does not
take any effect. When it is undiverted, the /sbin/start-stop-daemon (and
since the chroot is /usr-merged also /usr/sbin/start-stop-daemon) is
deleted and then undiverted with --rename, but there is no
/sbin/start-stop-daemon.REAL, because that diversion ended up being
ineffective. Therefore, nothing is moved back and we lost
/sbin/start-stop-daemon (and /usr/sbin-start-stop-daemon).

I've prepared a patch that duplicates diversions as needed and filed it
in the linked merge request on salsa. I've attempted testing this, but
debian-installer still FTBFS in unstable. Holger told me that Fil and
openqa.debian.net would be somehow able to test MRs on salsa. Fil, can
you help here?

I also see that https://openqa.debian.net/ has recent successes. dpkg
migrated to trixie about two weeks ago. I would have expected that this
breaks an d-i. Do you have an explanation for why jobs still pass?

Raphael, can you link this bug to the Kali bug?

Helmut