On Di, 12.04.22 14:38, Elbek Mamajonov (emm.boxin...@gmail.com) wrote: > On graph I have mmcblk.device taking 1.624s. From the point that > this partition is where my rootfs lies, and systems does remounting > of rootfs, I did look up for systemd-remount-fs.service, it took > 231ms, and systemd-udev-trigger.service, as you suggested, it took > 517ms to become active. But even after systemd-udev-trigger.service > becomes active there is about 800ms for mmcblk.device to become > active. Are those services related to the activation of the > mmcblk.device? Can I consider those 231ms and 517ms as a part of the > activation time of the mmcblk.device? How can I debug udev in this > case?
"systemd-udev-trigger.service" might take a while before it completes, since it triggers basically all devices in the system. It might be worth triggering block devices first. With upcoming v251 we actually will do that by default. But until then you could extend the service by first issuing "udevadm trigger -sblock", before the rest. udev will announce devices to the system (and thus also PID1) once it probed the device. it does this based on rules, and the default rules will run blkid on the device, to see what's on it (i.e. to extract fs label/uuid, …). maybe that's just terribly slow on your device? Lennart -- Lennart Poettering, Berlin