Total removal of MS bootloader

Tl;dr: After deleting an unused NTFS partition, an errant Windows Boot Manager somehow created an all new partition on its own. I want to kill all things Microsoft on this machine without totally wiping every drive.

I was really hoping not to have to ask another question so soon. When I shut down last night, everything was fine. This morning, when I started, it took so long that I actually hit reset assuming it was stuck, more than once. Eventually, I waited it out, and I got to the usual prompt requesting that I unlock the keystore (my install is encrypted; this is normal). I did so, and from that point on, things ran normally, until I tried to use Bottles, which couldn't find its bottles. This is because I have Bottles set up to create bottles on a separate drive, so when I distro hop, I don't have to download multiple gigs of games all over again to test performance.

Last night, I had three partitions: two ext4 and one not-actually-a-partition (free space from a deleted NTFS partition). This morning, I had all three of those, plus a "Microsoft Reserved." Looking at where my bottles should have been (~/.big bottles mounting the partition under home) showed me an EFI directory and similar.

In other words, Windows took umbrage at being deleted, and from the grave, created a new boot partition that's screwed stuff up. Deleting that partition entirely and rebooting fixed my bottles, but I still have a Windows Boot Manager entry in my UEFI somehow. In the interests of keeping this from ever happening again, how might I completely expunge all things Microsoft? At my skill level, thorough backups and then deleting every single partition from a live USB and starting fresh is my only option, since I don't know where this zombie partition came from. I'd like something less destructive.

I explained here how You can come to the EFI-Folder on Linux:

Because I have a Dual-Boot System with Windows You see there a Microsoft Folder (that is the Microsoft Boot Stuff). When You should have that too there, You could delete the Folder.

1 Like

That did in fact get rid of the irritating, unnecessary Microsoft entry in my UEFI, thank you! I'm still suffering a very long delay between POST and being prompted for the keystore password though. Any thoughts on what might be causing that?

Check your BIOS settings.

Your first post included your problem, drive encryption. Remember encryption will look at your entire system and if something is out of place, this is when systems break. It is why I never use encryption.

2 Likes

Sorry, with Encryption I can't help You. I don't use it and have no Idea of it.

But one Question: Do You use a third-party Tool for the Encryption?

This may be the case. This is post recovery from full system backup, and as noted above, MS threw in a new partition. That was on a different, unencrypted drive, but it's not too hard to imagine one little thing being off during restoration could force the system to go to lengths to access something. I'd honestly be content with encrypting just /home and putting that on a separate drive, but the only options for encryption I saw at install were for the whole system. I can't speak to the security of either implementation, but in terms of ease of use, Bitlocker has Linux beat. So did TrueCrypt and VeraCrypt on Windows. Why Linux's whole drive encryption is so arcane is another topic though, and possibly for a less-Zorin specific venue.

We haven't exactly proven the encryption is at fault here, but it seems plausible enough I'll mark this solved and live with it for a while to see whether or not I need to out myself through a teardown and reinstall. Good time to test the r2 ISO if so.

@Ponce-De-Leon No, the encryption I'm using is what Zorin offers at install.

No need to mark as "Solved" if not actually solved.
If a solution is subsequently found, or you end up doing a reinstall, then come back with the result. If then solved, you can go ahead and mark as such, which may help others.

Fair enough. I didn't want a lingering thread to clutter the forum is all. I do have a couple of ideas for experiments, but one takes 2+ hours (restoring the backup again and killing the MS partition and EFI directory before it can do anything) and the other may not work at all. We'll see...

...oh yeah. It's encryption somehow. When I ran Zorin boot repair, it told me I may want to mount my encrypted volumes so it can include them. They're... they're mounted. That's what the whole OS is on. I couldn't use it if they weren't. SOMETHING ain't right there. <_<

1 Like

You have got 3months before the thread gets automatically closed, so no panic.

As others have already mentioned, encryption adds a extra layer of complexity when troubleshooting.

So BitLocker has GNU/Linux beat? I beg to differ:

I would not say encryption is at fault for MS appearing in the EFI partition with a bootloader. That it did, strongly implies that there is another present partition on the drive for Microsoft Recovery.
What encryption does, however, is make it harder to access and modify elements of the drive since the entire drive is encrypted. This is a lesson in hindsight.
Prior to encrypting the drive, elements the user wants modified need to be addressed. Once you know, that is a fine thing but if you did not know before committing to the encryption, you end up stuck with it or wiping the drive and reinstalling.
Encryption on GnuLinux is not arcane. In fact it is quite advanced and complex. I would say it is not user-friendly for the daily driver. But it does not need to be as that is not what it is for.
It is over-powered, by far, for the average daily driver. If you do not work for the CIA or Coca Cola, you simply do not need the massive Iron Dome that LUKS encryption offers.

A user can use PAM to add additional password protection to the Home directory or install cryptfs-utils, then migrate their home directory to it: sudo apt install cryptfs-utils sudo ecryptfs-migrate-home -u $USER
Or use Gnome ENCFS to do encrypt specific files or folders.

1 Like

I would not say encryption is at fault for MS appearing in the EFI partition with a bootloader.

Ah, no, by that point I was referring to the long delay at boot. Encryption is surely not responsible for the appearance of Microsoft, or the partition appearing on the non-encrypted drive.

Encryption on GnuLinux is not arcane. In fact it is quite advanced and complex.

I think we may be working from different meanings of "arcane." When I say encryption on Linux is arcane, I'm referring to the definition given by dictionary.com: "known or understood by very few; mysterious; secret; obscure; esoteric." That it is not friendly to the end user is largely because it's obscure and (relatively) mysterious, compared to Bitlocker, where you can turn it on and off pretty freely. If it breaks, the data loss is the same, but there are no mysterious rpool and bpool partitions, the recovery key is easily preserved (provided you do it in advance, of course), and so on.

It is over-powered, by far, for the average daily driver. If you do not work for the CIA or Coca Cola, you simply do not need the massive Iron Dome that LUKS encryption offers.

I don't work for Coca Cola. The company I work for has a market cap almost 10 times larger, and my work PCs are required to have whole drive encryption on at all times, but are Windows machines. My personal machines I prefer to encrypt, but do not have to, and it had gone quite well until the shenanigans that started this thread. Thank you for the information on manually protecting the home directory; that's of use to me.

@swarfendor437 Please double check what I wrote. I said BitLocker beats Gnu/Linux encryption for ease of use, after specifically disclaiming that I can't speak to the security of either. I try to be very careful not to overstate what I know, especially on Linux forums, where I'm a rank amateur. Were I having delayed boot due to BitLocker, I'd turn off BitLocker on that drive in under 30 seconds (then wait however long for decryption of course). That is assuming I hadn't hit something like the bluescreen in your last link.

Edit: upon further consideration it occurred to me that you may consider those bugs and general failings you linked ease of use issues. I don't, on the grounds that they're bugs, but they certainly do speak poorly of BitLocker in general.

1 Like

I agree, Bitlocker is more user friendly than LUKS. I am going to go out on a limb and mildly argue semantics... :stuck_out_tongue:
LUKS is not poorly understood or only understood by the few. Not anymore than Bitlocker is. Do you understand the inner workings of BitLocker? it is not user-friendly with its use for a daily driver. It is over-powered for the average person.
This does not mean you cannot or should not use it. But its usage comes with a trade in costs and risks.
An analogy might be that you go to the auto dealer and request a rugged vehicle that you can take off road, resists shopping carts in grocery store parking lots and can tow. They look at their stock and offer you an M1A2 Abrams tank, because everything else they have in stock is a Ford Fiesta style vehicle.
Now, in a brief and juvenile moment, having a tank seems pretty cool. Might be handy in slow traffic...
But in practical use, its problems and over-powered nature vastly outweigh any hopeful benefits. It's rugged. It can go off road. It can resist shopping carts.
But maintenance? Forget about it. Changing a flat is not something you have to worry about, but you will need an M-88 support vehicle to change a track.

You have power you cannot use... Heavy traffic - what are you gonna do, shoot the gun at people? You can't do that. Or drive over there cars? No. It's not worth all that.

I think part of the reason developers show little interest in encryption security on GnuLinux is because GnuLinux already tends more secure. So when users thought they needed something, like peace of mind, they threw their M1A2 Abrams LUKS Encryption out there because it is what they had, then focused their attention back on what they were working on before being pestered about added layers of security that most users don't need.
You are right: It isn't user friendly as a whole: Gnome ENCFS is a bit of a hair-puller and configuring PAM, I would qualify as a nightmare. You might begin the process, look up multiple guides, read many pages, before taking a shower, curling up on the bed and suckling your thumb to sleep, giving up on all things in life and reverting back to infancy when things seemed much easier.

What you might do is check what you need for your home use. A fully encrypted LUKS drive... probably not. And BitLocker does not offer what LUKS does.
A similar option may be a vault which has been my own preferred method for over a decade- A dedicated separate drive for sensitive data and files that need protection.

I get the point, honestly, though I stand by arcane, given the "known or understood by very few," though I might revise to its usage is arcane, because you have a point: both are arcane in their inner workings. The math behind encryption itself is; that's why cryptography is a field with genuine experts. Anyway, this is a bit out in the weeds.

I get your point regarding the power of the encryption LUKS provides not matching the use case, and you're generally right. I'll also cop to a bit of paranoia: the odds of someone stealing my drives and mounting them is vanishingly small, but it's not irrelevant to me, even if perhaps it should be. My real use case is that I want any files I generate encrypted, and I don't want the applications' caches/temp files to be usable to work out what my data is. This includes browser history, cache, and so on even if mainly I'm out to protect spreadsheets and word documents. I don't care so much about keeping Steam games, or applications' own files encrypted. Given my limited Linux literacy, that seems like at a minimum, I need /home and MAYBE /var for everything I could want. I could be mistaken, and everything I care about could be in /home.

On the other hand, given that this debacle seemed to start with some remnant of Windows on another drive, and given that I may need to reinstall to sort out the delay at boot, another option might just be to completely wipe all drives and resume whole drive encryption, since it'd been working just fine, right up until Microsoft got involved.

Gnome ENCFS is a bit of a hair-puller and configuring PAM, I would qualify as a nightmare. You might begin the process, look up multiple guides, read many pages, before taking a shower, curling up on the bed and suckling your thumb to sleep, giving up on all things in life and reverting back to infancy when things seemed much easier.

I started that process once, actually, before settling on Zorin. My eyes glazed over in a matter of seconds.

This happens to me often. I have had to learn the hard way that your options are to roll up your sleeves or give up.
I usually roll up my sleeves... but not always. Last night being a case in point where I quit, gave up, threw in the towel and said "100% nope" to a complicated bit of graphical driver software.

Sounds like a plan - given how you describe what you want. Whether LUKS is over-powered or not is not relevant. Feeling like you are accomplishing your goal is and if someone did get your hard drive and that has spreadsheets - I would be eating crow if I advised otherwise. Once all partitions are completely wiped and sorted, I cannot see any way Windows OS could add a partition on the drive at that point.

1 Like

Finally tracked down the cause of the long delay. Not actually encryption, so my reinstall was a waste of effort, apart from the fact that booting from live USB let me see errors that Zorin wasn't displaying (since it doesn't normally display the full output while booting). This was the offender, answered in an 11 year old StackExchange post.

In the end, I needed to unplug my computer for a few minutes as the comments suggested, because of some electrical issue with a USB device.

1 Like