Can't boot into windows after installing manjaro

thepooyan · 18 September 2023 09:52

Hi,
i cannot boot into my windows,
after installing manjaro

both OS are installed in UEFI mode
os-prober does not find anything
i can mound / read / write to my windows partition no problem

this is my efibootmgr -v output:

➜  ~ sudo efibootmgr -v

BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0003,2001,2002,2003
Boot0000* EFI PXE 0 for IPv4 (E4-A8-DF-DD-22-80) 	PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(e4a8dfdd2280,0)/IPv4(0.0.0.00.0.0.0,0,0)RC
      dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 00 1c / 01 01 06 00 00 00 / 03 0b 25 00 e4 a8 df dd 22 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 03 0c 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 7f ff 04 00
    data: 52 43
Boot0001* EFI PXE 0 for IPv6 (E4-A8-DF-DD-22-80) 	PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(e4a8dfdd2280,0)/IPv6([::]:<->[::]:,0,0)RC
      dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 00 1c / 01 01 06 00 00 00 / 03 0b 25 00 e4 a8 df dd 22 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 03 0d 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 7f ff 04 00
    data: 52 43
Boot0002* EFI USB Device (UFD 3.0 Silicon-Power32G)	UsbWwid(13fe,5500,0,P160001607036179041F017)/HD(2,GPT,abbf4e5b-6388-4cc7-e3eb-68f84616659f,0x3afffd8,0x10000)RC
      dp: 03 10 3a 00 00 00 fe 13 00 55 50 00 31 00 36 00 30 00 30 00 30 00 31 00 36 00 30 00 37 00 30 00 33 00 36 00 31 00 37 00 39 00 30 00 34 00 31 00 46 00 30 00 31 00 37 00 37 00 / 04 01 2a 00 02 00 00 00 d8 ff af 03 00 00 00 00 00 00 01 00 00 00 00 00 5b 4e bf ab 88 63 c7 4c e3 eb 68 f8 46 16 65 9f 02 02 / 7f ff 04 00
    data: 52 43
Boot0003* EFI Hard Drive (PHKA222005EV512A-INTEL SSDPEKNW512GZL)	PciRoot(0x0)/Pci(0x6,0x2)/Pci(0x0,0x0)/NVMe(0x1,5C-D2-E4-85-21-61-73-D0)/HD(1,GPT,973189bb-a594-4ff3-8c57-6eae16514941,0x800,0x32000)RC
      dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 02 06 / 01 01 06 00 00 00 / 03 17 10 00 01 00 00 00 5c d2 e4 85 21 61 73 d0 / 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 20 03 00 00 00 00 00 bb 89 31 97 94 a5 f3 4f 8c 57 6e ae 16 51 49 41 02 02 / 7f ff 04 00
    data: 52 43
Boot0004* Manjaro	HD(1,GPT,973189bb-a594-4ff3-8c57-6eae16514941,0x800,0x32000)/File(\EFI\Manjaro\grubx64.efi)
      dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 20 03 00 00 00 00 00 bb 89 31 97 94 a5 f3 4f 8c 57 6e ae 16 51 49 41 02 02 / 04 04 36 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 61 00 6e 00 6a 00 61 00 72 00 6f 00 5c 00 67 00 72 00 75 00 62 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
Boot2001* EFI USB Device	RC
      dp: 7f ff 04 00
    data: 52 43
Boot2002* EFI DVD/CDROM	RC
      dp: 7f ff 04 00
    data: 52 43
Boot2003* EFI Network	RC
      dp: 7f ff 04 00
    data: 52 43

can anyone help me please?

cscs · 18 September 2023 10:40

What does this mean?
You have an entry but when selected it fails?
There is no windows entry in grub?
Does everything share the same ESP?
Have you run sudo update-grub ?

thepooyan · 18 September 2023 11:23

sorry my question was not clear, there is no windows entry in grub
i already tried sudo update-grup didn’t work
and I’m not sure about the ESP

Teo · 18 September 2023 11:47

I am not sure in that case, because it is usually the other way around and windows breaks grub. You can take a look to see what files are in the ESP, if you see the Microsoft folder. (boot from live usb, then mount the ESP with sudo).

But at the end of the day, even if it is there, it is somehow not detected from the UEFI or at least not in the variables list, so you will still need to boot into some form of windows recovery (download an install media from microsoft with the media creation tool on a booting windows) and restore the bootloader. Then you will have to restore the grub/manjaro, so do not lose that flash drive too.

Theoretically you can work linux-only with efibootmgr but it will just be easier from windows.

linux-aarhus · 18 September 2023 11:49

Most often it is caused by mixing MBR and EFI boot loaders as they are mutually exclusive.

megavolt · 18 September 2023 13:02

@linux-aarhus Exactly my first thought.

Manjaro is listed as EFI entry. while Windows is not.
Windows must have been installed in BIOS/CSM/Legacy mode.
Both have to be in the same mode, so that grub can probe for other OS’s.

Teo · 18 September 2023 13:08

I guess he can easily test this theory by toggling it in the uefi - windows should come alive and manjaro should disappear, i guess?

thepooyan · 18 September 2023 14:10

thanks for everyone’s input.
i looked around and there was no option name ‘boot mode’ or anything in my bios i dunno why. i searched around but couldn’t find it.
but i found these:

this is the output of fdisk -l:

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: INTEL SSDPEKNW512GZL                    
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7C150E7E-B014-4ECF-BA19-534FC1DE4599

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     206847    204800   100M EFI System
/dev/nvme0n1p2    206848     239615     32768    16M Microsoft reserved
/dev/nvme0n1p3    239616  787947519 787707904 375.6G Microsoft basic data
/dev/nvme0n1p4 998891520 1000212479   1320960   645M Windows recovery environment
/dev/nvme0n1p5 787947520  866072575  78125056  37.3G Linux filesystem
/dev/nvme0n1p6 866072576  895369215  29296640    14G Linux swap
/dev/nvme0n1p7 895369216  998891519 103522304  49.4G Linux filesystem

Partition table entries are not in disk order.


Disk /dev/loop0: 105.82 MiB, 110964736 bytes, 216728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 86.7 MiB, 90906624 bytes, 177552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

and knowing that my windows partition is /dev/nvme0n1p4 this is the output of sudo gdisk -l /dev/nvme0n1p4:

GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************

Exact type match not found for type code 7200; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6C00; assigning type code for
'Linux filesystem'

Warning! Secondary partition table overlaps the last partition by
3101973429 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/nvme0n1p3: 787707904 sectors, 375.6 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 40DA9597-BD2E-4084-BB6E-480C0D38ED0D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 787707870
Partitions will be aligned on 32-sector boundaries
Total free space is 787707837 sectors (375.6 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1      1920221984      3736432267   866.0 GiB   8300  Linux filesystem
   2      1936028192      3889681299   931.6 GiB   8300  Linux filesystem

i guess this means my windows was installed in Legacy mode right? because under partition table scan it says MBR?

linux-aarhus · 18 September 2023 14:22

It is possible to use BIOS/GPT but frankly I have no clue.

fdisk list the partition layout as gpt and corresponds with the EFI partition (0xEF00)

There is something completely off with your partition layout as reported by gdisk and these errors may cause unpredicatable issues.

That cannot be deducted from the available data as the disk is GPT partition layout, a valid UUID disk identifier and you have 100MB efi partition which is consistent with Windows EFI partition size.

I think this is because your system has Legacy or CSM boot enabled but is installed in EFI mode.

The Legacy or CSM mode is usually set to be selected as primary thus causing your Manjaro ISO to boot in Legacy mode and install in legacy mode. You will have to fix the errors in the filesystem - disable Legacy mode in the firmware and reinstall Manjaro in EFI mode.

megavolt · 18 September 2023 15:54

Frankly saying it is a Hybrid Partition Table. While it is GPT, it has an MBR overlay. Windows likes to mix that stuff for legacy reasons. That way you can boot in BIOS mode while it is a GPT partition table on Windows.

Grub on the other hand needs just a seperated 10MB partition where it writes the MBR, no hybrid table needed.

This partition has the equal propose as a grub partition flagged with bios_grub, so that an UEFI can boot in BIOS mode on a GPT scheme.

You need to verify if efi files for Windows are written there plus an entry on efi boot loader. All that said, you would need to reinstall the Windows Bootloader in EFI mode, but no support here.

bedna · 19 September 2023 08:37

Here is a windows page with information you might find useful:

soundofthunder · 19 September 2023 14:02

@thepooyan – As I understand it (unless I’m grossly mistaken), OS-Prober isn’t enabled by default on an Arch-based system due to a potential security risk. It’s briefly mentioned here. The current recommendation (from Grub 2.06) is to not use OS-Prober, or just run it once. This is understandable when booting an Arch-only system - but, damned inconvenient if you’re multibooting.

For OS-Prober to detect your other OS’s at boot, it needs to be enabled in /etc/default/grub, which it probably isn’t. Check that os-prober is enabled:

cat /etc/default/grub | grep -i os_prober

The output should be something like:

# documentation on GRUB_DISABLE_OS_PROBER, if you still want to
# enable this functionality install os-prober and uncomment the next line:
#GRUB_DISABLE_OS_PROBER=false

If the GRUB_DISABLE_OS_PROBER=false line is commented, un-comment it, and reboot.

sudo nano /etc/default/grub

Information can be found in the Arch wiki page about Grub, in particular under the heading 3.1.2 Detecting other operating systems.

If this line is already uncommented, then your problem lies elsewhere. Cheers

Teo · 19 September 2023 15:17

You are technically right and he sure has to check it after fixing everything else, but judging by the output from, for example efibootmgr, a windows bootloader is nowhere to be seen by the uefi at all. He has to fix it first, because os prober will only see it if everything is working.

bedna · 19 September 2023 15:24

And create another fat32 partition for grub instead of trying to use the same partition to boot into both os:es.

soundofthunder · 19 September 2023 17:39

@thepooyan @Teo

I’ll preface this by stating this is only conjecture, but it looks to me like the protective MBR was doing its job but the conversion somehow borked the GPT layout. A protective MBR (by design) tends to hide, or protect GPT partitioning schemes from environments, tools, or bootloaders that don’t understand GPT.
As I understand it, booting in CSM mode qualifies here in that all it should see is the protective MBR and no GPT partitions. Booting in full UEFI mode would allow the GPT partitions to be seen.

The output of gdisk -l /dev/nvme0n1p4 indicates that all hell broke loose when installing Linux: partitions were overwritten and/or deleted by the Linux installer (booted in CSM mode, I’m assuming), and the installer was oblivious to the existence of GPT partitions containing Windows.

The gdisk command gdisk -l ... should have returned something like:

GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

…but it didn’t. Instead, the output posted was:

GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present

Found invalid GPT and valid MBR; converting MBR to GPT format in memory.
...
Warning! Secondary partition table overlaps the last partition by
3101973429 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/nvme0n1p3: 787707904 sectors, 375.6 GiB

…which tells an obvious tale of woe.

The MBR scheme is valid, but the GPT is trashed.

As has been mentioned already, installing both operating systems from a fully UEFI boot environment (without CSM enabled) should have been a prerequisite. My opinion is that the best way forward may be to start again from scratch, and [if possible], install each OS on a separate, dedicated drive (not partition).

A quick (and general) guide would be to install Windows first (in UEFI mode) and when fully functional, remove it completely from your system. Then install Linux on the second drive, set it up, solve any Grub issues; install rEFInd aswell (optional) for good measure.

The EFI on this drive will become your main EFI partition.

When finished setting up Linux – shut down the machine – unplug the power – reconnect your Windows drive. Boot straight to BIOS settings and make sure the drive with Linux/Grub/rEFInd (your main EFI) will boot first. Then reboot into Grub (or rEFInd, if you installed it) and your perfectly healthy Windows EFI and boot files should be automatically detected (note my previous post about os-prober); and birds will sing a happy song; life will be rosey again.

As always, seek a second opinion, and a third, if needed. Cheers.

bedna · 20 September 2023 00:45

I strongly disagree to that, reinstalling TWO operating systems when ONLY the boot is missing/broken seems very over the top for me. The only ghing need to be installed is win boot and grub.

This is what is needed:

Repair the windows boot and make sure you can boot with it. (I posted link earlier)
Load into a manjaro live.
Create partition for grub in fat32 (100mb should be just fine)
Chroot into the manjaro installation and Install grub on the newly created partition
Enter bios and make sure the correct boot is selected first
Have windows and manjaro in dual boot.
Enjoy

soundofthunder · 20 September 2023 04:58

@thepooyan @bedna

All things being equal I might agree.

However, taking all things into consideration (from what I’ve read above) there seems a lot more afoot than the case of the missing boot:- The partitions containing his Windows installation are no more; non-existent; defunct; rudely cut down in their prime; overwritten and/or deleted during attempted conversion from MBR to GPT.

It can be difficult to diagnose a problem without having full knowledge of how the situation came to be, however, in this instance (with the information provided) I feel that simply throwing a new EFI into the mix at this stage won’t fix the problem – I’d like to be proven wrong, though.

While I acknowledge there are potentially ways to recover data in situations like this, I maintain (in the context of my complete post) that starting over is probably the best way forward. Yes, my suggestion requires an additional drive; yes, it requires disabling CSM mode booting in his BIOS; yes, the whole process may take additional time; and yes, there’s also the hassle of taking the lid off the machine.

Installing each OS to its own separate/dedicated drive is the generally recognised safest path when multibooting disparate OS types. I doubt there are many with experience in multibooting who would strongly disagree with that.

Aside:- While this is sound advice when using strictly MBR partitioning schemes, when using GPT and UEFI formatting the partition as fat32 is not applicable (even though it’s still fat32 under the hood). It should be formatted as an EFI System Partition (ESP) which uses a specific hex code – ef00 – to identify it as such.

Rod Smith’s GDISK (used by the OP) can assign these hex codes while preparing a disk, which is handy when setting up a GPT scheme and partitions laid out just the way you want them.

That said, I’d still recommend installing Windows to a separate drive as M$ tends to have too many opinionated defaults which can often do undesirable things to the proverbial pooch in a multiboot environment.

Let Windows do Windows!

E&OE.

system · 23 September 2023 17:01

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.