[SOLVED] Grub has 'lost' Windows

[phil1349]

I have just upgraded from 18.04 to 20.04 by doing a clean install from DVD. All seemed to proceed normally except on rebooting after installation Windows no longer appears on the Grub menu. Running update-grub has no effect.

The history is when I bought the computer as is usual it had Windows 10 installed. I carefully installed Kubuntu 18.04 as this was my first experience with a uefi bios and all went well and Windows was on the grub menu - no problem. I subsequentially installed Mint 19 on the same hard drive and again all went well everything worked. So what is different this time that windows has not been recognised ?

I have read through the thread started by Nimic who had similar problems but this does not seem appropriate as he was installing on 2 drives and in my case everything is all on the same drive.

I can start windows by going into the bios menu on startup and altering the device priority but this is not particularly convenient.

If I try a re-installation is there anything in particular I should look out for ?

Thanks and regards,

phil1349

[mr_raider]

Open a terminal, type the command:

sudo os-prober

What is the output?

[phil1349]

os-prober produces :-

/dev/sda8:Linux Mint 19.3 Tricia (19.3):LinuxMint:linux

Obviously grub has not seen the windows partition even though it is present in Partition Manager

[jlittle]

Do you have access to a backup of 18.04? I'd have a look at /boot/grub/grub.cfg, and print out the menu entry stanza from it, or even write it out carefully. Then, at the grub menu, I'd press C and type the commands at the grub prompt, and see if it works. If it doesn't, it might reveal what's going on. If it works, I could try using custom.cfg or /etc/grub.d/40_custom (or something like that).

(That update-grub scripting machinery is too complex and hence unreliable IMO. When it has a problem, diagnosis is difficult.)

Using another bootloader, like rEFInd or systemd-boot, might be an idea, but others would have to advise you about them.

[phil1349]

Unfortunately I did not do a backup of the 18.04 root partition so I cannot do what you suggest.

I agree that the update-grub is very complex, it seems to rely on the output of os-prober which as my previous post indicates cannot find the windows partition so it is not surprising that update-grub does not work.

Trying other bootloaders is a bit beyond my knowledge but I do have some space on the hd enough for a minimalist install of 18.04 so I will give that a try.

REgards

[mr_raider]

DO you want to absolutely fix grub, or would you be willing to use another boot loader like refind?

https://www.rodsbooks.com/refind/

[phil1349]

It would be nice to fix grub but I will consider alternatives so I will check out the link mr_raider has given.

It maybe that I overlooked something when installing. When I first installed 18.04 it was my first experience with uefi so I carefully followed the directions in a howto I found I think on the kubuntu site so it maybe worth re-reading this, the trouble is I cannot find it again so if anyone can point me in the right direction I will be grateful.

[phil1349]

It looks like I made an error on installation in leaving the nominated boot device during the disk partition at the default of /dev/sda but it should of course point to the /boot/efi partition in my case /dev/sda2. Re-installing with this correction has solved the problem.

Thanks to those who replied.

Regards

[mr_raider]

It looks like I made an error on installation in leaving the nominated boot device during the disk partition at the default of /dev/sda but it should of course point to the /boot/efi partition in my case /dev/sda2. Re-installing with this correction has solved the problem.

Thanks to those who replied.

Regards

No. You should set the boot device as /dev/sda in EFI installations. There is no need to specify the exact EFI partition by number. The installer should find the efi partition and put the first stage of grub there.

Start by posting the output of

lsblk

and then

cat /etc/fstab

We can then check if the EFI partition is mounted right.

the next step is to list the contents of

/boot/efi/EFI

There should be Microsoft subfolder there.

[phil1349]

Hmmm... There seems to be a conflict of opinion here. My original installation of 20.04 went ahead with the default boot device of /dev/sda and it clearly installed itself in legacy bios mode.

if test -d /sys/firmware/efi; then echo efi; else echo bios; fi

confirmed this. There was no efi entry in fstab, I checked.

I read through the installation notes at https://help.ubuntu.com/community/UEFI which clearly indicates that it should point to the exact partition, in my case sda2. I did this and it has now installed itself in efi mode, there is now a /boot/efi entry in fstab and /boot/efi/EFI has 3 subdirectories, Boot, Microsoft and Ubuntu. I forget exactly what I did when installing 18.04, it was 2 years ago, but I would have closely followed a howto such as referred to above and that worked out ok.

Maybe the default of /dev/sda failed because it was expecting to find it as the first partition, in my case sda1 is an ntfs-formatted windows recovery partition which must be common where windows is pre-installed.

Regards

[mr_raider]

Hmmm... There seems to be a conflict of opinion here. My original installation of 20.04 went ahead with the default boot device of /dev/sda and it clearly installed itself in legacy bios mode.

if test -d /sys/firmware/efi; then echo efi; else echo bios; fi

confirmed this. There was no efi entry in fstab, I checked.

I read through the installation notes at https://help.ubuntu.com/community/UEFI which clearly indicates that it should point to the exact partition, in my case sda2. I did this and it has now installed itself in efi mode, there is now a /boot/efi entry in fstab and /boot/efi/EFI has 3 subdirectories, Boot, Microsoft and Ubuntu. I forget exactly what I did when installing 18.04, it was 2 years ago, but I would have closely followed a howto such as referred to above and that worked out ok.

Maybe the default of /dev/sda failed because it was expecting to find it as the first partition, in my case sda1 is an ntfs-formatted windows recovery partition which must be common where windows is pre-installed.

Regards

It is possible you installed Windows in EFI mode and Linux in legacy mode. In that case grub won't find windows and you can't chain load it.

To make matters worse, there is a bug in the current installer that will create an EFI partition even in legacy mode.

The safest way to proceed is to fully deactivate legacy booting in your firmware options.

You can tell because the live USB boot screen is a bit different in legacy mode.

[phil1349]

It is possible you installed Windows in EFI mode and Linux in legacy mode. In that case grub won't find windows and you can't chain load it.

That is precisely what happened, Windows was pre-installed in efi mode on the system when I bought it and my first installation of 20.04 accidentally installed it in legacy mode.

Reading through the installation howto again, what it is saying is that when using the automatic install option to take over the whole disk then leaving the default of /dev/sda is fine as the installer will do the rest but when installing alongside an existing OS you must point to the efi partition to ensure kubuntu installs in efi mode. The only other aspect which puzzles me is that legacy booting, together with FastBoot was turned off in firmware and had been turned off as part of the original 18.04 installation so why did it install in legacy mode ? But there you go - aint Technology fun at times !!

[mr_raider]

That is precisely what happened, Windows was pre-installed in efi mode on the system when I bought it and my first installation of 20.04 accidentally installed it in legacy mode.

Reading through the installation howto again, what it is saying is that when using the automatic install option to take over the whole disk then leaving the default of /dev/sda is fine as the installer will do the rest but when installing alongside an existing OS you must point to the efi partition to ensure kubuntu installs in efi mode. The only other aspect which puzzles me is that legacy booting, together with FastBoot was turned off in firmware and had been turned off as part of the original 18.04 installation so why did it install in legacy mode ? But there you go - aint Technology fun at times !!

The install mode is determined by the mode in which you boot the USB live environment. You can't boot in one mode and install in the other. You must have booted the USB in legacy mode.

The first step is to de-activate legacy booting if possible and make absolutely sure you boot the Live USB in EFI mode.