VirtualBox

Opened 3 years ago

Closed 2 years ago

#20567 closed defect (fixed)

Linux 5.14 Host & Guest - vboxsf intermittant guest addition build failures

Reported by: David C Rankin Owned by:
Component: shared folders Version: VirtualBox 6.1.26
Keywords: Cc:
Guest type: Linux Host type: Linux

Description

Per the bug-request from thread:

Re: [VBox-users] [External] : Linux 5.14 with Testbuild 6.1.x revision 146688 - no vboxsf?

After installing testbuild revision 146688 and updating to Linux 5.14 on Archlinux and after updating the kernel on the Archlinux guest as well, the guest shared folders were not present and the following error was received:

/usr/bin/mount.vboxsf: mounting failed with error: No such device

As explained in the thread, Archlinux also updated dkms (2.8.5-1 -> 2.8.6-1) along with this kernel update. (there were dkms problems with it not removing old virtualbox driver directories for versions that were no longer present) A couple of days later dkms was updated to 2.8.6-2 and another kernel update was applied.

After the kernel update, dkms ran and updated all modules on the host. Then after applying the kernel update on the guest, rebuilding the guest addition modules and restarting, the shared-folders were working and all appeared well. At that point I chocked the problems up to the flaky dkms behavior -- but that apparently wasn't the total story.

A second server with the same host/guest config was updated directly to Linux 5.14.3 with dkms 2.8.6-2 present - and the shared-folder problem appeared on the second server -- but this time the vboxsf device was found -- only the shared folder was empty on access.

Per the request in the thread, I preserved dmesg and vboxadd-setup.log from the guest in the state where the shared-folders were empty (attached as after_5.14.3.tar.bz2) In the interim, Archlinux updated to Linux 5.14.5 and updating both host and guest on the second server succeeded (same files from that update are attached as after_5.14.5.tar.bz2)

What looks to have happened to the second server, even though it updated to what was a good setup with testbuild revision 146688 on the first server, was an autoconf error along with an error on struct iov_iter preventing the guest addition build from completing. The error (included in the vboxadd-setup.log) was

echo >&2 "  ERROR: Kernel configuration is invalid.";           \
echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";      \
...
/tmp/vbox.0/regops.c: In function ‘vbsf_iter_lock_pages’:
/tmp/vbox.0/regops.c:2129:15: error: ‘struct iov_iter’ has no member named ‘type’
 2129 |     if (!(iter->type & ITER_KVEC)) {
      |               ^~
/tmp/vbox.0/regops.c: In function ‘vbsf_iter_max_span_of_pages’:
/tmp/vbox.0/regops.c:2376:37: error: ‘struct iov_iter’ has no member named ‘type’
 2376 |     if (iter_is_iovec(iter) || (iter->type & ITER_KVEC)) {
      |                                     ^~
/tmp/vbox.0/regops.c:2439:28: error: ‘struct iov_iter’ has no member named ‘type’
 2439 |         size_t cSegs = iter->type & ITER_BVEC ? RT_MAX(1, iter->nr_segs) : 1;
      |                            ^~
/tmp/vbox.0/regops.c: At top level:
/tmp/vbox.0/regops.c:3796:23: error: ‘simple_write_end’ undeclared here (not in a function); did you mean ‘simple_write_begin’?
 3796 |     .write_end      = simple_write_end,
      |                       ^~~~~~~~~~~~~~~~
      |                       simple_write_begin
make[2]: *** [scripts/Makefile.build:271: /tmp/vbox.0/regops.o] Error 1

This was odd because the exact same packages had been used on the first server and there the guest additions build on 5.14.3. On update of the second server to 5.15.5, this error was not triggered and the guest additions built successfully.

Bottom line, I can't tell if this is an intermittent problem with the current guest additions build or some strange set of issues that effected server 1 and server 2 in slightly different ways both causing the loss of shared folders.

Both of these servers have run Virtualbox since version 4.X and have both been updated though 5.X and now 6.X, so they have gone through the update process some 50+ times and this was an odd set up issues affecting the guest addition shared-folder update.

All is working now, but after explaining this on vbox-users list there was a request that I open this bug so a more careful look can be had.

Let me know if you need any additional information.

Attachments (2)

after_5.14.3.tar.bz2 (17.0 KB ) - added by David C Rankin 3 years ago.
dmesg and vboxadd-setup.logs on 2nd server after 5.14.3 update
after_5.14.5.tar.bz2 (14.2 KB ) - added by David C Rankin 3 years ago.
dmesg and vboxadd-setup.logs on 2nd server after 5.14.5 update

Download all attachments as: .zip

Change History (9)

by David C Rankin, 3 years ago

Attachment: after_5.14.3.tar.bz2 added

dmesg and vboxadd-setup.logs on 2nd server after 5.14.3 update

by David C Rankin, 3 years ago

Attachment: after_5.14.5.tar.bz2 added

dmesg and vboxadd-setup.logs on 2nd server after 5.14.5 update

comment:1 by galitsyn, 3 years ago

Hi drankinatty,

For the case of after_5.14.3 (an empty VBox share on a guest side), you are trying to build outdated Additions (from the previous official release 6.1.24). This is expected not to work for 5.14 kernels.

In case of after_5.14.5 I can see from logs that build went smoothly and Shared Folder was successfully mounted afterwards:

[   37.202859] 01:31:46.280586 automount vbsvcAutomounterMountIt: Successfully mounted 'davidfr' on '/media/sf_davidfr'

So, general recommendation is to update all the guests to the latest development build of Additions. Version https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_6.1.27-146914.iso should work with upstream kernels up to 5.15.0-rc2 currently.

There is, however, might be an issue in case of after_5.14.5. I see that no VBoxClient processes are running. These services are started only after user performs graphical log-in. Did you do graphical log-in or you accessing VM remotely, for example, using ssh connection?

comment:2 by David C Rankin, 3 years ago

Yes, I always start the VM headless on the server and then use rdesktop to access the guest. For example, I start the guest with:

exec VBoxManage startvm arch_1_64 --type headless

and then I set the video mode hint to fit my laptop (in a normal window that is almost full screen):

VBoxManage controlvm "arch_1_64" setvideomodehint 1382 864 32

I can also report updating both host and guest through Linux 5.14.7 and both Linux and Windows guests are working as normal. I suspect the early failure of the build choking on an early module build was due to the bug in dkms that left the old guest versions of modules in the filesystem. dkms saw the module directories left in the filesystem and attempted to build it -- resulting in the failure.

The autoconf issue is a bit more odd. There were updates to that package surrounding the time of failure, and I certainly cannot explain why that failure happened.

I have another server to update to 5.14.7 tonight and I'll add more if anything unusual occurs -- but at this point, I don't expect anything out of the ordinary.

comment:3 by David C Rankin, 3 years ago

Just another update on the 5.14 kernel on Archlinux. Since the last report of a successful update to 5.14.7 on both servers, I have updated through 5.14.8, 5.14.9 and 5.14.10 without any further issues.At least from my perspective it looks like the initial failures were related to spurious changes in the DKMS and autoconf packages. At least I haven't been able to pin the early failures on anything else.

Let me know if I can send any additional information.

comment:4 by James Brown, 3 years ago

vboxsf appears to fail to build on a 5.4.11 guest with the same set of errors as in the original post of this thread:

/tmp/vbox.0/regops.c: In function 'vbsf_iter_lock_pages':
/tmp/vbox.0/regops.c:2129:17: error: 'struct iov_iter' has no member named 'type'; did you mean 'pipe'?
     if (!(iter->type & ITER_KVEC)) {
                 ^~~~
                 pipe
/tmp/vbox.0/regops.c: In function 'vbsf_iter_max_span_of_pages':
/tmp/vbox.0/regops.c:2376:39: error: 'struct iov_iter' has no member named 'type'; did you mean 'pipe'?
     if (iter_is_iovec(iter) || (iter->type & ITER_KVEC)) {
                                       ^~~~
                                       pipe
/tmp/vbox.0/regops.c:2439:30: error: 'struct iov_iter' has no member named 'type'; did you mean 'pipe'?
         size_t cSegs = iter->type & ITER_BVEC ? RT_MAX(1, iter->nr_segs) : 1;
                              ^~~~
                              pipe
/tmp/vbox.0/regops.c: At top level:
/tmp/vbox.0/regops.c:3796:23: error: 'simple_write_end' undeclared here (not in a function); did you mean 'simple_write_begin'?
     .write_end      = simple_write_end,
                       ^~~~~~~~~~~~~~~~
                       simple_write_begin
make[3]: *** [/tmp/vbox.0/regops.o] Error 1
make[2]: *** [/tmp/vbox.0] Error 2
make[1]: *** [__sub-make] Error 2
make: *** [vboxsf] Error 2

It looks like the iov_iter structure saw big changes in 5.14 merge in as commit d3acb15a3a1b841dc709c3853ec900170b2478e5 upstream.

in reply to:  4 comment:5 by galitsyn, 3 years ago

Replying to jbrownEP:

It looks like the iov_iter structure saw big changes in 5.14 merge in as commit d3acb15a3a1b841dc709c3853ec900170b2478e5 upstream.

Hi jbrownEP,

This issue has been fixed. Could you please try one the Latest 6.1.x test builds from our Test Builds page?

comment:6 by James Brown, 3 years ago

I just tested with build 147422 (6.1.27) from that page and confirmed that vboxsf builds and works on 5.4.11 now. Hooray!

comment:7 by galitsyn, 2 years ago

Resolution: fixed
Status: newclosed

Thank you for reporting the issue. It should be fixed in VirtualBox 6.1.36. Please refer to https://www.virtualbox.org/wiki/Downloads page.

Note: See TracTickets for help on using tickets.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette