|
Virtualbox 6.1.18 /sbin/vboxconfig fails on Ubuntu 20.04 (liquorix kernel)
Hi,
Recently applied some updates on my Ubuntu Mint 20.04 running liquorix kernel (5.11.0-13.1-liquorix-amd64 specifically for audio production work) on a 6-core Intel i5-8400 with 16GB RAM (single channel). I am on Virtualbox release 6.1.18 r142142. This system has been running stable, with Virtualbox for over a month and survived many updates, but this one did something to Virtualbox. I see this in /var/log/vbox-setup.log: :: Code ::
gcc -Wp,-MMD,/tmp/vbox.0/linux/.SUPR0IdcClient-linux.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/9/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O3 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fomit-frame-pointer -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -include /tmp/vbox.0/include/VBox/SUPDrvMangling.h -fno-pie -Wno-declaration-after-statement -I./include -I/tmp/vbox.0/ -I/tmp/vbox.0/include -I/tmp/vbox.0/r0drv/linux -D__KERNEL__ -DMODULE -DRT_WITHOUT_PRAGMA_ONCE -DRT_OS_LINUX -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64 -DMODULE -DKBUILD_BASENAME='"SUPR0IdcClient_linux"' -DKBUILD_MODNAME='"vboxnetflt"' -c -o /tmp/vbox.0/linux/SUPR0IdcClient-linux.o /tmp/vbox.0/linux/SUPR0IdcClient-linux.c ./tools/objtool/objtool orc generate --module --no-fp --retpoline --uaccess /tmp/vbox.0/linux/SUPR0IdcClient-linux.o ./tools/objtool/objtool orc generate --module --no-fp --retpoline --uaccess /tmp/vbox.0/SUPR0IdcClientComponent.o ./tools/objtool/objtool orc generate --module --no-fp --retpoline --uaccess /tmp/vbox.0/SUPR0IdcClient.o ./tools/objtool/objtool orc generate --module --no-fp --retpoline --uaccess /tmp/vbox.0/VBoxNetFlt.o /tmp/vbox.0/linux/VBoxNetFlt-linux.c: In function ‘vboxNetFltNeedsLinkState’: /tmp/vbox.0/linux/VBoxNetFlt-linux.c:1761:47: error: dereferencing pointer to incomplete type ‘const struct ethtool_ops’ 1761 | if (pDev->ethtool_ops && pDev->ethtool_ops->get_drvinfo) | ^~ /tmp/vbox.0/linux/VBoxNetFlt-linux.c:1763:32: error: storage size of ‘Info’ isn’t known 1763 | struct ethtool_drvinfo Info; | ^~~~tmp/vbox.0/linux/VBoxNetFlt-linux.c:1766:20: error: ‘ETHTOOL_GDRVINFO’ undeclared (first use in this function) 1766 | Info.cmd = ETHTOOL_GDRVINFO; | ^~~~~~~~~~~~~~~~ /tmp/vbox.0/linux/VBoxNetFlt-linux.c:1766:20: note: each undeclared identifier is reported only once for each function it appears in /tmp/vbox.0/linux/VBoxNetFlt-linux.c:1763:32: warning: unused variable ‘Info’ [-Wunused-variable] 1763 | struct ethtool_drvinfo Info; | ^~~~ make[2]: *** [scripts/Makefile.build:279: /tmp/vbox.0/linux/VBoxNetFlt-linux.o] Error 1 make[1]: *** [Makefile:1832: /tmp/vbox.0] Error 2 make: *** [/tmp/vbox.0/Makefile-footer.gmk:117: vboxnetflt] Error 2 Does this need some fix on liquorix side or Virtualbox side ? cheers, f74 PS> Also posted pretty similar message on Virtualbox community forum. Back to top |
|||||
|
Pick one:
1. Stable system where all components interact with each other and don't change 2. Rolling release system, where kernel and modules may not always work as expected It's really not any more complicated than that. Note that 1 can be achieved in several ways, one is to stick to frozen pool distro kernel and modules, the other is to maintain your system properly, and only install and retain kernels that are shown to work with the modules you need. This method works fine too, and often can result in a newer kernel working reliably on a frozen pool system. However, it has limits, because at some point Liquorix will ship requiring a newer gcc version than Mint has, and then it's game over for that idea, and you have to stick to the last one that worked, which is what you have to do always anyway. What does NOT work reliably is expecting various modules to always work on latest kernels, and this is most particularly the case with Mint, which is not just one frozen pool away from current, it's TWO, ubuntu > mint. In other words, do NOT use kernel metapackages in this situation, manage your kernels, and install latest, but retain working and known good one, then if you hit an issue with a module you need, remove the new kernel, and wait. If you are depending on a module like vbox that may not track latest rolling kernels, same goes for nvidia, you will almost always hit a point where something makes the module sad, as in this case. It's 100% not a Liquorix problem if you make the choice for uncertain module/kernel interaction, and you'll be doing yourself a long term favor if you understand what this means, and stop expecting frozen pool releases of frozen pool releases like Mint to be reliable over time when using a rolling current kernel, and stop expecting kernel modules that generally track several versions behind current linux to always work on new kernels. Also, do us all a favor and don't make us look up your vbox version, we have no idea where it comes from, is it installed from vbox latest repos, does it come from mint? if from mint, of course it won't work, if from vbox, of course it's not always going to work with latest kernel, this is standard and not a valid issue, though you can help the vbox devs find issues that they probably already know about on latest linux current kernels, but that's totally outside of liquorix scope, that's their and your problem, not Liquorix's. Frozen pool distro users have to learn that you can't have your cake and eat it too, lol, either have stability where everything keeps working nicely together, or don't. I'll give you a pro tip: once you start properly managing your kernels, stuff like nvidia or vbox drivers will generally work within 1 or 2 major kernel versions, so say, if you stay on 5.10, and wait a few months, then go to 5.11 when the last 5.11 version comes out, say, and install latest nvidia or vbox, it will often then often work, but what will not always work is expecting new kernels to work with modules that do not track current kernel live, which is impossible due to massive numbers of linux kernel changes almost every new major release. With the major caveat that as soon as Liquorix changes to new compiler, none of your stuff will compile on the new liquorix, and that's the end of the liquorix + compiled modules road for you. That time usually comes between 3 and 12 months after the distro freeze. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||