Dual boot woes - Windows update killed booting both OS's.

Hello,

I run Manjaro / KDE and Windows 10 on separate drives but in the same system. Unfortunately, Microsoft's latest forced major update went so far as to cripple grub or some other boot-related function, rendering the system unable to boot either OS.

I fixed the ability to boot Manjaro by eventually managing to run "update-grub". Grub now sees all installed disks, but that wasn't good enough to get Windows to boot too. Edit: grub sees the Windows disk and can "boot" it, but Windows fails immediately anyway.

I tried booting into the Windows CD and entering recovery mode, but it complains that it is unable to effect a repair.

The latter problem is likely off topic here, but:

  • Is dual boot really this seriously vulnerable to the point of being inadvisable? This is not the first problem I've had with dual-boot. I hate Microsoft for its de-facto presumptuousness that it's the only OS around, but I do need to use it on occasion, and I'd really rather not run two machines.

  • I am hardly an expert on Linux, but I know virtually nothing about Windows. With no other idea left to try, I am preparing to wipe the Windows disk and start over, but I wonder if anyone can suggest something else?

  • Is there anything I can do to protect the system from something similar happening in the future?

Thank you.

There's far more skilled people here that can assist you in getting grub back to working order and taming Windows.

Some of the things I've learned that I use on my Dual Boot Windows/Manjaro system
I use Timeshift to backup my /boot. If a Windows update borks it, I can liveUSB in and restore it.
There are commands to do that but I'm not that brave yet. :wink:
Using Timeshift again, I do at least two daily snapshots. But that's just for the filesystem.

As for protecting /boot from Windows predations? I don't know if that's possible. Windows seems to get worse as time goes on for assuming it's the only OS.

I would assume you have os-prober installed with Grub? It's the function that allows Grub to see other OSes and add a boot entry as I understand it.

EDIT: Have a look at this.

Yes, os-prober is installed. Is there more to know about it or do with it than it merely being installed?

Grub sees the Windows disk and can "boot" into it, but Windows nevertheless fails immediately. Thus, I can't execute any commands. Maybe I can try using the CD, but the problem doesn't seem to be with grub and hence it's not clear that link (thank you!) will help.

1 Like

If Os-prober is installed Grub will use it on it's own.

Of course windows doesn't give you any real info on how or why it failed. /sigh

I'm going to ping @gohlip = :man_superhero:

It might be a wonky UUID entry or something with windows.

Heh heh heh.. superheroes don't need sleep. I do. :grinning:

@nano From manjaro terminal, print out output of

sudo parted -l
sudo blkid
test -d /sys/firmware/efi && echo UEFI || echo BIOS
efibootmgr -v

ps: depending on the output, I may ask for more info.
ps: late here, may hear from me much later.
ps: my partner in crime @petsam and others here can help too

1 Like

First, I think a little background might be pertinent, as some messiness was accumulated along the way: I originally ran dual-boot on a single drive, but then moved to two drives due to running out of space. The Windows disk in question was thus originally cloned from the single-disk dual-boot system disk to a separate disk. The Manjaro partition was later deleted to make more room. Therefore, there is likely to be some remnants of Manjaro on it still. This did work fine until the forced Windows update.

The Samsung 850 ATA disk is a backup Manjaro drive that I installed only in order to resurrect the machine, and this is not involved in the problem.

The problematic Windows disk is nvme0n1 (2 TB). It used to contain Manjaro too due to the cloning operation, but the main Manjaro partition was later deleted and merged into the main Windows partition.

My main Manjaro disk is nvme1n1 (1 TB). As mentioned, it also contains an old dual-boot Windows partition which became non-functional long ago (possibly the same problem, even?) but not deleted. The Manjaro system on it now boots and runs properly.


sudo parted -l

Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 2098kB 317MB 315MB fat32 boot, esp
2 317MB 963GB 963GB ext4
3 963GB 1000GB 37.1GB linux-swap(v1)

Model: Unknown (unknown)
Disk /dev/nvme0n1: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs Basic data partition hidden, diag
2 524MB 629MB 105MB fat32 EFI system partition boot, esp
3 629MB 646MB 16.8MB Microsoft reserved partition msftres
4 646MB 2000GB 2000GB ntfs Basic data partition msftdata

Model: Unknown (unknown)
Disk /dev/nvme1n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs Basic data partition hidden, diag
2 524MB 629MB 105MB fat32 EFI system partition boot, esp
3 629MB 646MB 16.8MB Microsoft reserved partition msftres
4 646MB 336GB 336GB ntfs Basic data partition msftdata
5 336GB 1000GB 664GB ext4


sudo blkid

/dev/nvme0n1p1: LABEL="Recovery" UUID="FC22225A22221A62" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="f923ee65-0b8b-47e3-bf29-aeb03c973e99"
/dev/nvme0n1p2: UUID="4223-1575" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="c727faf8-af54-4095-a3fd-0fcfbee503f4"
/dev/nvme0n1p4: UUID="BA7E26327E25E839" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="5b455e1d-78af-4d9f-94d4-0e3659cb52a2"
/dev/nvme1n1p1: LABEL="Recovery" UUID="FC22225A22221A62" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="976f9c90-a0e0-11e9-bab0-b7f996171c9d"
/dev/nvme1n1p2: UUID="4223-1575" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="976f9c91-a0e0-11e9-bab0-b7f996171c9d"
/dev/nvme1n1p4: UUID="BA7E26327E25E839" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="976f9c93-a0e0-11e9-bab0-b7f996171c9d"
/dev/nvme1n1p5: UUID="a1be17fe-3926-47f9-b824-d395f7f64186" TYPE="ext4" PARTUUID="cdced3bd-a97d-4ba1-ad44-51cba38bc94e"
/dev/sda1: UUID="E589-8600" TYPE="vfat" PARTUUID="5899f905-b0c3-4ee9-b12f-18ef2c39ef63"
/dev/sda2: UUID="defd1791-59e4-4319-b3f1-4f106f7d4804" TYPE="ext4" PARTUUID="1938c9fa-edbb-415d-9c4e-ee3e272cf041"
/dev/sda3: UUID="115efeec-5e1a-4e2c-985a-20019e4d5008" TYPE="swap" PARTUUID="49ab2337-c0ad-4bb4-8c37-f68cbcfe3638"
/dev/nvme0n1p3: PARTLABEL="Microsoft reserved partition" PARTUUID="c34f2009-57bd-4bc6-9e95-c9c637e816e5"
/dev/nvme1n1p3: PARTLABEL="Microsoft reserved partition" PARTUUID="976f9c92-a0e0-11e9-bab0-b7f996171c9d"


test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI


Thank you all!

Cloning needs to change UUIDs afterwards.
A possible solution could be to

  • boot to your alternate manjaro system
  • use gparted to change UUIDs of root and esp partitions on normal manjaro.
  • update UUID info in fstab
  • chroot into normal manjaro and run update-grub

This may not fix Windows, but who knows...
I know nothing about Windows idiosyncrasies.

Oh, I see! I hadn't been aware of that. And of course now I note that there are matching UUID's in my system. I guess it's rarely mentioned since people don't often mount both the original and cloned disks?

I'll look into changing it. Thank you!

Oops - editing error.

I suppose a utility checks the FS and creates a compatible one.
UUIDs for vfat are short, while for ext4 are long.

Do you know how the shorter ones should be generated? How risky is just editing them randomly, e.g. changing a digit or two?

I don't know.

In what measurement unit? Which Risk Management ISO standard?

The risk is obviously binary: total annihilation vs. eternal peace on earth.

I was just hoping for a "NO, don't do THAT, you idiot!!!" or else "sure, roll the dice, the odds of a collision down the road are virtually zero."

OBVIOUSLY!!

OK, in that case I will have to figure out how to generate an "official" short UUID. :dizzy_face:

It's answered

Oh, sorry! OK, thank you, I will try to take it from here, and will report back. Thanks again.

1 Like

OK, an update (thanks to all those who have helped):

  • I don't believe there are any remaining duplicate UUIDs. However, I note that there are some duplicate PARTUUIDs.

  • Correcting the duplicate UUIDs did not fix the Windows boot problem (that would have been too easy, right?).

  • I note that GParted claims that it cannot detect a file system on the following "Microsoft reserved partitions": /dev/nvme1n1p3 and /dev/nvme0n1p3. I don't know if this is normal or not.

  • I noticed that my main swap, on /dev/nvme1n1p5, is missing! What!?

Here is the data (redone) that was requested:


sudo parted -l

Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 2098kB 317MB 315MB fat32 boot, esp
2 317MB 963GB 963GB ext4
3 963GB 1000GB 37.1GB linux-swap(v1)

Model: Unknown (unknown)
Disk /dev/nvme0n1: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs Basic data partition hidden, diag
2 524MB 629MB 105MB fat32 EFI system partition boot, esp
3 629MB 646MB 16.8MB Microsoft reserved partition msftres
4 646MB 2000GB 2000GB ntfs Basic data partition msftdata

Model: Unknown (unknown)
Disk /dev/nvme1n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs Basic data partition hidden, diag
2 524MB 629MB 105MB fat32 EFI system partition boot, esp
3 629MB 646MB 16.8MB Microsoft reserved partition msftres
4 646MB 336GB 336GB ntfs Basic data partition msftdata
5 336GB 1000GB 664GB ext4


sudo blkid

/dev/nvme1n1p1: LABEL="Recovery" UUID="FC22225A22221A62" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="976f9c90-a0e0-11e9-bab0-b7f996171c9d"
/dev/nvme1n1p2: UUID="4223-1575" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="976f9c91-a0e0-11e9-bab0-b7f996171c9d"
/dev/nvme1n1p4: UUID="5F2186C97E25E839" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="976f9c93-a0e0-11e9-bab0-b7f996171c9d"
/dev/nvme1n1p5: UUID="a1be17fe-3926-47f9-b824-d395f7f64186" TYPE="ext4" PARTUUID="cdced3bd-a97d-4ba1-ad44-51cba38bc94e"
/dev/nvme0n1p1: LABEL="Recovery" UUID="599647A622221A62" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="f923ee65-0b8b-47e3-bf29-aeb03c973e99"
/dev/nvme0n1p2: UUID="2C44-9274" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="c727faf8-af54-4095-a3fd-0fcfbee503f4"
/dev/nvme0n1p4: UUID="BA7E26327E25E839" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="5b455e1d-78af-4d9f-94d4-0e3659cb52a2"
/dev/sda1: UUID="E589-8600" TYPE="vfat" PARTUUID="5899f905-b0c3-4ee9-b12f-18ef2c39ef63"
/dev/sda2: UUID="defd1791-59e4-4319-b3f1-4f106f7d4804" TYPE="ext4" PARTUUID="1938c9fa-edbb-415d-9c4e-ee3e272cf041"
/dev/sda3: UUID="115efeec-5e1a-4e2c-985a-20019e4d5008" TYPE="swap" PARTUUID="49ab2337-c0ad-4bb4-8c37-f68cbcfe3638"
/dev/nvme1n1p3: PARTLABEL="Microsoft reserved partition" PARTUUID="976f9c92-a0e0-11e9-bab0-b7f996171c9d"
/dev/nvme0n1p3: PARTLABEL="Microsoft reserved partition" PARTUUID="c34f2009-57bd-4bc6-9e95-c9c637e816e5"


test -d /sys/firmware/efi && echo UEFI || echo BIOS

UEFI


efibootmgr -v

BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0001,0000,0005,0006,0002
Boot0000* Windows Boot Manager HD(2,GPT,c727faf8-af54-4095-a3fd-0fcfbee503f4,0xfa000,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}..._................
Boot0001* Hard Drive BBS(HD,,0x0)..GO..NO........q.S.a.m.s.u.n.g. .S.S.D. .9.6.0. .E.V.O. .1.T.B....................A...........................%8Rq.G.....4..Gd-.;.A..MQ..L.S.3.E.T.N.X.0.J.2.0.4.4.1.6.D........BO..NO........q.S.a.m.s.u.n.g. .S.S.D. .9.7.0. .E.V.O. .2.T.B....................A...........................%8Z.........4..Gd-.;.A..MQ..L.S.4.6.4.N.B.0.K.A.0.6.5.0.5.M........BO..NO........o.S.a.m.s.u.n.g. .S.S.D. .8.5.0. .E.V.O. .1.T.B....................A...........................>..Gd-.;.A..MQ..L.2.S.C.1.S.N.G.A.0.1.2.0.0.9. .F. . . . ........BO
Boot0002
Manjaro VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0005* CD/DVD Drive BBS(CDROM,,0x0)..GO..NO........o.A.S.U.S. . . . .D.R.W.-.2.4.B.1.S.T. . . .j....................A...........................>..Gd-.;.A..MQ..L.3.G.0.D.L.C.0.0.5.8.0.2. . . . . . . . ........BO
Boot0006 Windows Boot Manager HD(2,GPT,976f9c91-a0e0-11e9-bab0-b7f996171c9d,0xfa000,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0007* UEFI OS HD(1,GPT,5899f905-b0c3-4ee9-b12f-18ef2c39ef63,0x1001,0x96001)/File(\EFI\BOOT\BOOTX64.EFI)..BO


I mentioned that I've been preparing to wipe and reinstall Windows on its own drive in the eventuality that I cannot fix it. I'm quite low on space in my main Manjaro drive, too, and given all the self-inflicted problems could consider starting over there as well. :anguished:

Thank you again.

What the living heck!?

I made another attempt to use the Windows CD to perform a repair following the UUID changes. It failed again in its usual way. But now... I can't boot into anything, including my backup Manjaro disk (which I didn't think to remove first).

The symptom was that the machine kept trying to boot back into the Windows CD rather than where I was pointing it. After taking out the CD, the Bios still shows everything there, but trying to boot into a proper disk results in a bios complaint: "Reboot and select proper boot device."

This is going from bad to worse. I need to take a break from this and cool off a while.

Morning, hope you have a good break yourself. Now back to work.
Hopefully you cleaned out your double cloned UUID issue by petsam.
BTW, I don't know about cloning windows, I hear windows do not like clone and they do not work, probably ... well, they are (neo-liberal rent-seeking trumpian/clintonian capitalist) micro$oft, not us communist linux.

There are a few things. To make it simple, for a start...(there's more)

  1. Your manjaro entry (directed to /boot/efi) is not there in efibootmgr
    It must be there. But since it is default to bootx64.efi, we can also copy our grubx64.efi to it.
  2. More serious and harder is that you have 2 nvme drives.
    I do not have nvme drives but special parameters needed to be in kernel line or (more difficult) you can hide unwanted nvme in udev partition rules.
    We'll need to @Hipster and @Cagnulein help here as they have fixed it themselves. I'll do my best (under their supervision).

Let's start with the simple one first.
Try to boot up manjaro installed OS (which one?) by using this first post here. Start manjaro live media in uefi and (if you have 2 manjaro's) use the one your want to use.
search.file /etc/manjaro-release
set root=(hdx,y)

Oh, now we need your /etc/fstab
But continue to fix it and don't forget the 2 [Additional UEFI commands] when booted up.
It is important we must do these 2 commands.

Now here (for the 2 nvme disks you have) add "nvme_core.multipath=0" to this line in your /etc/default/grub and 'sudo update-grub'

GRUB_CMDLINE_LINUX_DEFAULT="quiet nvme_core.multipath=0"

Reboot normally and see if you can boot to manjaro.
We'll handle windows next (hopefully).

@Hipster (on nvme)
So far so good?

[EDIT] -
While using the live media grub prompt, add in the linux line the nvme parameter

grub> linux /boot/vmlinuz-4.19-x86_64 root=UUID=$abc  nvme_core.multipath=0 rw