OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Daniel Dickinson - 18.12.2019

FS#2685 - Coldplug too soon; hotplug.d scripts not run for some events

OpenWrt 19.07.0-rc2, latest openwrt-packages.

Occurs on at least ath79 but looking at the code this is not device-specific.

1. Have USB devices for which you have hotplug scripts (e.g. from p910d and sane-backends)
2. Boot (or reboot) with usb devices already plugged in.
3. Observe that the actions in the hotplug script (e.g. setting permissions / group ownership that don’t belong in the base system (i.e. hotplug.json)) as it’d be bloat to detect product:vendor ip pairs and take appropriate action for all the various packages and devices hotplug handles – if hotplug.json could have hotplug.json.d or somesuch it would alleviate most of this pain.

Looking at the procd code coldplug (udevtrigger) is called during ‘early’ init, which means that hotplug.d scripts are not yet present. Because /etc/init.d/boot (or any other initscript) no longer does a later call to udevtrigger, the events get missed).

If udevtrigger were called during regular init this wouldn’t be an issue (but probably the coldplug is needed earlier *as well* for devices needed to boot the system.

See also #1903 and #996 (they are likely the same root cause).

Daniel Dickinson commented on 18.12.2019 15:17

Also running udevtrigger manually causes the hotplug scripts to run correctly.

ogura.org.ua commented on 21.12.2019 00:16

What sort of only "some" devices it are?
I mean which are triggering and which do not?
May it be the same with my FS#2641 ?
By the way, my modem did not appear as /dev/ttyUSB* devices neither nor as hot plugged nor during during booting.

Daniel Dickinson commented on 21.12.2019 07:24

It's a race condition so it depends on when the system 'decides' to enumerate the device. If the device is detected by the kernel too quickly, then it only gets early init coldplug event and not the full hotplug.json with a root fs.

So it's not a specific type of type device, although USB is probably what most OpenWrt users will notice this with (because it's where most non-platform devices would be added to the system).

Yes it almost certainly is the same as https://bugs.openwrt.org/index.php?do=details&task_id=2641.

Not showing up in /dev is a symptom of the issue; check dmesg output and see if shows up there (i.e. if there kernel detected early in the boot).

Daniel Dickinson commented on 21.12.2019 07:25

In the past udevtrigger was run during the /etc/init.d/boot script but IIRC that also caused (different) issues with duplicate hotplug events.

Luiz Angelo Daros de Luca commented on 23.01.2020 22:29

Related/Duplicated FS#1903, FS#996

Luiz Angelo Daros de Luca commented on 03.02.2020 05:37

At least for sane-backends, the hotplug was running as expected. However, it was running before logger could send logs. So, all outputs got lost. I changed that output to /dev/kmsg to be able to read hotplug msgs. It would be nice if OpenWrt could keep logs from early stage.

The only issue with sane-backends hotplug script was that it ran before usblp module was loaded. So, it could not grant the needed access.

I just pushed a fix for that (while updating sane-backends too). Now it grants the same access when a device using usblp is plugged.

https://github.com/openwrt/packages/commit/0a85579e45477d4b824e49cadc243fe4f81959aa

After that, at least for p910nd and sane-backends, I could not reproduce any hotplug issue during boot.

Daniel Dickinson, could you test if the new hotplug script fixes your issue (it can be used with an older sane version)?

Daniel Dickinson commented on 25.02.2020 03:41

Ah! Thanks for looking into this, I was barking up the wrong tree. I will do a test later this week.

Daniel Dickinson commented on 07.03.2020 02:28

I can confirm this solves the problem I was having. I guess this will have to be de-duplicated from the other issues. This may be similar to the other issues in root cause, but it may taking examining each individually. Probably the most import hint is to know that logging doesn't include some early events.

Thanks again!

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing