ID_MM_DEVICE_MANUAL_SCAN_ONLY not applied properly?

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On 18/05/18 18:20, Bjørn Mork wrote:
>> Bjørn Mork <bjorn at mork.no> writes:
>>> Aleksander Morgado <aleksander at aleksander.es> writes:
>>>
>>>>>> The ID_MM_DEVICE_MANUAL_SCAN_ONLY is applied on the usb_device matched
>>>>>> by vid:pid from the list of rules we have.
>>>>>>
>>>>>> This first run is after booting the machine: I don't see the tag applied.
>>>>>
>>>>> Maybe you forgot to update your initramfs after adding the new rule?
>>>>>
>>>>
>>>> Hum... why would that be needed? udev rules are applied on boot as
>>>> soon as the USB devices gets exposed by the system. Or am I missing
>>>> something?
>>>
>>> This tends to happen before the real root system is mounted.  And there
>>> is no later rediscovery of already discovered USB devices.  At least
>>> that's how I thought this worked.  Could be wrong, as usual...
>>>
>>> Looking at my initramfs I guess I must be.  I note that *some* udev
>>> rules are copied there.  But most of them are not, and in particular the
>>> default MM rules.  Weird.  Have to look further at this.
>> 
>> The responsible for that is this hook, which has a short hardcoded list
>> of rules to copy:
>> https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/initramfs-tools/hooks/udev
>> 
>> I wonder why?  I would have thought that you either needed all or none?
>> 
>
> Does this theory explain the fact that ID_MM_CANDIDATE on the *tty*
> device is applied during boot as expected, but
> ID_MM_DEVICE_MANUAL_SCAN_ONLY on the *usb* device isn't applied?

I believe it might if the tty driver is loaded after switching to the
real root.

> Can any of you try to reproduce this issue? (e.g. make && make install
> from git master, then reboot, then start ModemManager without any
> filter applied).

I've been meaning to test this one of these days.  But scheduling a
reboot of my laptop is much more difficult than rebooting a core router
or 30 DNS servers.  And I haven't ever figured out how to do any
meaningful modem testing in a virtual machine.

So, sorry.  I don't know when I'll get around to trying to reproduce the
issue.



Bjørn