Summary: | sys-fs/udev-160 breaks integrity of creating vif devices for virtualisation apps. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ian Delaney (RETIRED) <idella4> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | holler.loudly |
Priority: | High | ||
Version: | 10.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Ian Delaney (RETIRED)
2010-08-04 22:39:01 UTC
idella@genny /mnt/suse/boot/grub $ sudo emerge --info Password: Portage 2.1.8.3 (default/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.11.2-r0, 2.6.31-xen-r10 i686) ================================================================= System uname: Linux-2.6.31-xen-r10-i686-Intel-R-_Core-TM-2_Duo_CPU_E6550_@_2.33GHz-with-gentoo-2.0.1 Timestamp of tree: Wed, 04 Aug 2010 18:45:01 +0000 app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4, 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 virtual/os-headers: 2.6.34 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA dlj-1.1" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=core2 -fomit-frame-pointer -pipe -O2 -mno-tls-direct-seg-refs -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/libvirt/libvirtd.conf /etc/xen/xend-config.sxp /etc/xen/xm-xonfig.sxp /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-march=core2 -fomit-frame-pointer -pipe -O2 -mno-tls-direct-seg-refs -ggdb" DISTDIR="/mnt/gentoo/distfiles" FEATURES="assume-digests buildpkg distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.swin.edu.au/gentoo/ ftp://mirror.pacific.net.au/linux/Gentoo ftp://mirror.isp.net.au/pub/gentoo/ http://mirror.isp.net.au/pub/gentoo/ http://mirror.averse.net/pub/gentoo/" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="(-altivec) (-aqua) (-corefonts%*) (-cups) (-devfs-compat%*) (-doc%) (-fixed-point) (-gallium) (-gold%) (-google-gadgets) (-hardened) (-iceweasel%)-deblob (-introspection) (-kdeenablefinal) (-kdeprefix) (-libffi) (-libsigsegv%) (-mozdevelop%) (-multilib) (-n32) (-n64) (-nocxx%) (-one%) (-pango%) (-pkcs11%) (-ppcsha1) (-ps3) (-python%*) (-seamonkey%) (-selinux) (-smartcard%) (-sqlite%) (-uclibc) (wide-unicode) X a52 aac acl acpi aio alsa apm armeb arts audiofile avi bash-completion berkdb blksha1 bluetooth bmp bzip2 cairo cairo%* cdparanoia cdr cli client%* consolekit corefonts cracklib cris crypt ctype cups cxx cxx%* dba dbmaker dbus dga dhcp dri dts dv dvd dvdr dvdread emboss encode esd eselect ethereal exif extras fam fbcon ffmpeg fftw fftw* firefox flac fortran ftp gdbm gif gnome gnutls gphoto gpm gprof gstreamer gtk gtk%* gtk2 hal handbook http%* i386 iconv imagemagick inifile ioctl ipc%* java jpeg kde kontact ladcca lcms lcms* ldap libg++ libnotify libvirtd lm_sensors lxc m3 mad mbox mdev%* microblaze mikmod mime mips64 mips64el mipsel mmap mng modules mono mozilla mp3 mp4 mpeg msn mudflap mysql ncurses net netapi network nls nptl nptlonly ogg openal opengl openmp oss pam pcre pdf perl perl%* pm-utils png png%* pnp posix ppc64abi32 ppcemb ppds pppd python qdbm qt qt3support qt4 quicktime readline reflection ruby samba sasl sasl% scanner sdl semantic-desktop server%* session sh4 sh4eb shared slp smbclient sndfile sockets source sparc32plus sparc64 spell spl sql sse sse2 ssl startup-notification svg svga svgtruetype sysfs tcpd theora threads tiff truetype udev udev%* urandom usb v4l videos vorbis webdav webkit webkit* websockets wifi wifi%* win32codecs x264 x86 x86_64 xcb xcb* xen xine xinerama xml xml2 xorg xulrunner xv xvid zlib" ALSA_CARDS="snd_hda_intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" QEMU_SOFTMMU_TARGETS="arm cris i386 m68k microblaze mips mips64 mips64el mipsel ppc ppc64 ppcemb sh4 sh4eb sparc sparc64 x86_64" QEMU_USER_TARGETS="alpha arm armeb cris i386 m68k microblaze mips mipsel ppc ppc64 ppc64abi32 sh4 sh4eb sparc sparc32plus sparc64 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev nvidia vesa v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY What version of libvirt do you have installed -- did it get upgraded when your udev did? If not, then this is probably an incompatibility of the old libvirt with the new udev. (In reply to comment #2) > What version of libvirt do you have installed -- did it get upgraded when your > udev did? If not, then this is probably an incompatibility of the old libvirt > with the new udev. > gentoo64 / # emerge -s libvirt Searching... [ Results for search key : libvirt ] [ Applications found : 2 ] * app-emulation/libvirt Latest version available: 0.8.2-r1 Latest version installed: 0.8.2-r1 Size of files: 11,943 kB If so, what is the suggested way to workaround or fix? downgrade udev? This is not an old libvirt, it was in fact upgraded, so unlikely that. There ia apparently a new libvirt out, must be only in the last week. I shall try that later and repost. At this point it still appears as a udev bug. hmm, needinfo switches to resolved, hardly. back as it was Ok this upstream xen bug looks relevant: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1612 Either you can go back to udev-151, or test the proposed xen kernel patch and see if that solves your problems with udev-160 (In reply to comment #5) > Ok this upstream xen bug looks relevant: > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1612 > > Either you can go back to udev-151, or test the proposed xen kernel patch and > see if that solves your problems with udev-160 > I've spent the last two days trying to test the patch, to the point that I've asked for assistance from the forum. The patch that was made and put on that bug submission is a .diff file. I've never done patching before, and I just found a std way to apply it. The patch will not take on a gentoo xen kernel. It reports failing 2 out of 4 hunks, whatever they are. Something re the kernel version. The patch did take on a linux-2.6-xen kernel that I acquired via git kernel.org. This xen kernel should work, but it's doing very strange things. It won't work for x86. I shall compile it and try in x86_64 only out of desperation and curiosity. If you know how to apply this patch to the gentoo xen kernel, please post it here. Until then, I am stuck. Reverting to udev might work, but leaves the bug untreated. It need work with the current udev. I've upgraded libvirt to current, and it's even worse, currently not even connecting to xen. idella@genny ~/xen/xen-4.0-testing.hg $ uname -r 2.6.34-xen idella@genny ~/xen/xen-4.0-testing.hg $ sudo virsh -c xen Password: error: unable to connect to 'localhost:8000': Connection refused error: failed to connect to the hypervisor idella@genny ~/xen/xen-4.0-testing.hg $ sudo grep vif /var/log/messages ................. Aug 12 18:56:44 genny libvirtd: 18:56:44.601: info : udevGetDeviceProperty:116 : udev reports device 'vif0.3' does not have property 'DRIVER' Aug 12 18:56:44 genny libvirtd: 18:56:44.601: debug : udevGetDeviceType:1088 : Found device type '(null)' for device 'vif0.3' Aug 12 18:56:44 genny libvirtd: 18:56:44.601: info : udevGetDeviceProperty:116 : udev reports device 'vif0.3' does not have property 'PCI_CLASS' Aug 12 18:56:44 genny libvirtd: 18:56:44.601: debug : udevGetDeviceProperty:136 : Found property key 'INTERFACE' value 'vif0.3' for device with sysname 'vif0.3' Aug 12 18:56:44 genny libvirtd: 18:56:44.601: debug : udevGetDeviceProperty:136 : Found property key 'INTERFACE' value 'vif0.3' for device with sysname 'vif0.3' Aug 12 18:56:44 genny libvirtd: 18:56:44.601: debug : udevGetDeviceSysfsAttr:225 : Found sysfs attribute 'address' value 'fe:ff:ff:ff:ff:ff' for device with sysname 'vif0.3' Aug 12 18:56:44 genny libvirtd: 18:56:44.601: debug : udevGetDeviceSysfsAttr:225 : Found sysfs attribute 'addr_len' value '6' for device with sysname 'vif0.3' I've returned to the steep learning curve of kernels. After 6 months I've finally found how to get the xensource kernel to work in 32 mode. I'm not there yet, Once I tweak the config and get it to actually boot I shall apply the patch and finally test it. Question of how long it will take me. (In reply to comment #7) Right, I've compiled the kernel. Applying a patch wasn't a step I expected, caused some extensive tinkering. I would still like to know if and how to apply that patch to the other kernels. The good news is that the patch does appear to have worked. idella@genny /usr/src/klinux-2.6.32-xen-r1 $ uname -a Linux genny 2.6.32.17-xen #24 SMP Sat Aug 14 05:37:38 WST 2010 i686 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux idella@genny /usr/src/klinux-2.6.32-xen-r1 $ sudo xm list Password: Name ID Mem VCPUs State Time(s) Domain-0 0 1462 2 r----- 240.1 fedora-nst 260 1 5.2 fedora11 2 285 2 -b---- 26.3 fedora8 218 2 21.5 fedora9 1 269 2 -b---- 4.6 karmic 282 2 32.9 lenny-5.04 300 1 0.0 mint 207 2 4.9 opensolaris 360 1 0.0 Now in this xensource kernel, ifconfig -a reveals a full content but no vifs. This is not really a fault. Just the config I suppose. The guests start up and stay started rather than close down with the serror stating vif device could not be connected. What I can't figure out is why this kernel actually works. I have 3 copies of the xensource kernel. Of these, I applied the patch to one, and to a second I happened to upgrade it using the instruct provided at the xensource site to a 2.6.32-17 kernel. Now I thought the patch was made for that version. I applied the patch to the gentoo kernels only to have them not take. Before I tried applying the patch to the upgraded 2.6.32-17, I compiled it and made the kernel image. After that, I tried to apply the patch, expecting it to take. It failed in the style of the gentoo kernels. Having applied half the patch, the 2.6.32-17 would not complete a re-compile. So the patch must have been for the still standard and used 2.6.31-13 kernel. This kernel is making vif devices under xen without the patch.The original 2.6.31-13 also does, having been patched. That leaves the gentoo kernels out in the cold. We need the patch made for them by inhouse gentoo. The 2.6.34 kernel was slightly different. On boot, ifconfig -a listed all the vif devices plus all those made by the xensource kernel. It couldn't however start xen. The xen I was using at the time was the xensource xen-4.0.1 from source. I re-emerged gentoo's xen-4.0.0. It's a dud now. The only working form of xen I have now is using xensource compiled from source with the xensource kernel. The gentoo package makers have some catching up to do. I shall keep testing, but the overall xen package has regressed from the fully working versions I have in my gentoo64 which was up to date 4-6 months ago. The xen itself also has an issue with opensolaris. I have two versions. The first is quite old, about 2006 vintage and I have only got it to install in xen in centos using older versions of everything, about xen-3.1 0r 3.2. I cannot import the installed xen solaris vm in xen in gentoo. Due to this, I acquired a current opensolaris to try. xen seems to be fine with linux installs, but it just can't handle this opensolaris. It pushes the cpu to 100% usage, it's awfully slow, and either the mouse freezes or it doesn't produce a full desktop. I tried it in kvm and it did it all without issue. kvm has far less hassles and bumps. Pass that onto upstream (In reply to comment #8) > (In reply to comment #7) > Correction. This is odd. the kernel 2.6.32-13 doesn't work. It is the kernel that I patched idella@genny /usr/src/linux-2.6-xen $ sudo patch -p1 < /home/idella/Documents/netback-xenbus-redone.diff patching file drivers/xen/netback/xenbus.c Reversed (or previously applied) patch detected! Assume -R? [n] idella@genny /usr/src/linux-2.6-xen $ nano Makefile GNU nano 2.2.4 File: Makefile VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 31 EXTRAVERSION = .13 NAME = Man-Eating Seals of Antiquity idella@genny /usr/src/linux-2.6-xen $ sudo ifconfig -a dummy0 Link encap:Ethernet HWaddr 6e:29:e8:0a:6c:2a BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth0 Link encap:Ethernet HWaddr 00:1f:c6:1a:ac:bd inet addr:192.168.0.2 Bcast:0.0.0.0 Mask:255.255.255.0 inet6 addr: fe80::21f:c6ff:fe1a:acbd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1817 errors:0 dropped:0 overruns:0 frame:0 TX packets:733 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:377618 (368.7 KiB) TX bytes:130629 (127.5 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:124 errors:0 dropped:0 overruns:0 frame:0 TX packets:124 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6312 (6.1 KiB) TX bytes:6312 (6.1 KiB) peth0 Link encap:Ethernet HWaddr 00:1f:c6:1a:ac:bd inet6 addr: fe80::21f:c6ff:fe1a:acbd/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:4807 errors:0 dropped:0 overruns:0 frame:0 TX packets:3915 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1693568 (1.6 MiB) TX bytes:547216 (534.3 KiB) Interrupt:150 Base address:0x8000 sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) vif1.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) virbr0 Link encap:Ethernet HWaddr b2:58:e8:44:e7:c1 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:960 (960.0 B) virbr1 Link encap:Ethernet HWaddr ce:4f:e3:6e:c4:80 inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:960 (960.0 B) wlan0 Link encap:Ethernet HWaddr 00:11:95:e9:b2:b7 inet6 addr: fe80::211:95ff:fee9:b2b7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:466 errors:0 dropped:0 overruns:0 frame:0 TX packets:51 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:40101 (39.1 KiB) TX bytes:4161 (4.0 KiB) wmaster0 Link encap:UNSPEC HWaddr 00-11-95-E9-B2-B7-00-00-00-00-00-00-00-00-00-00 UP RUNNING MTU:0 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Note it only makes vif1.0. The vif that is cited as not made is usually vif3.0 All the vif cited errors occur. - Hoyplug scripts not working. the upgrade version of this kernel 2.6.32-17 does work. Repeat; the kernel that I've made and booted was before attempting to patch it. I currently have a problem in that attempts to reconfigure and re-compile it are thwarted by the patch only half taking. Could you provide the instructions to reverse so I can remove it and reconfigure and further test this kernel. I'll leave it to you to determine whether this upgrade version has some other patch or already had it or whatever. I've never dealt with kernel patches before now. I'm not touching my healthy gentoo64 until this is fixed. (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > udev may make devices but the xen is shattered. Attempting to create a paravirt vm near crashes or freezes the system. It could be my kernel config, hard to tell the system is so unusable. edev makes vif but it can't seem to make a console for a vm. (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #7) > > > xen is not shattered, just tender. After several attempts, the 2.6.31 patched kernel does not work as fixed, the 2.6.32.19 does. This was a latch up lesson of the xensource kernel. I can only assume the upgraded version has absorbed the patch content somehow. The gentoo kernels are not usable until they can get patched. |