0

So recently I was asking a question about how to fix Grub if I'm installing Windows after Ubuntu. I found the solution and posted it in order to help others who will do the same. But now I want to ask about aftermaths of boot-repair. So, my system was working like this before:

  1. Ubuntu with Grub
  2. Windows on hdd

As I said in the answer to my previous question, I installed Windows on new ssd (let's call it m2), connected old hdd with my old windows, transfered all data and formatted hdd. Then I connected ssd with my ubuntu and run boot-repair from my usb flash. After that grub got fixed and I can choose between new Windows and Ubuntu, and it's all working.

But one thing that bothers me is that there's still old Windows left on grub menu, even tho I formatted old hdd with Windows. Also in UEFI there were added more options to boot from, like ubuntu (m2 ssd) and ubuntu (hdd) even tho ubuntu is not installed there at all. I have the logs from boot-repair saved, if they're safe to share, I can share them here or privately.

So my question is, should I be worried about something? Or it's not of a big deal and I can forget about it? It also says when I'm booting to Ubuntu "failed to set APST feature", but it loads and works after some little time.

Arzybek
  • 313
  • 1
  • 2
  • 10

1 Answers1

0

The GRUB configuration file is generated and the generator consists of a bunch of modules, each of it adds some part of configurations. In particular, menu is generated by various "prober" modules; there is an os-prober package which detects Windows somehow and adds it into the menu.

If you inspect the /boot/grub/grub.cfg file with some text viewer (in the console you can do less /boot/grub/grub.cfg, scroll with arrow and PgUp/PgDown keys and q for quitting), you'll see comments in it, which suggest which module added which boot options. There will be some general setup in the beginning, and the boot menu will be at the bottom of the file. It might look like this:

...
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
        set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-3f93e571-3e82-409a-9298-67ad16c80f2a' {
        load_video
        insmod gzio
...
                initrd  /initrd.img-5.10.0-18-amd64
        }
}

END /etc/grub.d/10_linux


BEGIN /etc/grub.d/20_linux_xen


...


END /etc/grub.d/20_linux_xen


...

In this example, first was 10_linux module, which created my main system's boot menu entries. I don't have Xen, so the 20_linux_xen didn't produce anything and so on.

Those are paths in the root file system to their respective modules. For example, next is 30_os-prober module which is supposed to detect other systems, including Windows. Read package's own documentation in /usr/share/doc/os-prober to understand its behavior and configuration. Also, thanks to open source, you can just read the code — it's simply the shell script which the system invokes during boot menu generation plus some other scripts which you find are called from the main file, and unsurprisingly you can just read it the same way (try less /etc/grub.d/30_os-prober). This way is possible to understand how it detects your leftovers in your particular case and then you can decide how to get rid of that.

Other Linuxes are usually detected because you have their stray kernels and initrds, root file systems and so on, so check your logical volumes (if you use LVM), partitions, /boot for unexpected kernels and other files. Check also contents of the ESP which is usually mounted to /boot/efi/, and you use UEFI (I suspect you do since this is the only way firmware entry could have appeared in the GRUB menu) you can compare it against firmware's view on the subject with efibootmgr -v. You will understand which files there are not really used.

Nikita Kipriyanov
  • 3,249