[oe] invalidating udev cache, how?
k.kooi at student.utwente.nl
Thu Dec 4 18:35:10 CET 2008
On 04-12-08 17:15, Tom Rini wrote:
> On Thu, Dec 04, 2008 at 05:05:58PM +0100, Koen Kooi wrote:
>> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev
>> dance that can take a few seconds to a minute depending on machine speed
>> and kernel options. It is working a bit too well at the moment:
>> * user boots image with 2.6.26 kernel on an omap board
>> * user gets /dev/fb0
>> * user fixes the bootargs in uboot to enable the overlay
>> * user doesn't get /dev/fb1
>> so remove /etc/dev.tar and reboot: /dev/fb1 appears.
>> I also encountered a case where the permissions on /dev/null where wrong
>> during first boot (it's a mystery why that happened) and udev cached
>> those making ssh daemons fail on boot.
>> My current ideas:
>> 1) remove /etc/dev.tar if its> x weeks old
>> 2) recreate it on shutdown
>> 3) remove it after x times
>> option 1) breaks on systems without an RTC and/or no /etc/timestamp
>> option 2) moves the slowness to shutdown
>> option 3) requires extra logic and filesystem access
>> and all options don't fix the first case I mentioned, they all take a
>> while to make /dev/fb1 appear.
>> The key is that it should be transparent to users, so adding a check for
>> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies
>> that users are aware of the problem and know how to 'fix' it.
>> Does anyone have other ways to invalidate the cache, and if not, which
>> option would get your vote?
> 2 is a different (and perhaps not as) slow. Also, prepopulate the cache
> with fb1? Or is this all done on the live system with nothing done
> during image creation?
It's done during first boot, since as the problem points out everything
is highly dependant on bootloader/kernel/moonphase.
More information about the Openembedded-devel