2

I Reinstalled Linux Parrot Security 3.9 Kernel Version 4.14.0 86_64 over an installation of Kali 2017.3 (ironically same kernel version of Debian right now) 4.14.0 86_64.

Now I partitioned the HDD fully, Manual like always, /dev/sda1-boot 512M,/dev/sda2-swap 8G,/dev/sda3-/root-25G, /dev/sda4 /home-rest of partion size.

I have 2 HDD's in correct order to boot linux first unless I hit F11 the Linux HDD is in the first SATA cable slot, and I have a separate Windows HDD on the Second SATA cable slot. I prefer not to Dual Boot Windows with Linux on the same HDD.

Normally when I power up I hit F11 for boot options, both HDD's show up and I select accordingly, I use Windows for Gaming, and Linux for everything else.

But now when I hit F11 the old Kali is still in the first option as /dev/sda3 Windows comes up as the second option to boot into (as it has for over a year now with this setup) but Parrot is also coming up on /dev/sda3 (same as Kali which should have been overwritten) I can Select /dev/sda3/Parrot and it works fine. Windows works fine, but if I select the /dev/sda3/Kali (which should have been over-written) it boots into a grub error and I have that grub rescue> prompt.

Lastly, the way I have always cabled this was Linux boots unless I hit F11 and Select Windows HDD, but because I'm getting this Grub Error Grub Rescue> and the last Kali's Grub didn't get removed it seems, I always have to hit F11 now. It’s not like I can't get into my new Parrot OS, built on identical Kernel as Kali now, the Debian 9 just a different repo update method I think. It works fine, I just want my system to be as correct as possible.

What should I do? I seem to have conflicts with /dev/sda3 having a real Distro on it, and another one thinking it does when it does not?

1

Hitting F11 sounds like you're accessing a BIOS boot menu. If it contains operating system names like Windows, Parrot or Kali, then this is a clue you're probably using UEFI-style boot.

If that's true, then the most convenient way to get rid of the remains of Kali is to use the efibootmgr tool in Linux.

In UEFI-style boot, three things about the bootloader are stored in the NVRAM (= the place where the BIOS settings are stored):

  • the UUID of the partition that contains the UEFI bootloader for a particular OS (this is usually a small FAT32 partition, known as the ESP, or (U)EFI System Partition )
  • the name of the bootloader file for that OS
  • a descriptive name for that OS

Even if you completely remove the bootloader of a particular OS and overwrite all the partitions it had, this information will still remain in the NVRAM. Some UEFI firmwares will offer a way to delete any obsolete boot settings through the UEFI BIOS settings menus, but unfortunately there are UEFI firmware versions on the market that don't have that option.

When you run efibootmgr -v in an UEFI system, you should see the list of UEFI boot settings that is currently stored in NVRAM. There is the BootCurrent value that identifies the boot option that was most recently used to boot the system. There is a Timeout value that is usually set to 0. Then there is the BootOrder list that identifies the order in which the firmware will try the various configured boot options: each boot option is identified by a 4-digit number, like 0000, 0001, 0002 and so on.

And finally, there are the actual boot options. Each boot option line will list the four-digit number of the boot option in the form of "BootNNNN" (e.g. Boot0000 for the first boot option). Then there will be the descriptive name of the OS, and then the bootloader partition UUID and the bootloader file pathname on that partition. At the end of the line, there can optionally be some parameters for the bootloader.

To get rid of the remains of the Kali boot option, find its four-digit number in the list. Then you can use efibootmgr -B -b NNNN to delete it.

For example, if you see that Kali was the boot option Boot0002, then you can remove it with:

efibootmgr -B -b 0002

The efibootmgr command must be run as root (or prefixed with sudo).

  • Fixed it instantly, thanks for your valued support :) All my OS's even windows were listed as EFI boot. Deleted the Kali on 0002 using efibootmgr -B -b 0002 and binbo everyones back to normal. Weird because ive installed Linux Mint/ UbuntuDesktop&Server/ DebianDesktop&Server/ Suse/ Arch /BlackArch /Mandriva and quite a few others :Linux Distros and this never happened before. – user265608 Dec 13 '17 at 20:06
  • Depending on which OS versions you have used, they might not have had native UEFI support yet, and so had used the legacy BIOS boot compatibility that is built in to practically all UEFI BIOSes on x86 hardware. I think most major Linux distributions have so far had only one or two major releases with production-quality native UEFI support. – telcoM Dec 13 '17 at 22:38
  • Windows has the bcdedit command which can be used to modify UEFI boot settings - but compared to efibootmgr, its user interface is atrocious in my opinion. I would recommend Hasleo EasyUEFI for any multi-boot UEFI systems that include Windows, just in case you ever need to edit UEFI boot settings from the Windows side. – telcoM Dec 13 '17 at 22:44
0

I'm not to experienced with asking for help on here. If A mod can recommend the correct place to ask this, and or help me transfer it to the correct forum, thanks a bunch in advance and I apologize ahead if this is the wrong place.

You are right, here, that's good! However, Parrot Security and Kali are security-centered distributions, not for the faint of heart! You are expected to be experienced Linux admin when you use those.

Basically, you have a problem that the old Kali grub entry is still there.

The grub configuration is stored in /etc/grub.d/* so you have to make sure that no file in there contains an entry for Kali, that the Parrot Security entry is there. Then you run sudo update-grub and it should fix your problem.

To check Kali is not there: grep Kali /etc/grub.d/* then grep Parrot /etc/grub.d/*, if both commands find "stuff", and both entries are NOT in the same file, you should be safe deleting the file containing Kali, hopefully.

  • neither Grep Command resulted in any results, however I did go into the /etc/grub.d folder and seen only ParrotSec related items were in there. – user265608 Dec 13 '17 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.