Bug#872598: udev-udeb: no input in graphical installer

[Cyril Brulebois]

Control: tag -1 patch

Hi,

(Again, please keep debian-boot@ in copy.)

Raphael Hertzog <hertzog at debian.org> (2017-08-19):
> > I've only quickly glanced at the contents of both packages, and
> > debdiff mentions no obvious issues (file lists are the same).
> 
> I believe this is precisely the problem. The new udev-udeb should
> include a new file:
> diff --git a/debian/udev-udeb.install b/debian/udev-udeb.install
> index 6a8e2108f..6758fef06 100644
> --- a/debian/udev-udeb.install
> +++ b/debian/udev-udeb.install
> @@ -5,6 +5,7 @@ lib/udev/ata_id
>  lib/udev/scsi_id
>  lib/udev/cdrom_id
>  lib/udev/rules.d/50-udev-default.rules
> +lib/udev/rules.d/60-input-id.rules
>  lib/udev/rules.d/60-cdrom_id.rules
>  lib/udev/rules.d/60-persistent-input.rules
>  lib/udev/rules.d/60-persistent-storage.rules
> 
> I won't have the time to test this now but I believe it's the problem.

That's absolutely correct. I've started by copying the file manually into
the netboot-gtk mini.iso, and confirmed the fix. To be extra sure, I've
rebuilt a systemd package with your change, and used the new udev udebs
for a clean build, and that works as well.

A timely fix would be appreciated, the breakage(s) in the graphical
installer prevented us from releasing debian-installer over the past few
weeks, and it would be great not to wait too long before we're able to do
so, esp. with linux 4.12.6-1 having reached testing lately.

Thinking about this, I'll check with debian-release@ and I might just
freeze all udeb-producing packages right away. Winter has come.


> It would be nice to have a fixed udev soon. Thank you Cyril for the
> investigation!
> 
> I wonder if it would be possible to have autopkgtest tests covering
> udev-udeb...

I'm still new to the whole autopkgtest thing, but from where I stand, the
fact d-i is broken has been known for quite a while; the core issue is
that nobody investigated this before I found some time. An easy way to be
more proactive on the systemd side would be to make sure that new (and/or
deleted) files in the udev and libudev1 binaries are detected by
maintainers (esp. since udev.install uses wildcards for rules files, while
udev-udeb.rules uses a static list), so that the update can be propagated
to the udebs if relevant.

I'm fine with setting up a check through a cron job on d-i.debian.org so
as to avoid putting the burden on systemd maintainers. The feedback loop
might take a few hours/days after an upload with such a change, but that
would make it obvious that something “important” changed, and would speed
up understanding such regressions.


KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170819/65f7299d/attachment-0002.sig>