Discuss the 6.1.26 release

This is for discussing general topics about how to use VirtualBox.

Discuss the 6.1.26 release

Postby arudnev » 29. Jul 2021, 01:27

Discuss the VirtualBox 6.1.26 release here.
You can download the release here.
VirtualBox 6.1.26 is a maintenance release.

Changelog is here.
arudnev
Oracle Corporation
 
Posts: 33
Joined: 20. Feb 2018, 14:59

Re: Discuss the 6.1.26 release

Postby mpack » 30. Jul 2021, 11:13

A Linux host user has pointed out what looks like a minor bug in new code added to a Linux install script.

See topic: viewtopic.php?f=7&t=103520.
mpack
Site Moderator
 
Posts: 34530
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Discuss the 6.1.26 release

Postby arQon » 19. Aug 2021, 00:31

As of 6.1.26, vboxsf mounts in rc.local no longer work. (Ubuntu 18.04 guest, W10 host).

The script has been running for several years, and is basically just this:
Code: Select all   Expand viewCollapse view
echo Mounting VirtualBox folders
mount -t vboxsf -o rw,uid=1000,gid=1000,fmode=666 cold /cold

plus a couple of similar entries.

syslog:
Code: Select all   Expand viewCollapse view
Aug 18 14:23:51 brandi systemd[1]: Reloading.
Aug 18 14:24:42 brandi systemd[1]: Starting rc.local...
Aug 18 14:24:42 brandi rc.local[2722]: Mounting VirtualBox folders
Aug 18 14:24:42 brandi rc.local[2722]: /sbin/mount.vboxsf: shared folder '/cold' was not found (check VM settings / spelling)
Aug 18 14:24:42 brandi systemd[1]: rc-local.service: Control process exited, code=exited status=1
Aug 18 14:24:42 brandi systemd[1]: rc-local.service: Failed with result 'exit-code'.
Aug 18 14:24:42 brandi systemd[1]: Failed to start rc.local.
Aug 18 14:24:42 brandi kernel: [  885.064384] vboxsf: SHFL_FN_MAP_FOLDER failed for '/cold': share not found
Aug 18 14:24:42 brandi kernel: [  885.064386] vbsf_read_super_aux err=-6


One interesting note is the incorrect / in the shared folder name in the log messages, but I expect that's just a formatting error. The mounts work correctly if run via "sudo /etc/rc.local" after startup, so the likely cause is a race.

vboxsf was added to /etc/modules not later than 21-Mar-2018, with a comment that explains why it was needed:
Code: Select all   Expand viewCollapse view
# open vbox folders sometimes don't restore properly on reboot
# because @#$%ing systemd doesn't run it at the right time
# so set vboxsf to load asap so rc.local can hopefully finish before the DE starts

i.e. if the mount is open in a file manager window, and session restore is enabled, the file manager will close the window on startup because the path isn't valid, which rather defeats the purpose. That error also seems to be causing the DE to fail to run some other startup scripts, including the xrandr hack required since VB6.1.?? to force the screen to start working.

I expect that to some extent this is "really" still a systemd problem, but even so, the question is "Why is vboxsf apparently still not loaded even with the /etc/modules change in place?". The race has obviously been a potential issue for several years now, but since making that change in May 2018 the problem has been under control until this release.

The relevent pieces of the VB log are:
Code: Select all   Expand viewCollapse view
00:00:04.787965 Changing the VM state from 'CREATING' to 'CREATED'
00:00:04.789273 SharedFolders host service: Adding host mapping
00:00:04.789287     Host path 'H:\', map name 'cold', writable, automount=false, automntpnt=, create_symlinks=false, missing=false
...
00:09:22.690287 VMMDev: Guest Additions capability report: (0x0 -> 0x0) seamless: no, hostWindowMapping: no, graphics: no
00:09:22.690398 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners
00:09:22.690519 VMMDev: Guest Log: vboxguest: Successfully loaded version 6.1.26 r145957
00:09:22.690550 VMMDev: Guest Log: vboxguest: misc device minor 56, IRQ 20, I/O port d040, MMIO at 00000000f0400000 (size 0x400000)
00:09:22.692204 VMMDev: Guest Log: vboxsf: g_fHostFeatures=0x8000000f g_fSfFeatures=0x1 g_uSfLastFunction=29
00:09:22.692430 VMMDev: Guest Log: vboxsf: Successfully loaded version 6.1.26 r145957 on 4.15.0-153-generic SMP mod_unload modversions  (LINUX_VERSION_CODE=0x40f12)
00:09:23.499378 VMMDev: Guest Log: vboxsf: SHFL_FN_MAP_FOLDER failed for '/cold': share not found

which seems to pretty much kill the "race" theory and suggest "bug" instead, I think, but...
edit> Okay, it's "both". The bug is "simple": if the folder name and the mountpoint are too similar (close to identical), AND the code tries to use them "early", it gets confused and uses the mountpoint as the device name. At some point AFTER boot, whatever the hell was going on there eventually gets itself untangled and the same command then works. The race isn't between VBox and the system, it's entirely within the VBox code.

add> The last known working version was VirtualBox-6.1.23-145004-Win.exe (a preview build with fixes for the DSound bugs). I never tried 6.1.24, but 6.1.22 was also fine (as you'd expect).

No amount of messing around with creating artificial dependencies etc seems able to resolve this: every attempt to mount the shared folders during boot, whether in rc.local, or defining them as noauto,x-systemd.automount in fstab, and so on, always results in the same (slightly wrong) error:
Code: Select all   Expand viewCollapse view
Aug 18 17:36:10 brandi systemd[1]: cold.automount: Got automount request for /cold, triggered by 1783 (ls)
Aug 18 17:36:10 brandi systemd[1]: Mounting /cold...
Aug 18 17:36:10 brandi mount[1784]: /sbin/mount.vboxsf: shared folder '/cold' was not found (check VM settings / spelling)
Last edited by arQon on 19. Aug 2021, 11:49, edited 1 time in total.
arQon
 
Posts: 148
Joined: 1. Jan 2017, 09:16
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Ubuntu 16.04 x64, W7

Re: Discuss the 6.1.26 release

Postby arQon » 19. Aug 2021, 04:30

6.1.26 has also broken the long-standing "blank screen at startup for (fullscreen) Linux guests" bug even further.

Although the bug itself was never fixed, it's been possible to work around it by issuing xrandr calls at startup to englarge the screen and then resize it back down to the correct resolution. This no longer works, and since "GUI/LastGuestSizeHint" also doesn't work there aren't any more hacks that I'm aware of that don't require user interaction every time. (Switching away from VT7 and back again, etc).

VBox itself appears to be trying some utterly ridiculous sizes at startup in what I assume is an attempt to work around this bug itself:
Code: Select all   Expand viewCollapse view
> findstr DisplayResize Logs\VBox.log
00:00:04.197772 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0
00:00:04.231528 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c7f0000 w=640 h=480 bpp=32 cbLine=0xA00 flags=0x0 origin=0,0
00:00:06.730977 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0
00:00:07.071138 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c7f0000 w=640 h=480 bpp=32 cbLine=0xA00 flags=0x0 origin=0,0
00:00:10.172534 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0
00:00:14.742330 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c7f0000 w=800 h=600 bpp=32 cbLine=0xC80 flags=0x1 origin=0,0
00:00:20.518400 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=800 h=600 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
00:00:24.548560 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cd6f000 w=1920 h=1200 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0
00:00:24.599650 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=1920 h=1200 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
00:00:36.989211 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c7f0000 w=800 h=600 bpp=32 cbLine=0xC80 flags=0x1 origin=0,0
00:00:38.216741 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=800 h=600 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
00:00:38.218396 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cb9a000 w=1920 h=1200 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0

and I notice that none of those entries actually matches the first call in this script:
Code: Select all   Expand viewCollapse view
$  cat ~/vbox-displayinit-bug.sh
#!/bin/bash
xrandr --size 1920x1440
xrandr --size 1920x1200

The full script includes explicit logging of the calls, which are still being executed, but it looks like 6.1.26 is now simply discarding the first one outright, and since that's required for VBox to actually trigger the change BACK to fullscreen resolution, since the first call is ignored the second one is now ALSO ignored because the screen size "didn't change".

Given that the underlying bug must be well over a year old at this point, I'd suggest the easiest way to deal with it would be just remove all these random attempts and simply honor whatever LastGuestSizeHint is. The continued attempts to solve this problem "properly" are appreciated, but are now only making things even worse.

--

add> Did some simple bisection and bughunting, since I might as well at this point:

* In 6.1.26: Changing the Maximum Guest Screen Size (via VBoxGUI -> File -> Preferences -> Display) from Auto to Hint(1920x1440) doesn't work. Nor does changing it to "None".
In all 3 cases, even "None", VBox failed to honor the x1440 request.
* 6.1.24-145767 has the same problems as 6.1.26.
* 6.1.23-145004 is fine. And, as you'd expect given that, 6.1.23 also shows the correct behavior in the VB logs:
Code: Select all   Expand viewCollapse view
> findstr DisplayResize Logs\VBox.log
00:00:04.184609 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0
00:00:04.272265 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c840000 w=640 h=480 bpp=32 cbLine=0xA00 flags=0x0 origin=0,0
00:00:06.737237 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0
00:00:07.057216 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c840000 w=640 h=480 bpp=32 cbLine=0xA00 flags=0x0 origin=0,0
00:00:10.245910 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0
00:00:13.914624 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c840000 w=800 h=600 bpp=32 cbLine=0xC80 flags=0x1 origin=0,0
00:00:21.290842 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=800 h=600 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
00:00:25.328469 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cdbf000 w=1920 h=1200 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0
00:00:25.335991 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=1920 h=1200 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
00:00:27.306075 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cbea000 w=1920 h=1440 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0
00:00:27.392491 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=1920 h=1440 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
00:00:27.403215 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000cbea000 w=1920 h=1200 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0
00:16:32.173451 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=1920 h=1200 bpp=0 cbLine=0x0 flags=0x2 origin=0,0
00:16:32.177872 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000c840000 w=800 h=600 bpp=32 cbLine=0xC80 flags=0x1 origin=0,0

Note the "h=1440" lines that were missing from the earlier output.
arQon
 
Posts: 148
Joined: 1. Jan 2017, 09:16
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Ubuntu 16.04 x64, W7

Re: Discuss the 6.1.26 release

Postby fth0 » 19. Aug 2021, 16:39

arQon wrote:No amount of messing around with creating artificial dependencies etc seems able to resolve this: every attempt to mount the shared folders during boot, whether in rc.local, or defining them as noauto,x-systemd.automount in fstab, and so on, always results in the same (slightly wrong) error:

While testing another user's issue regarding shared folders, I made a discovery that doesn't seem to fit to your description, but may be worth a try anyway. To me, it looked as if VirtualBox expected the "sf_" prefix on the mount point folder name, even if automatic mounting was disabled and no mount point was specified. See LG - Shared Folder mount point for my summary.

In the VM configuration, add a dummy name as the mount point and keep auto mount disabled. Does your manual mount then work as expected? Alternatively, rename your manual mount point to include the "sf_" prefix in its folder name and in the mount command.
fth0
Volunteer
 
Posts: 2379
Joined: 14. Feb 2019, 03:06
Location: Germany
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...

Re: Discuss the 6.1.26 release

Postby fth0 » 19. Aug 2021, 17:09

arQon wrote:VBox itself appears to be trying some utterly ridiculous sizes at startup in what I assume is an attempt to work around this bug itself:

All display resolution changes before the first change to 1920x1200 are initiated by the (VirtualBox-provided) BIOS and the guest OS, so they are not a really chosen by VirtualBox. That leaves only the last two resolution changes (from 1920x1200 to 800x600 and back) as debatable IMHO.

arQon wrote:I'd suggest the easiest way to deal with it would be just remove all these random attempts and simply honor whatever LastGuestSizeHint is.

Unfortunately, it's not that easy. If you want to read more about the details, scottgus1 and me did some deep investigation lately, to find out why the LastGuestSizeHint setting only works sometimes: See LastGuestSizeHint not written/updated (and the whole thread around it).
fth0
Volunteer
 
Posts: 2379
Joined: 14. Feb 2019, 03:06
Location: Germany
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...

Re: Discuss the 6.1.26 release

Postby PeterE » 18. Sep 2021, 05:05

The problem with special mouse pointers in a Windows guest still exists.
Microsoft uses special mouse pointers in MS Office (Excel, Word, Access). I assume it is a problem of the guest additions for Windows. I am using Windows 10 on the host and Windows XP with Office 2003 in the VB guest with a scale factor of 1.2. If the scale factor is set to 1.0 (100%) then the special mouse pointers work.
PeterE
 
Posts: 34
Joined: 10. Dec 2012, 16:13
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Arch Linux, Windows

Re: Discuss the 6.1.26 release

Postby arQon » 20. Sep 2021, 07:57

fth0 wrote:
arQon wrote:No amount of messing around with creating artificial dependencies etc seems able to resolve this: every attempt to mount the shared folders during boot, whether in rc.local, or defining them as noauto,x-systemd.automount in fstab, and so on, always results in the same (slightly wrong) error:

While testing another user's issue regarding shared folders, I made a discovery that doesn't seem to fit to your description, but may be worth a try anyway. To me, it looked as if VirtualBox expected the "sf_" prefix on the mount point folder name, even if automatic mounting was disabled and no mount point was specified. See LG - Shared Folder mount point for my summary.

In the VM configuration, add a dummy name as the mount point and keep auto mount disabled. Does your manual mount then work as expected? Alternatively, rename your manual mount point to include the "sf_" prefix in its folder name and in the mount command.


Sorry for the lag - I had to evacuate ahead of a fire and only got home recently.

As always, thanks for the input.

I THINK the "sf_" prefix was what I happened to go with at the time to change the mountpoint from having a name identical (at the final pathnode) to its mountpoint, but it was so long ago now that I can't actually remember. :/
edit> Jep, must have been: there's a /media/sf_xfer/folder there now, dated a month ago.

re "keep auto mount disabled", I've NEVER used VB's automount. I don't remember if that's because it was buggy at first or simply because I already had a working system, but either way that's not part of the bug - which, as you say, is that mounts don't work "even if automatic mounting was disabled and no mount point was specified".

After the disruption caused by the fire I'm quite badly backlogged, so it'll probably be quite a long time before I can afford to reinstall 6.1.26 and test again. (Especially with the added headache of the fullscreen bug that also came with .24+). Like I said in the original post though, this is a clear regression from <= 6.1.23, regardless of the specific cause.

If the end result is for Oracle to simply decide it's not worth fixing, the manual needs updating to say that shared folders MUST start with "sf_" or etc to avoid the bug. I'm fine with that: I don't care what they're called, I care that mounting them doesn't work! :P But regardless of the outcome, since the bug isn't documented anywhere I wanted to make the OP so that at least forum users would know how to deal with it without having to burn the same amount of time re-diagnosing it that I already did. :)

Will hopefully follow up in a couple of weeks with full details and a ticket, but it could take even longer.
arQon
 
Posts: 148
Joined: 1. Jan 2017, 09:16
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Ubuntu 16.04 x64, W7

Re: Discuss the 6.1.26 release

Postby arQon » 20. Sep 2021, 22:54

fth0 wrote:
arQon wrote:I'd suggest the easiest way to deal with it would be just remove all these random attempts and simply honor whatever LastGuestSizeHint is.

Unfortunately, it's not that easy. If you want to read more about the details, scottgus1 and me did some deep investigation lately, to find out why the LastGuestSizeHint setting only works sometimes: See LastGuestSizeHint not written/updated (and the whole thread around it).


I meant "for the devs". :)

This has been broken for well over a year at this point, so it's clearly not something any "supported" Oracle customers care about much, and at this point the attempts to fix it seem to be making things worse rather than better. I was suggesting that it's time to just rip out whatever "cleverness" is causing the problems, set the hint when the user changes things in the UI, and go from there instead.

The bigger problem is the bug with initial painting though, which is even older than this one: if that was fixed, we wouldn't need the guest hacks in the first place. But since it isn't, hacks is all we've got. :P
arQon
 
Posts: 148
Joined: 1. Jan 2017, 09:16
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Ubuntu 16.04 x64, W7


Return to Using VirtualBox

Who is online

Users browsing this forum: No registered users and 16 guests