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.
The exact meaning of the language in use is somewhat context dependent. It is technically possible to use a block device (e.g.
/dev/sda) [source] as a filesystem, but it is generally discouraged -- afaik, this is generally because of compatibility reasons. As to the meaning of a statement that looks something like "Install Ubuntu to/dev/sda" this could be interpereted as essentially just rewriting the existing partition table that exists on that drive with a new one, where, for example, partition 1 (e.g./dev/sda1) is for the boot partition, and partition 2 (e.g./dev/sda2) is where Ubuntu lives. In that example, technically Ubuntu is only resides in/dev/sda2, but, for the whole installation process, the user can interpret it as essentially installing it all to/dev/sda.It's worth understanding the boot process of a system (this is more taylored to an average Linux system, but can be generally applied, if one is careful):
0x7C00So, back to your statement, the actual program of Grub could reside in
/dev/sda2, but the "bootloader bootsrapping" program, which resides in the first 512 bytes of the disk, could be thought of as being installed to/dev/sda.[source], [source], [source], [source]
The only real "hard" limit on the location of Grub is that, in the case of MBR, it necessarily must be located within the first 2.2 TB of the disk.
[source], [source], [source], [source]
As I outlined above, this is sort of a technicality in language that depends on context.
I'm not sure if this is exactly equivalent to that software, but perhaps you would be interested in MuseScore -- it's open source.
This has been somewhat exaggerated through memes by the community, and strange elitism. It's a bit tough to separate oneself from their curse of knowledge, but if one possesses the motivation to learn, it's really not that complicated. Depending on one's existing knowledge, it may initially appear daunting, but the community is quite good, from my experience, and the Arch Wiki is extremely useful. Installation is essentially a matter of just following the installation guide step-by-step.
Imo, arch has nothing to do with that. If one wants to be a part of that then prob lurking around the Kali Linux communities would be a start. Do note that I am not speaking about Kali Linux from experience, just hearsay, so take that with a grain of salt. But, yeah, Arch is more for people that want more fine-grained control over their system without wanting to get into the full-time job that is something like Gentoo 😜.
Imo, that's not really what arch is -- even Gentoo isn't like that. The closest to that would probably be something like Linux From Scratch. Arch just gives you more freedom to choose the base software that your system is using -- stuff like your DE, your networking utils, display server, audio server, etc.
I would like to emphasize that this kind of choice exists with virtually all Linux distros -- as in you can essentially make any distro "look" like any other (there may be some intricacies that I am unaware of that may get in the way of changing some things without having to alter others); Arch Linux simply gives you most of the choice right up front.
It's always a heartwarming experience seeing someone passionate about a subject enough that they'd be willing to dedicate what was likely at least twenty minutes of their own free time to writing a detailed response to a stranger on the internet.
Your explanation was very helpful in explaining the process by which the BIOS is loaded. As I've continued to work on Ubuntu, I've been trying to hammer out little errors along the way and I believe that I inadvertently identified the problem with my dual-booting situation before. Whenever I load Linux, the system will load that ubiquitous screen where it does a filesystem check, etc, and I always get two errors: (1) VMX (outside TXT) disabled...; (2) ima: error communicating with TPM. I went into the BIOS and figured out how to turn the TPM on, and when I did so... what do you know, I started boot-looping again, just as before. Apparently I'm going to have to do a bit of troubleshooting to get Linux operable with the TPM, if I care enough about it to just undo a simple error message on boot-up that has no impact on my actual computing experience. But having his TPM chip before was causing boot-looping, perhaps due to a security issue with grubx, who knows, but for the time being I'm putting it on the back-burner.
I appreciate the thought, and yes Musescore has been on my periphery a good percentage of my 15 years of using notation software. Musescore is an admirable project and I'm impressed with the steps its taken in the last few updates. Frankly, this has probably been the fourth or fifth time now that someone has hocked Musescore as a FOSS alternative to Finale, and while I get it, they are not truly one-to-one in compatibility, at least not yet. Finale is a boutique program, designed for professional use and it's very feature-rich, especially as one gets into more specialized concerns in terms of unusual notations, etc. Finale works just fine on my system and I don't intend on changing away from it anytime soon. I've been using it for so many years, it's like second-nature to me. I couldn't imagine dropping a software I spent hundreds of dollars on now for something else if I still get great mileage out of it.
Following the last time you and I communicated, I actually saw a video from SomeOrdinaryGamers where Muta did a step-by-step installation of Arch on a new machine. It certainly seems more complex than Ubuntu, but at the same time, boy does it give you a rich experience in learning the intricacies of your system and how everything functions together. I am definitely going to be keeping Ubuntu on my main system for the time being, but I do have a blank ZBook15 gen 2 (I believe it has Mint on it right now? I haven't opened it in a few months...) and I might have a go at installing Arch on it and messing around for a while.
My current project is going to be taking my secondary HDD, which is only a storage device now, and configuring its file structure to be easier to use with Linux, as well as clearing out all the legacy OS files from when it used to have Windows on it. I've been having trouble using utilities like
rm -rfbecause for some reason, some files will delete with no issue, but then others will actually cause the drive to crash in some spectacular fashion, and I have tosudo umount -lthen remount again withntfs-3gjust to get back to it. I can't tell if its a permissions issue or something else. I know the drive is old and there are four damaged sectors, but the most recent SMART test didn't seem to throw up any major red flags. I can delete individual problem files, but trying to delete a bulk quantity runs into issues at times. It's weird. I don't exactly want to format the drive because there's ~0.9TB of personal files on there (that are all backed up both on a cloud service and an external SSD, no worries!), but so far I'm having fun learning some new commands.❤️
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/--lazyflag. 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?