Completely Removing Windows - EFI

[SlidingHorn]

I have a laptop that I'm going to completely remove Windows and install Debian...well..I already did, but I think I'm going to have to do it again:

At the beginning of my drive, there are 2 partitions (EFI System & "Microsoft Reserved") that I *figured* shouldn't be deleted. Is there anything wrong with me wiping them and starting over?

The only real live environment I have is a TAILS disk(I installed from a minimal iso), so I can't fstab, but here's what they are (in disk order):

sda1: 237 MB FAT (EFI System)
sda2: 134 MB Unknown (Microsoft Reserved)
sda3: 30 GB Ext4 (root)
sda5: 4.2 GB Swap
sda6: 446 GB Ext4 (/home)
sda4: 20 GB NTFS (Windows Recovery) I honestly don't care if this is left - only left it in the event of a head injury that causes me to want to go back to MS

So the question is: Do I wipe 1,2,3,,5,6 (maybe 4) and just start over on the install, or is the EFI system required? As of right now, it still attempts to find and boot a Windows OS rather than going to GRUB.

[SlidingHorn]

Bonus Question: At some point I'd turned on Legacy Support and disabled Secure Boot...is that/was that necessary? I.E. Once I have the above issue sorted, should I just go back to SB?

[SlidingHorn]

Okay, so I'm kind of getting further along in my google-fu here...

My understanding is that the EFI partition is necessary, but I'm still not sure about the "Microsoft Reserved" one, so I could use some input there.

I'm also understanding that Debian does not yet support Secure Boot, so I should therefore leave Legacy Mode enabled.

So now my (evolving) questions are:

1) Can/should I delete sda2 (the Microsoft Reserved partition)
2) Can/should I delete the Windows Boot Manager entry from efibootmgr? (See below...0002 was an old ubuntu install I deleted a long time ago)

Code: Select all

amnesia@amnesia:~$ efibootmgr
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0001,3001,0005,2001,2002,2004
Boot0000* Notebook Hard Drive - TOSHIBA MQ01ABF050
Boot0001* Windows Boot Manager
Boot0002* ubuntu
Boot0003* USB Hard Drive - USB     Flash DISK
Boot0004* USB Hard Drive (UEFI) - USB     Flash DISK
Boot0005* debian
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot3001* Internal Hard Disk or Solid State Disk

3) I'm assuming that running the following would cause a boot straight to GRUB rather than it looking for Windows (although, I also assume deleting the Windows entry above would do the same)

Code: Select all

sudo efibootmgr -o 0,5

[SlidingHorn]

More progress - Per Wikipedia, "[...] No meaningful data is stored within the MSR [...]" - So that's good to be deleted.

My (hopefully) last part of this problem is that when I remove the entries (I've only tried the old ubuntu one so far from the EFI partition using

Code: Select all

#efibootmgr -b 2 -B

in a Live environment (TAILS) the change doesn't persist when I reboot.

[Wheelerof4te]

Bonus Question: At some point I'd turned on Legacy Support and disabled Secure Boot...is that/was that necessary? I.E. Once I have the above issue sorted, should I just go back to SB?

Just delete entire disk, you don't need MiS reserved partition. For UEFI Debian installs, you need EFI partition which is fat32 system partition of around 500MB.
IIRC, Debian will make it automagically if you choose "use entire disk" during install.

Backup your data, reinstall Debian on one partition if you are not going to dual-boot. Doesn't make sense to have separate /home partition if you are going to stick with Debian and you're an only user. 30 GB for root partition is too small nowadays.

EDIT: If you ever get the need to return to Windows from Debian, here is how:
http://forums.debian.net/viewtopic.php?f=3&t=136138

[Head_on_a_Stick]

I'm also understanding that Debian does not yet support Secure Boot, so I should therefore leave Legacy Mode enabled.

Enabling "Legacy" mode will disable UEFI completely thus rendering the NVRAM entries irrelevant.

If you want to install a non-UEFI system then I would recommend wiping the GUID partition table on your device with

Code: Select all

# sgdisk --zap-all /dev/sdX

Then create a fresh msdos ("MBR" style) partition table on the disk.

It may be possible to install & boot a non-UEFI system on your current GPT disk if you create a BIOS boot partition (type "ef02" in gdisk) for GRUB (or I think perhaps SYSLINUX can do it directly without the special partition, I'm sure @p.H will be able to confirm or deny this) but this method is firmware-dependent and may not work on all devices.

For a non-UEFI system no special partitions are needed but for a UEFI system you will need a FAT-formatted EFI system partition (type "ef00" in gdsik) to hold the .efi loaders.

If changes to the NVRAM entries are not persisting then your firmware may be generating the Windows & Ubuntu entries on-the-fly, try removing their .efi loaders (bootmgfw.efi for Windows & grubx64.efi for Ubuntu) from the EFI system partition.

[SlidingHorn]

If changes to the NVRAM entries are not persisting then your firmware may be generating the Windows & Ubuntu entries on-the-fly, try removing their .efi loaders (bootmgfw.efi for Windows & grubx64.efi for Ubuntu) from the EFI system partition.

IgnoreBy NVRAM entries you mean the following whole directories?

Code: Select all

/boot/efi/EFI/Microsoft/
/boot/efi/EFI/ubuntu/

[Head_on_a_Stick]

I think just removing the respective .efi loaders will be enough but yes, you could move the folders in their entirety.

[SlidingHorn]

Just by perusing, I see that there's actually a grub.cfg in the ubuntu folder, but not in the debian one...Odd. (maybe debian saw it there during install and decided it didn't need to make another?)

I think what I'm going to do is delete those aforementioned directories, wipe everything after the EFI partition, and just reinstall and hope for the best from there

EDIT: There's a grub.cfg in /boot/grub. The one in the ubuntu directory just essentially points to it.

[p.H]

Just by perusing, I see that there's actually a grub.cfg in the ubuntu folder, but not in the debian one...Odd. (maybe debian saw it there during install and decided it didn't need to make another?)

It appears that Ubuntu puts all GRUB EFI files in the EFI partition whereas Debian puts only GRUB EFI core image in the EFI partition and puts the other files, including grub.cfg, in the traditional location /boot/grub.

IMO this is not a bad idea to put all GRUB files in one single filesystem because it makes GRUB more independant. With the traditional (Debian) way, if GRUB core image cannot find the filesystem containing /boot/grub for any reason (deleted, moved...), all you get is the very limited grub rescue shell. With the Ubuntu way, you get the full featured grub shell.

By NVRAM entries you mean the following whole directories?

No, NVRAM EFI boot entries are what is displayed by efibootmgr. However custom EFI boot entries usually point to EFI executable files in /boot/efi/EFI.

If you want to install a non-UEFI system then I would recommend wiping the GUID partition table

I would rather not, unless the UEFI firmware is badly broken and won't boot on GPT in legacy mode. GPT is more robust than MSDOS, more convenient if you have more than 4 partitions and has nice extra features such as filesystem independant partition UUID and label.

It may be possible to install & boot a non-UEFI system on your current GPT disk if you create a BIOS boot partition (type "ef02" in gdisk) for GRUB

Actually GRUB BIOS does not require a BIOS boot partition when installed in the MBR of a GPT disk if /boot/grub is on a plain partition (not an LVM logical volume or software RAID array) containing a "regular" filesystem type (ext4, but not btrfs) on the same disk. However it is strongly recommended, because embedding in the BIOS boot partition is more reliable than using blocklists on a filesystem.

or I think perhaps SYSLINUX can do it directly without the special partition, I'm sure @p.H will be able to confirm or deny this

Am I famous already ?

I have no experience with installing syslinux but indeed I have read that it can install a boot program in the MBR of a GPT disk which chainloads the boot sector of a partition which has the "legacy boot" attribute set (note that this is different from the "boot" flag displayed by parted and Gparted, which actually means "EFI partition" on GPT). I guess you also have to install a secondary boot loader in the partition boot sector.

For UEFI Debian installs, you need EFI partition which is fat32 system partition of around 500MB.

Actually Debian needs much less that 500 MB. The partition need to contain one or two copies of GRUB EFI's core image whose size is less than 1 MB. Note the EFI partition size in Debian installation or live ISO hybrid images. However disk size is cheap and it is wise to reserve space for future growing needs.

when I remove the entries (I've only tried the old ubuntu one so far from the EFI partition using
efibootmgr in a Live environment (TAILS) the change doesn't persist when I reboot.

This is weird. I have observed that EFI boot entry management is broken in some way on many UEFI implementations. Is it possible to delete the boot entries from the EFI firmware setup ?

So now, on non-multiboot EFI systems, I do not rely on EFI boot entries ; I install GRUB in the "removable device path" which does not require to register a boot entry with efibootmgr. This way the disk remains bootable even if the EFI boot entry is deleted or if the disk is connected to another EFI machine. What I usually do in the hope that the disk can be booted in most cases :

- create a GPT partition table
- create both EFI and BIOS boot partitions
- install both GRUB EFI (in the removable device path) and GRUB BIOS

I'm also understanding that Debian does not yet support Secure Boot, so I should therefore leave Legacy Mode enabled.

Debian does not support secure boot yet, but it does not require legacy mode. Debian supports native EFI mode if secure boot is disabled.

1) Can/should I delete sda2 (the Microsoft Reserved partition)
2) Can/should I delete the Windows Boot Manager entry from efibootmgr?

Yes. You can also delete the EFI/Microsoft directory (which contain the main Windows boot loader), the EFI/ubuntu directory (which contain GRUB installed by Ubuntu) and the files in the BOOT/ directory (which probably contain the Windows rescue boot loader) on the EFI partition.

[Segfault]

Actually, any Linux can do secure boot. http://www.rodsbooks.com/efi-bootloader ... ing_signed

[Head_on_a_Stick]

Am I famous already ?

Well, you clearly know more than me about this sort of thing, thanks for the lessons!

[Segfault]

I suggest spending a little time at rodbooks.com. I did, when I got my first EFI board. Among other things you will learn about UEFI quirks and possible workarounds for buggy firmware.

[p.H]

I second this suggestion. Time spent reading rodsbook.com is not wasted when you're messing with or are just interested in EFI boot or GPT.

[SlidingHorn]

Thank you all for all this helpful info! In the end, I just deleted the directories (the windows & ubuntu ones) in full from the partition, then removed the "Microsoft Reserved" partition (which was separate), and reinstalled.

I set the BIOS to disable legacy mode, and disable Secure Boot, and now everything boots wonderfully.

I think the whole "legacy mode" thing was following some unnecessary advice when I originally installed ubuntu back in the day.

[p.H]

Using legacy boot was not a wrong advice. In my experience, UEFI boot has been so far more troublesome than useful. The only situation where it provides a real benefit is multiboot with other operating systems such as Windows or distributions. I have yet to see another situation where UEFI provides a real benefit. Handling of > 2 TiB drives ? No : GPT is compatible with legacy BIOS and BIOS can handle much more than 2 TiB. I have read that UEFI mode may be required to boot from NVMe, but I suspect this is because motherboard manufacturers do not bother to implement NVMe support in legacy mode.

[Segfault]

There may be an additional step needed with GPT and CSM boot (aka legacy boot), depending how poorly written the firmware is. You may need to create a protective MBR in addition to GPT and set the bootable flag. This procedure is not destructive, although as always, have a backup of your data.

[p.H]

The protective MBR is part of the GPT format and already exists, but indeed some broken BIOS or UEFI firmwares require to activate the boot flag on the protective GPT partition.

[Segfault]

The protective MBR is part of the GPT format and already exists

I have seen GPT without protective MBR, perhaps not all partitioning tools comply.