and Mga7 rpms:

SRPMS:
kernel-5.10.20-2.mga7.src.rpm
kmod-virtualbox-6.1.18-8.mga7.src.rpm
kmod-xtables-addons-3.13-14.mga7.src.rpm



i586:
bpftool-5.10.20-2.mga7.i586.rpm
cpupower-5.10.20-2.mga7.i586.rpm
cpupower-devel-5.10.20-2.mga7.i586.rpm
kernel-desktop-5.10.20-2.mga7-1-1.mga7.i586.rpm
kernel-desktop586-5.10.20-2.mga7-1-1.mga7.i586.rpm
kernel-desktop586-devel-5.10.20-2.mga7-1-1.mga7.i586.rpm
kernel-desktop586-devel-latest-5.10.20-2.mga7.i586.rpm
kernel-desktop586-latest-5.10.20-2.mga7.i586.rpm
kernel-desktop-devel-5.10.20-2.mga7-1-1.mga7.i586.rpm
kernel-desktop-devel-latest-5.10.20-2.mga7.i586.rpm
kernel-desktop-latest-5.10.20-2.mga7.i586.rpm
kernel-doc-5.10.20-2.mga7.noarch.rpm
kernel-server-5.10.20-2.mga7-1-1.mga7.i586.rpm
kernel-server-devel-5.10.20-2.mga7-1-1.mga7.i586.rpm
kernel-server-devel-latest-5.10.20-2.mga7.i586.rpm
kernel-server-latest-5.10.20-2.mga7.i586.rpm
kernel-source-5.10.20-2.mga7-1-1.mga7.noarch.rpm
kernel-source-latest-5.10.20-2.mga7.noarch.rpm
kernel-userspace-headers-5.10.20-2.mga7.i586.rpm
libbpf0-5.10.20-2.mga7.i586.rpm
libbpf-devel-5.10.20-2.mga7.i586.rpm
perf-5.10.20-2.mga7.i586.rpm

xtables-addons-kernel-5.10.20-desktop-2.mga7-3.13-14.mga7.i586.rpm
xtables-addons-kernel-5.10.20-desktop586-2.mga7-3.13-14.mga7.i586.rpm
xtables-addons-kernel-5.10.20-server-2.mga7-3.13-14.mga7.i586.rpm
xtables-addons-kernel-desktop586-latest-3.13-14.mga7.i586.rpm
xtables-addons-kernel-desktop-latest-3.13-14.mga7.i586.rpm
xtables-addons-kernel-server-latest-3.13-14.mga7.i586.rpm



x86_64:
bpftool-5.10.20-2.mga7.x86_64.rpm
cpupower-5.10.20-2.mga7.x86_64.rpm
cpupower-devel-5.10.20-2.mga7.x86_64.rpm
kernel-desktop-5.10.20-2.mga7-1-1.mga7.x86_64.rpm
kernel-desktop-devel-5.10.20-2.mga7-1-1.mga7.x86_64.rpm
kernel-desktop-devel-latest-5.10.20-2.mga7.x86_64.rpm
kernel-desktop-latest-5.10.20-2.mga7.x86_64.rpm
kernel-doc-5.10.20-2.mga7.noarch.rpm
kernel-server-5.10.20-2.mga7-1-1.mga7.x86_64.rpm
kernel-server-devel-5.10.20-2.mga7-1-1.mga7.x86_64.rpm
kernel-server-devel-latest-5.10.20-2.mga7.x86_64.rpm
kernel-server-latest-5.10.20-2.mga7.x86_64.rpm
kernel-source-5.10.20-2.mga7-1-1.mga7.noarch.rpm
kernel-source-latest-5.10.20-2.mga7.noarch.rpm
kernel-userspace-headers-5.10.20-2.mga7.x86_64.rpm
lib64bpf0-5.10.20-2.mga7.x86_64.rpm
lib64bpf-devel-5.10.20-2.mga7.x86_64.rpm
perf-5.10.20-2.mga7.x86_64.rpm

virtualbox-kernel-5.10.20-desktop-2.mga7-6.1.18-8.mga7.x86_64.rpm
virtualbox-kernel-5.10.20-server-2.mga7-6.1.18-8.mga7.x86_64.rpm
virtualbox-kernel-desktop-latest-6.1.18-8.mga7.x86_64.rpm
virtualbox-kernel-server-latest-6.1.18-8.mga7.x86_64.rpm

xtables-addons-kernel-5.10.20-desktop-2.mga7-3.13-14.mga7.x86_64.rpm
xtables-addons-kernel-5.10.20-server-2.mga7-3.13-14.mga7.x86_64.rpm
xtables-addons-kernel-desktop-latest-3.13-14.mga7.x86_64.rpm
xtables-addons-kernel-server-latest-3.13-14.mga7.x86_64.rpm

Whiteboard: (none) => MGA7TOO
Summary: Update request: kernel-5.10.20-2.mga8 => Update request: kernel-5.10.20-2.mga8/7

Advisory, added to svn:

type: security
subject: Updated kernel packages fix security issues and possible filesystem corruption
CVE:
 - CVE-2021-28038
 - CVE-2021-28039
src:
  8:
   core:
     - kernel-5.10.20-2.mga8
     - kmod-virtualbox-6.1.18-18.mga8
     - kmod-xtables-addons-3.13-34.mga8
  7:
   core:
     - kernel-5.10.20-2.mga7
     - kmod-virtualbox-6.1.18-8.mga7
     - kmod-xtables-addons-3.13-14.mga7
description: |
  This kernel update is based on upstream 5.10.20 and fixes atleast the
  following security issues:

  An issue was discovered in the Linux kernel through 5.11.3, as used with
  Xen PV. A certain part of the netback driver lacks necessary treatment of
  errors such as failed memory allocations (as a result of changes to the
  handling of grant mapping errors). A host OS denial of service may occur
  during misbehavior of a networking frontend driver. NOTE: this issue
  exists because of an incomplete fix for CVE-2021-26931.
  (CVE-2021-28038 / XSA-367)

  An issue was discovered in the Linux kernel 5.9.x through 5.11.3, as used
  with Xen. In some less-common configurations, an x86 PV guest OS user can
  crash a Dom0 or driver domain via a large amount of I/O activity. The
  issue relates to misuse of guest physical addresses when a configuration
  has CONFIG_XEN_UNPOPULATED_ALLOC but not CONFIG_XEN_BALLOON_MEMORY_HOTPLUG.
  (CVE-2021-28039 / XSA-369)

  It also adds a critical fix for filesystem level corruption:
  - on setups with swapfiles on filesystems sitting on top of brd, zram,
    btt or pmem, then when the system starts to swap out pages, at which
    point it corrupts filesystem blocks that don't belong to the swapfile.

  It also adds the following fixes:
  - Input: elan_i2c - add new trackpoint report type 0x5F
  - Input: elantech - fix protocol errors for some trackpoints
  - net: usb: qmi_wwan: support ZTE P685M modem
  - tty: fix up iterate_tty_read() EOVERFLOW handling
  - tty: fix up hung_up_tty_read() conversion
  - tty: clean up legacy leftovers from n_tty line discipline
  - tty: teach n_tty line discipline about the new "cookie continuations"
  - tty: teach the n_tty ICANON case about the new "cookie continuations" too
  - x86_64-server config:
    * enable NUMA balancing
    * make CONNECTOR builtin to enable PROC_EVENTS (mga#28312)
    * support 512 cores/threads

  For other upstream fixes, see the referenced changelogs.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=28541
 - https://bugs.mageia.org/show_bug.cgi?id=28312
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.20
 - https://xenbits.xen.org/xsa/advisory-367.html
 - https://xenbits.xen.org/xsa/advisory-369.html

Keywords: (none) => advisory

this one is also pushed to cauldron for wider test-base

(In reply to Thomas Backlund from comment #0)
> There is however a bugfix for filesystem corruption if one use swapfiles on
> certain filesystems (instead of the default usage of swap partitions)

As I am writing on using swapfiles on live[1], can you tell what filesystems are affected on our release time kernel?

Lives running encrypted persistence can only boot original kernel.

[1] https://wiki.mageia.org/en/User:Morgano/Persistent_live_systems#Swap_file_in_persistent_partition

CC: (none) => fri

(In reply to Morgan Leijström from comment #4)
> (In reply to Thomas Backlund from comment #0)
> > There is however a bugfix for filesystem corruption if one use swapfiles on
> > certain filesystems (instead of the default usage of swap partitions)
> 
> As I am writing on using swapfiles on live[1], can you tell what filesystems
> are affected on our release time kernel?
> 

as per the advisory:
so far identified filesystems are: "on filesystems sitting on top of brd, zram, btt or pmem" so I hope there are not more, but time will tell...

the fallout on 5.12-rc1 is way worse, as there it can hit basically any filesystem on any type of device ...

mga7 64 bit OK on My workstation "svarten": Mainboard: Sabertooth P67, CPU: i7-3770, RAM 16G, GM107 [GeForce GTX 750] using nvidia-current; GeForce 635 series and later, 4k display.

Updated to:
- kernel-desktop-5.10.20-2.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-5.10.20-2.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-latest-5.10.20-2.mga7.x86_64
- kernel-desktop-latest-5.10.20-2.mga7.x86_64
- kernel-userspace-headers-5.10.20-2.mga7.x86_64
- virtualbox-kernel-5.10.20-desktop-2.mga7-6.1.18-8.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.1.18-8.mga7.x86_64

rebooted, $ sudo dkms status tells nvidia-current and virtualbox are OK

Disk&Filesystem: SSD with /boot/EFI and ext4 /boot, LUKS{LVM {swap, ext4 /home & / } and a spinner at /mnt/somewhere

Plasma desktop, using Thunderbird, LibreOffice, Ktorrent, Nextcloud client...
Video with sound in Firefox
CUDA and OpenCL detected
Stress test: While working with other things BOINC use all cores to 100%, videos do not stutter.

Also virtualbox 6.1.18 OK running MSW7 64 bit guest incl folder sharing (tested both readonly and rw), USB memory, bidirectional clipboard, dynamic guest window resizing. All as usual, need to free 1 or 2 cores from BOINC to avoid video stutter in guest Firefox, playing video with sound from internet svtplay.se, urplay.se, youtube, ..

mga 8 x86_64 Plasma. Main desktop is running 5.10.20-2.mga8 desktop flavour nicely.

Updated from 5.10.19.
Hardware is Core i5 6600K on a Gigabyte Z170, 16G DDR4 Ram, Nvidia Geforce GTX 1660 Ti governing two 27" displays. Drivers are nvidia-current 460.56.

Plasma desktop, using KMail, LibreOffice, VLC.
Firefox OK.
CUDA and OpenCL detected
Stress test: Do an encodage in Handbrake in h264 from an 120 min AVI video, took one hour and several minutes as usual. Desktop still responsive.

No regression.

DKMS OK for nvidia and virtualbox.
Virtualbox clients OK, and updated 4 Mageia 8 VM.

Give a MGA8-64-OK.

Since this is a security BR, give also a MGA7-64-OK per Morgan's above test.

Whiteboard: MGA7TOO => MGA7TOO MGA7-64-OK MGA8-64-OK
CC: (none) => ouaurelien

Will test the 32-bit desktop kernels (not desktop586) with Foolishness, but it may take some time as both installs need many updates first.

CC: (none) => andrewsfarm

No regressions noted here.

Three real hardware systems, two running m7 x86_64 and one m8 x86_64 and one
m8 x86_64 system. All running the desktop kernel.

On one m7 host, 4 vb guests. x86 and i586 installs for both m7 and m8.
All running desktop kernel except m8 i586 install which I chose the desktop586
kernel.

Sound and networking tested on all except the one m7 host which has no
speakers connected. That's the one I use just for konversation.

CC: (none) => davidwhodgins

Oh, and the m8 real hardware install has an m7 x86_64 guest where networking
and sound also work after updating the kernel on both.

For those who are scratching their heads over Comment 8, Foolishness is my aged Dell Inspiron 5100 laptop. Rescued from a church sale, it has a 32-bit P4 processor, Radeon Mobility 7500 (RV200) graphics, all of 2GB of RAM, and an old Atheros-based wifi card. I have spent far more on it than it's worth to bring it back into service, hence the name.

I have two 32-bit installs on this machine, one MGA8 and the other MGA7. Both are Xfce systems, running the desktop kernel. Both systems updated the kernel packages cleanly. 

While the ancient Radeon graphics have given us trouble with modern kernels in the past, there are no issues to report with either system this time. Both systems rebooted cleanly, with good video and sound. I visited various sites with Firefox, including playing a video on Youtube, and both worked well within the limitations imposed by the slow hardware. 

If anything, Mageia 8 played videos better than Mageia 7 on this hardware. 

Looks OK here.

Kernel: 5.10.20-desktop-2.mga8 x86_64
Quad Core Intel Core i7-4790
NVIDIA GM204 [GeForce GTX 970] driver: nvidia v: 460.56

No problems so far.  Too late for any more testing tonight.  mga7 in the morning.

CC: (none) => tarazed25

MGA8
A6 laptop - R4 graphics

$ uname -a
Linux localhost 5.10.20-desktop-2.mga8 #1 SMP Fri Mar 5 18:23:13 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux


- browser working
- sleep mode works
- sounds works


works for me - 1st test.

CC: (none) => brtians1

MGA8
Nvidia 390, AMD X3

# lsmod | grep nvidia
nvidia_uvm            925696  0
nvidia_drm             53248  1
drm_kms_helper        270336  1 nvidia_drm
nvidia_modeset       1056768  5 nvidia_drm
nvidia              15831040  181 nvidia_uvm,nvidia_modeset
ipmi_msghandler        69632  2 ipmi_devintf,nvidia
drm                   606208  4 drm_kms_helper,nvidia_drm
[root@localhost xxxx]# uname -a
Linux localhost 5.10.20-desktop-2.mga8 #1 SMP Fri Mar 5 18:23:13 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost xxxx]# 

System is working fine.

(In reply to Thomas Andrews from comment #11)
> I have two 32-bit installs on this machine, one MGA8 and the other MGA7.
> Both are Xfce systems, running the desktop kernel. Both systems updated the
> kernel packages cleanly. 

If "zgrep ^CONFIG_HZ /proc/config.gz" shows CONFIG_HZ_1000=y, those installs
may benefit from adding the boot parameter divider=10 as per bug 44

MGA7 - gnome
Nvidia 390 graphics



# lsmod | grep nvidia
nvidia_drm             53248  2
nvidia_modeset       1056768  13 nvidia_drm
nvidia              15831040  529 nvidia_modeset
ipmi_msghandler        69632  2 ipmi_devintf,nvidia
drm_kms_helper        262144  1 nvidia_drm
drm                   593920  6 drm_kms_helper,nvidia_drm,ttm
[root@linux xxxxx]# uname -a
Linux linux.local 5.10.20-desktop-2.mga7 #1 SMP Fri Mar 5 20:47:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

MGA7  - Mate - i586

The following 3 packages are going to be installed:

- cpupower-5.10.20-2.mga7.i586
- kernel-server-5.10.20-2.mga7-1-1.mga7.i586
- kernel-server-latest-5.10.20-2.mga7.i586


--- rebooted



$ uname -a
Linux localhost 5.10.20-server-2.mga7 #1 SMP Fri Mar 5 22:04:02 UTC 2021 i686 i686 i386 GNU/Linux


- Nextcloud working
- samba file shares are working
- screen looks fine (this uses nouveau)

(In reply to Dave Hodgins from comment #15)
> (In reply to Thomas Andrews from comment #11)
> > I have two 32-bit installs on this machine, one MGA8 and the other MGA7.
> > Both are Xfce systems, running the desktop kernel. Both systems updated the
> > kernel packages cleanly. 
> 
> If "zgrep ^CONFIG_HZ /proc/config.gz" shows CONFIG_HZ_1000=y, those installs
> may benefit from adding the boot parameter divider=10 as per bug 44

It's possible, but I have my doubts. As I misunderstand it, that parameter is supposed to reduce the load on the cpu. But I don't think the bottleneck on this particular hardware is the P4, but more likely the old-style I/O interfaces. 

The graphics card uses an AGP interface for one thing, but even more likely is the hard drive, which uses PATA. I did notice a very significant boost in performance when I replaced the old rust drive with a PATA-to-MSATA adapter with an SSD, but still, that is a PATA interface and therefore limited.

(In reply to Thomas Andrews from comment #18)
> It's possible, but I have my doubts. As I misunderstand it, that parameter
> is supposed to reduce the load on the cpu. But I don't think the bottleneck
> on this particular hardware is the P4, but more likely the old-style I/O
> interfaces. 

I highly recommend trying it and comparing "journalctl -b|grep \(userspace"
with and without the divider=10 kernel option. On the system I had when I
opened bug 44 the difference was that without the option, mkinitrd failed
due to a hard coded 10 minute timeout and with the option it was under the
10 minute mark.

Kernel: 5.10.20-desktop-2.mga7 x86_64
Quad Core Intel Core i7-4790
NVIDIA GM204 [GeForce GTX 970] driver: nvidia v: 460.56

That rebooted fine with the nouveau graphics driver.  Had forgotten that this system had been left with kernel-linus installed.  Ran drakx11 to change the driver and rebooted with nvidia.

Everything running as well as ever.  NFS shares mounted.  Stress tests work.
Thunderbird OK with selected profile.

MGA8 XFCE desktop

after reboot no regression tested with VLC, Thundeirbird and Firefox. Copy file from or to USB ok

System updated from 5.10.19 with:

bpftool-5.10.20-2.mga8.x86_64.rpm
cpupower-5.10.20-2.mga8.x86_64.rpm
cpupower-devel-5.10.20-2.mga8.x86_64.rpm
kernel-desktop-5.10.20-2.mga8-1-1.mga8.x86_64.rpm
kernel-desktop-devel-5.10.20-2.mga8-1-1.mga8.x86_64.rpm
kernel-desktop-devel-latest-5.10.20-2.mga8.x86_64.rpm
kernel-desktop-latest-5.10.20-2.mga8.x86_64.rpm
lib64bpf-devel-5.10.20-2.mga8.x86_64.rpm
lib64bpf0-5.10.20-2.mga8.x86_64.rpm
perf-5.10.20-2.mga8.x86_64.rpm
virtualbox-kernel-5.10.20-desktop-2.mga8-6.1.18-18.mga8.x86_64.rpm
virtualbox-kernel-desktop-latest-6.1.18-18.mga8.x86_64.rpm

Hardware setting:
Core i3 4Go RAM, Nvidia Geforce GT 520M driver 390, BCM4313 802.11bgn Wireless Network Adapter driver non free.

--------------------------------------------------------------------------------
MGA7 VM Gnome 2Go Ram

System updated from 5.10.19 with:

cpupower-5.10.20-2.mga7.x86_64.rpm
cpupower-devel-5.10.20-2.mga7.x86_64.rpm
kernel-desktop-5.10.20-2.mga7-1-1.mga7.x86_64.rpm
kernel-desktop-devel-5.10.20-2.mga7-1-1.mga7.x86_64.rpm
kernel-desktop-devel-latest-5.10.20-2.mga7.x86_64.rpm
kernel-desktop-latest-5.10.20-2.mga7.x86_64.rpm
kernel-userspace-headers-5.10.20-2.mga7.x86_64.rpm
lib64bpf-devel-5.10.20-2.mga7.x86_64.rpm
lib64bpf0-5.10.20-2.mga7.x86_64.rpm
perf-5.10.20-2.mga7.x86_64.rpm

No regression, tested with vlc and firefox

CC: (none) => guillaume.royer

MGA7-64 MATE on Peaq C1011
No installation issues.
After reboot the Wifi connection problem seems to be back. I will reboot in previous kernel to make sure there is no HW problem.

CC: (none) => herman.viaene

Wifi perfectly OK with kernel 5.10.19 (typing from it).

MGA8-64 MATE on Peaq C1011
No installation issues.
Rebooting, this new version is nowhere to see in grub menu, so booted again in 5.10.19. Will try to reconfig the boot system in MCC.

Kernel: 5.10.19-desktop-1.mga8 x86_64
Mobo: ASUSTeK model: TUF X299 MARK 2
10-Core Intel Core i9-7900X [MT MCP]
GeForce GTX 1080 Ti/PCIe/SSE2 v: 4.6.0 NVIDIA 460.56

Updated to latest desktop kernel and ran
# drakboot --boot

No problems at reboot.  Desktop appeared, running with nvidia graphics driver.
$ uname -r
5.10.20-desktop-2.mga8

$ stress -c 7 -t 30
stress: info: [3705] dispatching hogs: 7 cpu, 0 io, 0 vm, 0 hdd
stress: info: [3705] successful run completed in 30s

Ran other stress tests.

Installed glmark2.
$ glmark2 -b refract
Perfect.  NFS shares mounted.
LO writer, stellarium, thunderbird work fine.
Everything looks good so far.

In MCC choose explicitely kernel5.10.20 as boot default, let it write the boot system.
Reboot: as usual on this system after reconfiguring boot system from M8, there is no grub menu shown and the system boots directly into the M7.
Run MCC in M7 to reconfigure the bootsystem and in choosing the default, I noticed that the 5.10.20 was listed twice, once without indication of the disk partition, one with the partition. Made sure to select the correct one, and rebooted. Now the system boots directly into the M8 5.10.20 kernel and wifi can be configured OK.

(In reply to Herman Viaene from comment #26)
> In MCC choose explicitely kernel5.10.20 as boot default, let it write the
> boot system.
> Reboot: as usual on this system after reconfiguring boot system from M8,
> there is no grub menu shown and the system boots directly into the M7.
> Run MCC in M7 to reconfigure the bootsystem and in choosing the default, I
> noticed that the 5.10.20 was listed twice, once without indication of the
> disk partition, one with the partition. Made sure to select the correct one,
> and rebooted. Now the system boots directly into the M8 5.10.20 kernel and
> wifi can be configured OK.

On such system, you should use refind instead of Grub2. I do think there is an error as Mageia 7 AND Mageia 8 identify themselves as "Mageia" to the EFI firmware. Scripts in one version wants to take the lead on the boot process.

On real hardware, M7.1, Plasma, 64-bit

Packages checked:

kernel-desktop-latest virtualbox
virtualbox-guest-additions virtualbox-kernel-desktop-latest
x11-driver-video-vboxvideo kernel-desktop-devel-latest
cpupower dkms-vboxadditions dkms-virtualbox
        
M7.1 x86_64 Vbox Plasma Client, boots to a working desktop - Screen size correct
M8   x86_64 Vbox Plasma Client, boots to a working desktop - Screen size correct

install from update_testing:

kernel-desktop-latest
virtualbox-guest-additions virtualbox-kernel-desktop-latest
x11-driver-video-vboxvideo kernel-desktop-devel-latest cpupower
The following 7 packages are going to be installed:

- cpupower-5.10.20-2.mga7.x86_64
- kernel-desktop-5.10.20-2.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-5.10.20-2.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-latest-5.10.20-2.mga7.x86_64
- kernel-desktop-latest-5.10.20-2.mga7.x86_64
- virtualbox-kernel-5.10.20-desktop-2.mga7-6.1.18-8.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.1.18-8.mga7.x86_64

Boots to working desktop
M7.1 x86_64 Vbox Plasma Client, boots to a working desktop - Screen size correct
M8   x86_64 Vbox Plasma Client, boots to a working desktop - Screen size correct

CC: (none) => wilcal.int

thanks for the tests, flushing out

Keywords: (none) => validated_update
Whiteboard: MGA7TOO MGA7-64-OK MGA8-64-OK => MGA7TOO, MGA7-64-OK, MGA7-32-OK, MGA8-64-OK, MGA8-32-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0117.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

@ Aurelien Comment 27
rEFInd does not work on this machine since it has a 32-bit UEFI bios, but the installation is x86-64. i586 does not work on it because of graphics issues.

(In reply to Herman Viaene from comment #31)
> @ Aurelien Comment 27
> rEFInd does not work on this machine since it has a 32-bit UEFI bios, but
> the installation is x86-64. i586 does not work on it because of graphics
> issues.

Oh! you're right. Sorry.