Debugging udev cache issues

[Jonathan Austin <jonathan.austin@arm.com>]

Hi all,

I've built a small poky/Yocto 1.5 system for an imx6 board, using
core-image-minimal. I want to use the gadget driver, and have an init
script of my own to set that up.

However, this only works when the udev cache is not involved at boot time.

On the first boot of my new system, udev runs and loads the modules for my
USB hardware. (among other things):

---
Starting udev
udevd[69]: starting version 182
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
[...]
Starting Bootlog daemon: bootlogd: cannot allocate pseudo tty: No such file or directory bootlogd.
Populating dev cache
---

Good!

However, on subsequent boots, the udev cache kicks in and the appropriate
modules are no longer loaded.
---
Starting udev
udevd[71]: starting version 182
Starting Bootlog daemon: bootlogd: cannot allocate pseudo tty: No such file or directory bootlogd.
[...]
---

This means the init script that loads the gadget module for me fails.

I added some debug (set -x) to the udev init script, and I can see that
it is finding/unpacking the cache, and then running udevadm, as expected:

---
+ cd /
+ tar xf /etc/dev.tar
+ not_first_boot=1
+ [ no != no ]
+ [ -e /dev/shm/udev.cache ]
+ rm -f /dev/shm/udev.cache
+ kill_udevd
+ echo -e \000\000\000\000
+ /lib/udev/udevd -d
+ udevadm control --env=STARTUP=1
+ [ 1 !=  ]
+ udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform
+ exit 0
+ udevadm settle --timeout=3
---

But at that stage, no drivers are loaded.

Curiously, if I manually run the udevadm trigger command (as above) after I've
logged in, the usb drivers come up...

$udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux--subsystem-nomatch=platform
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
[...]

From there I can restart my service that controls the gadget driver and it
works...

This behaviour seems insensitive to the STARTUP env variable - I can
set it either way when I manually run udevadm and it still 'works' (ie causes
the USB hardware to be initialized)

So, I guess my initial question is: Why does running:

udevadm trigger --action=add --subsystem-noma[..etc...]

inside of the udev init script not work as expected, and how can I debug this
further? Does this work for other people with core-image-minimal? Perhaps I've
missed something obvious about how to compose the system?

I am aware I can disable the udev cache, but I'd rather sort out what's
going wrong rather than turn it off because it isn't working!

Thanks in advance for any pointers,

Jonny