* Re: [uml-devel] [systemd-devel] Timed out waiting for device dev-disk-by... [not found] <1412015343.9609.13.camel@localhost.localdomain> @ 2014-09-29 20:20 ` Richard Weinberger 2014-09-30 18:27 ` Thomas Meyer 0 siblings, 1 reply; 4+ messages in thread From: Richard Weinberger @ 2014-09-29 20:20 UTC (permalink / raw) To: Thomas Meyer Cc: systemd-devel@lists.freedesktop.org, user-mode-linux-devel@lists.sourceforge.net 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. -- Thanks, //richard ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [uml-devel] [systemd-devel] Timed out waiting for device dev-disk-by... 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 2014-09-30 18:47 ` Alexander E. Patrakov 0 siblings, 1 reply; 4+ messages in thread From: Thomas Meyer @ 2014-09-30 18:27 UTC (permalink / raw) To: Richard Weinberger, systemd-devel@lists.freedesktop.org, user-mode-linux-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [uml-devel] [systemd-devel] Timed out waiting for device dev-disk-by... 2014-09-30 18:27 ` Thomas Meyer @ 2014-09-30 18:47 ` Alexander E. Patrakov 2014-10-04 5:00 ` Andrei Borzenkov 0 siblings, 1 reply; 4+ messages in thread From: Alexander E. Patrakov @ 2014-09-30 18:47 UTC (permalink / raw) To: Thomas Meyer, Richard Weinberger, systemd-devel@lists.freedesktop.org, user-mode-linux-devel@lists.sourceforge.net 01.10.2014 00:27, 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@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? Imho the problem is not specific to UML. Something similar has been triggered on my desktop PC, and nobody replied: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22490.html If this triggers again, I will provide dumps. -- Alexander E. Patrakov ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [uml-devel] [systemd-devel] Timed out waiting for device dev-disk-by... 2014-09-30 18:47 ` Alexander E. Patrakov @ 2014-10-04 5:00 ` Andrei Borzenkov 0 siblings, 0 replies; 4+ messages in thread From: Andrei Borzenkov @ 2014-10-04 5:00 UTC (permalink / raw) To: Alexander E. Patrakov Cc: systemd-devel@lists.freedesktop.org, user-mode-linux-devel@lists.sourceforge.net, Thomas Meyer В Wed, 01 Oct 2014 00:47:08 +0600 "Alexander E. Patrakov" <patrakov@gmail.com> пишет: > 01.10.2014 00:27, 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@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. ... > > Imho the problem is not specific to UML. Something similar has been > triggered on my desktop PC, and nobody replied: > > https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22490.html > > If this triggers again, I will provide dumps. > Well, your problem seems to be entirely different. Here device links are created but systemd does not get notification about them. In your case device links are missing which usually means something wrong with udev rules. ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-04 5:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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
2014-09-30 18:47 ` Alexander E. Patrakov
2014-10-04 5:00 ` Andrei Borzenkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox