Posting this here because it might help someone unfamiliar with partitioning schemes or basic trouble shooting...
If you are not using GPT partitioning, you should be. Here's one reason why:
This morning, after an update I rebooted. The reboot failed and the system froze. I punched the reset button and readied myself for trouble-shooting. The reset worked and the system booted, but it took several minutes longer than usual.
Once I was logged in, my first step was to read the boot log:
The top lines showed several mounts failed to mount as "NOT FOUND". Checking my drives revealed 2 of them had no listed partitions! This obviously looked very bad.
I considered that the update had caused the issue, so I rolled back to before the update and the problem still existed - no partitions on two of my five drives.
Next step was to open Konsole and use gdisk to look at the drives:
It printed the expected partition table for the drive but also gave an error something like: "Found valid GPT with corrupted MBR; using GPT. Save will replace damaged partition table"
GPT partition has a backup copy of your partition table on the drive. This is why gdisk still showed the correct partition table even though userspace tools like lsblk did not.
The commands to restore the backup version using gdisk is as follows;
sudo gdisk /dev/nvme0n1 - this opens the drive with gdisk
x - this command switches gdisk to "Expert" mode
p - this prints the partition table so you can verify it's what you want
v - this verifies the disk is OK and shows you any errors or warnings
w - this "writes" (saves) the partition table and exits gdisk
NOTE: Any time you mess with a partition table, there's a risk of data loss. Have backups!
Once I had done this to both damaged drives, I was able to reboot normally and all the partitions mounted as expected.
If had had been using MBR partitioning, I might have been able to recover my partitions with testdisk, but it's not always successful and it would have taken much longer - hours even. Once I discovered the problem, it only took a few seconds to repair the damage using GPT tools.
Strangely the two drives that had the issue were of the same manufacturer and model. Something somewhere caused them both to lose their partition tables simultaneously. I hope I can figure out what or why...
If you are not using GPT partitioning, you should be. Here's one reason why:
This morning, after an update I rebooted. The reboot failed and the system froze. I punched the reset button and readied myself for trouble-shooting. The reset worked and the system booted, but it took several minutes longer than usual.
Once I was logged in, my first step was to read the boot log:
Code:
sudo grep /var/log/boot.log |more
I considered that the update had caused the issue, so I rolled back to before the update and the problem still existed - no partitions on two of my five drives.
Next step was to open Konsole and use gdisk to look at the drives:
Code:
sudo gdisk -l /dev/nvme0n1
GPT partition has a backup copy of your partition table on the drive. This is why gdisk still showed the correct partition table even though userspace tools like lsblk did not.
The commands to restore the backup version using gdisk is as follows;
sudo gdisk /dev/nvme0n1 - this opens the drive with gdisk
x - this command switches gdisk to "Expert" mode
p - this prints the partition table so you can verify it's what you want
v - this verifies the disk is OK and shows you any errors or warnings
w - this "writes" (saves) the partition table and exits gdisk
NOTE: Any time you mess with a partition table, there's a risk of data loss. Have backups!
Once I had done this to both damaged drives, I was able to reboot normally and all the partitions mounted as expected.
If had had been using MBR partitioning, I might have been able to recover my partitions with testdisk, but it's not always successful and it would have taken much longer - hours even. Once I discovered the problem, it only took a few seconds to repair the damage using GPT tools.
Strangely the two drives that had the issue were of the same manufacturer and model. Something somewhere caused them both to lose their partition tables simultaneously. I hope I can figure out what or why...