As described in https://bugs.mageia.org/show_bug.cgi?id=26199#c8 my Mageia 7 i586 virtualbox is seeing corrupt versions of some files on the host. Comments in /usr/src/kernel-5.5.4-1.mga7/drivers/staging/vboxsf/dir.c indicate that vboxsf is only intended for use on 64 bit systems, and the problems are consistent with alignment failures in the 32 bit vb guest, as some files are fine while others are not. I'll try downgrading various things to see if I can identify when this problem was first introduced.
Assignee: bugsquad => kernel
I did a fresh install of Mageia 7.1 x86_64 on the host, with a new virtualbox guest on it running Mageia 7.1 i586. This is using release media only, no updates and the problem is not visible there. That's using kernel-desktop-5.1.14-1.mga7-1-1.mga7 on the host and kernel-desktop586-5.1.14-1.mga7-1-1.mga7 in the guest. I'll experiment with updates tomorrow.
Well, the vboxsf code is running on the host, so thats 64bit for you :) But looking on the kernel commit logs... Does it still work with: kernel-5.3.13-2.mga7 and break with: kernel-5.4.2-1.mga7 ?
CC: (none) => tmb
And what comment in dir.c did you refer to ?
(In reply to Thomas Backlund from comment #3) > And what comment in dir.c did you refer to ? If you mean this: /* * Note the vboxsf_dir_info objects we are iterating over here * are variable sized, so the info pointer may end up being * unaligned. This is how we get the data from the host. * Since vboxsf is only supported on x86 machines this is not * a problem. */ then that is not it as x86 means the base arch in the kernel, and that covers both ix86 and x86_64
Also, please try with virtualbox 6.0.18 in bug 26238 It has official upstream support for kernel 5.5 series
Hello together, after investigating two days I figured something very similar as reported in the bug. My setup: - Windows 10 (1909) Pro with Virtual Box 6.1.10 as host system - Mageia 7 i585 (32bit) within Virtual Box as guest I don't have dkms-virtualbox installed, because vboxsf is already provided by the kernel itself, as well as vboxguest and vboxvideo. Using kernel-desktop-5.2.* and kernel-desktop-5.3.* I can access without any problems shared directories from Windows 10 host. Actually I'm using kernel-desktop-5.3.11-1.mga7 Starting with kernel-desktop-5.4.* series files that are copied from guest to host are corrupted and locking into simple textfiles e.g. less /shared/folder/foo.txt is only presented after the hint "may be a binary file. See it anyway?". I observe the same behaviour with kernel-desktop-5.5.* and kernel-desktop-5.6.14-desktop-2.mga7 I also tried kernel-linus-5.6.14-1.mga7 yesterday. All kernels after 5.3 seems to have that problem. If I'm right vboxsf is released with VirtualBox Shared Folder Driver in place since Linux 5.4-rc7. But so far I didn't find any reports about problems like that in other distributions or on the LKML. I can trigger the problem by rebooting my virtual machine and switch from kernel-desktop-5.3.11-1.mga7 to kernel-desktop-5.6.14-desktop-2.mga7 and resolve it the other way round. I also tried to build 3rdparty modules using dkms-vboxadditions-6.0.20-1mga7 but the build process (dkms build -m vboxadditions -v 6.0.20-1.mga7 -k 5.6.14-desktop-2.mga7 -a i586 --no-clean-kernel) which is normally called from dkms_autoinstaller fails with code 10 when compiling vboxvideo module. I didn't had the time to figure that down.... To sum up: I can observe corrupted files using a kernel above 5.3.* as reported in this bug but my host is a windows and not a linux system. My workaround is so far using a kernel version 5.3 where everything is fine but of cause I'd like to nail this bug down in upper versions.
CC: (none) => s.puch
Has no one an idea what could be root of the cause? I'm still facing this problem with every kernel version greater kernel-desktop-5.3.* I just tried kernel-desktop-5.10.6 and kernel-linus-5.10.12 together with virtualbox-guest-addition-6.1.18
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja
Resolution: (none) => OLDStatus: NEW => RESOLVED
Finally fixed in virtualbox-6.1.34-1.5.mga8
...which is Bug 30507 - Update request: virtualbox-6.1.34-1.5.mga8
CC: (none) => fri
Note it's still in testing for now. Should be released as an update soon.
I must have done something wrong. Wanted to confirm it was the vb guest additions that fixed it and not the kernel (I'd installed both for testing), so reverted the snapshot and retested. Even with both installed, the problem is still there.
Version: 7 => 8Status: RESOLVED => REOPENEDResolution: OLD => (none)Source RPM: kernel-5.5.4-1.mga7.src.rpm => kernel-5.15.44-1.mga8.src.rpm
CC: (none) => pterjan
I have just tried with host from cauldron x86_64 and a Mageia 8 i586 guest and can confirm the problem. I am not sure where the content comes from, either memory or the guest filesystem. Data is cached but changes when remounting the shared folder. I once got something containing a command I had just typed in the guest so either from bash memory in the guest or possibly from the bash_history file in the guest too. I tried looking at the code but nothing obvious.
In the i586 guest, I also tried using VBoxGuestAdditions_6.1.34.iso instead of the rpm package for the additions, with identical results.
Tu be sure this is not a Mageia problem on the guest I tried a Debian i386 guest with Mageia x86_64 host and the result is slightly different but still broken, files contain only 0s. I however don't have any non Mageia machine to try a different host.
I did a search and found a similar report with x86_64 windows host, x86_64 linux guest is fine but i386 linux guest gets corrupted files https://forums.virtualbox.org/viewtopic.php?f=6&t=105367
I added some logging some more debugging, the content of the file is whatever is in the kernel buffer in the guest before doing a call to the host, size gets updated based on the number of bytes read but the content doesn't get written. So the data is random guest memory (at least it's not host memory...). Logs when reading a 4097 bytes files: [ 6975.339747] vboxsf_read: requested offset: 0 [ 6975.339846] vboxsf_read: requested buf_len: 4096 [ 6975.339945] hgcm_call_preprocess: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c5000, size = 4096) [ 6975.340141] 23 31 36 35 [ 6975.340316] hgcm_call_init_call: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c5000, size = 4096) [ 6975.340589] hgcm_call_copy_back_result: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (dst=0xfe4c5000, size = 4096) [ 6975.340776] vboxsf_read: err: 0 [ 6975.340859] vboxsf_read: buf_len: 4096 [ 6975.340965] vboxsf_read: 23 31 36 35 [ 6975.341143] vboxsf_read: requested offset: 4096 [ 6975.341244] vboxsf_read: requested buf_len: 4096 [ 6975.341343] hgcm_call_preprocess: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c6000, size = 4096) [ 6975.341528] 69 6e 73 6d [ 6975.341600] hgcm_call_init_call: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c6000, size = 4096) [ 6975.341840] hgcm_call_copy_back_result: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (dst=0xfe4c6000, size = 4096) [ 6975.342026] vboxsf_read: err: 0 [ 6975.342107] vboxsf_read: buf_len: 1 [ 6975.342191] vboxsf_read: 69 6e 73 6d
I also tried running VirtualBox provided binary and the bug is there too, it is not specific to Mageia as host or guest.
I came back to this bug and did a bit more debugging and looked at a dump of the guest memory. It seems the data is correctly the guest physical address given to the host, which is computed in hgcm_call_init_linaddr using: page = virt_to_page(buf); dst_pg_lst->pages[i] = page_to_phys(page); But this is not visible in buf. I have a large file full of the character '1' (0x31) that I read from the guest. $ hexdump ~/VirtualBox\ VMs/Shared/foo3.txt 0000000 3131 3131 3131 3131 3131 3131 3131 3131 * 1000000 Looking for it in the memory dump: 3e328010 0000 0000 0000 0000 0000 0000 0000 0000 * 3e329000 3131 3131 3131 3131 3131 3131 3131 3131 * 3e600000 0000 0000 0000 0000 0000 0000 0000 0000 From the guest logs: [ 9124.797579] hgcm_call_copy_back_result: page=0x3e4c9000 [ 9124.797639] hgcm_call_copy_back_result: page=0x3e4ca000 [ 9124.797693] hgcm_call_copy_back_result: page=0x3e4cb000 [ 9124.797761] hgcm_call_copy_back_result: page=0x3e4cc000 [ 9124.798023] hgcm_call_copy_back_result: page=0x3e4cd000 ... [ 9124.804713] hgcm_call_copy_back_result: page=0x3e526000 [ 9124.805033] hgcm_call_copy_back_result: page=0x3e527000 [ 9124.805091] hgcm_call_copy_back_result: page=0x3e528000 However from the same logs, the data is just random garbage in buf which is supposed to be at that address...
I'm just bit by this bug. Host : Mageia 8 64 bits Guest : Mageia cauldron 32 bits
Version: 8 => CauldronCC: (none) => yves.brungard_mageiaWhiteboard: (none) => MGA8TOO
I didn't find any upstream bug report in https://bugzilla.kernel.org
It's possible that there may be compatibility or configuration issues between the different architectures. If the VBoxSF file sharing continues to produce file corruption, consider using alternative methods for transferring files between the host and guest. This could include using network file-sharing protocols (e.g., Samba) or transferring files via shared network folders. https://bitlifeonline.com
CC: (none) => misalumix9x
I must have made a mistake. Reverting the snapshot and running new tests allowed us to validate that it was the vb guest additions and not the kernel that corrected it. The issue persists even with both installed. https://geometrydash-free.com
CC: (none) => lynchfiona736
CC: lynchfiona736 => (none)
How will your life unfold? In （https://bitlifemod.net/）BitLife Mod , you have unlimited possibilities! With unlimited money and the God Mode to control your destiny, enjoy every decision in life! Come and create your dream life now.
CC: (none) => xu1612248616
<a href="https://sprunkicorruptbox3.com/">sprunkicorruptbox3 is a game that is both creative and full of challenges. In this game, you’ll experience a unique puzzle-solving and adventure experience, with each level filled with stunning designs and details. The game uses clever puzzles and well-designed levels to let you enjoy the challenge while feeling a sense of accomplishment and fun
CC: misalumix9x, xu1612248616 => (none)
Do this problem still show on current mga9 or Cauldron? New VB now in testing repo Bug 33952 (plus new kernel building)
Still present in a new m9 vb install created using the xfce i586 iso. # cat /etc/release Mageia release 9 (Official) for i586 Shared the host's / mounted read-only on /mnt/host in the guest. Checked both before and after installing updates. # mount|grep /mnt ROOT on /mnt/host type vboxsf (rw,nodev,relatime) # cat /mnt/host/etc/fstab ������������������������������������������������������������������������������������������������������������������������������������������������������� On the x86_64 m9 host ... $ head -n 2 /etc/fstab # Entry for /dev/nvme1n1p8 : LABEL=x9t / ext4 defaults 1 1
On the host ... $ rpm -q virtualbox virtualbox-7.0.24-1.mga9
On the host ... $ uname -r 6.6.74-server-1.mga9 In the guest ... # uname -r 6.6.65-desktop586-2.mga9
Installed the kernel update in the guest and rebooted it. $ uname -r 6.6.74-desktop586-1.mga9 /mnt/host/etc/fstab still corrupted, though it's now showing text from the middle of some other file rather then unprintable characters. [root@localhost ~]# cat /mnt/host/etc/fstab 5:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.divx=01;35:*.xvid=01;35:*.3gp=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.gem=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*.mp2=00;36:*.mod=00;36:*.xm=00;36:*[root@localhost ~]#
Looks like it used the correct length (606 bytes) for the file, but picked the wrong block on the host file system for the contents. Looks like it came from the middle of the host file /var/spool/at/ae27e001b95c74.
Thank you Dave. CC Maintainer as Kernel mail list is defunct.
CC: tmb => ghibomgxSource RPM: kernel-5.15.44-1.mga8.src.rpm => 6.6.74-server-1.mga9.src.rpmWhiteboard: MGA8TOO => MGA9TOO
Source RPM: 6.6.74-server-1.mga9.src.rpm => kernel-6.6.74-1.mga9.src.rpm
Did you find something similar in the upstream bug tracker, e.g.: https://forum.virtualbox.org/query?status=new&status=assigned&status=reopened&desc=1&order=id maybe https://forum.virtualbox.org/ticket/22277 ?
https://sprunksters.io/ Sprunki Sprunksters is an interactive music creation game based on Incredibox, allowing players to mix and create unique music by dragging and dropping different animated characters.
CC: (none) => sjr482015
https://bitlifemod.net/ BitLife Mod BitLife is a free online life simulation game where you control your destiny and start your life anew, immersing you in a vivid virtual world of new experiences.
https://sprunksters.io/games/sprunki_1996 sprunki 1996 is an interactive music creation game based on "Incredibox," allowing players to create personalized music by dragging and dropping different characters and sound effects.
CC: sjr482015 => (none)
sprunki incredibox is a revolutionary collection of add-ons designed to elevate the Sprunki experience. Each phase introduces a unique blend of immersive themes, dynamic soundscapes, and captivating visuals, offering endless opportunities for creativity and customization. https://sprunkin.com/
CC: (none) => divyaverma6963
CC: divyaverma6963 => (none)
thx CC: zoe@tikshots.com => (none) _______________________________________________ my site:https://allfreenovel.cc/
CC: (none) => zoe
CC: zoe => (none)
https://thornandballoons.net/games/donut-box
CC: (none) => 244678184
CC: 244678184 => (none)
Very good article<a href="https://hungergamessimulator.games/">,</a> I benefited a lot from it<a href="https://blockblastgames.net/">.</a>
CC: (none) => suowu97
CC: suowu97 => (none)
I really appreciate the insights you've shared in this article. It's refreshing to see such thoughtful analysis on gaming experiences. Lately, I've been exploring games with unique cooperative elements, and I recently stumbled upon R.E.P.O. Game, which offers a fascinating physics-based co-op experience. You can check it out here: https://repogame.org/
CC: (none) => tocij30222
CC: tocij30222 => (none)
This assessment accurately pinpoints the technical nature of the VirtualBox bug report and highlights the importance of detailed tracking for file corruption issues. Developers often participate in similar bug reporting systems, understanding that thorough documentation of system-specific problems (like those affecting i586 guests) significantly improves resolution timeframes and helps prioritize fixes based on user impact. https://www.chillguyclicker.us/
CC: (none) => rasafreelancer
CC: rasafreelancer => (none)