http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/release/has xen-4.14.1-1.mga8.x86_64.rpm
http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates_testing/
has xen-4.14.1-1.mga8.x86_64.rpm

Looks like release bump was missed.

Keywords: (none) => feedback
CC: (none) => davidwhodgins

Couldn't get the release version working with refind, so tried with grub2.

While it's no longer necessary to manually add a grub entry, I didn't figure
out how to change just the xen command line parameters, so just changed it
for all boots so in xen, /proc/cmdline has ...
placeholder root=UUID=1f3bf0c9-719c-4c75-b8e5-f03203154de0 ro noiswmd modprobedebug audit=0 nouveau.modeset=0 resume=LABEL=e1swap dom0_mem=4096MB vga=794

Xorg is failing to start with ...
[    25.736] (II) UnloadModule: "fbdev"
[    25.736] (II) Unloading fbdev
[    25.736] (II) UnloadSubModule: "fbdevhw"
[    25.736] (II) Unloading fbdevhw
[    25.736] (II) UnloadModule: "vesa"
[    25.736] (II) Unloading vesa
[    25.737] (II) NVIDIA: Using 24576.00 MB of virtual memory for indirect memory
[    25.737] (II) NVIDIA:     access.
[    25.743] (EE) NVIDIA(0): Failed to allocate shared surface
[    25.788] (EE) 
Fatal server error:
[    25.788] (EE) AddScreen/ScreenInit failed for driver 0

On a normal Mageia boot, the corresponding section has ...
[    16.769] (II) NVIDIA: Using 24576.00 MB of virtual memory for indirect memory
[    16.769] (II) NVIDIA:     access.
[    16.815] (II) NVIDIA(0): Setting mode "NULL"
[    16.829] (==) NVIDIA(0): Disabling shared memory pixmaps

The system has 16GB Ram, 32GB swap.

For xorg, I'm using mageia-prime with
# lspcidrake -v|grep Card
Card:ATI Volcanic Islands and later (amdgpu): Advanced Micro Devices, Inc. [AMD/ATI]|Renoir [DISPLAY_VGA] (vendor:1002 device:1636 subv:1043 subd:1e21) (rev: c6)
Card:NVIDIA GeForce 635 series and later: NVIDIA Corporation|TU106M [GeForce RTX 2060 Mobile] [DISPLAY_VGA] (vendor:10de device:1f15 subv:1043 subd:1e21) (rev: a1)

When the update with the bumped release is available, I'll just be checking
that the updates install cleanly over the current version, unless someone
can figure out what's needed to get this running.

The existing xen also has an boot delaying bug with ...
Xen boot entries ask for nonexistent grub2 module2.mod

https://bugzilla.redhat.com/show_bug.cgi?id=1858364#c12
has a fix for that one.

This is with the release version packages isntalled for ...
grub2-emu-modules-2.04.0-29.mga8
grub2-mageia-theme-2.04.0-29.mga8
grub2-emu-2.04.0-29.mga8
grub2-common-2.04.0-29.mga8
grub2-efi-2.04.0-29.mga8

Ping ? 101 days since last action here.

CC: (none) => ouaurelien
Summary: [Update candidate] xen => [Update candidate] xen packages fix new security issues (CVE-2021-26933
CVE: (none) => CVE-2021-26933, CVE-2021-26934

Reassigning back to packager

Assignee: qa-bugs => thierry.vignaud

Thierry, can you take a look to this bugreport ?

Dave, can you check xen-4.16 in cauldron?
If it works smoothly, I can backport it into mga8

Keywords: (none) => NEEDINFO

I installed Mageia 9 on my uefi laptop from comment 2 and got it working, then
installed xen.

Booting Mageia with xen hypervisor, xorg is still failing with
(EE) NVIDIA(0): Failed to allocate shared surface

Networking is also not currently working within xen.

Haven't done any configuration or created an guests yet, just installed and
rebooted using grub2-efi.

I decided to try running mageia-prime-uninstall and then try booting Mageia
Cauldron with Xen. It's working for getting to xorg display, so the problem is
specific to xen with nvidia, or perhaps xen with mageia-prime using nvidia.

I noticed that when running ifup, there is now a warning that it's deprecated.
Does networkmanager now support bridging? If not, deprecating the network
scripts will stop being able to get networking working under xen.

I'll try setting up the networking and a guest tomorrow.

I went back to testing the m8 version, on my main system where I'd had xen
working in the past (long past).

As ifup is going to be deprecated, and everything I've read indicates xen
does not work with networkmanager, I used systemd to create the bridge as per
https://major.io/2015/03/26/creating-a-bridge-for-virtual-machines-using-systemd-networkd/

That works. I have the hypervisor running now, the network is up, and is
working for both ipv4 and ipv6 traffic.

I'm having problems with the first domu test. In the past, in bug 16956, I was
only able to get a hvm guest working on this computer, so that's what I'm
trying.
# cat x8xenhvm.cfg 
name="x8xenhvm"
type="hvm"
vcpus=2
memory=2048
maxmem=4096
vncviewer=1
disk = [ 'file:/opt/hvmtest.img,sda,w', 'file:/s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso,hdb:cdrom,r', ]
vif = [ 'type=ioemu, mac=00:1f:5a:71:ae:37, bridge=xenbr', ] # choose a random mac
boot="dc"

However when I run "xl create x8xenhvm", it causes the host system to hard boot
as if the reset button had been pressed.

Between that, and the nvidia problem which affects both m8 and cauldron
versions, not sure how to go any further.

OK, I've updated xen to 4.16.0-1.mga8 in core/updates_testing

Source RPM: xen-4.14.1-1.mga8 => xen-4.16.0-1.mga8

First boot locked up early in boot during display of physical ram map. Magic
sysrq keys non-responsive. Used the reset button.

Second boot, was able to login (I use run level 3, then startx on this system).
Locked up again while starting kde, requiring reset again. Repeated on third
boot, locking up in the same place during kde start.

Fourth boot. Used "startx startxfce4". Was able to get to the xfce4 desktop.
In a terminal ...
# xl create /etc/xen/x8xenhvm.cfg 
Parsing config from /etc/xen/x8xenhvm.cfg
WARNING: ignoring "vncviewer" option. Use "-V" option of "xl create" to automatically spawn vncviewer.
libxl: info: libxl_create.c:121:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory
libxl: error: libxl_dm.c:2882:libxl__spawn_local_dm: Domain 1:device model /usr/libexec/xen/bin/qemu-dm is not executable: No such file or directory
libxl: error: libxl_dm.c:3131:device_model_spawn_outcome: Domain 1:(null): spawn failed (rc=-3)
libxl: error: libxl_dm.c:3351:device_model_postconfig_done: Domain 1:Post DM startup configs failed, rc=-3
libxl: error: libxl_create.c:1867:domcreate_devmodel_started: Domain 1:device model did not start: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-existant domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction of domain failed

So the xl create is no longer causing a hard boot, but problems remain.

Note that during install, qemu-system-x86-core-0:5.2.0-4.mga8 had to be
removed due to conflicts.

(In reply to Dave Hodgins from comment #12)

> 
> Note that during install, qemu-system-x86-core-0:5.2.0-4.mga8 had to be
> removed due to conflicts.

I uploaded a new build of qemu in updates_testing (it fixes a few bugs about rebuilding as well as some CVE) rebuilt against the xen version in same updates_testing, so it should no longer be removed for conflicts.

CC: (none) => ghibomgx

(In reply to Giuseppe Ghibò from comment #13)
> (In reply to Dave Hodgins from comment #12)
> 
> > 
> > Note that during install, qemu-system-x86-core-0:5.2.0-4.mga8 had to be
> > removed due to conflicts.
> 
> I uploaded a new build of qemu in updates_testing (it fixes a few bugs about
> rebuilding as well as some CVE) rebuilt against the xen version in same
> updates_testing, so it should no longer be removed for conflicts.

From a test install with --debug ...
chosen lib64xen3.0-4.14.1-1.mga8.x86_64 for libxenctrl.so.4.14()(64bit)
the more recent lib64xen3.0-4.16.0-1.mga8.x86_64 is installed, but does not provide libxenctrl.so.4.14()(64bit) whereas lib64xen3.0-4.14.1-1.mga8.x86_64 does

After that ...
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release (distrib1)")
  lib64daxctl1                   68           2.mga8        x86_64  
  lib64fdt1                      1.5.1        3.mga8        x86_64  
  lib64mpathcmd0                 0.8.5        2.mga8        x86_64  
  lib64mpathpersist0             0.8.5        2.mga8        x86_64  
  lib64multipath0                0.8.5        2.mga8        x86_64  
  lib64virglrenderer1            0.8.2        1.20200212gi> x86_64  
  qemu-common                    5.2.0        4.mga8        x86_64  
  seabios-bin                    1.14.0       1.mga8        noarch

Should I downgrade xen first and then test again?

No, get xen from updates_testing too. The right qemu version is 5.2.0-4.1.mga8, it has just built, wait a couple of minutes as it propagates to mirrors.

FINALLY! YES!

xl create /etc/xen/x8xenhvm.cfg  -c -d -V
with the config file from comment 8 is now working, and I can access the
network from a live iso running in the guest (once I configure the dns servers).
Sound isn't working, but that's a config issue I'll sort out another time.

So qemu and xen are ready to validate, but virt-manager cannot be installed due
to ...
the more recent lib64xen3.0-4.16.0-1.mga8.x86_64 is installed, but does not provide libxenstore.so.3.0()(64bit) whereas lib64xen3.0-4.14.1-1.mga8.x86_64 does

So virt-manager will need a rebuild or update too.

gnome-boxes will need a rebuild or update too.

BTW, I noticed that xen in cauldron has more CVE updates (and also a newer release 4.16.1). E.g.: https://svnweb.mageia.org/packages/cauldron/xen/current/SPECS/xen.spec?revision=1770708&view=markup, https://svnweb.mageia.org/packages/cauldron/xen/current/SPECS/xen.spec?r1=1817555&r2=1846236 or 4.16.1 that includes them all.

Maybe worthwhile to use that patches too and rebuild xen too?

If the current version is still supported, I don't see a justification for
updating to a newer release. As this is a security update, it would be better
to get gnome-boxes and virt-manager fixed, and this update pushed.

(In reply to Dave Hodgins from comment #19)

> If the current version is still supported, I don't see a justification for
> updating to a newer release. As this is a security update, it would be better
> to get gnome-boxes and virt-manager fixed, and this update pushed.

Ok, I only cited, because the cauldron xen version (either 4.16.1 or 4.16.0+patches) has fixes also for CVE-2022-23033, CVE-2022-23034, CVE-2022-23035, XSA-398, CVE-2022-26357, CVE-2022-26358, CVE-2022-26359, CVE-2022-26360, CVE-2022-26361 that current xen version in mga8/updates_testing hasn't yet. Anyway we can proceed in two steps, completing the missed rebuilding first and then releasing another xen in a 2nd step in another bug.

Additional cve entries is justification for a new update.
https://xenproject.org/downloads/xen-project-archives/xen-project-4-16-series/xen-project-4-16-1/
looks like it's mostly bug fixes.

I'll leave it to you whether to add more patches to 4.16.0 or go with 4.16.1

OK, since with the patches or the 4.16.1 tarball was the exactly same, I uploaded xen-4.16.1-1.2.mga8 in mga8's updates_testing (I included also couple of fixes for python3 scripts, otherwise for instance the script "xencons" won't run). Such fixes needs also to be included in cauldron. Have to remind.

I rebuilt also libvirt and qemu again against this latest 4.16.1-1.2. 

As for gnome-boxes does it still needs to be rebuilt? Currently old gnome-boxes-3.38.2-2.mga8 seems downloading/installing without broken deps. Actually gnome-boxes has these buildrequires:

pkgconfig(libvirt-gobject-1.0)
pkgconfig(libvirt-gconfig-1.0)

which are provided by libvirt-glib. Does libvirt-glib to be rebuilt too?

gnome-boxes fails, though it's not clear why ...
$ grep libvirt gnome-boxes.log 
2020-10-06 01:33:11.796+0000: starting up libvirt version: 5.5.0, qemu version: 4.0.0qemu-4.0.0-2.mga7, kernel: 5.7.19-desktop-1.mga7, hostname: x3.hodgins.homeip.net
XDG_CACHE_HOME=/home/dave/.config/libvirt/qemu/lib/domain-1-boxes-unknown/.cache \
-object secret,id=masterKey0,format=raw,file=/home/dave/.config/libvirt/qemu/lib/domain-1-boxes-unknown/master-key.aes \
2020-10-06 01:38:45.158+0000: starting up libvirt version: 5.5.0, qemu version: 4.0.0qemu-4.0.0-2.mga7, kernel: 5.7.19-desktop-1.mga7, hostname: x3.hodgins.homeip.net
XDG_CACHE_HOME=/home/dave/.config/libvirt/qemu/lib/domain-2-boxes-unknown/.cache \
-object secret,id=masterKey0,format=raw,file=/home/dave/.config/libvirt/qemu/lib/domain-2-boxes-unknown/master-key.aes \
2020-10-06T01:42:21.197511Z qemu-system-x86_64: terminating on signal 15 from pid 30158 (/usr/sbin/libvirtd)

$ rpm -q gnome-boxes xen qemu
gnome-boxes-3.38.2-2.mga8
xen-4.16.1-1.2.mga8
qemu-5.2.0-4.2.mga8

There is a new rebuilt of gnome-boxes-3.38.2-2.1.mga8 as well as libvirt-glib-3.0.0-2.1.mga8; you might try with them too.

Does it work with gnome-boxes-3.38.2-2.1.mga8 ?

I tried gnome-boxes while booted under the xen hypervisor, which doesn't work.

Booting normally with the Mageia kernel, it fails to start a virtual machine
I created the last time I tested gnome boxes successfully.

Just now, I tried creating a new virtual machine (using Mageia kernel) and
it's working, so there's something it didn't like about my old machine.

Ready to kick myself. :-) Just realized the old machine was set to use
the Mageia 8 beta1 iso image, which no longer exists on my system. Wish the
messages generated when it fails made it clear instead of a hundred plus
lines in the trouble shooting log, with no clear indication it was file
not found.

I'll review the update and hopefully validate everything later today.

Have to go out for a while right now.

BTW are i586 or x86_64 the vms? As on just qemu with i586 (with latest kernel beyond 5.10.18), I get a behaviour opposite to yours with mga8, i.e. it won't boot. Backing back to 5.10.18 it boots. This happens also on any qemu version (not just the ones related to this update), including qemu 7 from cauldron.
 
I also noticed the timestamp saying "terminating on signal 15" from the log at comment #23 are from 2020. Were that ok?

Ignore comment #23. I was trying to run gnome-boxes while the host was running
under the hypervisor.

Current status. Running xen with Mageia-8-Live-Xfce-x86_64.iso works running
the iso in live mode. After installing that to the virtual hard disk, booting
into Mageia from the virtual hard disk stops with the last message displayed
being about the random number generator being initialized.

Running xen with Mageia-8-Live-Xfce-i586.iso works in live mode, but trying
to install to the virtual hard disk, the virtual machine terminates while
formatting the file system, with no messages.

I'll boot back to the regular Mageia kernel, and try gnome-boxes again.

With gnome boxes, I can run either iso in live mode, but I see no way to add
a virtual hard drive or connect it to the network. It boots and runs the live
iso with the delay while trying to start networking. With no network or hard
drive, it's very limited.

What is the status here?

I see qemu 5.2.0-4.2.mga8 is still sitting in Core Updates Testing

CC: (none) => fri

(In reply to Morgan Leijström from comment #30)
> What is the status here?
> 
> I see qemu 5.2.0-4.2.mga8 is still sitting in Core Updates Testing

AFAIK it wasn't working as expected in gnome-boxes. I pushed also a newer qemu-5.2.0-4.3.mga8 to fix further CVEs (i.e. CVE-2021-4206, CVE-2021-4207, CVE-2022-0358, CVE-2022-26354, CVE-2022-26353).

Maybe before retiring mga8 we can validate/push this, so to have a working final qemu-5 for mga8.

Yes this have been sitting for long.

Removing NEEDINFO as it is old, Comment 7.

Priority: Normal => High

removing feedback too for same reason.
Fresh start test and ship...

Keywords: NEEDINFO, feedback => (none)

Satus of this?

Need testing of the new packages mentioned in Comment 31
- But maybe now it would be wise to now have even newer versions,
I have not checked.

(In reply to Morgan Leijström from comment #36)

> Need testing of the new packages mentioned in Comment 31
> - But maybe now it would be wise to now have even newer versions,
> I have not checked.

AFAIK the qemu 5.2 includes all the fixes available around (also from Debian), a least last time I checked a month ago. For newer versions we would need to backport 7.2, and also update xen further, to mga8, which I doubt we would have all the libs required, and also beyond my timeframe.

I'm we should push what we have, if works, and an eventually open a new one bug # for newer CVEs.