Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

2023-07-12 Thread Arnaud Rebillout
Following up with that, it seems that the failure is due to a change in 
the kernel.


I'm testing 2 Kali netinst ISOs, one from last week (no problem), and a 
daily iso from today (which fails).


Last weekly iso had kernel 6.1.0-kali9-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives nothing, hence the grub-installer 
postinst doesn't try to mount the efivarfs.


Today's iso has kernel 6.3.0-kali1-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives `nodev efivarfs`, hence the 
grub-installer postinst tries to mount efivarfs, and fails.


--
Arnaud Rebillout / OffSec / Kali Linux Developer



Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

2023-07-12 Thread Arnaud Rebillout

On 12/07/2023 21:57, Roland Clobus wrote:


This looks to be very similar that I reported in the first part of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039710

On BIOS-boots the EFI /sys mount is not present.


I've read #1039710, I can confirm about the syslog issue, 
/var/log/syslog has just one line in it.


Regarding GRUB failing to install, I forgot to mention how it actually 
looks like: a error screen, red, stating "Failed to mount /target/proc". 
The message is pretty misleading though, it's hardcoded in the template, 
and it can show up in various situations: when mkdir fails, or when 
mount fails, and for either /proc, /sys or /sys/firmware/efi/efivars...


Cheers,

--
Arnaud Rebillout / OffSec / Kali Linux Developer



Re: Strange MBR CHS partition values created by debian-installer

2023-07-12 Thread Lennart Sorensen
On Sun, Jul 09, 2023 at 12:15:35AM +0300, ValdikSS wrote:
> On 09.07.2023 00:02, Steve McIntyre wrote:
> > Nothing should be caring about C/H/S at all in the 21st century. Using
> > C/H/S only allows you to access 515MB of disk [1]. *Everything* these
> > days uses LBA instead.
> > 
> > What makes you think that the BIOS on this old machine cares about
> > C/H/S?
> 
> My machine is old, it's a 32-bit CPU from 2006 in a machine from 2008.

That's sad.  My 486 from 1993 uses LBA correctly and doesn't care about
CHS at all.  How could a machine from 15 years later when disks much
much bigger than CHS supported possibly care at all?

-- 
Len Sorensen



Processed: reassign

2023-07-12 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reopen 1039084
Bug #1039084 {Done: Bastian Germann } [debianutils] 
discover-config.1: remarks and a patch for the manual
Bug reopened
Ignoring request to alter fixed versions of bug #1039084 to the same values 
previously set
> reassign 1039084 discover
Bug #1039084 [debianutils] discover-config.1: remarks and a patch for the manual
Bug reassigned from package 'debianutils' to 'discover'.
No longer marked as found in versions debianutils/5.7-0.4.
Ignoring request to alter fixed versions of bug #1039084 to the same values 
previously set
> reassign 1039098 discover
Bug #1039098 [debianutils] discover-modprobe.conf.5: some remarks and a patch 
for the manual
Bug reassigned from package 'debianutils' to 'discover'.
No longer marked as found in versions debianutils/5.7-0.4.
Ignoring request to alter fixed versions of bug #1039098 to the same values 
previously set
> reassign 1039113 discover
Bug #1039113 [debianutils] discover-pkginstall.8: some remarks and a patch for 
the manual
Bug reassigned from package 'debianutils' to 'discover'.
No longer marked as found in versions debianutils/5.7-0.4.
Ignoring request to alter fixed versions of bug #1039113 to the same values 
previously set
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1039084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039084
1039098: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039098
1039113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039113
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

2023-07-12 Thread Roland Clobus

Control: affects 1039710 grub-installer

Hello Arnaud,

This looks to be very similar that I reported in the first part of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039710

On BIOS-boots the EFI /sys mount is not present.

With kind regards,
Roland Clobus

On 12/07/2023 16:30, Arnaud Rebillout wrote:
The postinst still fails at this point. The error can be reproduced from 
the console:


   mkdir -p /target/sys/firmware/efi/efivars
   mkdir: can't create directory '/target/sys/firmware/efi': Operation 
not permitted


I suppose the mkdir call must also be allowed to fail when fstype is 
efivarfs (following the same logic that is already used for mount).


Do you want me to submit a patch?

NB: the issue only affects a BIOS VM. If I boot a UEFI VM, everything 
works fine.




OpenPGP_signature
Description: OpenPGP digital signature


Processed: Re: Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

2023-07-12 Thread Debian Bug Tracking System
Processing control commands:

> affects 1039710 grub-installer
Bug #1039710 [busybox-udeb] busybox-udeb: /var/log/syslog is empty
Added indication that 1039710 affects grub-installer

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



Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

2023-07-12 Thread Arnaud Rebillout

Hello,

I'm testing a Kali Linux mini.iso, in a BIOS virtual machine. Kali uses 
the grub-installer package from Debian, no change and it's up-to-date.


The postinst still fails at this point. The error can be reproduced from 
the console:


  mkdir -p /target/sys/firmware/efi/efivars
  mkdir: can't create directory '/target/sys/firmware/efi': Operation 
not permitted


I suppose the mkdir call must also be allowed to fail when fstype is 
efivarfs (following the same logic that is already used for mount).


Do you want me to submit a patch?

NB: the issue only affects a BIOS VM. If I boot a UEFI VM, everything 
works fine.


Thanks

--
Arnaud Rebillout / OffSec / Kali Linux Developer



Re: Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

2023-07-12 Thread Simon McVittie
On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote:
> [ Reason ]
> https://bugs.debian.org/1040790
> [ Changes ]
> All changes are part of resolving or testing #1040790.

Debdiff attached.

> [ Tests ]

I should also have mentioned that I'm running the proposed package on
a bookworm desktop system and it works normally.

smcv
diffstat for dbus-1.14.8 dbus-1.14.8

 changelog|   16 +
 dbus-daemon.postinst |4 +--
 tests/control|9 +++
 tests/machine-id |   60 +++
 4 files changed, 87 insertions(+), 2 deletions(-)

diff -Nru dbus-1.14.8/debian/changelog dbus-1.14.8/debian/changelog
--- dbus-1.14.8/debian/changelog	2023-06-11 12:42:56.0 +0100
+++ dbus-1.14.8/debian/changelog	2023-07-11 20:59:33.0 +0100
@@ -1,3 +1,19 @@
+dbus (1.14.8-2~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm
+
+ -- Simon McVittie   Tue, 11 Jul 2023 20:59:33 +0100
+
+dbus (1.14.8-2) unstable; urgency=high
+
+  * dbus-daemon.postinst: Stop trying to take DPKG_ROOT into account.
+This unintentionally disabled the code path that would copy systemd's
+/etc/machine-id in preference to creating an entirely new machine ID.
+(Closes: #1040790)
+  * d/tests: Add test coverage for #1040790
+
+ -- Simon McVittie   Tue, 11 Jul 2023 18:38:22 +0100
+
 dbus (1.14.8-1~deb12u1) bookworm; urgency=medium
 
   * Rebuild for bookworm
diff -Nru dbus-1.14.8/debian/dbus-daemon.postinst dbus-1.14.8/debian/dbus-daemon.postinst
--- dbus-1.14.8/debian/dbus-daemon.postinst	2023-06-11 12:42:56.0 +0100
+++ dbus-1.14.8/debian/dbus-daemon.postinst	2023-07-11 20:59:33.0 +0100
@@ -7,8 +7,8 @@
 # script does this anyway, but you also have to do this before a session
 # bus will work on non-systemd systems, so we do this here for the
 # benefit of people starting a temporary session bus in a chroot.
-mkdir -p "${DPKG_ROOT:-/}var/lib/dbus"
-dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id"
+mkdir -p /var/lib/dbus
+dbus-uuidgen --ensure
 fi
 
 #DEBHELPER#
diff -Nru dbus-1.14.8/debian/tests/control dbus-1.14.8/debian/tests/control
--- dbus-1.14.8/debian/tests/control	2023-06-11 12:42:56.0 +0100
+++ dbus-1.14.8/debian/tests/control	2023-07-11 20:59:33.0 +0100
@@ -25,6 +25,15 @@
 Restrictions: allow-stderr, superficial
 Depends: dbus-daemon
 
+Tests: machine-id
+Restrictions: allow-stderr, needs-root, superficial
+Depends: dbus-daemon
+
+Test-Command: debian/tests/machine-id with-systemd
+Features: test-name=machine-id_with_systemd
+Restrictions: allow-stderr, needs-root, superficial
+Depends: dbus-daemon, systemd
+
 Tests: dbus-session-bus-common
 Restrictions: allow-stderr, superficial
 Depends: dbus-session-bus-common
diff -Nru dbus-1.14.8/debian/tests/machine-id dbus-1.14.8/debian/tests/machine-id
--- dbus-1.14.8/debian/tests/machine-id	1970-01-01 01:00:00.0 +0100
+++ dbus-1.14.8/debian/tests/machine-id	2023-07-11 20:59:33.0 +0100
@@ -0,0 +1,60 @@
+#!/bin/sh
+set -eu
+
+# Regression test for https://bugs.debian.org/1040790
+
+mode="${1-}"
+
+export LC_ALL=C.UTF-8
+fail=
+set -x
+
+# dbus-daemon.deb provides a machine ID
+ls -l /etc/machine-id /var/lib/dbus/machine-id || :
+head /etc/machine-id /var/lib/dbus/machine-id || :
+uuid="$(dbus-uuidgen --get)"
+test -n "$uuid" || fail=yes
+# The machine ID consists of 32 lower-case hex digits (and the file
+# also has a newline)
+test "$uuid" = "$(perl -pe 'print "wrong: " unless /\A[a-z0-9]{32}\n\z/' /var/lib/dbus/machine-id)" || fail=yes
+
+# Intentionally not asserting that /etc/machine-id matches
+# /var/lib/dbus/machine-id: if the test container has both dbus and
+# systemd, and it was generated with a version of dbus that has #1040790,
+# then that assertion could fail.
+
+# If there is a systemd machine ID, installing dbus-daemon should
+# make the D-Bus machine ID be the same as it.
+# Unfortunately nothing currently guarantees that a Debian
+# system will have a machine ID, so this has to be conditional. (See
+# also #745876, #783716).
+if [ -e /etc/machine-id ] || [ "$mode" = with-systemd ]; then
+rm -f /var/lib/dbus/machine-id
+# This is for its side-effect of running the postinst, emulating
+# a fresh installation
+dpkg-reconfigure -fnoninteractive -pcritical dbus-daemon
+ls -l /etc/machine-id /var/lib/dbus/machine-id || :
+head /etc/machine-id /var/lib/dbus/machine-id || :
+uuid="$(dbus-uuidgen --get)"
+test -n "$uuid" || fail=yes
+test "$uuid" = "$(perl -pe 'print "wrong: " unless /\A[a-z0-9]{32}\n\z/' /var/lib/dbus/machine-id)" || fail=yes
+test "$uuid" = "$(perl -pe 'print "wrong: " unless /\A[a-z0-9]{32}\n\z/' /etc/machine-id)" || fail=yes
+fi
+
+# Similarly, if there is a D-Bus machine ID but no systemd machine ID
+# (for example if dbus-daemon happened to be installed before systemd),
+# then we expect systemd-machine-id-setup to copy ours.

Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

2023-07-12 Thread Simon McVittie
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@packages.debian.org, debian-boot@lists.debian.org
Control: affects -1 + src:dbus

[ Reason ]
https://bugs.debian.org/1040790

[ Impact ]
A regression in bookworm's dbus packaging led to /etc/machine-id and
/var/lib/dbus/machine-id having different contents in fresh installations
of bookworm or later. The machine ID is an opaque hex string analogous
to a MAC address, intended to identify the machine in contexts where the
hostname would traditionally have been used, but avoiding the risk that
a sysadmin setting an aesthetically appealing hostname will result in
non-uniqueness (either the same hostname on more than one concurrently
used installation, or the same installation having more than one hostname
over time).

Some packages that rely on this interface try /etc/machine-id first and
fall back to /var/lib/dbus/machine-id if it doesn't exist, while others
do the opposite, so this bug leads to those packages disagreeing on what
the machine ID is, and therefore potentially behaving as though they
are running on two different machines with a shared (NFS) home directory.
The full user-visible impact of this is unknown: the machine ID is
intentionally quite a general feature, so we cannot know all the things
that might use it.

pulseaudio, ibus, dbus-x11 and maybe others have autostart protocols that
involve it, so non-uniqueness could result in unintentionally running
two instances of the same service on the same machine.

Conversely, GNOME and maybe others store per-machine data in the user's
home directory (in particular, GNOME screen settings) keyed by the
machine ID, so the apparent machine ID changing could result in apparent
configuration data loss.

[ Tests ]
The majority of the changes are new automated test coverage.

I can reproduce the problem with mmdebstrap, and I have confirmed that
replacing packages from src:dbus with the proposed version resolves it.

I have not attempted to provide the updated dbus to a d-i image and do an
install from first principles.

[ Risks ]
Low-risk change, reverting unnecessary complexity in the postinst and
returning to what we did in bullseye.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
All changes are part of resolving or testing #1040790.

[ Other info ]
dbus technically has a udeb, but it's essentially unused, and in any case
dbus-udeb.postinst never had this bug (so it has not changed here).

I have not attempted to retroactively fix the machine ID of existing
installations: that would be much higher-risk and will require
considerably more thought. It's entirely possible that the best approach
to existing installations is to ignore the mismatch and hope that it
doesn't cause any user-visible symptoms.



Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty

2023-07-12 Thread Cyril Brulebois
Hi Michael,

Cyril Brulebois  (2023-06-28):
> Control: reassign -1 busybox-udeb 1:1.36.1-3

[…]

> With a local build, confirmed -3 is buggy, and that reverting only
> busybox-udeb to -1 is sufficient to restore syslog support in the
> installer.
> 
> Reassigning there; the GRUB thing can be filed separately once we have
> actual information via syslog.

A fix would be appreciated, we've got reports piling up about things we
have no logs for.


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


signature.asc
Description: PGP signature


Processed: Re: Bug#1040899: debian-cd: "Failed to mount /target/proc" during GRUB installation

2023-07-12 Thread Debian Bug Tracking System
Processing control commands:

> affects 1039710 debian-cd
Bug #1039710 [busybox-udeb] busybox-udeb: /var/log/syslog is empty
Added indication that 1039710 affects debian-cd

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