I don’t know how it happened, I did not do anything different than usual when I shut down my pc, but I can’t boot into my manjaro installation on my pc, normally.
I have a separate windows ssd in my desktop that I rarely boot up, and haven’t recently used
when I turned on my pc it booted directly to windows, and I immediately thought, this is going to take up my day. It has, and it threatens to take more. I have since removed the windows ssd because I don’t trust it to be even present on my system. I have used SystemRestoreCD to boot into my installation, and running lsblk returns:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
└─sda2 8:2 0 931.4G 0 part
sdb 8:16 1 28.9G 0 disk
├─sdb1 8:17 1 737M 0 part
└─sdb2 8:18 1 1.4M 0 part
nvme0n1 259:0 0 931.5G 0 disk
└─nvme0n1p1 259:1 0 931.5G 0 part /var/lib/snapd/snap
/
There is no /boot partition
running sudo gdisk -l /dev/nvme0n1 returns:
GPT fdisk (gdisk) version 1.0.9.1
Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!
Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: OK
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: damaged
Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
1 - MBR
2 - GPT
3 - Create blank GPT
following some other tutorials like
did not work because
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
fails and returns:
Installing for x86_64-efi platform.
grub-install: error: failed to get canonical path of `/boot/efi'.
which makes sense because that partition is not there
running uname -r returns:
6.1.30-1-lts
I also ran test disk which also failed to recover the partition, and gave off some errors.
here is what the initial output looks like when selecting the analyse function:
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/nvme0n1 - 1000 GB / 931 GiB - CHS 953869 64 32
Current partition structure:
Partition Start End Size in sectors
Bad GPT partition, invalid signature.
Trying alternate GPT
1 P EFI System 4096 1023998 1019903
No FAT, NTFS, ext2, JFS, Reiser, cramfs or XFS marker
2 P MS Data 1024000 9412606 8388607 [recovery]
2 P MS Data 1024000 9412606 8388607 [recovery]
3 P Linux filesys. data 9412608 646067813 636655206
4 P Linux Swap 1945132464 1953521070 8388607
5 P EFI System 646067815 1945132462 1299064648 [root]
Here is what the output of a quick scan looks like:
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/nvme0n1 - 1000 GB / 931 GiB - CHS 953869 64 32
Partition Start End Size in sectors
>P Linux filesys. data 2048 1953520063 1953518016
And here is part of what a deeper scan returns because it has to finish running:
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/nvme0n1 - 1000 GB / 931 GiB - CHS 953869 64 32
The harddisk (1000 GB / 931 GiB) seems too small! (< 2172 GB / 2023 GiB)
Check the harddisk size: HD jumper settings, BIOS detection...
The following partitions can't be recovered:
Partition Start End Size in sectors
> Linux filesys. data 128558911 1976179884 1847620974
Mac HFS 384999568 4243760017 3858760450
Mac HFS 821847179 2149409932 1327562754 [lambda_1>@?1???$GetNodeOBB@~F ~T
Linux filesys. data 973342736 2926860751 1953518016
Linux filesys. data 973342792 2926860807 1953518016
Linux filesys. data 973342904 2926860919 1953518016
Linux filesys. data 973342976 2926860991 1953518016
Linux filesys. data 973343184 2926861199 1953518016
Linux filesys. data 973343272 2926861287 1953518016
Linux filesys. data 973343384 2926861399 1953518016
[ Continue ]
LUKS 83 (Data size unknown), 945 GB / 881 GiB
then the next page:
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/nvme0n1 - 1000 GB / 931 GiB - CHS 953869 64 32
Partition Start End Size in sectors
>D Linux filesys. data 2046 1953520061 1953518016
D Linux filesys. data 2048 1953520063 1953518016
D Mac HFS 62845489 62847604 2116
D Mac HFS 62847601 62849716 2116
D Linux filesys. data 73416393 74788376 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 73416394 74788377 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 78528201 79900184 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 78528202 79900185 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 85507785 86879768 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 85507786 86879769 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 89579209 90951192 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 89579210 90951193 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 104627913 105999896 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 104627914 105999897 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 111533769 112905752 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 111533770 112905753 1371984 [GWM-9M-$ث݊M-= b~^dS
D EFI System 137727408 137730287 2880 [EFI System Partition] [EFISECTOR]
D MS Data 137732107 137738280 6174
D MS Data 137738280 137744453 6174 [Boot]
D EFI System 139528612 139536803 8192 [EFI System Partition] [NO NAME]
D Linux filesys. data 152977097 154349080 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 152977098 154349081 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 192560841 193932824 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 192560842 193932825 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 223215305 224587288 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 223215306 224587289 1371984 [GWM-9M-$ث݊M-= b~^dS
D Mac HFS 260743896 765371097 504627202
D MS Data 271495168 376246271 104751104
D MS Data 272579506 376242176 103662671
D Linux filesys. data 274947785 276319768 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 274947786 276319769 1371984 [GWM-9M-$ث݊M-= b~^dS
D MS Data 376127489 376229888 102400
D MS Data 376133632 376236031 102400
D MS Data 376229888 376332287 102400
D MS Data 376236031 376338430 102400
D MS Data 376242176 479904846 103662671
D MS Data 376246271 480997374 104751104
D MS Data 382484571 382490744 6174
D MS Data 382490744 382496917 6174 [Boot]
D EFI System 382503216 382506095 2880 [EFI System Partition] [EFISECTOR]
D MS Data 382982187 382988360 6174
D MS Data 382988360 382994533 6174 [Boot]
D MS Data 383412371 383418544 6174
D MS Data 383414475 383420648 6174
D MS Data 383418544 383424717 6174
D MS Data 383420648 383426821 6174
D EFI System 383424808 383427687 2880 [EFI System Partition] [EFISECTOR]
D Mac HFS 383990598 920927046 536936449
D Linux filesys. data 505347785 506719768 1371984 [GWM-9M-$ث݊M-= b~^dS
D Linux filesys. data 505347786 506719769 1371984 [GWM-9M-$ث݊M-= b~^dS
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
P=Primary D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
I have tried to follow along some other tutorials and forum posts but failed because they are often very specific to the poster’s scenario and do not match up with mine. I am out of ideas
Thank you for your time
Some theories I have on why or how this happened:
I don’t think that this is nearly as important as getting the ability to use my computer back, but, I find it interesting and I would like to have this not happen again.
I don’t know much about how windows can screw with your linux install, but I thought it was unable to directly access another disk, but when poking around in bios settings I found a setting called windows uefi firmware update, which looking back on probably has nothing to do with all of this, and secure boot was turned back on, when I am very sure that it was off. So maybe windows, through an update, screwed with my boot partition on an separate drive, and turned on secure boot as a final screw you. I sure would love this to be the case, because that would mean that removing the windows drive from my machine would keep this from happening again. But I don’t think windows can even do that? The most I have seen it affect other drives is by marking my data hard drives as read only and reserving them for windows, not screwing with bios settings and other drives partitions.