Win10 Guest in Maui Host + VB 3D Accel + Nouveau gpu driver = Dead Maui.

[leszek]

Yes that's all correct (the steps + the conclusion for the nvidia driver and possible future)

[kdemeoz]

Am now running Tower with kernel 4.9.9 -- thank you leszek  

Booted ok; logged in ok; eCryptFS-encrypted /home auto-mounted & decrypted during login ok; eCryptFS-encrypted /DATA manually mounted & decrypted after login ok; connected to VPN ok [with an immediate improvement seen here; Plasma no longer prompted me for my kwallet password {which it also did not used to do in Mint, did not used to do in my original Maui (Sept to Dec 2016] but annoyingly did always do after my clean reinstallation (31/12/16) until now - yay}]; audio ok; graphics ok; VirtualBox VMs ok [except that, being cowardly, i have not yet felt up to re-enabling the Win10 VM's 3D Acceleration to see if that still freezes Maui]. Basically, so far, everything seems to be working well.

Only time will tell if this has actually fixed the long-term chronic freeze problems of https://forums.mauilinux.org/showthread....9#pid41689

The actual upgrade process did throw up a challenge however; two errors occurred, which made me panic about maybe Tower might not boot [but it did; seems i worried for nothing]. Here's what i saw happen in Konsole during the sudo dpkg:

Code:

Selecting previously unselected package linux-headers-4.9.9-040909.
(Reading database ... 309286 files and directories currently installed.)
Preparing to unpack linux-headers-4.9.9-040909_4.9.9-040909.201702090333_all.deb ...
Unpacking linux-headers-4.9.9-040909 (4.9.9-040909.201702090333) ...
Selecting previously unselected package linux-headers-4.9.9-040909-generic.
Preparing to unpack linux-headers-4.9.9-040909-generic_4.9.9-040909.201702090333_amd64.deb ...
Unpacking linux-headers-4.9.9-040909-generic (4.9.9-040909.201702090333) ...
Selecting previously unselected package linux-image-4.9.9-040909-generic.
Preparing to unpack linux-image-4.9.9-040909-generic_4.9.9-040909.201702090333_amd64.deb ...
Done.
Unpacking linux-image-4.9.9-040909-generic (4.9.9-040909.201702090333) ...
Setting up linux-headers-4.9.9-040909 (4.9.9-040909.201702090333) ...
Setting up linux-headers-4.9.9-040909-generic (4.9.9-040909.201702090333) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
Error! Bad return status for module build on kernel: 4.9.9-040909-generic (x86_64)
Consult /var/lib/dkms/ndiswrapper/1.59/build/make.log for more information.
Setting up linux-image-4.9.9-040909-generic (4.9.9-040909.201702090333) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
run-parts: executing /etc/kernel/postinst.d/dkms 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
Error! Bad return status for module build on kernel: 4.9.9-040909-generic (x86_64)
Consult /var/lib/dkms/ndiswrapper/1.59/build/make.log for more information.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
update-initramfs: Generating /boot/initrd.img-4.9.9-040909-generic
W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_01.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module i915
run-parts: executing /etc/kernel/postinst.d/pm-utils 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.9.9-040909-generic /boot/vmlinuz-4.9.9-040909-generic
Generating grub configuration file ...
Found theme: /boot/grub/themes/maui/theme.txt
Found linux image: /boot/vmlinuz-4.9.9-040909-generic
Found initrd image: /boot/initrd.img-4.9.9-040909-generic
Found linux image: /boot/vmlinuz-4.4.0-62-generic
Found initrd image: /boot/initrd.img-4.4.0-62-generic
Found linux image: /boot/vmlinuz-4.4.0-59-generic
Found initrd image: /boot/initrd.img-4.4.0-59-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
done

...& here's the corresponding contents of /var/lib/dkms/ndiswrapper/1.59/build/make.log:

Code:

DKMS make.log for ndiswrapper-1.59 for kernel 4.9.9-040909-generic (x86_64)
Tue 14 Feb 12:27:55 AEDT 2017
make: Entering directory '/usr/src/linux-headers-4.9.9-040909-generic'
 LD      /var/lib/dkms/ndiswrapper/1.59/build/built-in.o
 MKEXPORT /var/lib/dkms/ndiswrapper/1.59/build/crt_exports.h
 MKEXPORT /var/lib/dkms/ndiswrapper/1.59/build/hal_exports.h
 MKEXPORT /var/lib/dkms/ndiswrapper/1.59/build/ndis_exports.h
 MKEXPORT /var/lib/dkms/ndiswrapper/1.59/build/ntoskernel_exports.h
 MKEXPORT /var/lib/dkms/ndiswrapper/1.59/build/ntoskernel_io_exports.h
 MKEXPORT /var/lib/dkms/ndiswrapper/1.59/build/rtl_exports.h
 MKEXPORT /var/lib/dkms/ndiswrapper/1.59/build/usb_exports.h
 MKSTUBS /var/lib/dkms/ndiswrapper/1.59/build/win2lin_stubs.h
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/crt.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/hal.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/iw_ndis.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/loader.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/ndis.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/ntoskernel.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/ntoskernel_io.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/pe_linker.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/pnp.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/proc.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/rtl.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/wrapmem.o
 CC [M]  /var/lib/dkms/ndiswrapper/1.59/build/wrapndis.o
/var/lib/dkms/ndiswrapper/1.59/build/wrapndis.c: In function ‘tx_worker’:
/var/lib/dkms/ndiswrapper/1.59/build/wrapndis.c:707:16: error: ‘struct net_device’ has no member named ‘trans_start’
   wnd->net_dev->trans_start = jiffies;
               ^
scripts/Makefile.build:293: recipe for target '/var/lib/dkms/ndiswrapper/1.59/build/wrapndis.o' failed
make[1]: *** [/var/lib/dkms/ndiswrapper/1.59/build/wrapndis.o] Error 1
Makefile:1496: recipe for target '_module_/var/lib/dkms/ndiswrapper/1.59/build' failed
make: *** [_module_/var/lib/dkms/ndiswrapper/1.59/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.9.9-040909-generic'

[AJSlye]

This might be helpful:
http://unix.stackexchange.com/questions/...nux-kernel

[kdemeoz]

Oh golly - thank you. Just when i thought i was out of the scary dark forest, do i now have to go back into it? ;-)

[Might be a really stupid question:] Even though those two errors occurred [which presumably is A Bad Thing], my Tower has booted into 4.9.9, & so far at least, everything seems good. Should i still try to do that fix per your link, or is it "safe" for me to assume those errors were non-fatal / non-critical, & hence non-mandatory to fix?

[AJSlye]

Yes, the error your getting just means that dkms could not build ndiswrapper and fails to finish.
If the system is running everything correctly, then I wouldn't worry about it.
However, if anything isn't working correctly, and you need dkms to finish building modules, then you should probably use the fix.

[kdemeoz]

Thanks AJ. I realise the following is probably philosophically rhetorical, but here goes anyway...

If my Tower had not booted, or if something glaringly bad had immediately occurred following the boot & login, or then my launching of my regular programs, i suppose it would have been reasonable of me to speculate a higher than average probability of the root cause being the incomplete 4.9.9 installation. Ie, solving those 2 errors would be critical.

Conversely, it's now several hours later & so far Tower is still going great. That fact does not yet prove that my 4.9.9 is "perfect", or even "good enough", but it must lower the probability of my new kernel being "bad". It also certainly does not yet prove that the new kernel has finally fixed those accursed chronic Maui freezes [though i hope it has], coz history shows that several days can elapse between freezes.

However, as more & more time elapses [hours, days, weeks?], with/if Tower remaining "happy", the probability of my 4.9.9 being "bad" must logically get lower & lower. But here's the philosophical [unanswerable] bit... what if Tower stays good for say, 3 weeks or 2 months, but then one day after that it seriously falls over? I mean, there's no way i'd be able to rationally attribute that putative crash to my 4.9.9 after so much [fingers crossed] uneventful time. Between now & then i might have installed new programs, made various system changes, upgraded to Maui 3.7 [ ;-) ] etc, any one or combo of which might be the real culprits.

Given that me / you / nobody could factually answer the timing of the above speculative events, i suppose that means it's not actually possible to know how many more hours/days i should wait, then if still nothing bad had happened, i would know it's safe to permanently forget about any need to fix those initial 4.9.9 make errors.

Alternatively, a counter-view might be i should proceed immediately now to try to fix my 4.9.9, which would then unequivocally rule out my new kernel as root cause in ANY future crash, regardless of how far into the future, & despite the fact that at time of writing now everything seems excellent...?


BTW the answer to the question you're probably asking yourself as you read this crap ["why the hell did she waste all her time writing that, rather than just grasping the nettle & fixing the kernel?"] is that whilst following the procedure in that link you supplied is doubtless trivial & easy for experts like you, it is complicated & confusing to people like me. Ie, i'll try to do it if i really really really have to, but if i can avoid it without my Tower suffering, then i will.

[leszek]

The ndiswrapper module is a driver to make unsupported wifi cards work by using the windows driver.
As you don't have that, don't need that don't worry about it.
There is no need to philosophize about that either. Its just one thirdparty driver like the proprietary nvidia or virtualbox (vboxdrv). The "normal" modules of the kernel are precompiled and already included in the kernel package itself.

[kdemeoz]

Oh that's fabulous news! Yes, my Tower does not have WiFi [only my Lappy does, but it does not suffer any of the system freezes]. OK then due to your kind help i now have a shiny new nice 4.9.9 in my Tower -- something i'd never have known how to do by myself. Thanks!!

I really really hope this now eliminates all those freezes.

[kdemeoz]

For any further topic-updates re freezes but unrelated specifically to VirtualBox, see https://forums.mauilinux.org/showthread....1#pid41691