Windows 10 is messing up grub I think

English Install/Boot/Login
1

Introduction

Pc is dual boot, openSUSE tumble weed and windows 10.

It does work, most of the time when I turn on my pc , I get the grub menu, were I can choose suse or windows.
Its set up in a way that if I do nothing suse will boot.

Now the problem:

Often when I start windows 10 it starts to fix the file system. Then after a reboot, I can’t boot suse, because it start windows 10 right away, no grub.

I know how to fix this, use boot option from motherboard, select suse hard disk and boot Linux.
Then I go into yast, under bootloader, I make sure probe foreing OS is checked and I click oke.

This works until windows 10 again messes up grub.

I would like to fix this in a more permanent way.

As you probably guessed, openSUSE and Windows 10 both have there own hard disk.

Some more info, under windows 10 this fixing of the file system, takes less then 2 seconds, so its not checking the entire disk.

2

Legacy boot or UEFI boot?

Often when I start windows 10 it starts to fix the file system.

That’s a problem already. It should not need to fix the file system.

Perhaps disable Windows fast boot.

My solution, with Windows 8.1, is to use SHIFT-RESTART when leaving Windows. That ensures that the file system is prooperly shutdown.

Then after a reboot, I can’t boot suse, because it start windows 10 right away, no grub.

Perhaps Windows is changing the UEFI boot order (assuming that you use UEFI for booting). You can actually change it back from a root command line. Currently, I find it easier to allow Windows to be the first in boot order. And using SHIFT RESTART to leave Windows allows me to select openSUSE for the next boot.

3

Hi
Or shutdown… I use a shortcut shutdown /s -t 2 and of course disable that fast start…

4

Thank you guys.

I am using UEFI and secure boot for leap

Not sure if win 10 also uses secure boot, but EUFI I do know for sure.

Fast boot should be disabled, and every setting I could click in windows is set to really shut down.

Windows not properly shutting down must be it though. :slight_smile:

This would also explain why the problem is not persistent on every boot and shutdown.

That shortcut, just to be sure, will be on the windows desktop right ?

I just copied a text file to the windows desktop, with instructions from this topic.

While typing this, I start to wonder.
To switch back to suse from windows 10, I usual use restart not shutdown. Maybe that is causing the issue.

So on Windows, I should probably not use restart, to get to the grub screen. :X

5

Restart maybe the issue
I set my power button to shutdown in win10 and always use that when exiting windows and of course fastboot is off

6

I don’t trust it to stay that way through updates, so I never shut Windows down, only ever reboot it. :wink:

7

My desktop has lots of systems with Windows 10 sitting on sdc11:

**erlangen:~ #** lsblk -f 
NAME        FSTYPE FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINT 
sda                                                                                       
├─sda1      ext4   1.0   Leap-15.1   57bdbf64-b309-477c-b94c-8987e0c8032a                 
├─sda2      ext4   1.0   Manjaro     fad3604b-5a61-4653-8c14-518d850400ba                 
├─sda3      ext4   1.0   Home-HDD    f5177cae-4082-44ed-9471-b99030f06866                 
└─sda4      ext4   1.0               42f23f3c-9ff6-46f6-a9d9-6894062c37d7                 
sdb                                                                                       
└─sdb1      ext4   1.0   Home-SSD    5605f149-34a7-4301-9bf3-f1f177e35ed6  490.8G    68% /home-SSD 
sdc                                                                                       
├─sdc1      vfat   FAT16             4A24-B10D                                            
├─sdc2      ext4   1.0   ArchLinux   690b51d7-7034-4585-b362-615f8056be45                 
├─sdc3      ext4   1.0   SLED        492c5d5e-5d9b-4a99-9d34-e1f9cee09fe9                 
├─sdc4      ext4   1.0   spare       f4c5463f-f43d-420a-a0ea-4456cfbc54fa                 
├─sdc5      btrfs        Tumbleweed  204f7d0f-979a-41e1-a483-a597d0357e0b                 
├─sdc6      ext4   1.0   Manjaro-SSD bf6ba7c9-9068-4a9b-b210-84b6d105df5c                 
├─sdc7      swap   1                 96df969e-8897-4a5c-8473-3ed007f97b29                 
├─sdc8      btrfs        Leap-15.2   69774d55-8da2-4599-9c27-766b1012771d                 
├─sdc9      ext4   1.0   Ubuntu      9a3eec78-dd20-44c0-a38a-f705b3bbbc66                 
├─sdc10                                                                                   
└─sdc11     ntfs                     7CB4EC04B4EBBEB0                                     
sr0                                                                                       
nvme0n1                                                                                   
├─nvme0n1p1 vfat   FAT16             6DEC-64F9                              85.8M    14% /boot/efi 
├─nvme0n1p2 ext4   1.0   Fedora      6fe43319-8566-4a09-9d2d-fcf8c104671f                 
├─nvme0n1p3 btrfs        TW-20200515 e7ad401f-4f60-42ff-a07e-f54372bc1dbc   27.2G    45% / 
└─nvme0n1p4 ext4   1.0   Home        704621ef-9b45-4e96-ba7f-1becd3924f08  118.8G    71% /home 
**erlangen:~ #**

When booting into Windows 10 I use the Tumbleweed grub menu. Doing so for the first time in 2021 I got prompted for aborting the fsck on the ntfs partition. I hit a key to perform the abort and proceeded. When restarting Windows 10 I was warned not to turn off the computer. Windows started 15 minutes of ***turbations and finally rebooted into Tumbleweed on nvme0n1p3, which is the grub default. Thus I think you may fix the unwanted behavior by configuring Windows 10 not to run fsck or by skipping fsck.