on mga7-64  kernel-desktop-5.4.17  plasma

packages installed cleanly:
- dkms-virtualbox-6.0.16-2.mga7.noarch
- virtualbox-6.0.16-2.mga7.x86_64
- virtualbox-kernel-5.4.17-desktop-1.mga7-6.0.16-4.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.0.16-4.mga7.x86_64

# dkms status
virtualbox, 6.0.16-2.mga7, 5.4.17-desktop-1.mga7, x86_64: installed 
virtualbox, 6.0.16-2.mga7, 5.4.17-desktop-1.mga7, x86_64: installed-binary from 5.4.17-desktop-1.mga7

vbox and client launched normally
 
updated additions in mga7-32 client running plasma on kernel-desktop586-5.4.17
 
No regressions observed. 
looks OK for mga7-64 on this system with 5.4 kernels:

Desktop System: Dell product: Precision Tower 3620
Quad Core model: Intel Core i7-6700
Intel HD Graphics 530

CC: (none) => jim

MGA7-64-kernel-desktop 5.4.17 Plasma

Packages installed cleanly. I do not use dkms, so have to rely on the pre-nuilt kmods.

Ran VirtualBox, and started a MGA-7-64 guest, and updated guest additions in that. Shared folders and clipboard work as designed.

No regressions noted. Looks OK here.

Almost forgot- hardware is an i5-2500, 16GB RAM, integrated graphics, wired Internet connection. MGA7 guest, and all guests for that matter, reside on an ssd to take advantage of the speed over the rust drive.

CC: (none) => andrewsfarm

Created attachment 11509 [details]
During upgrade: "write error: Broken pipe"

Machine "svarten": Mainboard: Sabertooth P67, CPU: i7-3770, RAM 16G, Nvidia GTX760 (GK104)

While using kernel-linus 5.4.20-1; updating:

  dkms-virtualbox-6.0.16-2.mga7.noarch.rpm
  virtualbox-6.0.16-2.mga7.x86_64.rpm
  virtualbox-kernel-5.4.17-desktop-1.mga7-6.0.16-4.mga7.x86_64.rpm
  virtualbox-kernel-desktop-latest-6.0.16-4.mga7.x86_64.rpm


In the terminal i notice:

vboxpci.ko.xz:
 - Uninstallation
   - Deleting from: /lib/modules/5.4.17-desktop-1.mga7/dkms-binary/3rdparty/vbox/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.
/usr/sbin/dkms: rad 2006: echo: skrivfel: Brutet rör
/usr/sbin/dkms: rad 2006: echo: skrivfel: Brutet rör
/usr/sbin/dkms: rad 2006: echo: skrivfel: Brutet rör
/usr/sbin/dkms: rad 1861: echo: skrivfel: Brutet rör

Swedish("skrivfel: Brutet rör") = write error: Broken pipe

-now rebooting to try anyway, then desktop kernels

CC: (none) => fri

OK using kernel-linus 5.4.20-1 and nouveau driver, existing MSW7 64bit client.

Virtualbox reports it is version 6.0.16 r135674
OK: USB2 support (i have installed extpack since earlier version), host folder sharing, shared ethernet, sound.

OK 64 bit (forgot to say also commment #4 was 64 bit) using kernel-5.4.17-desktop-1.mga7, CPU: i7-3770, nvidia-current 430.64, GTX 760 (GK104)

VirtualBox running MSW7 client with bidirectional clipboard, host folder sharing, USB2 flash stick and internet working, with video with sound in firefox while BOINC on host chewing on using all cores.

x86_64, linus kernel 5.4.20-1.mga7

Updated virtualbox.
Installed maga7.1 guest, updated it and installed the 5.5.4 desktop kernel.
Running OK.  Not yet tried adding the extpack yet.

CC: (none) => tarazed25

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

https://advisories.mageia.org/MGAA-2020-0056.html

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

Just noticed a problem with shared folders corrupting files

Using a virtualbox shared folder, allowing the guests to access / on the host
[root@i7v ~]# head -n 1 /ROOT/etc/profile.d/zlocal.sh 
hv�     �G�      ��������������������

Accessing the same file on the host using an nfs mount ...
[root@i7v ~]# head -n 1 /mnt/profile.d/zlocal.sh 
#!/bin/sh

The strangest part is that not all files are corrupted. For example ...
[root@i7v profile.d]# head -n 1  /ROOT/etc/profile.d/10inputrc.csh 
See the
[root@i7v profile.d]# head -n 1 /ROOT/etc/profile.d/10mageia-release.csh
���     QX��    HV�     �

I have not been able to determine why some files are being corrupted and others
not.

# ll /ROOT/etc/profile.d/10*
-rwxrwx--- 1 root vboxsf 708 Feb 15  2019 /ROOT/etc/profile.d/10inputrc.csh*
-rwxrwx--- 1 root vboxsf 209 Jul 11  2019 /ROOT/etc/profile.d/10mageia-release.csh*
-rwxrwx--- 1 root vboxsf 117 Jul 11  2019 /ROOT/etc/profile.d/10mageia-release.sh*

In the guest ...
# rpm -qa|grep virtualbox
virtualbox-guest-additions-6.0.16-2.mga7

# rpm -qa|grep virtualbox|sort -V
dkms-virtualbox-6.0.16-2.mga7
virtualbox-6.0.16-2.mga7
virtualbox-kernel-5.4.17-desktop-1.mga7-6.0.16-4.mga7
virtualbox-kernel-5.5.4-desktop-1.mga7-6.0.16-5.mga7
virtualbox-kernel-desktop-latest-6.0.16-5.mga7


-rwxrwx--- 1 root vboxsf 581 Feb 15  2019 /ROOT/etc/profile.d/10tmpdir.csh*
-rwxrwx--- 1 root vboxsf 598 Feb 15  2019 /ROOT/etc/profile.d/10tmpdir.sh*

Ok to reopen this bug or would you prefer a new bug report.

Resolution: FIXED => (none)
Status: RESOLVED => REOPENED
CC: (none) => davidwhodgins

In your test the guest is reading the file end get errors?
Is it the same when it is not sharing /, but i.e /home/someuser/Documents ?

FWIW, I used a shared folder with a Windows XP guest this afternoon, with no ill effects. The shared folder is on /home/someuser, and someuser is running vbox. 

I've never tried sharing root-owned folders. I just assumed it wasn't allowed.

I changed the guest settings to use /etc/profile.d/ instead of /, and the
problem remains unchanged.

Also note that this problem is only showing up in my Mageia 7 i586 guest
install, and does not show up in my x86_64 guest, so it's most likely something
in the i586 version of the vboxsf module.

I do have the correct version of the extension pack installed on the Mageia 7
x86_64 host.

(In reply to Thomas Andrews from comment #10)
> I've never tried sharing root-owned folders. I just assumed it wasn't
> allowed.

Any directory readable by the user running virtualbox can be shared. Even if
read only is unchecked, the hosts permissions still control what can be written.

I somehow doubt this update broke that as the only thing changed was the drm interface against the kernel, nothing regarding vboxsf

the vboxsf we have as standard is part of the kernel...

Anyway, do open a new bugreport about this, and info about what kernel the host is running, and also if downgrading the vbox packages part of this update actually fixes the issue.

Closing this again as the update is already pushed.

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

https://bugs.mageia.org/show_bug.cgi?id=26214 opened for the i586 vboxsf
corruption problem.