[systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...

[Tomasz Torcz]

On Tue, Sep 30, 2014 at 08:27:36PM +0200, Thomas Meyer wrote:
> Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger:
> > On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer <thomas at m3y3r.de> wrote:
> > > Hi,
> > >
> > > I get a timeout in the Fedora 21 alpha:
> > >
> > > [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device.
> > >
> > > What exactly makes the device unit go into the state active/plugged?
> > >
> > > This is a boot of the Fedora 21 alpha under user mode linux.
> Some more info about the above systemd wait (with
> systemd.log_level=debug and DEBUG_KOBJECT)
> 
> Systemd starts and installs a job for each device tagged with "systemd":
> Sep 30 18:07:58 localhost systemd[1]: Installed new job dev-ubdb3.device/start as 34
> Sep 30 18:07:58 localhost systemd[1]: Installed new job systemd-fsck at dev-ubdb3.service/start as 35
> 
> Sep 30 18:07:58 localhost systemd[1]: Enqueued job initrd.target/start as 1
> Sep 30 18:07:58 localhost systemd[1]: Loaded units and determined initial transaction in 837.189ms.
> Sep 30 18:07:58 localhost systemd[1]: Received SIGCHLD from PID 32 (n/a).
> 
> Device unit is waiting:
> Sep 30 18:07:58 localhost systemd[1]: Expecting device dev-ubdb3.device...
> 
> udev coldplug:
> Sep 30 18:08:02 localhost systemd[360]: Executing: /bin/dracut-pre-trigger
> Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.dm=0: removing DM RAID activation
> Sep 30 18:08:02 localhost systemd-udevd[358]: starting version 215
> Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.md.imsm=0: no MD RAID for imsm/isw raids
> Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md.ddf=0: no MD RAID for SNIA ddf raids
> Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md=0: removing MD RAID activation
> Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (00000000930ef220): kobject_uevent_env
> Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (00000000930ef220): fill_kobj_path: path = '/devices/platform/alarmtimer'
> Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (00000000605a1700): kobject_uevent_env
> Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (00000000605a1700): fill_kobj_path: path = '/devices/platform/uml-blkdev.1'
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (000000008c030480): kobject_uevent_env
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (000000008c030480): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb'
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (0000000093205838): kobject_uevent_env
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (0000000093205838): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb1'
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (0000000093205638): kobject_uevent_env
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (0000000093205638): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb2'
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (0000000093205438): kobject_uevent_env
> Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (0000000093205438): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb3'

  Check the udev database at this moment.  In my understanding, to have device deemed
ready by systemd, two things must happen for device entry:
– TAGS variable must contain ”systemd”
– SYSTEMD_READY must be ”1”

  I don't have UML installation handy to check, but maybe there is missing
rule?  Rule which is supposed to flip SYSTEMD_READY to ”1”?
  Some default devices are tagged in 99-systemd.rules; if UML-specific devs
are missing, please send a patch.

-- 
Tomasz Torcz                "Funeral in the morning, IDE hacking
xmpp: zdzichubg at chrome.pl    in the afternoon and evening." - Alan Cox