Any and all help would be so greatly appreciated. I've been battling with my laptop to be able to dual-boot Ubuntu Cinnamon and Windows 10 for about four days now. I've probably gone down five or six different rabbit-holes of troubleshooting, GRUB command-line fun, reinstalling and updating the BIOS, trying and failing to deal with VMX and locked NVram. As of now, my system boot-loops and fails to run Windows, but paradoxically I am able to get Ubuntu running, which is what I am using now.
I'll try to provide as much relevant information here as I can:
- Device: HP ZBook 17, gen 6
- Primary OS: Windows 10 Home
- Linux distro: Ubuntu Cinnamon 23.10
- Ubuntu location: /dev/sda3
grub-install --version
= 2.12~rc1-10ubuntu4- boot-repair Boot-info summary: https://paste.ubuntu.com/p/rxZ3D5GtpP/
- I'm more than happy to provide more information as it's requested.
As of now, I am unable to run Windows through the BIOS. If I run via the dedicated SSD as I normally do, it boot-loops, and if I try to go through any other drives it just tells me I need to install an OS. I am currently able to run Ubuntu, but only by going through the following process:
- Startup menu
- Boot configuration
Boot from EFI > Ubuntu > shimx64.efi
At this point, I am happy with two outcomes to this scenario:
- I am able to run my laptop with Windows 10 as the primary OS, with the ability to dual-boot to Ubuntu Cinnamon 23.10.
- Assuming option 1 is impossible/requires a Herculean amount of work to pull off from this state, I am willing to scrub Windows 10 from my laptop and move forward with Cinnamon as my daily driver, though I am rather inexperienced in it. I can learn to move forward as I need to and run a VM or WINE for any Windows-specific processes I still need to do. But I would rather keep this option as my dead man's switch.
❤️
From what I can see, this isn't that big of a deal. It's just a warning (technically it is an error, but, essentially it's a warning), that Virtual Machine Extensions aren't enabled in the BIOS. Unless these are required for the boot process of your distro (which I seriously doubt), it shouldn't cause you any problems, unless you explicitly require their functionality for some other program.
That's... strange. Are you certain that it isn't the converse? Very strange that enabling the TPM would cause issues. It could certainly make sense for it to cause issues if the TPM was in use, and it was disabled.
In case you are unaware, the TPM is essentially a chip on the motherboard (in most cases, anyways -- it potentially could be in a different form within the CPU e.g. fTPM)
It's completely possible, and I would certainly not discourage it's use -- especially if the device is a laptop. It's, of course, not the be-all and end-all of security, but full disk encryption with a TPM is definitely a good first line of defence. Obviously, it's better to manually input the encryption password, rather than having it be released by the TPM, but I certainly wouldn't blame someone for opting for the more user friendly alternative.
For sure! If you are comfortable in your work flow, then by all means stay wiht it. Ethically, though, it of course doesn't hurt to keep FOSS alternatives to proprietary software in the back of your mind 😊.
It sort of depends on exactly what you mean by that, but I certainly wouldn't argue with the colloquial statement that it's more "complex" -- especially the installation.
Absolutely! And if you want to go another step further in that understanding, then I would recomend looking into Gentoo.
I think I may know what you are talking about with this. I have experienced issues with external HDD's going to sleep when they are being read from, or written to, but I attribute that to USB sleep modes. So, if you are referring to an internal SATA drive, then I'm not sure what would be causing that issue.
I would caution against using the
-l
/--lazy
flag. It may present you with unintended consequences. It woudl be better to find what process is keeping the dive busy before attempting an unmount.[source]
Out of curiosity, is there any particular reason why you're using the userspace NTFS driver, rather than the included kernel driver?