From: Thomas Meyer <thomas@m3y3r.de>
To: Richard Weinberger <richard.weinberger@gmail.com>,
"systemd-devel@lists.freedesktop.org"
<systemd-devel@lists.freedesktop.org>,
"user-mode-linux-devel@lists.sourceforge.net"
<user-mode-linux-devel@lists.sourceforge.net>
Subject: Re: [uml-devel] [systemd-devel] Timed out waiting for device dev-disk-by...
Date: Tue, 30 Sep 2014 20:27:36 +0200 [thread overview]
Message-ID: <1412101656.2769.17.camel@localhost.localdomain> (raw)
In-Reply-To: <CAFLxGvxD=+VxJeGkKS_Ukq5m3KvV5femmhVWYdm1XFYGHauBqw@mail.gmail.com>
Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger:
> On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer <thomas@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.
> >
> > But all devices are available from early kernel start:
> > # ls -l /dev/disk/by-uuid/
> > total 0
> > lrwxrwxrwx 1 root root 11 Sep 29 20:17 008af19d-2562-49bd-8907-721ea08f3e14 -> ../../ubda1
> > lrwxrwxrwx 1 root root 11 Sep 29 20:17 e2bffa45-d84f-47bc-81ba-e7a395751fa6 -> ../../ubda3
> > lrwxrwxrwx 1 root root 11 Sep 29 20:17 f452f020-a446-41ed-93c0-ee5ce56d6ea4 -> ../../ubda2
> >
> > It feels like some event notification is lost in the boot process or something like this?!
> >
> > 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.
> >
> > Any ideas what could be wrong here?
>
> Please always CC me and/or the UML mailinglist in case of UML related issues.
> I'm very interested in having UML work with systemd.
>
Okay Richard, will do so in future.
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@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'
So here the udev coldplug triggers the kernel kobject_uevent for 'ubdb3'.
I don't understand why the systemd unit doesn't change to PLUGGED here! It should?! Or shouldn't it?
systemd dump:
Sep 30 18:13:44 servername systemd[1]: -> Unit dev-ubdb3.device:
Sep 30 18:13:44 servername systemd[1]: Description: dev-ubdb3.device
Sep 30 18:13:44 servername systemd[1]: Instance: n/a
Sep 30 18:13:44 servername systemd[1]: Unit Load State: loaded
Sep 30 18:13:44 servername systemd[1]: Unit Active State: inactive
Sep 30 18:13:44 servername systemd[1]: Inactive Exit Timestamp: n/a
Sep 30 18:13:44 servername systemd[1]: Active Enter Timestamp: n/a
Sep 30 18:13:44 servername systemd[1]: Active Exit Timestamp: n/a
Sep 30 18:13:44 servername systemd[1]: Inactive Enter Timestamp: n/a
Sep 30 18:13:44 servername systemd[1]: Need Daemon Reload: no
Sep 30 18:13:44 servername systemd[1]: Transient: no
Sep 30 18:13:44 servername systemd[1]: Slice: n/a
Sep 30 18:13:44 servername systemd[1]: CGroup: n/a
Sep 30 18:13:44 servername systemd[1]: CGroup realized: no
Sep 30 18:13:44 servername systemd[1]: CGroup mask: 0x0
Sep 30 18:13:44 servername systemd[1]: CGroup members mask: 0x0
Sep 30 18:13:44 servername systemd[1]: Name: dev-ubdb3.device
Sep 30 18:13:44 servername systemd[1]: DropIn Path: /run/systemd/generator/dev-ubdb3.device.d/timeout.conf
Sep 30 18:13:44 servername systemd[1]: Condition Timestamp: Tue 2014-09-30 18:07:48 UTC
Sep 30 18:13:44 servername systemd[1]: Condition Result: yes
Sep 30 18:13:44 servername systemd[1]: Wants: sysroot.mount
Sep 30 18:13:44 servername systemd[1]: WantedBy: initrd.target
Sep 30 18:13:44 servername systemd[1]: BoundBy: sysroot.mount
Sep 30 18:13:44 servername systemd[1]: BoundBy: systemd-fsck@dev-ubdb3.service
Sep 30 18:13:44 servername systemd[1]: Before: sysroot.mount
Sep 30 18:13:44 servername systemd[1]: Before: systemd-fsck@dev-ubdb3.service
Sep 30 18:13:44 servername systemd[1]: Before: initrd.target
Sep 30 18:13:44 servername systemd[1]: ReferencedBy: initrd.target
Sep 30 18:13:44 servername systemd[1]: ReferencedBy: sysroot.mount
Sep 30 18:13:44 servername systemd[1]: ReferencedBy: systemd-fsck@dev-ubdb3.service
Sep 30 18:13:44 servername systemd[1]: StopWhenUnneeded: no
Sep 30 18:13:44 servername systemd[1]: RefuseManualStart: no
Sep 30 18:13:44 servername systemd[1]: RefuseManualStop: no
Sep 30 18:13:44 servername systemd[1]: DefaultDependencies: yes
Sep 30 18:13:44 servername systemd[1]: OnFailureJobMode: replace
Sep 30 18:13:44 servername systemd[1]: IgnoreOnIsolate: yes
Sep 30 18:13:44 servername systemd[1]: IgnoreOnSnapshot: yes
Sep 30 18:13:44 servername systemd[1]: Device State: dead
Sep 30 18:13:44 servername systemd[1]: Sysfs Path: n/a
Sep 30 18:13:44 servername systemd[1]: -> Job 34:
Sep 30 18:13:44 servername systemd[1]: Action: dev-ubdb3.device -> start
Sep 30 18:13:44 servername systemd[1]: State: running
Sep 30 18:13:44 servername systemd[1]: Forced: no
Sep 30 18:13:44 servername systemd[1]: Irreversible: no
As far as I understand the code the device unit transits to PLUGGED when
a sysfs path is available, but this seems not to be the case here:
Sysfs Path: n/a
kobj ubdb3 (different boot, therefor changed addresses):
p *(struct kobject*) 0x0000000091e15638
$3 = {name = 0x91e13160 "ubdb3",
entry = {next = 0x91e15440, prev = 0x91e15840},
parent = 0x91e17c80,
kset = 0x91c063c0,
ktype = 0x605e81a0 <device_ktype>,
sd = 0x91e1b118,
kref = {refcount = {counter = 4}},
state_initialized = 1,
state_in_sysfs = 1,
state_add_uevent_sent = 1,
state_remove_uevent_sent = 0,
uevent_suppress = 0}
help is appreciated.
with kind regards
thomas
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2014-09-30 18:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1412015343.9609.13.camel@localhost.localdomain>
2014-09-29 20:20 ` [uml-devel] [systemd-devel] Timed out waiting for device dev-disk-by Richard Weinberger
2014-09-30 18:27 ` Thomas Meyer [this message]
2014-09-30 18:47 ` Alexander E. Patrakov
2014-10-04 5:00 ` Andrei Borzenkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1412101656.2769.17.camel@localhost.localdomain \
--to=thomas@m3y3r.de \
--cc=richard.weinberger@gmail.com \
--cc=systemd-devel@lists.freedesktop.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.