Mailinglist Archive: opensuse-virtual (28 mails)

< Previous Next >
Re: [opensuse-virtual] Chainloaded Leap 42.1 Xen Dom0 on EFI hardware -- network offline, xen init failing: "Failed to start The Xen xenstore"
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-virtual+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups