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

[Felipe Sateler]

On Sat, Aug 19, 2017 at 9:38 AM, Cyril Brulebois <kibi at debian.org> wrote:
> 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.

--fail-missing is broken on the udeb builds at the moment, so it is
not enabled. I'll try to fix this and enable it. This should help
catch these sort of issues in the future.

-- 

Saludos,
Felipe Sateler