can I recover linux mint v21.10 boot drive ???

[maxreason]

##### DISASTER ##### HELP #####

I just built a new computer about a month ago ... installed Linux Mint v21.10 Cinnamon ... configured most everything ... then spent an entire month downloading and installing new applications and transferring files from my other (old) Linux Mint v19.10 Cinnamon.

Finally, after a month of downloading, installing, configuring new applications ... and copying most of my C and assembly source-code files from my "old v19.10 Linux Mint computer", I nearly had my new Linux Mint v21.10 Cinnamon computer ready to go (to get back to work writing software).

The last major task remaining was to copy about 38TB of data files from five 8TB HDD in my older Linux Mint v19.10 computer. But this is where essentially the worst possible disaster possible happened. Namely ... the boot drive on my new Linux Mint v21.10 computer VANISHED. Sorta.

To understand the situation clearly, I must first describe the basic configuration of the new Linux Mint v21.10 computer --- which was:

#0: 02TB Samsung 980 PRO SSD on the motherboard. This is a M.2 NVME "chewing gum stick" non-volatile memory --- HDD replacements.
#1: 16TB HDD --- conventional 3.5" spinning HDD connected to SATA_01 connector on motherboard.
#2: 01TB HDD --- conventional 3.5" spinning HDD connected to SATA_02 connector on motherboard.
#3: 04TB HDD --- conventional 3.5" spinning HDD connected to SATA_03 connector on motherboard.

#0 == Linux Mint v21.10 boot drive and ALL linux system directories and files and applications and data ... the M.2 NVME SSD drive.
#1 == Linux Mint v21.10 boot drive with little more than bare minimum to boot up and run Linux.
#2 == Windows 11 pro boot drive (manual dual boot system at boot-up time prompt with Linux Mint v21.10 at top == default boot choice).
#3 == data drive with no OS, just a bunch of data files and mostly room to store additional data files.

IMPORTANT NOTES:

A: I first installed Linux Mint v21.10 on the 16TB HDD ... just to become familiar with the Linux Mint v21.10 installation process. This drive does boot Linux Mint v21.10 ... and in fact is what I am running right now to post this message on this forum. However, this is only a minimally configured installation that I had not even booted up for over one week before the disaster happened.

B: I installed Windoze11pro on an old but fully functional 01TB HDD because a friend has been pestering me to update some open-source software I wrote years ago. That software runs on both Linux and Windows, but I haven't updated the Windows implementation of my application since I quit all things "Windows" several years ago (circa Windoze7).

C: I installed Linux Mint v21.10 on the 02TB SSD and got that default installation minimally configured.

D: I got the system working as dual boot in the convenient fashion I wanted. This is for the option to boot either Linux Mint v21.10 or Windoze11pro at boot-up time. The option to boot-up Linux Mint v21.10 (from the 02TB SSD) or Linux Mint v21.10 (from the 16TB HDD) or Windoze11pro happens at every boot-up time. The 02TB SSD version of Linux Mint v21.10 is the top and default choice, and if one is not manually selected, the system boots up the top == default choice == 02TB SSD == Linux Mint v21.10 ... followed by the 16TB HDD == Linux Mint v21.10 ... followed by Windoze11pro.

E: IMPORTANT NOTE: Before the disaster happened, I had not booted-up any OS except the default 02TB SSD Linux Mint v21.10 system for over one week, and probably two weeks. And so, though I totally don't trust anything Windows or macroshaft ... I can't imagine any way nefarious behavior by Windows is responsible. But they are a truly tricky, nefarious, diabolical bunch ... so who knows?

##########

Now to the disaster that happened.

I had just run the computer non-stop for a couple days ... mostly downloading, installing and configuring applications on the default Linux Mint v21.10 system (on the 02TB M.2 NVME SSD "drive").

My next task was to copy nearly 40TB of data from five 8TB HDD drives on my older Linux Mint v19.10 computer --- an entirely physically separate computer and my main computer for the past 3 or 4 years.

But I still have problems accessing and copying data over my local area ethernet connection ... even from Linux Mint to Linux Mint with no Windows computer involved. And so, I decided to adopt a "better" alternative. I decided to physically remove three 8TB HDD from my old Linux Mint v19.10 computer and physically install them into my new Linux Mint v21.10 computer. Hell, "why not" I figured. All those file transfers would happen faster ... and why not leave at least 3 of those drives in my new computer --- since my new computer has a total of six SATA III connectors for HDD and SDD?

So I shut down my computers, removed the three 8TB HDD from my old Linux Mint v19.10 computer, installed them in the new computer, plugged the three SATA III cables into the three empty motherboard connectors and connected the three SATA III power cables from those drives to the power-supply.

When I turned the computer on --- it should boot into the default 02TB M.2 NVME SSD drive ... right? Just like I had been doing for weeks. Right?

NOPE.

I tried several times, but no cigar.

The boot menu did not show an option to boot-up on the 02TB SSD Linux Mint v21.10 drive.

The boot menu did show an option to boot-up on the 16TB HDD Linux Mint v21.10 drive.
The boot menu did show an option to boot-up on the 01TB HDD Windoze11pro drive.

But the boot menu did not show any SSD drive at all.

I booted into BIOS.

I looked at the entry for NVME ... which should show the M.2 NVME SSD that was my default boot drive for Linux Mint v21.10. And sure enough, that exact 02TB M.2 NVME SSD drive was displayed. So ... BIOS knows the default SSD boot drive exists. So confused ... why is this drive not even shown as a boot-up option at boot-up time?

I went into everything in BIOS that had anything to do with SATA or storage-drives or boot-up configuration and so forth.

NOWHERE was the 02TB SSD drive displayed. And so, there was no option to select the 02TB SSD drive as the boot-up drive, and there was no option to bypass the boot drive selections and directly boot-up into the 02TB SSD drive --- again because the 02TB SSD drive was not shown.

In an attempt to get more information, I pulled the SATA-III cables for the three new 08TB HDD drives out of the motherboard. I figured this would simplify the setup slightly, return the configuration to what was working fine for several weeks, eliminate the chance that somehow the motherboard could not handle the full complement of six HDD ... PLUS additional M.2 NVME drives, and booted up again. No luck. No change.

Finally I booted-up into the 16TB HDD Linux Mint v21.10 drive. And the first thing I did was run the "disks" application --- a really great app, BTW.

##### OH FREAKING NO #####

The "disks" application shows ALL the drives in the computer ...
#00 : which "disks" labeled as 2.0 TB Disk : Samsung SSD 980 PRO 2TB
#01 : which "disks" labeled as 16 TB Hard Disk : WDC WD1611KFGX-68AFPNO
#02 : which "disks" labeled as 1.0 TB Hard Disk : WDC WD10-EADS-00M2B0
#03 : which "disks" labeled as 4.0 TB Hard Disk : forgot to write the part # down

When I selected the 2.0 TB SSD drive in "disks" --- the disaster became clear.

Model: Samsung SSD 980 PRO 2TB (5B2QGXA7)
Serial Number: S6B0NL0W224966T
Size: 2.0 TB (2,000,398,934,016 bytes)
Partitioning: Master Boot Record

Volumes: this graphic shows only one single wide bar the full width, with the following text in the middle: Free Space : 2.0 TB

Size: 2.0 TB (2,000,398,934,016 bytes)
Contents: Unallocated Space
Device /dev/nvme0n1

SAY WHAT ?????

The 3 or 4 partitions that were on the drive are now just a single "Master Boot Record"?

The "contents" of the drive is "unallocated space"?

!!!!! confused !!!!! I had about 1.6GB of Linux Mint OS + Linux Mint apps + Linux Mint configuration + many other apps + most of my own code + more!

ALL JUST TOTALLY GONE ?????
AND FOR NO REASON ?????

Seriously! All I did was boot down the computer via the "LM" menu at the bottom-left of the display --- just as usual. Then install three new HDD into the computer and connect three SATA cables into those HDD and the final three available SATA connectors on the motherboard. Then turn on the computer power again to boot up.

At which point the SSD was apparently wiped clean --- as far as the "disks" application is concerned.

----------

Is there any way to recover everything ... or most everything from the SSD? At least the data --- I can install and configure Linux Mint v21.10 again which will involve quite a bit of work. But to reinstall and reconfigure everything else will be an entire extra month! What a hassle!

My guess is ... somehow one bit got flipped somewhere in the root (partitions or directory) area of the SSD, and the result of that is the "disks" application (and the Linux operating system) do not recognize the SSD partitions and directories any more. Though that's just a guess.

Why else would the entire SSD get totally wiped clean by a shutdown ... install of 3 SATA drives ... and restart of the computer?

ANY ideas will be greatly appreciated.

PS: Yeah, I suppose I should have backed-up 30 times in the past month as I went through this. But geez ... I didn't expect the computer to be so flaky!

[all41]

my read is you have non backed files in jeopardy.
If so stop using that partition and look at recovery tools such as testdisk

[maxreason]

Yes, everything on the SSD was not yet backed up. The plan was to get this new installation done, then back the whole thing up.

So much for that idea! It is true that some of what is lost is the new Linux Mint v21.10 installation ... which I can obviously recreate simply by reinstalling Linux Mint v21.10 again. But obviously the days I spent configuring everything in Linux and applications the way I want is now gone (or as you put it ... in jeopardy).

Also obviously I can reinstall all the applications that I downloaded, installed and configured by downloading, installing and configuring again. So obviously that is not "lost data" because it is available downloadable software. But obviously all my configuration work on Linux and applications is lost (or as you put it ... in jeopardy).

In addition I downloaded and copied a boatload of additional applications and data that I should be able to find again and download again and configure again and get working again.

So in a sense, the only thing I've totally lost is ... all the configurations I've created. Everything else I can download and install and configure again ... but it took me a whole freaking month to get all this done, and I do not look forward to doing all that all over again!!! I never expected an entire drive to vanish like that. OTOH, I've only had one other system installed on M.2 SSD ... and that was the Linux Mint v19.10 system.

-----

I don't know what you mean by "stop using that partition". What partition do you mean? The 02TB M.2 SSD that I installed Linux Mint v21.10 onto --- that vanished into nowhere? Well, there is no partition on that SSD any more ... it is now an empty device as you see in my summary in my original message. Previously it had a boot partition, a swap partition, a main partition, and a 256GB spare partition for later use for backups and restore info. But all those partitions ARE NOW GONE --- according to the "disks" application, and the SSD is an empty device.

I'll look into the testdisk app you mention. Hopefully it can see all those partitions that were on the SSD ... and restore them.

If not ... any other possibilities?

Thanks for the info.

[maxreason]

Okay, that testdisk application looks awesome --- but way over my head. So let me post the following information here and hope you or someone can recognize what is going on here:

#1: The image below is the "disks" application display of the 16TB HDD that contains my second (and still working) Linux Mint v21.10 installation (that I'm running now). As I recall, the partition layout of this HDD drive was the same or similar to the 02TB SSD drive that now looks empty.



#2: The image below is the "disks" application display of the 02TB SSD that used to contain the working Linux Mint v21.10 installation (that vanished as you see below). As you can see, instead of 4 or 5 partitions like the HDD above, the "disks" application now shows the entire SSD as empty (no partitions).



#3: The image below is the output of the "testdisk" terminal after I selected the 02TB SSD drive from the list of 4 drives the "testdisk" application displayed. As you can see, it shows 5 partitions just like displayed by the "disks" application above for the 16TB drive. This is roughly what I would expect ... EXCEPT ... the "testdisk" output says the very first partition is "Linux filesystem" whereas I would have expected something like FAT or EFI or GPT or something along those lines. But I don't know what I'm talking about, so maybe this is okay. You folks tell me!



#4: The image below is the content of the "testdisk.log" created by the "testdisk" application ... which I assume is the longer and more complete version of the previous image.



----------

It is very interesting that the "testdisk" application seems to see all the partitions that should be there ... but the "disks" application sees the entire SSD as empty and not partitioned.

Another thing that seems potentially odd to me is ... the first partition seems to start at sector 2048 instead of sector 0000. But maybe that's the way it is supposed to be ??? The first two and the last partitions are roughly 64GB ... which is the same as the 16TB HDD drive, so probably correct. And the volume name on the huge main data partition is 0002TB_0001 ... which looks like the correct name that I would give it.

Supposedly "testdisk" can fix a lot of things ... but I am totally over my head and don't understand what to do with "testdisk" to fix this SSD.

If anyone out there can tell me from the above, I'll appreciate that very much. Thanks.

[mikeflan]

I too am hoping some smart guy (not me) can just tell you what all the problems are.
In the meantime lets work on one problem at a time. I'm guess the first problem relates to #0 and the problem is:

but the "disks" application sees the entire SSD as empty and not partitioned.

Can you post a picture of that?

Post pic to the forum:
viewtopic.php?p=2092757#p2092757
viewtopic.php?p=1999476#p1999476
viewtopic.php?p=2206430#p2206430
viewtopic.php?p=2207187#p2207187
viewtopic.php?f=42&t=267320

Also provide the output of these in a terminal:

Code: Select all

lsblk -o NAME,FSTYPE,MOUNTPOINT,LABEL,UUID | egrep -v "squashfs|tmpfs"
sudo parted -l
df -Th

[AndyMH]

Can you post the output of sudo sfdisk /dev/nvme0n1 --dump. This will output the current partition table.
This tells you how to post terminal output so it is more readable:
viewtopic.php?p=2119362&hilit=terminal#p2119362

Your screenshot from testdisk shows your partitions:

and testdisk is also reporting that the partition table is bad.

It might be possible to rebuild the partition table.

Note, I've never had to use testdisk in anger, but this is a good tutorial, haven't looked at the detail but it might rebuild the partition table for you.
https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

Note, you can upload screenshots less than 200KB direct to the forum, see the attachments tab below the reply window.

the first partition seems to start at sector 2048 instead of sector 0000.

That is normal, the partition table lives in the first 34 sectors on the drive.

[gittiest personITW]

There seems to be a problem with some Samsung 980 Pro ssd that only a firmware update can fix. It seems they run themselves into the ground and use up their alloted read/writes far sooner than they should.
A simple search will point you in the correct direction to see if your drive is affected - if the drive is still useable it is worth trying the update. If it isn't, then look at getting a refund.

[MRunar]

put your hd setup back to where it was..

I plug a live USB of linux mint

I boot on the USB key

I go inside TImeshift
if you find saved timeshift stamps, use one

I restore from there (being booted on the USB KEY)

unplug usb

restart

[maxreason]

I too am hoping some smart guy (not me) can just tell you what all the problems are.
In the meantime lets work on one problem at a time. I'm guess the first problem relates to #0 and the problem is:

but the "disks" application sees the entire SSD as empty and not partitioned.

Can you post a picture of that?

Post pic to the forum:
viewtopic.php?p=2092757#p2092757
viewtopic.php?p=1999476#p1999476
viewtopic.php?p=2206430#p2206430
viewtopic.php?p=2207187#p2207187
viewtopic.php?f=42&t=267320

Also provide the output of these in a terminal:

Code: Select all

lsblk -o NAME,FSTYPE,MOUNTPOINT,LABEL,UUID | egrep -v "squashfs|tmpfs"
sudo parted -l
df -Th

[/color]

Okay, I guess you're saying we can post images (or other files?) on these forum messages ... and that is easier for people that what I did in my previous message that has links to some of what you asked for ... you can display each of them by clicking on the paragraph that contains only the word "image". So, let me try here the alternative you mentioned. But first a couple notes:

#0: Just so you know the order things were done: First I built this new computer and installed the 02TB Samsung M.2 NVME SSD in the motherboard plus three 3.5" SATA HDD with the usual SATA-III cables (including a brand new 16TB HDD and a couple older non-OS HDD I had lying around). Then I installed Linux Mint v21.10 onto the 16TB HDD ... no problems. Then I installed windoze11pro onto the 01TB HDD and got that minimally working. Then I made sure I could see the data files on the third drive, but did nothing else with that drive. Then I did a tiny amount of configuring of the 16TB Linux Mint install so I could do basic things ... but only a little (maybe 1 hour of work). Then I installed Linux Mint v21.10 onto the 02TB SSD. Then I fiddled around in BIOS for a couple days (very annoying) until I finally got the system to dual boot the way I want ... which is as follows: When the system boots up it displays text on black background that lets me choose which drive to boot from (02TB SSD Linux Mint or 16TB Linux Mint or 01TB Windoze11 ... with the top == default choice being the 02TB SSD Linux Mint installation that I intend to run 99% of the time). Then I spent the past month configuring 02TB SSD Linux Mint v21.10 to get everything the way I want, plus downloaded, installed and configured dozens of applications that I need or want, then downloaded about 1.5TB of data (of various kinds) that I need on the disk for my current programming project. All this download/installation/configuration took at least 1 month --- which is why I don't want to lose this 02TB SSD. Note that I had not booted into Windoze11pro or the 16TB HDD Linux Mint v21.10 installation even once during the two weeks or so before the disaster happened. So even though I don't trust macroshaft AT ALL ... to put it mildly ... I don't see how they could have done this to me. Yet.

#1: I was aware of the problem with the "older" firmware in the SSD, and I updated the firmware in the 02TB Samsung 980 PRO SSD before I did anything else (including partition the SSD and install Linux Mint v21.10 onto it). But thanks for mentioning that issue, because lots of people out there don't know about that problem! I think you can verify the new firmware is on the SSD in one of the images from the "disks" application.

#2: The following two images show what the "disks" app displays for two drives. The 02TB SSD drive was the Linux Mint v21.10 boot drive that I installed one month ago and have spent the past one month configuring the OS the way I want it, downloading Linux Mint and other applications that I work with and configuring those applications the way I want them, and downloading other files (data files of various kinds) that I need for the main programming project I am currently working on.

#3: Note that ... as far as I can remember ... the partitions I created on the 02TB SSD were the same as the partitions I created on the 16TB HDD. Except for the larger size of the main partition of course, which is much larger on the 16TB HDD. And maybe the sizes of the other partitions aren't exactly the same, but they are similar. Some of the partitions are vastly larger than they need be, including the first partition. As I recall, I made them all roughly 64GB ... the same as the swap partitions ... just in case some future version of Linux or some fancy future feature required more room in some partition.

Because the partition layout of the 02TB SSD and 16TB HDD were virtually identical ... the current information about the working 16TB HDD might be a clue for fixing the 02TB SSD. The one possible exception --- which might be very relevant --- is that all that fiddling to get the dual boot capabilities to work might have included a change of the first/boot partition in the 02TB SSD. That would not have been me purposely changing the partition type, but I had to fiddle with endless configurations in the BIOS to finally get the dual boot stuff to work, and it is possible that some trick in the BIOS did that to try to accomplish "something".


#4: image of the "disks" app for 02TB SSD:

output of "disks" app for 02TB SSD

#5: image of the "disks" app for 16TB SSD:

output of "disks" app for 16TB HDD

#6: image of output of "testdisk" app that was displayed in the console/terminal window where I executed "testdisk" on the 02TB SSD. This is the output after just the first phase ... before pressing the "enter" key to have "testdisk" continue with more investigations.

output of "testdisk" app for 02TB SSD - initial

#7: image of output of "testdisk" app that was displayed in the console/terminal window where I executed "testdisk" on the 16TB HDD. This is the output after just the first phase ... before pressing the "enter" key to have "testdisk" continue with more investigations.

Note that the forum would not let me place this attachment here ... apparently because the 61KB file was "too large" (and perhaps exceeded a 200KB total size for attachments?). So click on the "image" just below to see that file:



#8: Can you tell me what will happen when I execute the commands you posted? When I see words like "squash" I get worried. Also, am I supposed to replace those arguments in all uppercase with something else ... or just enter those uppercase words as you show them?

I hope the above helps. In the future, if you see a whole line of text with only the word "image" on it ... click on "image" to see the attachment. Unfortunately the total sum size of all attachments directly into a forum message cannot exceed 200KB ... and my first 3 images added up to nearly 200KB.

PS: Final thought. I might be wrong (so don't assume I'm definitely correct) ... but I have a vague feeling/memory that the output of "disks" on the 02TB SSD had two horizontal bars ... one like the bar shown in the image above (that extends all the way across), and another that contained several partitions (like the 16TB HDD). Is there such a thing as an "overlayed partitions" setup like I describe? If so, does that explain anything?

[maxreason]

Can you post the output of sudo sfdisk /dev/nvme0n1 --dump. This will output the current partition table.
This tells you how to post terminal output so it is more readable:
viewtopic.php?p=2119362&hilit=terminal#p2119362

Your screenshot from testdisk shows your partitions:
Screenshot from 2023-05-18 13-19-16.png
and testdisk is also reporting that the partition table is bad.

It might be possible to rebuild the partition table.

Note, I've never had to use testdisk in anger, but this is a good tutorial, haven't looked at the detail but it might rebuild the partition table for you.
https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

Note, you can upload screenshots less than 200KB direct to the forum, see the attachments tab below the reply window.

the first partition seems to start at sector 2048 instead of sector 0000.

That is normal, the partition table lives in the first 34 sectors on the drive.

The output of sudo sfdisk /dev/nvme0n1 --dump is:

Code: Select all

label: dos
label-id: 0x41acd963
device: /dev/nvme0n1
unit: sectors
sector-size: 512

Does "dos" look right or reasonable? I don't know, but that makes me wonder.

The "disks" app shows the entire 02TB SSD to be one blank unpartitioned area ... while the "testdisk" app shows 5 partitions that mostly look like what the 16TB HDD contains implies (to dummy me) that:

#1: some bit or byte or information-field near the beginning of the 02TB SSD is screwed up ... but most bits/bytes/information is still correct.

#2: that if one knew what bit/byte/field was screwed-up, one could fix the problem.

#3: it would be great to recover the entire 02TB SSD drive so ALL the work I did:
--- to install and configure Linux Mint v21.10 remained
--- to download/install/configure Linux Mint applications remained
--- to download/install/configure various other downloaded applications remained
--- to transfer/install/configure my own applications remained
--- to download the roughly 1.0TB to 1.5TB of data for the programming project I'm doing remained

... BUT ... most of the time and work that seems lost was in the last item. And so, even if I cannot recover Linux Mint and the Linux Mint applications that I downloaded/installed/configured ... most of my loss would be recovered if I could just "recover" (as in copy-files-from) the directory-and-file system ... even if just that part below "/home/max".

So ... anyone who might be able to help ... keep that in mind. Given what "testdisk" displays, that partition seems like it might be okay.

BTW, I read a bunch of pages about "testdisk" on the internet. It looks like a really great program --- BUT --- it seems to assume we know everything about the low-level layout of drives and partitions to be able to know how to operate it. That might work for me ... because I'm used to working with low-level stuff ... but I would need documentation about exactly what the various layouts and byte-definitions of EVERYTHING in drives and partitions before I could understand what I need to understand. And I've never found any such reference. Have you? Anyone?

Any idea what to try next?

PS: Shouldn't I see EFI or GPT or similar somewhere ... like at the very start of the drive?

[maxreason]

There seems to be a problem with some Samsung 980 Pro ssd that only a firmware update can fix. It seems they run themselves into the ground and use up their alloted read/writes far sooner than they should.
A simple search will point you in the correct direction to see if your drive is affected - if the drive is still useable it is worth trying the update. If it isn't, then look at getting a refund.

Yes. And wise and prudent to keep mentioning that until everyone on the planet knows. In my case I knew about the problem before I built my computer, so I updated the firmware on the 02TB SSD before I installed it into my motherboard.

Actually, I have two of these SSD ... cuz they were selling them at a really good price due to the problem.

[maxreason]

put your hd setup back to where it was..

I plug a live USB of linux mint

I boot on the USB key

I go inside TImeshift
if you find saved timeshift stamps, use one

I restore from there (being booted on the USB KEY)

unplug usb

restart

My disk drive setup is now where it was for the past 2 weeks or more. The only difference is, I now boot from the 16TB HDD instead of the 02TB SSD (because the 02TB SSD won't boot and appears not to have any partitions according to the "disks" app ... but not the "testdisk" app).

When I boot up my new installation of Linux Mint v21.10 on the 16TB HDD and then run the "timeshift" app ... the "timeshift" app goes into what appears to be its "setup wizard" mode and displays a "setup wizard window". The following is what the "setup wizard window" displays:

timeshift setup wizard on 16TB HDD

timeshift setup wizard on 02TB SSD

timeshift setup wizard on 01TB HDD

Whoever wrote the "timeshift" app appears to be not careful or precise with descriptions. For example, at the bottom of the "setup wizard" window it says "devices displayed above have Linux file systems". But the 01TB drive is the Windoze11pro boot drive (pure Windows) and the 256GB drive is also a NTFS drive (pure Windows).

As you can see in the images, the "setup wizard" window says "selected drive does not have Linux partition" for the 01TB HDD (Windoze11pro).

As you can also see, however, is the "setup wizard" window says "selected drive does not have Linux partition" for the 02TB SSD ... which is the drive that was the Linux Mint v21.10 boot drive until the drive somehow got hosed (and the "disks" app says has no partitions at all any more ... while the "testdisk" app says it has 5 partitions but apparently with some defects).

Anyway, my take-away from this attempt to run timeshift is ... there was never any timeshift running on any of the drives, and no timeshift information got created anywhere.a

My other guess is ... even if it worked, that would not solve my problem. It appears to me ... though I'm not sure ... that timeshift is not designed to deal with the entire Linux partition and directory tree vanishes! Along with all users and all their directory trees and all the files within them.

But maybe I'm wrong. At any rate, does the above give you any more information or hints that might help?

[MRunar]

HI, personally i always use timeshift on my installs, saved me many times mucking around ,, looks like you have a corrupt partition reg, on the 2t drive, not sure how to fix it though, dont think a automated process would be a good solution, just me 2 cent ,, good luck

did a quick search and found this,, maybe it helps

https://askubuntu.com/questions/48717/h ... tion-table

.

[maxreason]

HI, personally i always use timeshift on my installs, saved me many times mucking around ,, looks like you have a corrupt partition reg, on the 2t drive, not sure how to fix it though, dont think a automated process would be a good solution, just me 2 cent ,, good luck

did a quick search and found this,, maybe it helps

https://askubuntu.com/questions/48717/h ... tion-table

.

Would timeshift help me recover the 1.5TB of data I downloaded and stored on my disk? That data is specific to the software application I'm writing and nothing to do with Linux itself. I thought timeshift only saves updates to the Linux OS ... and maybe some Linux system apps. Or is that wrong? What does timeshift save?

[maxreason]

A little more information.

The following image shows hex dumps of the first 4 sectors == 2048 bytes of the 02TB SSD that got its partitions trashed ... and a 16TB HDD that has valid partitions:

hex dump of first 4 sectors of 02TB SSD

hex dump of first 4 sectors of 16TB SSD

Here are some differences that I note.

The 02TB SSD has about 64 bytes of binary at the very start (address 0x0000). This may be a binary loader ... or a binary loader loader. This also has what looks like a 4-byte disk drive identifier field at 0x01B0 and a 0xAA55 "end of partition marker" at 0x01FE (that last two bytes of the first 512-byte sector on the drive).

This is very different from the 16TB HDD MBR ... which follows immediately below.


The 16TB HDD contains all zero bytes from 0x0000 to 0x01BC ... followed by what appears to be four 16-byte partition identifiers, the last three of which are all zero bytes (presumably meaning "no partitions"). The first 16-byte partition identifier having the following fields (I think):

0x0000 to 0x01BD == 0x00 == nothing presumably ... presumably this indicates an EFI format MBR with boot code somewhere else

##### partition #0 #####
0x01BE == 0x00 == drive inactive
0x01BF == 0x00 == head 0x00 (address of first sector in partition)
0x01C0 == 0x02 == sector 0x02 (address of first sector in partition)
0x01C1 == 0x00 == cylinder 0x000 (address of first sector in partition) == 0x000002
0x01C2 == 0xEE == indicates this conventional MBR is immediately followed by an EFI header
0x01C3 == 0xFF == head 0xFF (address of last sector in partition)
0x01C4 == 0xFF == sector 0x3F (address of last sector in partition)
0x01C5 == 0xFF == cylinder 0x3FF (address of last sector in partition) == 0xFFFFFF ::: total number of sectors == 16,777,216
0x01C6 to 0x01C9 == 0x00000001 == LBA of first block of data in partition
0x01CA to 0x01CD == 0xFFFFFFFF == LBA of final block of data in partition

##### partition #1 #####
0x01CE to 0x01DD == 0x00 == partition #1 does not exist (or is not specified here)

##### partition #2 #####
0x01DE to 0x01ED == 0x00 == partition #2 does not exist (or is not specified here)

##### partition #3 #####
0x01EE to 0x01FD == 0x00 == partition #3 does not exist (or is not specified here)

0x01FE to 0x01FF == 0xAA55 == end of partition marker

0x0200 to ??????? == presumably an EFI partition since starting at 0x0200 is the following ASCII text: "EFI PART"

What the EFI partition format is ... I don't know.

##########

Question: What do I tend to infer from the above?

Answer: That there should be partition specifications at 0x01BE to 0x01FD in the 02TB SSD MBR (master boot record). But that area is all 0x00 bytes. Is this maybe what got wiped clean somehow?

[AndyMH]

Reading through the link I posted, it looks like testdisk will attempt to re-write the partition table. But it identifying p3 as a swap partition looks a bit iffy - too small. It may have been an extended partition with a msdos partition table or it may have been a gpt partition table and it just got the swap partition wrong?

How did you install mint to the nvme drive - "erase and install" would not explain all the partitions - it would have created a single ext4 partition for /, or did you do a "something else" install manually setting up your partitions? Can you remember if the partitions were ntfs or ext4?

I'm assuming mint was installed in UEFI mode but there is no EFI partition on the drive and you haven't provided details on the other drives where it might have installed grub.

I assume you still get a grub menu on boot, but it is selecting mint on the nvme drive that fails? This would be consistent with grub being on another drive. Boot into mint on the 16TB drive and run efibootmgr, if it says EFI variables are not supported then that is legacy boot, anything else is UEFI.

Does "dos" look right or reasonable? I don't know, but that makes me wonder.

That's what I'm trying to figure out, is it a dos/msdos/legacy/mbr partition table or is it a gpt partition table? legacy would be problematic, you can only have four primary partitions and you are showing five. One must be an extended partition, which then raises the question, which partitions are logical - could be one or both of p4 and p5?

It may be a case of taking a punt, try gpt and is stuff readable, if not go back and try msdos. Answers to the above might add some clarity, but they won't be definitive.

[maxreason]

Reading through the link I posted, it looks like testdisk will attempt to re-write the partition table. But it identifying p3 as a swap partition looks a bit iffy - too small. It may have been an extended partition with a msdos partition table or it may have been a gpt partition table and it just got the swap partition wrong?

How did you install mint to the nvme drive - "erase and install" would not explain all the partitions - it would have created a single ext4 partition for /, or did you do a "something else" install manually setting up your partitions? Can you remember if the partitions were ntfs or ext4?

I'm assuming mint was installed in UEFI mode but there is no EFI partition on the drive and you haven't provided details on the other drives where it might have installed grub.

I assume you still get a grub menu on boot, but it is selecting mint on the nvme drive that fails? This would be consistent with grub being on another drive. Boot into mint on the 16TB drive and run efibootmgr, if it says EFI variables are not supported then that is legacy boot, anything else is UEFI.

Does "dos" look right or reasonable? I don't know, but that makes me wonder.

That's what I'm trying to figure out, is it a dos/msdos/legacy/mbr partition table or is it a gpt partition table? legacy would be problematic, you can only have four primary partitions and you are showing five. One must be an extended partition, which then raises the question, which partitions are logical - could be one or both of p4 and p5?

It may be a case of taking a punt, try gpt and is stuff readable, if not go back and try msdos. Answers to the above might add some clarity, but they won't be definitive.

#1: Yes, the swap partition is absurdly tiny. However, if you look at the location of the start of the swap partition and the start of the next partition, they are the correct distance apart for the swap partition to be 64GB --- which is what I created when I partitioned the drive. It is almost as if the size of the swap partition was the quantity of that partition being used, though I doubt the OS would keep track of how much swap space it had used in real time by modifying the actual partition information!

To answer your question, yes I did choose "other" and manually choose partition sizes. I did that because I figured it would be safer to have the boot, swap and recovery partitions separate. But this experience has made me think that the extra safety in some ways is [possibly more than] offset by extra risks. If you look at the partitions on the working 16TB HDD drive, you will see how I partitioned the 02TB SSD drive ... except maybe (from current appearances) it appears that maybe the boot portion of the 02TB SSD is not EFI, but instead conventional modern PC form.

Anyway, as for the swap partition specifically, it was definitely roughly 64GB as implied by the separation of the starting location of the swap partition and starting location of the following (main, large) partition. OTOH, I don't think the OS or the "disk" app would claim the entire drive was a single unpartitioned device just because the endpoint of the swap partition was "too close" to the start. I think something near the start ... probably within or just after the MBR (sector zero) of the drive got buggered and is throwing off the various tools. If you look at the hex dumps of the MBR and following area (in my previous message just before yours) you'll see they look radically different from each other.

#2: ALL partitions on the 02TB SSD were definitely specified by me to be ext4 format ... except the swap partition, which was "swap" format. The only possible exception is the very first partition (or pre-partition?) where the MBR is located. I thought that was EFI ... but the hex dump implies not. And when I select the type of drive before the "Analyze" step in testdisk --- I've tried both the "EFI" and the "Intel/PC" options ... and the "Intel/PC" option seems to see the partitions slightly more correctly when the longer/deeper analyses are performed by testdisk. Which further supports the GUESS that the format of the MBR area of the 02TB drive somehow was not EFI format, but was "conventional Intel/PC" format. But I need to emphasize ... that's a GUESS on my part, because while I only create ext4 and swap format partitions on Linux drives (including this 02TB one) ... I don't have full control over such things when it comes to the MBR partition or pre-partition.

#3: Look at the display of the "disks" application for the 16TB HDD in one of the previous messages. You will see a good example of what I was just talking about. Note that the very first partition is called a FAT partition type by disks. And we can see in the hex dumps in my previous message that this drive is definitely EFI format (because the text display of the hex-dump actually says EFI PART in it, which I have to assume is a pretty reliable hint). Since it wasn't me who chose FAT format, I'm guessing the Linux Mint installation process selects FAT whenever the user chooses EFI mode. Which implies to me ... while I'm sure I specified all the other partitions should be ext4 and swap type partitions, the Linux Mint installer may well have forced the first partition or pre-partition to be FAT or something very vanilla "Intel/PC" --- like maybe FAT32 or something. I just don't know this, partly because I had to fiddle for a whole freaking day or two to finally get the bootup process to let me select whether to boot from the 02TB Linux SSD or the 16TB Linux HDD or the 01TB Windoze11pro HDD ... and maybe in that process BIOS or Linux or some process decided to make the MBR partition or pre-partition a different format than I expected. I DEFINITELY did not intentionally create any NTFS partitions on the Linux drives (the 02TB SSD or the 16TB HDD).

#4: You say I haven't provided information on other drives where "it" (meaning the Linux installer I presume) might have installed grub. First take a look at the message I posted on May 24 at 1:28pm and look at the middle image --- an image captured of the "disks" app on the 16TB HDD that I also installed Linux Mint v21.10 on. In fact, I installed Linux Mint v21.10 on this 16TB HDD first to refresh my memory of the installation process before I performed the same installation process on the internal 02TB SSD "M.2 NVME chewing gum stick shape drive" on the motherboard (the one that is all messed up now). It may be important that you remember the following --- which is the order I did things:

- 00: Build computer.
- 01: Install the 02TB SSD drive on motherboard.
- 02: Plug 16TB HDD into motherboard SATA connector #0 with the usual SATA-III type cable. This is a brand new new-formatted drive.
- 03: Plug 01TB HDD into motherboard SATA connector #1 with the usual SATA-III type cable. This was an old drive lying around but totally erased.
- 04: Plug 04TB HDD into motherboard SATA connector #2 with the usual SATA-III type cable. This was an old drive that contained saved data files.
- 05: Create USB stick with Linux Mint v21.10 installer from downloaded Linux Mint v21.10 ISO file (with my old Linux Mint v19.10 computer).
- 06: Insert USB stick with Linux Mint v21.10 installer into new computer USB port, turn on computer, install Linux Mint v21.10 onto 16TB HDD.
- 07: Configure BIOS to make sure the 16TB HDD is functioning as the boot drive.
- 08: Install basic apps and perform basic configuration of Linux Mint v21.10 on 16TB HDD to assure "Linux Mint v21.10 works as expected".
- 09: Insert Windoze11pro USB stick into computer, boot up into Windows installer, install WIndoze11pro onto 01TB HDD.
- 10: Install basic apps and perform basic confirmation of Windoze11kpro on 01TB HDD to assure Windoze11pro works.
- 11: Insert USB stick with Linux Mint v21.10 installer into computer USB port, turn on computer, install Linux Mint v21.10 onto 02TB SSD.
- 12: Install basic apps and perform basic configuration of Linux Mint v21.10 on 02TB SSD to assure "Linux Mint v21.10 works as expected".
- 13: Fiddle with BIOS settings for a day or two (very frustrating) to finally manage to get BIOS to let me choose disk to boot-up on powerup.
- 14: Note that the default boot-up drive was always the 02TB SSD on the motherboard (the Samsung 980 PRO M.2 NVME drive).
- 15: Test that I could boot-up onto any drive (meaning any OS) that I wanted to at each power-up.
- 16: The default boot-up drive was always the 02TB SSD drive on the motherboard (the 980 PRO M.2 NVME drive).
- 17: Spend nearly one month downloading/installing/configuring Linux Mint and other applications.
- 18: Spend nearly two weeks downloading roughly 1.5TB of data files necessary for a programming project I'm working on --- onto 02TB SSD.
- 19: The only OS that I booted into for ~2 weeks was the default 02TB SSD Linux Mint v21.10 ... (no Windows, no 16TB HDD Linux).
- 20: POOF --- A few days ago I tried to boot-up as usual (into the default 02TB SSD) and ... would not boot.
- 21: Booted into BIOS and found the 02TB SSD was listed in the NVME section and the SATA III drives were listed ...
- 22: BUT ... in the BIOS boot-up section there was no longer any option to boot-up into the 02TB SSD drive --- that drive was not displayed.
- 23: So I booted up into the 16TB HDD version of Linux Mint v21.10 in order to be able to run apps to look at the drives and such.
- 24: When I ran the "disks" application --- MY MIND EXPLODED --- when I saw the 02TB SSD drive only contained empty space and no partitions!
- 25: Like the 16TB HDD, when I installed Linux Mint v21.10 on the 02TB SSD drive, I created several partitions, including (approximately):
----- 64GB boot partition (which I thought was EFI and still is EFI on the 16TB SSD, but now appears to be vanilla "Intel/PC" on 02TB SSD.
----- 64GB "swab" partition in ext4 format for later undefined purposes.
----- 64GB "swap" partition in swap format for conventional OS swap purposes.
-----1800GB "root" AKA "/" partition in ext4 format for OS and all other user applications.
----- 64GB "swat" partition in ext4 format for potential (not-yet-specific) "backup" and/or "recovery" purposes.
- 26: The 02TB SSD and 16TB HDD partitions were same, except the "/" partition was ~14TB and the "swat" partition was ~338GB on the 16TB HDD.
- 27: After the DISASTER I have been able to boot-up onto the 16TB HDD version of Linux Mint v21.10 just fine, and inspect all drives with apps.
- 28: The 02TB SSD no longer appears in the boot-up list of drives to boot-up onto.
- 29: The 02TB SSD looks like a blank, never partitioned space to the "disks" application.
- 30: The 02TB SSD appears to exist in BIOS, but is not listed as a possible boot-up location.
- 31: The 02TB SSD information displayed at various points by the "testdisk" app have been shown in previous messages.

Okay, I hope the above helps you and anyone else who is confused about exactly how this disaster happened. The system had been running perfectly for weeks before the disaster happened, and only the 02TB SSD version of Linux Mint v21.10 had been booted-up into for about 2 weeks --- so difficult to pin this on macroshaft and Windows.

At this point now, sometimes when I boot-up the system, it displays a "grub >" prompt. I don't know why or where this comes from, but I simply press ctl-alt-del to bootup again and press F2 or DEL to enter BIOS, and select the 16TB HDD to boot-up on --- which boots up into the 16TB HDD version of Linux Mint v21.10. This version appears to run entirely correctly --- just as the 02TB SSD version of Linux Mint v21.10 did for weeks before DISASTER struck.

Oh, and yes, I ran the latest version of memtest64+ for 20 hours with zero errors after I built the computer and before I installed or ran any versions of Linux or Windows. Just to become fairly sure the computer and memory were working properly. In case it matters, the hardware is:

CPU == 7950x.
CPU cooler == yes (with two 140mm radiator fans).
fans == 4 x 140mm case fans + 4 x 120mm case fans.
motherboard == ASUS ROG crosshair x670e extreme.
the two 5600MHz memory sticks have always been running at 4800MHz.
always run at nominal speeds and settings --- NO speedup or boost of any kind.
the various CPU/other temperatures are usually 28C to 35C and never exceed 40C.

#5: Yes, I sometimes get a "grub >" prompt at bootup, but as I mentioned above, if it doesn't boot into the 16TB HDD automatically and instead displays the "grub >" prompt ... I reset the computer, enter BIOS with F2 or DEL keys, then tell BIOS to force boot-up on the 16TB HDD.

I don't know whether grub would even show the 02TB SSD "nvme drive" ... because I don't know how to run "grub". What should I try with grub to see whether grub considers the 02TB SSD "nvme drive" as something that could potentially boot-up onto ... or even something that has any partitions?

The output of running efibootmgr and efibootmgr -v in a terminal window is the following output:

display of efibootmgr and efibootmgr -o

I have no idea what the above means, but maybe you do and can tell me. HOWEVER ... don't forget that the 16TB HDD drive may be EFI (which the hex-dump seems to indicate) while the 02TB SSD drive may not be EFI (which the hex-dump seems to indicate).

Is it okay for more than one drive in a computer to be EFI ??? If not, maybe both 02TB SSD and 16TB HDD were both EFI and that caused the 02TB SSD drive to be modified (by EFI perhaps?), causing the disaster?

Thanks for following this through.

----------

PS: A maybe unrelated question. When we add or remove mass storage drives from a computer, are we supposed to update some text file somewhere ... perhaps "before we even boot-up the computer again"? I ask because somewhere I was reading how certain files contain this kind of information --- and I never update any .conf (or other text files). And it doesn't seem reasonable to require such behavior especially these days when people insert and remove USB drives from many different USB ports on their computers all the time (many times after one boot-up).

As reminders, the following two images show what the "disks" application displays for the 02TB SSD and 16TB HDD drives:

display of disks app for 02TB SSD

display of disks app for 16TB HDD

Before the disaster the output of the "disks" app for the 02TB SSD and 16TB HDD looked nearly identical.


Note that if you look back a couple messages you'll see images of hex-dumps of the MBR plus a couple more sectors for the 02TB SSD and 16TB HDD. My comments might be misguided, but you might find them relevant. They imply "no EFI on the 02TB SSD" and "yes EFI on the 16TB HDD".


One followup point. Maybe I'm just stupid, but after reading a bunch of documentation about the "testdisk" application, I really have no freaking idea how or when the "testdisk" application will try to fix the 02TB SSD drive --- or how much danger doing so might represent.

Furthermore, is there a way to save and later restore everything at the root of the 02TB SSD drive before and after letting "testdisk" try to fix the drive ... so if this causes even worse disaster, the state of the 02TB SSD can be restored and ready for another attempt?

[AndyMH]

Based on what you have said, my best guess is that LM21 was installed in UEFI mode on the 2TB drive. I would tell testdisk to write the partition table using a gpt partition table. Note I have never needed to do this so you are on your own. Good luck!

If it works and you can read the partitions I would copy off all your hidden files in whichever partition was home - these are files/folders starting with a . and are all your config files. I would re-install mint and then copy all the hidden files back. You still need to re-install all your applications, but they will be configured as you set them up (including the desktop).

For reference, manually partitioning a drive:

• your EFI partition does not need to be more than 100MB, looks like 66GB on your 16TB drive. Format fat32 and set the flags esp and boot.

• your / partition 40-50GB, mine is 40GB on a 512GB drive, it is 22GB used with a lot installed (no flatpaks or snaps).

• you don't need a swap partition, by default mint will use a 2GB swap file. I still have one but only because I can't be bothered to remove it. If you want one make it the same size as your RAM.

Also note that there is a bug in the installer, it will put grub, the bootloader, in the first EFI partition it finds, not what you tell it (you really want grub in an EFI partition on your 2TB drive). The fix for this is, either:

• disconnect your other LM drive and win drive before install, or

• disable the esp and boot flags on the EFI partitions on those drives before install, re-enable after. gparted is the standard linux partition editor, there is a copy on your install stick.

When you finally get a working LM21 on your 2TB drive, ask about backup utilities.

[deepakdeshp]

I use Clonezilla to Clone the partition or drive. It's very versatile but needs some getting used to. Fox Clone for which AndyMH is the developer is less versatile and more user friendly. Entirely your choice.

The fact remains that without backups you remain vulnerable. So the Mantra is backup and even backup the backup you created.

[kato181]

There seems to be a problem with some Samsung 980 Pro ssd that only a firmware update can fix. It seems they run themselves into the ground and use up their alloted read/writes far sooner than they should.
A simple search will point you in the correct direction to see if your drive is affected - if the drive is still useable it is worth trying the update. If it isn't, then look at getting a refund.

Those drives should start with number 3, they are the faulty ones. If his number starts with 4 or later then the drive is ok. Sometimes the firmware update will fix the nvme, but if he is getting an error then the update will not repair it according to samsung.