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

[Thomas Meyer]

Am Dienstag, den 30.09.2014, 21:44 +0200 schrieb 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”

I think the tag is okay:

# udevadm info -q all -p /devices/platform/uml-blkdev.1/block/ubdb/ubdb3
P: /devices/platform/uml-blkdev.1/block/ubdb/ubdb3
N: ubdb3
S: disk/by-label/ANACONDA
S: disk/by-path/platform-uml-blkdev.1-part3
S: disk/by-uuid/d3f89867-087c-3f26-a261-477750d18179
E: DEVLINKS=/dev/disk/by-label/ANACONDA /dev/disk/by-path/platform-uml-blkdev.1-part3 /dev/disk/by-uuid/d3f89867-087c-3f26-a261-477750d18179
E: DEVNAME=/dev/ubdb3
E: DEVPATH=/devices/platform/uml-blkdev.1/block/ubdb/ubdb3
E: DEVTYPE=partition
E: ID_FS_APPLICATION_ID=GENISOIMAGE\x20ISO\x209660\x2fHFS\x20FILESYSTEM\x20CREATOR\x20\x28C\x29\x201993\x20E.YOUNGDALE\x20\x28C\x29\x201997-2006\x20J.PEARSON\x2fJ.SCHILLING\x20\x28C\x29\x202006-2007\x20CDRKIT\x20TEAM
E: ID_FS_BOOT_SYSTEM_ID=EL\x20TORITO\x20SPECIFICATION
E: ID_FS_LABEL=ANACONDA
E: ID_FS_LABEL_ENC=ANACONDA
E: ID_FS_SYSTEM_ID=LINUX
E: ID_FS_TYPE=hfsplus
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=d3f89867-087c-3f26-a261-477750d18179
E: ID_FS_UUID_ENC=d3f89867-087c-3f26-a261-477750d18179
E: ID_FS_VERSION=Joliet Extension
E: ID_PART_ENTRY_DISK=98:16
E: ID_PART_ENTRY_NUMBER=3
E: ID_PART_ENTRY_OFFSET=193456
E: ID_PART_ENTRY_SCHEME=dos
E: ID_PART_ENTRY_SIZE=50656
E: ID_PART_ENTRY_TYPE=0x0
E: ID_PART_ENTRY_UUID=314777b5-03
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=314777b5
E: ID_PATH=platform-uml-blkdev.1
E: ID_PATH_TAG=platform-uml-blkdev_1
E: MAJOR=98
E: MINOR=19
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=29249846

Maybe systemd/udev get's confused by the point in this name?!
uml-blkdev.1

> – 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.
>