On 11/19/2015 01:35 AM, Olaf Hering wrote:
There's no longer any xen bridge, or properly-named eth interface, here eno1
cat /etc/sysconfig/network/ifcfg-br0 NAME='br0' BRIDGE='yes' BRIDGE_PORTS='eno1'
eno1 does not exist as interface name.
Hm. It certainly _used_ to prior to the upgrade ...
wicked: ifcfg-br0: unable to qualify post-up script - unknown script type '(null):/etc/sysconfig/network/scripts/br0-config.sh'
Not sure if these hooks are supported that way. Perhaps wicked already has ethtool knobs.
Again, it worked absolutely fine prior to the upgrade; the script executed, and the knobs' values were verified to be set. That preceding "(null):" is a problem, but iirc is due to the lack of properly init'd xenstored
At least xen works on my Leap installation. Not sure why EFI would make any difference. Are there stale xen related .service files or sysv scripts which prevent xenstored.service/xenstored.socked from starting? Our xencommons.service is supposed to start everything.
I made a little progress. I read this http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01262.html exec'd these systemctl enable xenstored.service systemctl enable xenconsoled.service systemctl enable xen-init-dom0.service systemctl enable xen-qemu-dom0-disk-backend.service systemctl enable xendomains.service So now, systemctl list-unit-files | grep -i xen proc-xen.mount static var-lib-xenstored.mount static xen-dom0-modules.service disabled xen-init-dom0.service enabled xen-qemu-dom0-disk-backend.service enabled xen-watchdog.service disabled xencommons.service enabled xenconsoled.service enabled xendomains.service enabled xenstored.service enabled xenstored.socket enabled xenstored_ro.socket enabled Also found & removed these from the /etc/default/grub - GRUB_CMDLINE_LINUX_XEN_REPLACE=" (.*) rdloaddriver=xennet rdloaddriver=xenblk" + GRUB_CMDLINE_LINUX_XEN_REPLACE=" (.*) " Since I'd been using my own, custom xen.cfg, I'd never noticed these before. Here's the current, post-upgrade systemd script status With BOTH of those changes, I no longer see Xen dependency problems reported on boot, dmesg | grep -i xen ... [ 0.000000] Linux version 4.3.0-4.g734b32c-xen (geeko@buildhost) (gcc version 5.2.1 20151008 [gcc-5-branch revision 228597] (SUSE Linux) ) #1 SMP Sat Nov 14 16:19:19 UTC 2015 (734b32c) [ 0.000000] Command line: root=UUID=471... rootfstype=ext4 rootflags=journal_checksum noresume showopts noquiet video=vesa:off video=efifb:1024x768 video=o [ 0.000000] Xen-provided machine memory map: [ 0.000000] e820: Xen-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x00000000c07fffff] usable [ 0.000000] Kernel command line: root=UUID=471... rootfstype=ext4 rootflags=journal_checksum noresume showopts noquiet video=vesa:off video=efifb:1024x768o [ 0.000000] Xen reported: 3092.928 MHz processor. [ 0.000000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 0.377137] xen_mem: Initialising balloon driver. [ 0.388028] clocksource: Switched to clocksource xen [ 1.698180] Xen virtual console successfully installed as xvc0 [ 5.023083] usb usb1: Manufacturer: Linux 4.3.0-4.g734b32c-xen xhci-hcd [ 5.243846] usb usb2: Manufacturer: Linux 4.3.0-4.g734b32c-xen xhci-hcd [ 5.329938] usb usb3: Manufacturer: Linux 4.3.0-4.g734b32c-xen xhci-hcd [ 5.331195] usb usb4: Manufacturer: Linux 4.3.0-4.g734b32c-xen xhci-hcd [ 5.588164] usb usb5: Manufacturer: Linux 4.3.0-4.g734b32c-xen ehci_hcd [ 5.604160] usb usb6: Manufacturer: Linux 4.3.0-4.g734b32c-xen ehci_hcd
Does "systemctl start xencommons.service" give any errors? Could be that it fails because its dependencies are in failed state.
> > systemctl status xencommons.service xencommons.service - xencommons Loaded: loaded (/usr/lib/systemd/system/xencommons.service; enabled) Active: inactive (dead) > systemctl start xencommons.service Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode. Give root password for maintenance (or press Control-D to continue):
If in doubt open a bug and attach journalctl -b output. The posted output also shows journal errors, perhaps the issue is unrelated to xen.
First, at a glance, in the journalctl -- not dmesg -- output I _do_ see: Nov 18 19:15:56 xensvr systemd-udevd[812]: Network interface NamePolicy= disabled on kernel commandline, ignoring. I've no idea what it's referring to, as dmesg | grep -i "kernel command" [ 0.000000] Kernel command line: root=UUID=471... rootfstype=ext4 rootflags=journal_checksum noresume showopts noquiet video=vesa:off video=efifb:1024x768 video=o=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=xvc0 clocksource=xen apparmor=0 selinux=0 nomodeset noquiet showopts elevator=cfq mce=off plymouth.enable=0 log_buf_len=10M print_fatal_signals=1 loglevel=6 systemd.log_level=warning systemd.log_target=kmsg earlyprintk=xen which derives directly from cat /etc/default/grub GRUB_CMDLINE_LINUX_XEN_REPLACE=" rootfstype=ext4 rootflags=journal_checksum noresume showopts noquiet video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=xvc0 clocksource=xen apparmor=0 selinux=0 nomodeset noquiet showopts elevator=cfq mce=off plymouth.enable=0 log_buf_len=10M print_fatal_signals=1 loglevel=6 systemd.log_level=warning systemd.log_target=kmsg earlyprintk=xen" but "NamePolicy= disabled" certainly looks suspicious. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org