On Do, 14.04.22 13:10, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> Apr 01 08:46:25 h16 kernel: sd 0:2:0:0: [sda] 467664896 512-byte logical
> blocks: (239 GB/223 GiB)
> ...
> Apr 01 08:46:33 h16 kernel: sd 3:0:7:2: [sdda] 524288 512-byte logical blocks:
> (268 MB/256 MiB)
> ...
>
>>> Lennart Poettering schrieb am 14.04.2022 um 09:45
in
Nachricht :
> On Do, 14.04.22 08:00, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
>
>> >>> Lennart Poettering schrieb am 13.04.2022 um
17:38
>> in
>> Nachricht :
>> > On Di, 12.04.22 14:38, Elbek Mamajonov
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
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
On Mon, Apr 11, 2022 at 5:16 PM Elbek Mamajonov
wrote:
> How to track down the lifespan of the device unit file, i.e. the
> activating state? I have an embedded system where systemd-analyze plot
> shows that the unit file I am interested in, let’s say
> dev-mmcpartition.device, takes about 2
How to track down the lifespan of the device unit file, i.e. the activating
state? I have an embedded system where systemd-analyze plot shows that the unit
file I am interested in, let’s say dev-mmcpartition.device, takes about 2
seconds to be become active. This partition (mmcpartition) holds
