@susejunky project configuration and all the compile flags used in the various macros is always the likely issue. When compiling locally, you have to explicitly add…
Considering the fact, that the locally build works and the OBS doesn’t this sounds to me like the problem is with the OBS way of building. One more reason to contact the OBS mailinglist. Or even open a bugreport for OBS?
I found this thread where a workaround is described. I have not tested it yet but will report back here as soon as I have.
PS
@larryr : It would have been nice if you had posted your findings here as well.
I tested the proposed workaround. It did not work for me:
on the host:
> ls -la /home/USER_HOST/VM_Data/Open*.*
-rw-r--r-- 1 USER_HOST users 40749 Mar 3 2023 /home/USER_HOST/VM_Data/Opensuse_beer_label.jpg
>
the same file in the guest:
> ls -la /home/USER_GUEST/VM_share/Open*.*
-rwxrwx--- 1 root vboxsf 40749 Apr 3 09:43 /home/USER_GUEST/VM_share/Opensuse_beer_label.jpg
>
There were errors when building the modules for kernel 6.8.1-1-default in the guest (openSUSE Tumbleweed 20240329).
The issue, and we will use a file on a Window 10 share that is mounted on my Linux Guest (with Windows 10 host) by VirtualBox as an example:
michael@Kubuntu-VM:/media/J$ stat /media/sf_J_DRIVE/build-vim.sh # Note: `/media/J` is just a symlink to `/media/sf_J_DRIVE` the actual mount point:
File: /media/sf_J_DRIVE/build-vim.sh
Size: 4952 Blocks: 128 IO Block: 1048576 regular file
Device: 0,56 Inode: 72591 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 999/ vboxsf)
Access: 1969-12-31 18:00:00.000000000 -0600
Modify: 1969-12-31 18:00:00.000000000 -0600
Change: 2023-03-27 19:27:39.989683700 -0500
Birth: 2023-03-27 19:27:39.989683700 -0500
Running the mount command with regard to the guest mount of that share shows us:
J_DRIVE on /media/sf_J_DRIVE type vboxsf (rw,nodev,relatime,iocharset=utf8,uid=0,gid=999,dmode=0770,fmode=0770,tag=VBoxAutomounter)
Additional notes:
- Access time updates have been disabled on the Windows 10 host (but the file does have a valid access time, as I will show shortly).
- Notice that the modify time appears to be, in effect, 0 (i.e., right at the epoch). Also, the TZ offset is showing incorrectly as -0600 when it should be -0500 for my timezone (CDT), as is the case for the seemingly correct timestamps.
- The date command on the Linux guest tells us that the time and timezone are correct and match those of the host:
michael@Kubuntu-VM:/media/J$ date
Fri Apr 5 06:00:37 PM CDT 2024
and then several seconds later on the Windows host:
J:\>date
The current date is: Fri 04/05/2024
Enter the new date: (mm-dd-yy)
J:\>time
The current time is: 18:01:33.88
Enter the new time:
Also, using Cygwin64 on the Windows host:
J:\>c:\cygwin64\bin\date
Fri Apr 5 18:02:24 CDT 2024
I dug deeper into this and here is what is happening:
The Windows file Change Time is being placed into the Modified Time as viewed from the Linux Guest on the mount and the actual Modified Time for the Windows share file is discarded. The Linux guest is also showing an erroneously unset Modified Time as: 1969-12-31 18:00:00.000000000 -0600.
Here is how the file time info looks from the Windows Host perspective, after I did some programming to get the Change Time which is not easy to come by on Windows and note that -05:00 is correct for the CDT time zone:
Item : J:\build-vim.sh
CreationTime : 2023-03-27T19:27:39.9896837-05:00
LastAccessTime : 2023-03-27T19:27:39.9896837-05:00
LastWriteTime : 2023-03-27T19:27:40.0328607-05:00
ChangeTime : 2023-03-27T19:27:39.9896837-05:00
FileAttributes : 128
again compare and contrast with the stat from the Linux Guest side:
File: /media/sf_J_DRIVE/build-vim.sh
Size: 4952 Blocks: 128 IO Block: 1048576 regular file
Device: 0,56 Inode: 72591 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 999/ vboxsf)
Access: 1969-12-31 18:00:00.000000000 -0600
Modify: 1969-12-31 18:00:00.000000000 -0600
Change: 2023-03-27 19:27:39.989683700 -0500
Birth: 2023-03-27 19:27:39.989683700 -0500
Additional info about my setup:
Virtual Box: 7.0.15 latest Developer Build (doesn’t matter, 7.0.14 has same issue)
Host: Windows 10 (10.0.19045 with latest updates)
Guest: Ubuntu 23.10
Installed kernel: 6.8.1 , or more specifically:
Linux Kubuntu-VM 6.8.1-060801-generic #202403151937 SMP PREEMPT_DYNAMIC Fri Mar 15 19:52:22 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Taken as a .deb file straight from Ubuntu’s: Index of /mainline/v6.8.1/amd64
With the corresponding Virtual Box guest additions built for the kernel, installed, and operating (for the vbox 7.0.15 Development Build I am presently running).
So, there you go, another data point with far more info!
Let’s use another file for comparison on the same mount, that has different timestamps for all four of its timestamps, so that there is no ambiguity present:
Windows 10 host:
Item : J:\other-file.out
CreationTime : 2020-01-08T11:06:04.7240271-06:00
LastAccessTime : 2021-11-08T14:53:39.4419329-06:00
LastWriteTime : 2020-01-08T11:06:49.3562341-06:00
ChangeTime : 2024-04-05T18:18:19.3274703-05:00
FileAttributes : 8224
Here is how it appears on the linux guest and I have no idea why it is showing the times it is showing for the modify/access times (probably left over garbage in memory from some other file?):
michael@Kubuntu-VM:~$ stat /media/sf_J_DRIVE/other-file.out
File: /media/sf_J_DRIVE/other-file.out
Size: 466173 Blocks: 1024 IO Block: 1048576 regular file
Device: 0,56 Inode: 75441 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 999/ vboxsf)
Access: 2024-04-05 18:11:46.642577408 -0500
Modify: 2024-04-05 18:11:46.642577408 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
Birth: 2020-01-08 11:06:04.724027100 -0600```
As an additional cross-reference, I created a second (manually mounted) mount of the J_DRIVE share of the Windows 10 host on the linux guest running as a VM, as "$HOME/jshare", but this time with all ttl mount options set to 0 (i.e., cache nothing for file access), which looks as follows from a mount perspective (note the presence of the following options: ttl=0,dcachettl=0,inodettl=0):
J_DRIVE on /home/michael/jshare type vboxsf (rw,nodev,relatime,ttl=0,dcachettl=0,inodettl=0,iocharset=utf8,uid=0,gid=0)
On this manually set up mount with “cache nothing” mount options, running stat on the file shows us:
File: /home/michael/jshare/other-file.out
Size: 466173 Blocks: 1024 IO Block: 1048576 regular file
Device: 0,52 Inode: 76041 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 1969-12-31 18:00:00.000000000 -0600
Modify: 1969-12-31 18:00:00.000000000 -0600
Change: 2024-04-05 18:18:19.327470300 -0500
Birth: 2020-01-08 11:06:04.724027100 -0600
So I was mistaken, the ChangeTime is being shown correctly, whether FS caching is utilized on the guest side or not, but the Modified (i.e., LastWrite) and LastAccess times are just garbage.
Still more tests of different Linux kernels on the Linux guest with the same version of Virtual Box and guest additions as used previously (7.0.15 Developer Build):
Summary:
Linux Kernel 6.5.0 - Looks good (notice the lack of the creation time with this kernel running, is this a possible clue to the origin of this bug??)
Linux Kernels 6.6.12 and up - All have the issue
#######################
# kernel 6.5.0 - Good #
#######################
michael@Kubuntu-VM:/media/J$ uname -a; stat /media/sf_J_DRIVE/other-file.out
Linux Kubuntu-VM 6.5.0-26-generic #26-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 5 21:19:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
File: /media/sf_J_DRIVE/other-file.out
Size: 466173 Blocks: 1024 IO Block: 4096 regular file
Device: 0,57 Inode: 11 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 999/ vboxsf)
Access: 2021-11-08 14:53:39.441932900 -0600
Modify: 2020-01-08 11:06:49.356234100 -0600
Change: 2024-04-05 18:18:19.327470300 -0500
Birth: -
#######################
# kernel 6.6.12 - Bad #
#######################
Linux Kubuntu-VM 6.6.12-060612-generic #202401151837 SMP PREEMPT_DYNAMIC Mon Jan 15 18:49:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
File: /media/sf_J_DRIVE/other-file.out
Size: 466173 Blocks: 1024 IO Block: 1048576 regular file
Device: 0,56 Inode: 123 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 999/ vboxsf)
Access: 2024-04-05 18:56:24.605974612 -0500
Modify: 2024-04-05 18:56:24.605974612 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
Birth: 2020-01-08 11:06:04.724027100 -0600
#######################
# kernel 6.6.22 - Bad #
#######################
michael@Kubuntu-VM:~$ uname -a; stat /media/sf_J_DRIVE/other-file.out
Linux Kubuntu-VM 6.6.22-060622-generic #202403151938 SMP PREEMPT_DYNAMIC Fri Mar 15 20:29:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
File: /media/sf_J_DRIVE/other-file.out
Size: 466173 Blocks: 1024 IO Block: 1048576 regular file
Device: 0,55 Inode: 123 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 999/ vboxsf)
Access: 2024-04-05 18:51:47.947721793 -0500
Modify: 2024-04-05 18:51:47.947721793 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
Birth: 2020-01-08 11:06:04.724027100 -0600
#######################
# kernel 6.7.10 - Bad #
#######################
michael@Kubuntu-VM:/media/J$ uname -a; stat /media/sf_J_DRIVE/other-file.out
Linux Kubuntu-VM 6.7.10-060710-generic #202403151538 SMP PREEMPT_DYNAMIC Fri Mar 15 20:14:18 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
File: /media/sf_J_DRIVE/other-file.out
Size: 466173 Blocks: 1024 IO Block: 1048576 regular file
Device: 0,55 Inode: 123 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 999/ vboxsf)
Access: 2024-04-05 18:48:09.147629542 -0500
Modify: 2024-04-05 18:48:09.147629542 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
Birth: 2020-01-08 11:06:04.724027100 -0600
Today I updated my systems (host + guest) to openSUSE Tumbleweed 20240426 with
- virtualbox-kmp-default 7.0.14_k6.8.7_1-9.1
- virtualbox-guest-tools 7.0.14-9.2
and the issue seems to be fixed.
Thank you very much to all who worked hard to solve this problem.
Yes - this weeks zypper dup has the fix in it - it does requires a reboot to take effect as it is a kernel module that changed.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.