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: [email protected]
To contact the owner, e-mail: [email protected]
