[Bug 874463] New: Device 0 (vif) could not be connected. Hotplug scripts not working.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c0 Summary: Device 0 (vif) could not be connected. Hotplug scripts not working. Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Critical Priority: P5 - None Component: Xen AssignedTo: jdouglas@suse.com ReportedBy: t.wagner@inode.at QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/7.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E) After upgrade from 12.3 to 13.1 xen with xend and bridge-mode does not work any more. I know that xm is deprecated by xen project. But migration from xm to xl/libvirt is not so simple at the moment. ===================================================== zeus:/ # rpm -q -a |grep xen xen-xend-tools-4.3.2_01-12.1.x86_64 xen-libs-4.3.2_01-12.1.x86_64 libvirt-daemon-xen-1.1.2-2.18.3.x86_64 xen-4.3.2_01-12.1.x86_64 libvirt-daemon-driver-xen-1.1.2-2.18.3.x86_64 xen-tools-4.3.2_01-12.1.x86_64 <domain type='xen'> <name>template</name> <uuid>7fdf20a8-08b1-8d01-09e9-cfe8ca12de7d</uuid> <description>template for all Linux VMs</description> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>2</vcpu> <bootloader>/usr/bin/pygrub</bootloader> <bootloader_args>-q</bootloader_args> <os> <type>linux</type> <cmdline>brokenmodules=edd</cmdline> </os> <clock offset='utc' adjustment='reset'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <disk type='file' device='disk'> <driver name='file'/> <source file='/srv/domains/template.0'/> <target dev='xvda' bus='xen'/> </disk> <interface type='bridge'> <mac address='00:16:3e:51:a3:b8'/> <source bridge='br1'/> <script path='/etc/xen/scripts/vif-bridge'/> </interface> <console type='pty'> <target type='xen' port='0'/> </console> <input type='mouse' bus='xen'/> <graphics type='vnc' port='-1' autoport='yes' keymap='de'/> </devices> </domain> zeus:~ # brctl show bridge name bridge id STP enabled interfaces br0 8000.0025b3e0f418 no eth0 br1 8000.0025b3e0f41a no eth1 br2 8000.0025b3e0f41c no eth2 "qemu-dm-template.log" domid: 2 Warning: vlan 0 is not connected to host network char device redirected to /dev/pts/0 xs_read(): target get error. /local/domain/2/target. xs_read(): vncpasswd get error. /vm/7fdf20a8-08b1-8d01-09e9-cfe8ca12de7d/vncpasswd. char device redirected to /dev/pts/2 xen-hotplug.log xenstore-read: couldn't read path backend/vbd/2/51712/node xm start -c template (on a second shell because vm is in state 'p') - xm unpause 2 zeus:/var/log/xen # xm start -c template [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.10.24-4-xen (root@artemis) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP Sun Dec 15 12:22:45 CET 2013 [ 0.000000] Command line: root=/dev/xvda2 resume=/dev/xvda1 splash=silent showopts brokenmodules=edd [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable [ 0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x00000000207fffff] usable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI not present or invalid. [ 0.000000] No AGP bridge found [ 0.000000] e820: last_pfn = 0x20800 max_arch_pfn = 0x400000000 [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] [ 0.000000] init_memory_mapping: [mem 0x1fe00000-0x1fffffff] [ 0.000000] init_memory_mapping: [mem 0x1c000000-0x1fdfffff] [ 0.000000] init_memory_mapping: [mem 0x00100000-0x1bffffff] [ 0.000000] init_memory_mapping: [mem 0x20000000-0x207fffff] [ 0.000000] RAMDISK: [mem 0x019d4000-0x034b4fff] [ 0.000000] NUMA turned off [ 0.000000] Faking a node at [mem 0x0000000000000000-0x00000000207fffff] [ 0.000000] Initmem setup node 0 [mem 0x00000000-0x207fffff] [ 0.000000] NODE_DATA [mem 0x1ff1a000-0x1ff1dfff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x0009ffff] [ 0.000000] node 0: [mem 0x00100000-0x207fffff] [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs [ 0.000000] No local APIC present [ 0.000000] APIC: disable apic facility [ 0.000000] APIC: switched to apic NOOP [ 0.000000] e820: [mem 0x20800000-0xffffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.3.2_01-12.1 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 26 pages/cpu @ffff88001fc00000 s76736 r8192 d21568 u1048576 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 131182 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: root=/dev/xvda2 resume=/dev/xvda1 splash=silent showopts brokenmodules=edd [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Memory: 479080k/532480k available (3096k kernel code, 388k absent, 53012k reserved, 1305k data, 800k init) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2. [ 0.000000] NR_IRQS:4352 nr_irqs:288 16 [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] console [hvc0] enabled [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] tsc: Detected 2800.160 MHz processor [ 0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5600.32 BogoMIPS (lpj=11200640) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.004000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.004000] Mount-cache hash table entries: 256 [ 0.004000] Initializing cgroup subsys devices [ 0.004000] Initializing cgroup subsys freezer [ 0.004000] Initializing cgroup subsys blkio [ 0.004000] CPU: Physical Processor ID: 0 [ 0.004000] CPU: Processor Core ID: 0 [ 0.004000] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7 [ 0.004000] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32 [ 0.004000] tlb_flushall_shift: 6 [ 0.010163] cpu 0 spinlock event irq 17 [ 0.010185] Performance Events: unsupported p6 CPU model 26 no PMU driver, software events only. [ 0.010332] installing Xen timer for CPU 1 [ 0.010341] cpu 1 spinlock event irq 24 [ 0.010908] SMP alternatives: switching to SMP code [ 0.019175] Brought up 2 CPUs [ 0.019495] devtmpfs: initialized [ 0.019807] Grant tables using version 2 layout. [ 0.019807] Grant table initialized [ 0.019807] NET: Registered protocol family 16 [ 0.020561] PCI: setting up Xen PCI frontend stub [ 0.021311] bio: create slab <bio-0> at 0 [ 0.021599] xen/balloon: Initialising balloon driver. [ 0.023000] xen-balloon: Initialising balloon driver. [ 0.023199] vgaarb: loaded [ 0.023199] SCSI subsystem initialized [ 0.023199] PCI: System does not support PCI [ 0.023199] PCI: System does not support PCI [ 0.023199] Switching to clocksource xen [ 0.024000] NET: Registered protocol family 2 [ 0.024000] TCP established hash table entries: 8192 (order: 5, 131072 bytes) [ 0.024000] TCP bind hash table entries: 8192 (order: 5, 131072 bytes) [ 0.024000] TCP: Hash tables configured (established 8192 bind 8192) [ 0.024000] TCP: reno registered [ 0.024000] UDP hash table entries: 256 (order: 1, 8192 bytes) [ 0.024000] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) [ 0.024000] NET: Registered protocol family 1 [ 0.024000] Unpacking initramfs... [ 0.037852] Freeing initrd memory: 27524k freed [ 0.043538] platform rtc_cmos: registered platform RTC device (no PNP device found) [ 0.043721] audit: initializing netlink socket (disabled) [ 0.043736] type=2000 audit(1397664913.095:1): initialized [ 0.043907] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 0.044193] msgmni has been set to 989 [ 0.044396] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) [ 0.044402] io scheduler noop registered [ 0.044435] io scheduler cfq registered (default) [ 0.048759] Console: switching to colour frame buffer device 100x37 [ 0.049512] console [tty0] enabled [ 0.049747] Event-channel device installed. [ 0.050109] Non-volatile memory driver v1.3 [ 1.051091] i8042: No controller found [ 1.051199] mousedev: PS/2 mouse device common for all mice [ 1.051976] input: Xen Virtual Keyboard as /devices/virtual/input/input0 [ 1.052017] input: Xen Virtual Pointer as /devices/virtual/input/input1 [ 1.053676] TCP: cubic registered [ 1.053810] registered taskstats version 1 [ 1.152138] XENBUS: Device with no driver: device/vbd/51712 [ 1.152178] XENBUS: Device with no driver: device/vif/0 [ 1.152672] Freeing unused kernel memory: 800k freed [ 6.328185] XENBUS: Waiting for devices to initialise: 25s...20s...15s...10s... zeus:/var/log/xen # Error: Device 0 (vif) could not be connected. Hotplug scripts not working. Reproducible: Always Steps to Reproduce: Try to start a vm. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c1 Charles Arnold <carnold@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |carnold@suse.com, | |jfehlig@suse.com, | |ohering@suse.com InfoProvider| |t.wagner@inode.at --- Comment #1 from Charles Arnold <carnold@suse.com> 2014-04-21 14:54:41 UTC --- (In reply to comment #0)
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/7.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
After upgrade from 12.3 to 13.1 xen with xend and bridge-mode does not work any more. I know that xm is deprecated by xen project. But migration from xm to xl/libvirt is not so simple at the moment.
I am wondering why this is not so simple at the moment. Could you explain what problems you face migrating to xl?
xen-hotplug.log xenstore-read: couldn't read path backend/vbd/2/51712/node
Seems to be missing the disk here. Can you start the VM using 'xl'? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c2 --- Comment #2 from Thomas Wagner <t.wagner@inode.at> 2014-04-21 15:37:00 UTC --- I am using den pvscsi module which is - as far as I know - not supported in xl in a custom build kernel. Yes - if I stop xend I can start the vm with the xl commands. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c3 Thomas Wagner <t.wagner@inode.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|t.wagner@inode.at | --- Comment #3 from Thomas Wagner <t.wagner@inode.at> 2014-04-25 11:00:29 UTC --- see my last posting -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c4 Charles Arnold <carnold@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jdouglas@suse.com |carnold@suse.com QAContact|qa-bugs@suse.de |jdouglas@suse.com --- Comment #4 from Charles Arnold <carnold@suse.com> 2014-04-28 14:40:18 UTC --- Maybe related to 875370 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c5 Dion Kant <g.w.kant@hunenet.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |g.w.kant@hunenet.nl --- Comment #5 from Dion Kant <g.w.kant@hunenet.nl> 2014-04-28 23:04:39 UTC --- *** Bug 875370 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=875370 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c6 --- Comment #6 from Dion Kant <g.w.kant@hunenet.nl> 2014-04-28 23:44:17 UTC --- I want to add a couple of remarks on the discussion about xl en xm. The problem is related to libvirtd. Since libvirtd is required to use tools like virt-manager, which is even used by Yast to setup VMs. It has to do with xl being stateless whereas xend did track state in some way. See this article: http://blog.xen.org/index.php/2014/01/17/libvirt-support-for-xens-new-libxen... As a result, when domains are started with xl, they remain invisible to tools like virt-viewer, virt-manager and virsh. Furthermore, until now, "all" SuSE documentation is/was still based on the xend tool stack. Have a look at /usr/share/doc/packages/xen/README.SuSE. Xl is not even mentioned in there. In particular I want to cite here the section on Init scripts:
Init scripts ------------ Before you can create additional VMs (or use any other xm command) xend must be running. This init script is part of the xen-tools package, and it is activated at installation time. You can (de)activate it using insserv. You can also start it manually with "rcxend start".
The deprecated xendomains script is also shipped, but disabled by default. In SLES 10 GA (xen 3.0.2) and older, this script allowed VMs to be started and stopped automatically when the machine starts and stops. In SLES 10 SP1 (xen 3.0.4) and newer, the proper way to start and stop VMs automatically is to set the "on_xend_start" and "on_xend_stop" settings in the VMs configuration. (Deprecating xendomains was necessary because xend, not the configuration file in /etc/xen/vm, is now the authoritative source for the VM's settings.) Consult the online documentation for more information.
This is really confusing since AFAIK the "on_xend_start" and the deprecation of xendomains is contradictory to using xl. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c7 --- Comment #7 from Charles Arnold <carnold@suse.com> 2014-04-28 23:58:05 UTC --- You are absolutely correct about the documentation. This is something we will be working on fixing. As you noted, you can't use 'xl' and the libvirt enabled tools because they don't communicate with each other. Likewise you can't use 'xl' while also using the old xm/xend toolstack. We left the flexibility there to choose your own toolstack but didn't document the dangers of mixing them. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c8 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aginies@suse.com --- Comment #8 from James Fehlig <jfehlig@suse.com> 2014-04-29 02:01:00 UTC --- (In reply to comment #6)
The problem is related to libvirtd. Since libvirtd is required to use tools like virt-manager, which is even used by Yast to setup VMs.
What problem does libvirtd have? AFAIK, libvirtd is not involved in this bug.
As a result, when domains are started with xl, they remain invisible to tools like virt-viewer, virt-manager and virsh.
Right. Those are libvirt apps, not libxl apps. The libvirt libxl driver is a libxl app, as is xl. libxl is designed to allow multiple applications to manage a xen host, but one libxl app should not manipulate domains, resource pools, etc. owned by another libxl app. IMO, either use libvirt and all the apps in its ecosystem, or use xl.
Furthermore, until now, "all" SuSE documentation is/was still based on the xend tool stack. Have a look at /usr/share/doc/packages/xen/README.SuSE. Xl is not even mentioned in there.
Thanks for pointing that out. Adding Antoine so he is aware of the doc issue too. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c9 --- Comment #9 from Dion Kant <g.w.kant@hunenet.nl> 2014-04-29 07:37:24 UTC --- (In reply to comment #8)
What problem does libvirtd have? AFAIK, libvirtd is not involved in this bug.
Oh sorry, "The problem" was meant to be the fact that libvirtd and xm work well together, whereas (from a user point of view) this is not the case with xl. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c10 --- Comment #10 from Dion Kant <g.w.kant@hunenet.nl> 2014-04-29 08:00:21 UTC --- To continue on fixing the issue with xend not detecting devices, some loud thinking here..... The xend based xen-tools package is renamed and continues to live under the name xen-xend-tools. The xen-tools package now brings in the xl tool stack, but also more general Xen related stuff which is required for running xend as well. There may be a conflict when installing xen-xend-tools on top of xen-tools. In /etc/xen/xl.conf I find
# default option to run hotplug scripts from xl # if disabled the old behaviour will be used, and hotplug scripts will be # launched by udev. #run_hotplug_scripts=1
which implies that hotplug scripts are currently not launched by udev. Does xend know about this? ... It would be more clear if the tool sets were packaged along the line xen-generic-tools xen-xl-tools xen-xend-tools and make xen-xl-tools more pure about xl and dito for xen-xend-tools -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c11 Antoine Ginies <aginies@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |fs@suse.com --- Comment #11 from Antoine Ginies <aginies@suse.com> 2014-04-29 08:24:35 UTC --- The XEN doc openSUSE13.1 need to be updated with the new XL toolstack. What's the process to get this update for openSUSE? Xen doc is currently under review/rewrite for SLE product, this will be the same content. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c12 Thomas Wagner <t.wagner@inode.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|fs@suse.com | --- Comment #12 from Thomas Wagner <t.wagner@inode.at> 2014-05-03 11:12:37 UTC --- I would appreciate some hints how to solve the current issue and not starting a request about xl documentation. I know that we all have to switch to xl toolstack earlier or later. But at the moment I have really to solve this issue. I have checked udev rules. They are in place like under 12.3 release. regards Thomas -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c13 --- Comment #13 from Dion Kant <g.w.kant@hunenet.nl> 2014-05-03 11:23:33 UTC --- (In reply to comment #12)
I would appreciate some hints how to solve the current issue and not starting a request about xl documentation.
I know that we all have to switch to xl toolstack earlier or later. But at the moment I have really to solve this issue.
I have checked udev rules. They are in place like under 12.3 release.
Hello Thomas, I continue on this tomorrow if I find some time. If I make progress, I'll share it here.... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c14 --- Comment #14 from Dion Kant <g.w.kant@hunenet.nl> 2014-05-04 14:24:24 UTC --- I have found a fix which works for me. mv /etc/udev/rules.d/40-xen.rules /etc/udev/rules.d/99-xen.rules /etc/init.d/boot.udev restart BACKGROUND INFORMATION To narrow it down to this. I raised udev_log to debug in /etc/udev/udev.conf. With running udevadm monitor --kernel --udev --property it looks like the udev events are passing by fine. However, I found that, despite /var/log/messages shows the scripts are selected for execution, they are actually *NOT* executed. Here an example for the call to /etc/xen/scripts/vif-setup 2014-05-03T21:37:36.881736+02:00 dom0-test systemd-udevd[4322]: seq 1811 queued, 'remove' 'net' 2014-05-03T21:37:36.895971+02:00 dom0-test systemd-udevd[4349]: device 0x2484fa0 filled with db file data 2014-05-03T21:37:36.896712+02:00 dom0-test systemd-udevd[4349]: RUN '/etc/xen/scripts/vif-setup offline type_if=vif' /etc/udev/rules.d/40-xen.rules:5 2014-05-03T21:37:36.897256+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 2014-05-03T21:37:36.897796+02:00 dom0-test systemd-udevd[4349]: device 0x2473720 has devpath '/devices/xen-backend' 2014-05-03T21:37:36.898477+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' returned non-zero 2014-05-03T21:37:36.899190+02:00 dom0-test systemd-udevd[4349]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 2014-05-03T21:37:36.900052+02:00 dom0-test systemd-udevd[4349]: execute 'load' 'xen-backend:vif' 2014-05-03T21:37:36.900598+02:00 dom0-test systemd-udevd[4349]: inserted 'netbk' 2014-05-03T21:37:36.901149+02:00 dom0-test systemd-udevd[4349]: passed -1 bytes to netlink monitor 0x2482e30 2014-05-03T21:37:36.901760+02:00 dom0-test systemd-udevd[4349]: seq 1808 processed with 0 2014-05-03T21:37:36.902302+02:00 dom0-test systemd-udevd[4322]: seq 1808 done with 0 2014-05-03T21:37:36.902923+02:00 dom0-test systemd-udevd[4322]: passed 182 bytes to netlink monitor 0x24732d0 2014-05-03T21:37:36.903453+02:00 dom0-test systemd-udevd[4349]: seq 1809 running 2014-05-03T21:37:36.904162+02:00 dom0-test systemd-udevd[4349]: no db file to read /run/udev/data/+queues:rx-0: No such file or directory I did put some echo in the script (echo "Here we are" >> /tmp/xen.log) and found that the file was not created. To make a long story short, I found that the scripts *are* executed by getting the xen.rules higher in the udev rules list. So I think, in the original situation, there is some rule overriding the relevant RUN list. In the mean time I found an error thrown for /usr/lib/udev/rules.d/90-hwrng.rules: 2014-04-27T10:59:37.203487+02:00 linux systemd-udevd[324]: invalid key/value pair in file /usr/lib/udev/rules.d/90-hwrng.rules on line 1,starting at character 107 ('s') This is caused by a missing new line in the file. Please forward this issue to the right people from openSUSE. And please share with us what is the root cause of this. In the mean time I can start using xm again. Cheers, Dion -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c15 --- Comment #15 from Dion Kant <g.w.kant@hunenet.nl> 2014-05-04 15:00:21 UTC --- It looks like /usr/lib/udev/rules.d/80-drivers.rules:5 is resetting the RUN list. 2014-05-03T21:37:36.896712+02:00 dom0-test systemd-udevd[4349]: RUN '/etc/xen/scripts/vif-setup offline type_if=vif' /etc/udev/rules.d/40-xen.rules:5 2014-05-03T21:37:36.897256+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 2014-05-03T21:37:36.897796+02:00 dom0-test systemd-udevd[4349]: device 0x2473720 has devpath '/devices/xen-backend' 2014-05-03T21:37:36.898477+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' returned non-zero 2014-05-03T21:37:36.899190+02:00 dom0-test systemd-udevd[4349]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 Since in reversed order it does work: 2014-05-04T15:59:34.551076+02:00 dom0-test systemd-udevd[7856]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 2014-05-04T15:59:34.551635+02:00 dom0-test systemd-udevd[7856]: RUN '/usr/sbin/vif-setup online type_if=vif' /etc/udev/rules.d/99-xen.rules:4 2014-05-04T15:59:34.552207+02:00 dom0-test systemd-udevd[7856]: created db file '/run/udev/data/+xen-backend:vif-18-0' for '/devices/xen-backend/vif-18-0' 2014-05-04T15:59:34.553039+02:00 dom0-test systemd-udevd[7856]: execute 'load' 'xen-backend:vif' 2014-05-04T15:59:34.553672+02:00 dom0-test systemd-udevd[7856]: inserted 'netbk' 2014-05-04T15:59:34.554280+02:00 dom0-test systemd-udevd[7900]: starting '/usr/sbin/vif-setup online type_if=vif' 2014-05-04T15:59:34.582353+02:00 dom0-test logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0 2014-05-04T15:59:34.593038+02:00 dom0-test logger: /etc/xen/scripts/block: Writing backend/vbd/18/51712/physical-device fd:0 to xenstore. The rule /usr/lib/udev/rules.d/80-drivers.rules:5, does ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}" I would not expect that the assignment to RUN{builtin}= clears a RUN= (without a type) as well. And looking at openSUSE 12.3, indeed it follows that /usr/lib/udev/rules.d/80-drivers.rules has been changed. There IMPORT as used iso RUN: # do not edit this file, it will be overwritten on update ACTION=="remove", GOTO="drivers_end" ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", IMPORT{builtin}="kmod load tifm_sd" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", IMPORT{builtin}="kmod load tifm_ms" SUBSYSTEM=="memstick", IMPORT{builtin}="kmod load ms_block mspro_block" SUBSYSTEM=="i2o", IMPORT{builtin}="kmod load i2o_block" SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", IMPORT{builtin}="kmod load sg" SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}="kmod load ppdev" LABEL="drivers_end" Note that xl would have been broken as well in a mode where it solely relied on the hot plugging scripts. Apparently it does it a different way. Dion. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c16 --- Comment #16 from Dion Kant <g.w.kant@hunenet.nl> 2014-05-04 16:12:00 UTC --- It looks like /usr/lib/udev/rules.d/80-drivers.rules:5 is resetting the RUN list. 2014-05-03T21:37:36.896712+02:00 dom0-test systemd-udevd[4349]: RUN '/etc/xen/scripts/vif-setup offline type_if=vif' /etc/udev/rules.d/40-xen.rules:5 2014-05-03T21:37:36.897256+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 2014-05-03T21:37:36.897796+02:00 dom0-test systemd-udevd[4349]: device 0x2473720 has devpath '/devices/xen-backend' 2014-05-03T21:37:36.898477+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' returned non-zero 2014-05-03T21:37:36.899190+02:00 dom0-test systemd-udevd[4349]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 Since in reversed order it does work: 2014-05-04T15:59:34.551076+02:00 dom0-test systemd-udevd[7856]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 2014-05-04T15:59:34.551635+02:00 dom0-test systemd-udevd[7856]: RUN '/usr/sbin/vif-setup online type_if=vif' /etc/udev/rules.d/99-xen.rules:4 2014-05-04T15:59:34.552207+02:00 dom0-test systemd-udevd[7856]: created db file '/run/udev/data/+xen-backend:vif-18-0' for '/devices/xen-backend/vif-18-0' 2014-05-04T15:59:34.553039+02:00 dom0-test systemd-udevd[7856]: execute 'load' 'xen-backend:vif' 2014-05-04T15:59:34.553672+02:00 dom0-test systemd-udevd[7856]: inserted 'netbk' 2014-05-04T15:59:34.554280+02:00 dom0-test systemd-udevd[7900]: starting '/usr/sbin/vif-setup online type_if=vif' 2014-05-04T15:59:34.582353+02:00 dom0-test logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0 2014-05-04T15:59:34.593038+02:00 dom0-test logger: /etc/xen/scripts/block: Writing backend/vbd/18/51712/physical-device fd:0 to xenstore. The rule /usr/lib/udev/rules.d/80-drivers.rules:5, does ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}" I would not expect that the assignment to RUN{builtin}= clears a RUN= (without a type) as well. And looking at openSUSE 12.3, indeed it follows that /usr/lib/udev/rules.d/80-drivers.rules has been changed. There IMPORT as used iso RUN: # do not edit this file, it will be overwritten on update ACTION=="remove", GOTO="drivers_end" ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", IMPORT{builtin}="kmod load tifm_sd" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", IMPORT{builtin}="kmod load tifm_ms" SUBSYSTEM=="memstick", IMPORT{builtin}="kmod load ms_block mspro_block" SUBSYSTEM=="i2o", IMPORT{builtin}="kmod load i2o_block" SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", IMPORT{builtin}="kmod load sg" SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}="kmod load ppdev" LABEL="drivers_end" Note that xl would have been broken as well in a mode where it solely relied on the hot plugging scripts. Apparently it does it a different way. Dion. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c17 --- Comment #17 from Thomas Wagner <t.wagner@inode.at> 2014-05-04 18:09:23 UTC --- I can confirm that the hint mv /etc/udev/rules.d/40-xen.rules /etc/udev/rules.d/99-xen.rules /etc/init.d/boot.udev restart works for me too. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c18 --- Comment #18 from Dion Kant <g.w.kant@hunenet.nl> 2014-05-05 08:06:53 UTC --- In factory this has been fixed too. From there it seems the formal fix is updating /usr/lib/udev/rules.d/80-drivers.rules with: # do not edit this file, it will be overwritten on update ACTION=="remove", GOTO="drivers_end" ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN{builtin}+="kmod load tifm_sd" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN{builtin}+="kmod load tifm_ms" SUBSYSTEM=="memstick", RUN{builtin}+="kmod load ms_block mspro_block" SUBSYSTEM=="i2o", RUN{builtin}+="kmod load i2o_block" SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}+="kmod load ppdev" KERNEL=="mtd*ro", ENV{MTD_FTL}=="smartmedia", RUN{builtin}+="kmod load sm_ftl" LABEL="drivers_end" Every RUN{builtin}= has been replaced with RUN{builtin}+= . -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com