[opensuse-virtual] Xen 4.8 upgrade missing /usr/bin/domu-xenstore, fails to start xencommons
After upgrading to latest xen now available rpm -qa | egrep -i ^xen" xen-4.8.0_01-465.1.x86_64 xen-libs-4.8.0_01-465.1.x86_64 xen-tools-4.8.0_01-465.1.x86_64 on boot ... [FAILED] Failed to start xencommons. See 'systemctl status xencommons.service' for details. Starting Xendomains - start and stop guests on boot and shutdown... ... but it proceeds to prompt [ OK ] Started Xendomains - start and stop guests on boot and shutdown. Welcome to openSUSE Leap 42.2 - Kernel 4.9.0-6.ge989b9d-default (hvc0). checking at shell systemctl status xencommons -l ● xencommons.service - xencommons Loaded: loaded (/usr/lib/systemd/system/xencommons.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2017-01-06 13:26:32 PST; 6min ago Process: 1947 ExecStart=/usr/bin/xenstore-ls -f (code=exited, status=203/EXEC) Process: 1942 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS) Main PID: 1947 (code=exited, status=203/EXEC) because cd /usr/bin/ ls -al xenstore-ls lrwxrwxrwx 1 root root 13 Jan 6 13:14 xenstore-ls -> domu-xenstore ls -al domu-xenstore -bash: /usr/bin/xenstore-ls: No such file or directory rpm -q --whatprovides /usr/bin/xenstore-ls xen-tools-4.8.0_01-465.1.x86_64 rpm -q --whatprovides /usr/bin/domu-xenstore error: file /usr/bin/domu-xenstore: No such file or directory rpm -ql xen-tools-4.8.0_01-465.1.x86_64 | egrep "xenstore-ls|domu-xenstore" /usr/bin/xenstore-ls /usr/share/man/man1/xenstore-ls.1.gz this can NOT be fixed with a reinstall rm -f /usr/bin/xenstore-ls zypper in --force xen-tools ls -al /usr/bin/xenstore-ls lrwxrwxrwx 1 root root 13 Jan 6 13:40 /usr/bin/xenstore-ls -> domu-xenstore -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
Pull down another version of Xen 4.8 from the Virtualization repo that was just recently built. The xen-tools package contains a fix for what you are seeing. - Charles
On 1/6/2017 at 02:46 PM, <lists@ssl-mail.com> wrote: After upgrading to latest xen now available
rpm -qa | egrep -i ^xen" xen-4.8.0_01-465.1.x86_64 xen-libs-4.8.0_01-465.1.x86_64 xen-tools-4.8.0_01-465.1.x86_64
on boot
... [FAILED] Failed to start xencommons. See 'systemctl status xencommons.service' for details. Starting Xendomains - start and stop guests on boot and shutdown... ...
but it proceeds to prompt
[ OK ] Started Xendomains - start and stop guests on boot and shutdown.
Welcome to openSUSE Leap 42.2 - Kernel 4.9.0-6.ge989b9d-default (hvc0).
checking at shell
systemctl status xencommons -l ● xencommons.service - xencommons Loaded: loaded (/usr/lib/systemd/system/xencommons.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2017-01-06 13:26:32 PST; 6min ago Process: 1947 ExecStart=/usr/bin/xenstore-ls -f (code=exited, status=203/EXEC) Process: 1942 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS) Main PID: 1947 (code=exited, status=203/EXEC)
because
cd /usr/bin/ ls -al xenstore-ls lrwxrwxrwx 1 root root 13 Jan 6 13:14 xenstore-ls -> domu-xenstore ls -al domu-xenstore -bash: /usr/bin/xenstore-ls: No such file or directory
rpm -q --whatprovides /usr/bin/xenstore-ls xen-tools-4.8.0_01-465.1.x86_64 rpm -q --whatprovides /usr/bin/domu-xenstore error: file /usr/bin/domu-xenstore: No such file or directory
rpm -ql xen-tools-4.8.0_01-465.1.x86_64 | egrep "xenstore-ls|domu-xenstore" /usr/bin/xenstore-ls /usr/share/man/man1/xenstore-ls.1.gz
this can NOT be fixed with a reinstall
rm -f /usr/bin/xenstore-ls zypper in --force xen-tools ls -al /usr/bin/xenstore-ls lrwxrwxrwx 1 root root 13 Jan 6 13:40 /usr/bin/xenstore-ls -> domu-xenstore -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Fri, Jan 6, 2017, at 02:13 PM, Charles Arnold wrote:
Pull down another version of Xen 4.8 from the Virtualization repo that was just recently built. The xen-tools package contains a fix for what you are seeing.
I thought the force-install did that. Trying again zypper clean --all xen4 Specified repositories have been cleaned up. zypper -vvv in --force xen-tools ... The following package is going to be reinstalled: xen-tools 4.8.0_01-465.1 x86_64 XEN4 obs://build.opensuse.org/Virtualization ... Continue? [y/n/? shows all options] (y): y ... Retrieving package xen-tools-4.8.0_01-465.1.x86_64 (1/1), 7.8 MiB ( 10.7 MiB unpacked) Retrieving: http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.2/... ......................................[done (690.3 KiB/s)] (1/1) Installing: xen-tools-4.8.0_01-465.1.x86_64 .....................................................................................................................................[done] Additional rpm output: Updating /etc/sysconfig/xencommons... Updating /etc/sysconfig/xendomains... CommitResult (total 1, done 1, error 0, skipped 0, updateMessages 0) rpm -ql xen-tools | grep xenstore /etc/xen/scripts/launch-xenstore /usr/bin/xenstore /usr/bin/xenstore-chmod /usr/bin/xenstore-control /usr/bin/xenstore-exists /usr/bin/xenstore-list
/usr/bin/xenstore-ls
/usr/bin/xenstore-read /usr/bin/xenstore-rm /usr/bin/xenstore-watch /usr/bin/xenstore-write /usr/lib/systemd/system/var-lib-xenstored.mount /usr/lib/systemd/system/xenstored.service /usr/lib/xen/bin/init-xenstore-domain /usr/lib/xen/boot/xenstore-stubdom.gz /usr/sbin/xenstored /usr/share/doc/packages/xen/misc/xenstore-paths.markdown /usr/share/man/man1/xenstore-chmod.1.gz /usr/share/man/man1/xenstore-ls.1.gz /usr/share/man/man1/xenstore.1.gz /var/lib/xenstored
ls -al /usr/bin/xenstore-ls lrwxrwxrwx 1 root root 13 Jan 6 14:23 /usr/bin/xenstore-ls -> domu-xenstore ls -al /usr/bin/domu-xenstore ls: cannot access '/usr/bin/domu-xenstore': No such file or directory Is there another step needed? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
It should be version 4.8.0_01-466.1 (not 4.8.0_01-465.1). It appears to be published so you should just be able to update to that version. Also, if you are installing tumbleweed as a PV guest using virt-manager you will want to grab the latest version of that package from the Virtualization repo. - Charles
On 1/6/2017 at 03:28 PM, <lists@ssl-mail.com> wrote:
On Fri, Jan 6, 2017, at 02:13 PM, Charles Arnold wrote:
Pull down another version of Xen 4.8 from the Virtualization repo that was just recently built. The xen-tools package contains a fix for what you are seeing.
I thought the force-install did that.
Trying again
zypper clean --all xen4 Specified repositories have been cleaned up. zypper -vvv in --force xen-tools ... The following package is going to be reinstalled: xen-tools 4.8.0_01-465.1 x86_64 XEN4 obs://build.opensuse.org/Virtualization ... Continue? [y/n/? shows all options] (y): y ... Retrieving package xen-tools-4.8.0_01-465.1.x86_64
(1/1), 7.8 MiB ( 10.7 MiB unpacked) Retrieving: http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.2/... 86_64/xen-tools-4.8.0_01-465.1.x86_64.rpm ......................................[done (690.3 KiB/s)] (1/1) Installing: xen-tools-4.8.0_01-465.1.x86_64 ............................................................................. ........................................................[done] Additional rpm output: Updating /etc/sysconfig/xencommons... Updating /etc/sysconfig/xendomains...
CommitResult (total 1, done 1, error 0, skipped 0, updateMessages 0)
rpm -ql xen-tools | grep xenstore /etc/xen/scripts/launch-xenstore /usr/bin/xenstore /usr/bin/xenstore-chmod /usr/bin/xenstore-control /usr/bin/xenstore-exists /usr/bin/xenstore-list
/usr/bin/xenstore-ls
/usr/bin/xenstore-read /usr/bin/xenstore-rm /usr/bin/xenstore-watch /usr/bin/xenstore-write /usr/lib/systemd/system/var-lib-xenstored.mount /usr/lib/systemd/system/xenstored.service /usr/lib/xen/bin/init-xenstore-domain /usr/lib/xen/boot/xenstore-stubdom.gz /usr/sbin/xenstored /usr/share/doc/packages/xen/misc/xenstore-paths.markdown /usr/share/man/man1/xenstore-chmod.1.gz /usr/share/man/man1/xenstore-ls.1.gz /usr/share/man/man1/xenstore.1.gz /var/lib/xenstored
ls -al /usr/bin/xenstore-ls lrwxrwxrwx 1 root root 13 Jan 6 14:23 /usr/bin/xenstore-ls -> domu-xenstore ls -al /usr/bin/domu-xenstore ls: cannot access '/usr/bin/domu-xenstore': No such file or directory
Is there another step needed?
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Fri, Jan 6, 2017, at 02:44 PM, Charles Arnold wrote:
It should be version 4.8.0_01-466.1 (not 4.8.0_01-465.1). It appears to be published so you should just be able to update to that version.
Looks like it's just stuck The pkgs are here https://build.opensuse.org/package/binaries/Virtualization/xen?repository=op... but not here http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.2/...
Also, if you are installing tumbleweed as a PV guest using virt-manager you will want to grab the latest version of that package from the Virtualization repo.
I'm not, but I'll note it. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Friday, January 06, 2017 03:11:22 PM lists@ssl-mail.com wrote:
On Fri, Jan 6, 2017, at 02:44 PM, Charles Arnold wrote:
It should be version 4.8.0_01-466.1 (not 4.8.0_01-465.1). It appears to be published so you should just be able to update to that version.
Looks like it's just stuck
The pkgs are here
https://build.opensuse.org/package/binaries/Virtualization/xen?repository=op enSUSE_Leap_42.2
but not here
http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.2/ x86_64/
That's likely due to OBS workers just being slow in the publishing process. I'll keep an eye on it and make sure it completes. Thanks for reporting the problem, and please let us know how your 4.8 testing goes. -Mike -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Fri, Jan 6, 2017, at 03:17 PM, Mike Latimer wrote:
Thanks for reporting the problem, and please let us know how your 4.8 testing goes.
Once everything propagated to the repos, I upgraded to xen 4.8.0_01-466.1 xen-libs 4.8.0_01-466.1 xen-tools 4.8.0_01-466.1 kernel-default 4.9.1-2.1.g1072b39 Checking, there's no dangling link anymore ls -al /usr/bin/xenstore-ls lrwxrwxrwx 1 root root 8 Jan 6 16:37 /usr/bin/xenstore-ls -> xenstore* ls -al /usr/bin/xenstore -rwxr-xr-x 1 root root 19K Jan 6 13:24 /usr/bin/xenstore* Reboot now completes Welcome to openSUSE Leap 42.2 - Kernel 4.9.1-2.g1072b39-default (hvc0). xent login: root Password: Last login: Fri Jan 6 14:56:48 from 192.168.1.19 Have a lot of fun... Previously working DomUs come up on boot xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2048 1 r----- 51.1 opensuse 1 1024 1 -b---- 7.0 but are not accessible anymore either via console, or their individual, embedded sshd's xl console 1 ������������������������������������������������������������������������������Ŀ � ERROR � � � � Verification failed: (15) Access Denied � � � � � � � � � � � � � � ����Ŀ � � � OK � � � ����� Trust openSUSE Certificate � � � � Do you agree to use the built-in openSUSE certificate � � to verify boot loaders and kernels? � � � � �����Ŀ � � � No � � � � Yes � �1 � ������� ������������������������������������������������������������������������������Ŀ � ERROR � � � � Could not install security protocol: (2) Invalid Parameter � � � � � � � � � � � � � � ����Ŀ � � � OK � � � ����� � I don't know what to do with all that yet. I've tried any/all of the DomUs I'd had working; everyone of them's the same so far. 1st look at journalctl -f on the Dom0, from launching the DomU to the 1st error on boot, Jan 06 17:48:00 xent.lanint systemd-udevd[894]: seq 3317 queued, 'add' 'xen-backend' Jan 06 17:48:01 xent.lanint systemd-udevd[894]: Validate module index Jan 06 17:48:01 xent.lanint systemd-udevd[894]: Check if link configuration needs reloading. Jan 06 17:48:01 xent.lanint systemd-udevd[894]: seq 3317 forked new worker [4992] Jan 06 17:48:01 xent.lanint systemd-udevd[4992]: seq 3317 running Jan 06 17:48:01 xent.lanint systemd-udevd[4992]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:15 Jan 06 17:48:01 xent.lanint systemd-udevd[4992]: IMPORT builtin 'hwdb' returned non-zero Jan 06 17:48:01 xent.lanint systemd-udevd[4992]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 Jan 06 17:48:01 xent.lanint systemd-udevd[4992]: Execute 'load' 'xen-backend:vbd' Jan 06 17:48:01 xent.lanint systemd-udevd[4992]: Inserted 'xen_blkback' Jan 06 17:48:01 xent.lanint systemd-sysctl[5394]: Parsing /usr/lib/sysctl.d/50-coredump.conf Jan 06 17:48:01 xent.lanint systemd-sysctl[5394]: Parsing /usr/lib/sysctl.d/50-default.conf Jan 06 17:48:01 xent.lanint systemd-sysctl[5394]: Parsing /etc/sysctl.d/99-sysctl.conf Jan 06 17:48:01 xent.lanint systemd[2006]: sys-subsystem-net-devices-vif4.0\x2demu.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[2006]: sys-devices-virtual-net-vif4.0\x2demu.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[1]: sys-subsystem-net-devices-vif4.0\x2demu.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[1]: sys-devices-virtual-net-vif4.0\x2demu.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitNew cookie=223 reply_cookie=0 error=n/a Jan 06 17:48:01 xent.lanint systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitNew cookie=224 reply_cookie=0 error=n/a Jan 06 17:48:01 xent.lanint systemd-sysctl[5403]: Parsing /usr/lib/sysctl.d/50-coredump.conf Jan 06 17:48:01 xent.lanint systemd-sysctl[5403]: Parsing /usr/lib/sysctl.d/50-default.conf Jan 06 17:48:01 xent.lanint systemd-sysctl[5403]: Parsing /etc/sysctl.d/99-sysctl.conf Jan 06 17:48:01 xent.lanint systemd[2006]: sys-subsystem-net-devices-vif4.0.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[2006]: sys-devices-vif\x2d4\x2d0-net-vif4.0.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[1]: sys-subsystem-net-devices-vif4.0.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[1]: sys-devices-vif\x2d4\x2d0-net-vif4.0.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitNew cookie=225 reply_cookie=0 error=n/a Jan 06 17:48:01 xent.lanint systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitNew cookie=226 reply_cookie=0 error=n/a Jan 06 17:48:01 xent.lanint kernel: vif vif-4-0 vifT: renamed from vif4.0 Jan 06 17:48:01 xent.lanint systemd[2006]: sys-subsystem-net-devices-vif4.0.device: Dev sys-subsystem-net-devices-vif4.0.device appeared twice with different sysfs paths /sys/devices/vif-4-0/net/vif4.0 and /sys/devices/vif-4-0/net/vifT Jan 06 17:48:01 xent.lanint systemd[2006]: sys-subsystem-net-devices-vifT.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[2006]: sys-devices-vif\x2d4\x2d0-net-vifT.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint systemd[1]: sys-subsystem-net-devices-vif4.0.device: Dev sys-subsystem-net-devices-vif4.0.device appeared twice with different sysfs paths /sys/devices/vif-4-0/net/vif4.0 and /sys/devices/vif-4-0/net/vifT Jan 06 17:48:01 xent.lanint systemd[1]: sys-subsystem-net-devices-vifT.device: Changed dead -> plugged Jan 06 17:48:01 xent.lanint kernel: br0: port 2(vifT) entered blocking state Jan 06 17:48:01 xent.lanint kernel: br0: port 2(vifT) entered disabled state Jan 06 17:48:01 xent.lanint kernel: device vifT entered promiscuous mode Jan 06 17:48:02 xent.lanint kernel: IPv6: ADDRCONF(NETDEV_UP): vifT: link is not ready Jan 06 17:48:02 xent.lanint kernel: vifT-emu: renamed from vif4.0-emu Jan 06 17:48:02 xent.lanint systemd[2006]: sys-subsystem-net-devices-vif4.0\x2demu.device: Dev sys-subsystem-net-devices-vif4.0\x2demu.device appeared twice with different sysfs paths /sys/devices/virtual/net/vif4.0-emu and /sys/devices/virtual/net/vifT-emu Jan 06 17:48:02 xent.lanint systemd[2006]: sys-subsystem-net-devices-vifT\x2demu.device: Changed dead -> plugged Jan 06 17:48:02 xent.lanint systemd[2006]: sys-devices-virtual-net-vifT\x2demu.device: Changed dead -> plugged Jan 06 17:48:02 xent.lanint kernel: br0: port 3(vifT-emu) entered blocking state Jan 06 17:48:02 xent.lanint kernel: br0: port 3(vifT-emu) entered disabled state Jan 06 17:48:02 xent.lanint kernel: device vifT-emu entered promiscuous mode Jan 06 17:48:02 xent.lanint kernel: br0: port 3(vifT-emu) entered blocking state Jan 06 17:48:02 xent.lanint kernel: br0: port 3(vifT-emu) entered listening state Jan 06 17:48:00 xent.lanint root[5036]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51712 Jan 06 17:48:00 xent.lanint root[5037]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51776 Jan 06 17:48:00 xent.lanint root[5041]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51808 Jan 06 17:48:00 xent.lanint root[5038]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51792 Jan 06 17:48:00 xent.lanint root[5177]: /etc/xen/scripts/block: Writing backend/vbd/4/51712/physical-device fe:d to xenstore. Jan 06 17:48:00 xent.lanint root[5179]: /etc/xen/scripts/block: Writing backend/vbd/4/51712/physical-device-path /dev/dm-13 to xenstore. Jan 06 17:48:00 xent.lanint root[5181]: /etc/xen/scripts/block: Writing backend/vbd/4/51712/hotplug-status connected to xenstore. Jan 06 17:48:00 xent.lanint root[5247]: /etc/xen/scripts/block: Writing backend/vbd/4/51776/physical-device fe:e to xenstore. Jan 06 17:48:00 xent.lanint root[5249]: /etc/xen/scripts/block: Writing backend/vbd/4/51776/physical-device-path /dev/dm-14 to xenstore. Jan 06 17:48:00 xent.lanint root[5251]: /etc/xen/scripts/block: Writing backend/vbd/4/51776/hotplug-status connected to xenstore. Jan 06 17:48:00 xent.lanint root[5315]: /etc/xen/scripts/block: Writing backend/vbd/4/51808/physical-device fe:10 to xenstore. Jan 06 17:48:00 xent.lanint root[5317]: /etc/xen/scripts/block: Writing backend/vbd/4/51808/physical-device-path /dev/dm-16 to xenstore. Jan 06 17:48:00 xent.lanint root[5319]: /etc/xen/scripts/block: Writing backend/vbd/4/51808/hotplug-status connected to xenstore. Jan 06 17:48:01 xent.lanint root[5381]: /etc/xen/scripts/block: Writing backend/vbd/4/51792/physical-device fe:f to xenstore. Jan 06 17:48:01 xent.lanint root[5383]: /etc/xen/scripts/block: Writing backend/vbd/4/51792/physical-device-path /dev/dm-15 to xenstore. Jan 06 17:48:01 xent.lanint root[5385]: /etc/xen/scripts/block: Writing backend/vbd/4/51792/hotplug-status connected to xenstore. Jan 06 17:48:01 xent.lanint root[5414]: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/4/0 Jan 06 17:48:01 xent.lanint root[5442]: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vifT, bridge br0. Jan 06 17:48:01 xent.lanint root[5443]: /etc/xen/scripts/vif-bridge: Writing backend/vif/4/0/hotplug-status connected to xenstore. Jan 06 17:48:01 xent.lanint root[5455]: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/4/0 Jan 06 17:48:01 xent.lanint root[5483]: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vifT-emu, bridge br0. Jan 06 17:48:03 xent.lanint kernel: xen-blkback: backend/vbd/4/51712: using 1 queues, protocol 1 (x86_64-abi) Jan 06 17:48:03 xent.lanint kernel: xen-blkback: backend/vbd/4/51776: using 1 queues, protocol 1 (x86_64-abi) Jan 06 17:48:03 xent.lanint kernel: xen-blkback: backend/vbd/4/51792: using 1 queues, protocol 1 (x86_64-abi) Jan 06 17:48:03 xent.lanint kernel: xen-blkback: backend/vbd/4/51808: using 1 queues, protocol 1 (x86_64-abi) Jan 06 17:48:05 xent.lanint kernel: br0: port 3(vifT-emu) entered learning state Jan 06 17:48:09 xent.lanint kernel: br0: port 3(vifT-emu) entered forwarding state Jan 06 17:48:09 xent.lanint kernel: br0: topology change detected, propagating -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On 01/06/2017 06:55 PM, lists@ssl-mail.com wrote:
Previously working DomUs come up on boot xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2048 1 r----- 51.1 opensuse 1 1024 1 -b---- 7.0
but are not accessible anymore either via console, or their individual, embedded sshd's
The "Verification failed: (15) Access Denied" and "Could not install security protocol: (2) Invalid Parameter" messages sound like they are related to secure boot. Are you using this within your domU's? Can you give us some more details on the domU configurations (e.g. version of openSUSE, pv/hvm, etc.)? It would also be interesting to know if a new VM experiences the same problem. Thanks, Mike -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
related to secure boot. Are you using this within your domU's?
EFI, yes. SecureBoot, no.
Can you give us some more details on the domU configurations (e.g. version of openSUSE, pv/hvm, etc.)?
This DomU is my base config. It's PVHVM, runs Opensuse Leap 42.. Here's the usual base config cat /etc/xen/auto/opensuse.cfg name = 'opensuse' builder = 'hvm' xen_platform_pci = 1 device_model_version="qemu-xen" bios = 'ovmf' bios_override = '/usr/share/qemu/ovmf-x86_64.bin' maxmem = 1024 memory = 1024 boot = 'cd' disk = [ 'phy:/dev/VG0/EFI,xvda,w', 'phy:/dev/VG0/BOOT,xvde,w', 'phy:/dev/VG0/SWAP,xvdf,w', 'phy:/dev/VG0/ROOT,xvdg,w',] vif = [ 'mac=00:16:3E:50:00:01, model=e1000, bridge=br0, vifname=vifT',] acpi = 1 apic = 1 hap = 1 localtime = 0 nestedhvm = 0 nx = 1 pae = 1 tsc_mode = 'default' sdl = 0 serial = 'pty' vga = 'stdvga' vnc = 1 vncdisplay = 1 vnclisten = '0.0.0.0' on_crash = 'destroy' on_reboot = 'restart' on_shutdown = 'destroy'
It would also be interesting to know if a new VM experiences the same problem.
There always seems to be some sort of "can't boot anymore" problem with a Xen full point upgrade. At least the last couple ... Last time around I had to re-install DomUs from scratch. It eventually gets fixed that way, and is cool until the next point upgrade. I'm hoping that's not gonna be the case again. Got some testing I can do 1st. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
fwiw, I chrooted into the Guest env from the DomU, rebuilt the initrd there and re-exec'd grub2-mkconfig. No change restarting the Guest - same errors as above. This morning I woke to find that the Guest had been restarting itself all night -- apparently 200+ times! xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2048 1 r----- 2907.0 opensuse 225 1024 1 -b---- 5.7 That's new -- & clearly not good, esp since in the config I have on_crash = 'destroy' on_reboot = 'restart' on_shutdown = 'destroy' -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
With Xen cmdline containing loglvl=all guest_loglvl=all between xl create -c opensuse.cfg and the appearance of ������������������������������������������������������������������������������Ŀ � ERROR � � � � Verification failed: (15) Access Denied � � � � � � � � � � � � � � ����Ŀ � � � OK � � � ����� � � � � � � � � � � � � � � � � � � � � � �������������������������������������������������������������������������������� here's the @Dom0 output of `journalctl -f` Jan 07 10:23:12 xent.lanint systemd-udevd[918]: seq 3220 queued, 'add' 'xen-backend' Jan 07 10:23:12 xent.lanint systemd-udevd[918]: Validate module index Jan 07 10:23:12 xent.lanint systemd-udevd[918]: Check if link configuration needs reloading. Jan 07 10:23:12 xent.lanint systemd-udevd[918]: seq 3220 forked new worker [2464] Jan 07 10:23:12 xent.lanint systemd-udevd[2464]: seq 3220 running Jan 07 10:23:12 xent.lanint systemd-udevd[2464]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:15 Jan 07 10:23:12 xent.lanint systemd-udevd[2464]: IMPORT builtin 'hwdb' returned non-zero Jan 07 10:23:12 xent.lanint systemd-udevd[2464]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 Jan 07 10:23:12 xent.lanint systemd-udevd[2464]: Execute 'load' 'xen-backend:vbd' Jan 07 10:23:12 xent.lanint systemd-udevd[2464]: Inserted 'xen_blkback' Jan 07 10:23:12 xent.lanint root[2508]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51712 Jan 07 10:23:12 xent.lanint root[2511]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51808 Jan 07 10:23:12 xent.lanint root[2509]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51776 Jan 07 10:23:12 xent.lanint root[2510]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51792 Jan 07 10:23:13 xent.lanint kernel: tun: Universal TUN/TAP device driver, 1.6 Jan 07 10:23:14 xent.lanint kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> Jan 07 10:23:14 xent.lanint systemd-sysctl[2870]: Parsing /usr/lib/sysctl.d/50-coredump.conf Jan 07 10:23:14 xent.lanint systemd-sysctl[2870]: Parsing /usr/lib/sysctl.d/50-default.conf Jan 07 10:23:14 xent.lanint systemd-sysctl[2870]: Parsing /etc/sysctl.d/99-sysctl.conf Jan 07 10:23:14 xent.lanint systemd[2028]: sys-subsystem-net-devices-vif1.0\x2demu.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[2028]: sys-devices-virtual-net-vif1.0\x2demu.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[1]: sys-subsystem-net-devices-vif1.0\x2demu.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[1]: sys-devices-virtual-net-vif1.0\x2demu.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd-sysctl[2876]: Parsing /usr/lib/sysctl.d/50-coredump.conf Jan 07 10:23:14 xent.lanint systemd-sysctl[2876]: Parsing /usr/lib/sysctl.d/50-default.conf Jan 07 10:23:14 xent.lanint systemd-sysctl[2876]: Parsing /etc/sysctl.d/99-sysctl.conf Jan 07 10:23:14 xent.lanint systemd[2028]: sys-subsystem-net-devices-vif1.0.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[2028]: sys-devices-vif\x2d1\x2d0-net-vif1.0.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[1]: sys-subsystem-net-devices-vif1.0.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[1]: sys-devices-vif\x2d1\x2d0-net-vif1.0.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint kernel: vif vif-1-0 vifT: renamed from vif1.0 Jan 07 10:23:14 xent.lanint systemd[2028]: sys-subsystem-net-devices-vif1.0.device: Dev sys-subsystem-net-devices-vif1.0.device appeared twice with different sysfs paths /sys/devices/vif-1-0/net/vif1.0 and /sys/devices/vif-1-0/net/vifT Jan 07 10:23:14 xent.lanint systemd[2028]: sys-subsystem-net-devices-vifT.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[2028]: sys-devices-vif\x2d1\x2d0-net-vifT.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint systemd[1]: sys-subsystem-net-devices-vif1.0.device: Dev sys-subsystem-net-devices-vif1.0.device appeared twice with different sysfs paths /sys/devices/vif-1-0/net/vif1.0 and /sys/devices/vif-1-0/net/vifT Jan 07 10:23:14 xent.lanint systemd[1]: sys-subsystem-net-devices-vifT.device: Changed dead -> plugged Jan 07 10:23:14 xent.lanint kernel: br0: port 2(vifT) entered blocking state Jan 07 10:23:15 xent.lanint kernel: br0: port 2(vifT) entered disabled state Jan 07 10:23:15 xent.lanint kernel: device vifT entered promiscuous mode Jan 07 10:23:15 xent.lanint kernel: IPv6: ADDRCONF(NETDEV_UP): vifT: link is not ready Jan 07 10:23:15 xent.lanint kernel: vifT-emu: renamed from vif1.0-emu Jan 07 10:23:15 xent.lanint systemd[2028]: sys-subsystem-net-devices-vif1.0\x2demu.device: Dev sys-subsystem-net-devices-vif1.0\x2demu.device appeared twice with different sysfs paths /sys/devices/virtual/net/vif1.0-emu and /sys/devices/virtual/net/vifT-emu Jan 07 10:23:15 xent.lanint systemd[2028]: sys-subsystem-net-devices-vifT\x2demu.device: Changed dead -> plugged Jan 07 10:23:15 xent.lanint systemd[2028]: sys-devices-virtual-net-vifT\x2demu.device: Changed dead -> plugged Jan 07 10:23:15 xent.lanint kernel: br0: port 3(vifT-emu) entered blocking state Jan 07 10:23:15 xent.lanint kernel: br0: port 3(vifT-emu) entered disabled state Jan 07 10:23:15 xent.lanint kernel: device vifT-emu entered promiscuous mode Jan 07 10:23:15 xent.lanint kernel: br0: port 3(vifT-emu) entered blocking state Jan 07 10:23:15 xent.lanint kernel: br0: port 3(vifT-emu) entered listening state Jan 07 10:23:12 xent.lanint root[2649]: /etc/xen/scripts/block: Writing backend/vbd/1/51808/physical-device fe:10 to xenstore. Jan 07 10:23:12 xent.lanint root[2651]: /etc/xen/scripts/block: Writing backend/vbd/1/51808/physical-device-path /dev/dm-16 to xenstore. Jan 07 10:23:12 xent.lanint root[2653]: /etc/xen/scripts/block: Writing backend/vbd/1/51808/hotplug-status connected to xenstore. Jan 07 10:23:12 xent.lanint root[2719]: /etc/xen/scripts/block: Writing backend/vbd/1/51712/physical-device fe:d to xenstore. Jan 07 10:23:12 xent.lanint root[2721]: /etc/xen/scripts/block: Writing backend/vbd/1/51712/physical-device-path /dev/dm-13 to xenstore. Jan 07 10:23:12 xent.lanint root[2723]: /etc/xen/scripts/block: Writing backend/vbd/1/51712/hotplug-status connected to xenstore. Jan 07 10:23:13 xent.lanint root[2787]: /etc/xen/scripts/block: Writing backend/vbd/1/51776/physical-device fe:e to xenstore. Jan 07 10:23:13 xent.lanint root[2789]: /etc/xen/scripts/block: Writing backend/vbd/1/51776/physical-device-path /dev/dm-14 to xenstore. Jan 07 10:23:13 xent.lanint root[2791]: /etc/xen/scripts/block: Writing backend/vbd/1/51776/hotplug-status connected to xenstore. Jan 07 10:23:13 xent.lanint root[2853]: /etc/xen/scripts/block: Writing backend/vbd/1/51792/physical-device fe:f to xenstore. Jan 07 10:23:13 xent.lanint root[2855]: /etc/xen/scripts/block: Writing backend/vbd/1/51792/physical-device-path /dev/dm-15 to xenstore. Jan 07 10:23:13 xent.lanint root[2857]: /etc/xen/scripts/block: Writing backend/vbd/1/51792/hotplug-status connected to xenstore. Jan 07 10:23:13 xent.lanint root[2888]: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/1/0 Jan 07 10:23:13 xent.lanint root[2916]: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vifT, bridge br0. Jan 07 10:23:13 xent.lanint root[2917]: /etc/xen/scripts/vif-bridge: Writing backend/vif/1/0/hotplug-status connected to xenstore. Jan 07 10:23:13 xent.lanint root[2929]: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/1/0 Jan 07 10:23:13 xent.lanint root[2957]: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vifT-emu, bridge br0. Jan 07 10:23:16 xent.lanint kernel: xen-blkback: backend/vbd/1/51712: using 1 queues, protocol 1 (x86_64-abi) Jan 07 10:23:16 xent.lanint kernel: xen-blkback: backend/vbd/1/51776: using 1 queues, protocol 1 (x86_64-abi) Jan 07 10:23:16 xent.lanint kernel: xen-blkback: backend/vbd/1/51792: using 1 queues, protocol 1 (x86_64-abi) Jan 07 10:23:16 xent.lanint kernel: xen-blkback: backend/vbd/1/51808: using 1 queues, protocol 1 (x86_64-abi) Jan 07 10:23:17 xent.lanint kernel: br0: port 3(vifT-emu) entered learning state Jan 07 10:23:22 xent.lanint kernel: br0: port 3(vifT-emu) entered forwarding state Jan 07 10:23:22 xent.lanint kernel: br0: topology change detected, propagating and here's the output @ Dom0 serial console (XEN) [2017-01-07 18:30:27] HVM3 save: CPU (XEN) [2017-01-07 18:30:27] HVM3 save: PIC (XEN) [2017-01-07 18:30:27] HVM3 save: IOAPIC (XEN) [2017-01-07 18:30:27] HVM3 save: LAPIC (XEN) [2017-01-07 18:30:27] HVM3 save: LAPIC_REGS (XEN) [2017-01-07 18:30:27] HVM3 save: PCI_IRQ (XEN) [2017-01-07 18:30:27] HVM3 save: ISA_IRQ (XEN) [2017-01-07 18:30:27] HVM3 save: PCI_LINK (XEN) [2017-01-07 18:30:27] HVM3 save: PIT (XEN) [2017-01-07 18:30:27] HVM3 save: RTC (XEN) [2017-01-07 18:30:27] HVM3 save: HPET (XEN) [2017-01-07 18:30:27] HVM3 save: PMTIMER (XEN) [2017-01-07 18:30:27] HVM3 save: MTRR (XEN) [2017-01-07 18:30:27] HVM3 save: VIRIDIAN_DOMAIN (XEN) [2017-01-07 18:30:27] HVM3 save: CPU_XSAVE (XEN) [2017-01-07 18:30:27] HVM3 save: VIRIDIAN_VCPU (XEN) [2017-01-07 18:30:27] HVM3 save: VMCE_VCPU (XEN) [2017-01-07 18:30:27] HVM3 save: TSC_ADJUST (XEN) [2017-01-07 18:30:27] HVM3 restore: CPU 0 (d3) [2017-01-07 18:30:28] HVM Loader (d3) [2017-01-07 18:30:28] Detected Xen v4.8.0_01-466 (d3) [2017-01-07 18:30:28] Xenbus rings @0xfeffc000, event channel 1 (d3) [2017-01-07 18:30:28] System requested OVMF (d3) [2017-01-07 18:30:28] CPU speed is 3093 MHz (d3) [2017-01-07 18:30:28] Relocating guest memory for lowmem MMIO space disabled (d3) [2017-01-07 18:30:28] PCI-ISA link 0 routed to IRQ5 (d3) [2017-01-07 18:30:28] PCI-ISA link 1 routed to IRQ10 (d3) [2017-01-07 18:30:28] PCI-ISA link 2 routed to IRQ11 (d3) [2017-01-07 18:30:28] PCI-ISA link 3 routed to IRQ5 (d3) [2017-01-07 18:30:28] pci dev 01:3 INTA->IRQ10 (d3) [2017-01-07 18:30:28] pci dev 02:0 INTA->IRQ11 (d3) [2017-01-07 18:30:28] pci dev 04:0 INTA->IRQ5 (d3) [2017-01-07 18:30:28] No RAM in high memory; setting high_mem resource base to 100000000 (d3) [2017-01-07 18:30:28] pci dev 02:0 bar 14 size 001000000: 0f0000008 (d3) [2017-01-07 18:30:28] pci dev 03:0 bar 10 size 001000000: 0f1000008 (d3) [2017-01-07 18:30:28] pci dev 04:0 bar 30 size 000040000: 0f2000000 (d3) [2017-01-07 18:30:29] pci dev 04:0 bar 10 size 000020000: 0f2040000 (d3) [2017-01-07 18:30:29] pci dev 03:0 bar 30 size 000010000: 0f2060000 (d3) [2017-01-07 18:30:29] pci dev 03:0 bar 18 size 000001000: 0f2070000 (d3) [2017-01-07 18:30:29] pci dev 02:0 bar 10 size 000000100: 00000c001 (d3) [2017-01-07 18:30:29] pci dev 04:0 bar 14 size 000000040: 00000c101 (d3) [2017-01-07 18:30:29] pci dev 01:1 bar 20 size 000000010: 00000c141 (d3) [2017-01-07 18:30:29] Multiprocessor initialisation: (d3) [2017-01-07 18:30:29] - CPU0 ... 39-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... do ne. (d3) [2017-01-07 18:30:29] Writing SMBIOS tables ... (d3) [2017-01-07 18:30:29] Loading OVMF ... (XEN) [2017-01-07 18:30:29] d3v0 Over-allocation for domain 3: 524545 > 524544 (d3) [2017-01-07 18:30:29] Loading ACPI ... (d3) [2017-01-07 18:30:29] vm86 TSS at fc00a400 (d3) [2017-01-07 18:30:29] BIOS map: (d3) [2017-01-07 18:30:29] ffe00000-ffffffff: Main BIOS (d3) [2017-01-07 18:30:29] E820 table: (d3) [2017-01-07 18:30:29] [00]: 00000000:00000000 - 00000000:000a0000: RAM (d3) [2017-01-07 18:30:29] HOLE: 00000000:000a0000 - 00000000:000f0000 (d3) [2017-01-07 18:30:29] [01]: 00000000:000f0000 - 00000000:00100000: RESERVED (d3) [2017-01-07 18:30:29] [02]: 00000000:00100000 - 00000000:7eeb5000: RAM (d3) [2017-01-07 18:30:29] HOLE: 00000000:7eeb5000 - 00000000:fc000000 (d3) [2017-01-07 18:30:29] [03]: 00000000:fc000000 - 00000001:00000000: RESERVED (d3) [2017-01-07 18:30:29] Invoking OVMF ... it stops there. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
From inside the chrooted DomU guest
Re-installing grub, without overwriting the physical, motherboard efi-related nvram, grub2-install -v --target=x86_64-efi --efi-directory=/boot/efi --no-nvram ... grub2-install: info: copying `/boot/grub2/x86_64-efi/core.efi' -> `/boot/efi/EFI/opensuse/grubx64.efi'. Installation finished. No error reported. Ensuring the startup boots the right loader echo "fs0:\EFI\opensuse\grubx64.efi" > /boot/efi/startup.nsh What's installed at this point is tree -D /boot/efi /boot/efi ├── [root 512 Jun 21 2016] EFI │ ├── [root 512 Jan 7 9:47] boot │ │ ├── [root 1164376 Jan 7 9:47] bootx64.efi │ │ ├── [root 72240 Jan 4 6:37] fallback.efi │ │ ├── [root 120 Jan 7 9:47] grub.cfg │ │ ├── [root 1008720 Jan 7 9:47] grub.efi │ │ └── [root 1166552 Jan 7 9:47] MokManager.efi │ └── [root 512 Jun 21 2016] opensuse │ ├── [root 58 Jan 4 6:37] boot.csv │ ├── [root 120 Jan 4 6:37] grub.cfg │ ├── [root 1008720 Jan 4 6:37] grub.efi │ ├── [root 129024 Jan 7 13:53] grubx64.efi │ ├── [root 1166552 Jan 4 6:37] MokManager.efi │ └── [root 1164376 Jan 4 6:37] shim.efi └── [root 30 Jan 7 13:53] startup.nsh exit the chroot, then create the DomU xl create -c /etc/xen/vm/opensuse.cfg It still fails as reported above. Destroy the guest again xl destroy opensuse re-enter chroot Now, note the creationg/addition of tree -D /boot/efi /boot/efi ... ├── [root 12673 Jan 7 13:55] NvVars ... Checking that strings /boot/efi/NvVars | head 10 Washington1 Redmond1 Microsoft Corporation1;09 2Microsoft Corporation Third Party Marketplace Root0 110624204129Z 260624205129Z0 Washington1 Redmond1 Microsoft Corporation1*0( !Microsoft Corporation KEK CA 20110 So clearly the Guest's BIOS (tianocore/ovmf) at least 'touches' the EFI partition -- i.e. it's aware of the Guest. Why SecureBoot is involved is unclear. Is there some new Xen mechanism, or config param, to ensure it's DISABLED for Guests ? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On 01/06/2017 10:11 PM, lists@ssl-mail.com wrote:
It's PVHVM, runs Opensuse Leap 42..
42.1 or 42.2? I tested a fresh, EFI-based install of 42.2 (pvhvm) on a new 42.2 xen host. On the first boot of the guest, I was prompted with "Do you agree to use the built-in openSUSE certificate", which I agreed to. I then shut the guest down, updated the host to xen 4.8 (-466), rebooted and started the guest again. I was not prompted to accept the certificate, and the guest booted correctly. Do you remember accepting the certificate on this guest prior to the update to 4.8? Were you able to say 'Yes' to that prompt during the startup under 4.8? Are you continuing to see the following errors during every (failed) boot? Verification failed: (15) Access Denied Could not install security protocol: (2) Invalid Parameter I'll reach out to a bootloader guy to see if we can figure out what those are related to.
There always seems to be some sort of "can't boot anymore" problem with a Xen full point upgrade. At least the last couple ...
That's not good, and definitely something that shouldn't happen. You've gathered some great information on the problem so far. Can you enter this into an official bug on this at bugzilla.opensuse.org? Thanks, Mike -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Sat, Jan 7, 2017, at 03:48 PM, Mike Latimer wrote:
42.1 or 42.2?
42.2
Do you remember accepting the certificate on this guest prior to the update to 4.8?
no, never.
Were you able to say 'Yes' to that prompt during the startup under 4.8?
Yes, I am *able* to select 'Yes'. Unfortunately, it simply then pops up the 'Error' screen, as above.
Are you continuing to see the following errors during every (failed) boot?
Yes
I'll reach out to a bootloader guy to see if we can figure out what those are related to.
I have a strong, sneaking suspicion that it's OVMF The fact that I can chroot, re-grub, then reboot -- and *see* that 'new' NvVars file suggests, to me anyway, that "a BIOS" is touching that Guest. And there's the staring-me-in-the-face message it hangs at in the serial console (d2) [2017-01-07 21:55:36] Invoking OVMF ... Obviously that^ has to be OVMF. I don't know why the strings in the NvVars file are all Microsoft-laden. The only thing I can imaging is that it's the SecureBoot stuff. I've tried echo "fs0:\EFI\opensuse\shim.efi" > /boot/efi/startup.nsh instead of echo "fs0:\EFI\opensuse\grubx64.efi" > /boot/efi/startup.nsh but that doesn't seem to have any effect.
You've gathered some great information on the problem so far. Can you enter this into an official bug on this at bugzilla.opensuse.org?
https://bugzilla.opensuse.org/show_bug.cgi?id=1018741 -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On 01/07/2017 05:44 PM, lists@ssl-mail.com wrote:
I have a strong, sneaking suspicion that it's OVMF
I agree. The bootloader expert(s) I forwarded the thread to are also involved with OVMF development, so hopefully they will have some ideas.
I don't know why the strings in the NvVars file are all Microsoft-laden.
There are a few different OVMF images, with the main difference with these images being the keys that are included. The best explanation of these differences is in the README file of the OVMF package in OBS: https://build.opensuse.org/package/view_file/Virtualization/ovmf/README?expa... You could try switching to ovmf-x86_64-{opensuse|suse|ms}.bin, just to see if one of the other ones behaves better. If there is no difference, we'll probably have to wait for an expert in this area to respond.
Thanks for the bug report. We should probably continue the discussion there. -Mike -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
Thanks for the bug report. We should probably continue the discussion there.
Sure, from now on ... Let me know if the 'component' there needs changing, or just change it if u can. For issues like this, I never know what component to choose. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
participants (3)
-
Charles Arnold -
lists＠ssl-mail.com -
Mike Latimer