can I recover linux mint v21.10 boot 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.

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.

Yes indeed. If you look at the "disks" application display of my 02TB SSD in my May 24 at 1:28pm message (a few messages previous), you will see the firmware version is listed as 5B2QGXA7. And so, I conclude the firmware in the 02TB SSD was probably not the cause of my problem. Nonetheless, it is a good idea to keep repeating this firmware problem with the Samsung 980 PRO SSD to prevent as many people as possible from getting screwed.

I will repeat the image of the "disks" output below in this message too (immediately below) --- just to make this easier to find. The firmware version is in parentheses at the end of the first information line ... labeled "Model".

-----

disks application display of 02TB SSD ::: Samsung 980 PRO M.2 nvme --- after the disaster

[maxreason]

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.

To answer your questions and points above:

#01: Yes, my [very poor excuse for] memory is that I installed LM21 on the 02TB SSD with EFI. However, the hex-dumps and my comments about them tend to imply otherwise. But I guess you're saying that --- all things considered based upon what I've posted in this thread --- you still believe that I probably installed LM21 on the 02TB SSD in EFI mode. Given that the MBR [and more] seems to have been modified, I no longer have any opinion about this question.

#02: You say "tell testdisk to write the partition table using a gpt partition table" ... but I still don't understand how to "tell testdisk to do anything". I have gone through the steps up-to and including "deep test" or "deep something-or-other" (forget the term ... but as far as I can tell this does not modify anything, but instead gathers information from the disk in order to provide a basis for "testdisk" (or the user) to decide HOW to modify the drive --- things like "what kind of MBR or boot-up scheme to put in the MBR and immediately-following sectors (how many "immediately-following sectors I have no freaking idea". So my next question to you is "when and how do I tell "testdisk to write the partition tables ... and what is a gpt partition table"? Is a "gpt partition table" the same as an "EFI partition table"? Is this a step that I haven't gotten to yet ... and a step at which "testdisk" will say something like "press enter to have me modify the MBR and partitions ... or Q to quit testdisk without modification to the disk"?

#03: I assume you mean I'm supposed to copy all those "hidden files" (which are not hidden the way I have nemo configured, but I assume include all files that begin with a "." (dot) character) --- AFTER --- I install all applications again.

#04: I assume the "EFI partition" is the first partition on the drive. Does this partition include the MBR (and the following 1MB or so) ... or the MBR (and the following 1MB or so) are entirely separate (and in addition to) all the partition specifications. I guess we need to be very careful to distinguish the difference between the MBR area and the area where the partition locations on disk [??? and the partition configurations ???] are specified ... versus the partitions themselves (where data is stored in those partitions).

#05: Do the specifications of the partition locations include all the specifications about the format and nature of those partitions? Or is that information stored [at the start of] the area allocated-to and reserved-for the partition? Or both?

#06: If I can't recover the 02TB SSD drive with "testdisk" (or other app) ... I will take your advice and make the "EFI partition" much smaller ... maybe 250MB or so (to be perhaps somewhat excessively conservative). Actually, I guess I can resize that partition to be smaller once everything is working again without much danger ... and ditto with some of the other partitions. But I think I better not do anything that moves the starting point of the huge/main 1.7GB partition to make it more likely the locations of files in that partition are not made more difficult to find.

#07: If I recover the 02TB SSD drive, I'll probably leave the 64GB swap partition as is. If I have to reformat ... not sure what I'll do.

#08: Why would I not want the grub loader in an EFI formatted drive?

#09: When I power-up (or reset) the computer, it used to display a list of bootable OS ... with the 02TB SSD LM21 at top. I can then move the cursor from OS to OS with up-arrow and down-arrow keystrokes to select which OS I want to boot --- and then press <enter> to boot. Or I can just do nothing and after a few seconds it would boot from the top (default) entry, namely the 02TB SSD with LM21.

What is displaying this boot-up option? Is this grub? Is this EFI? Is this BIOS? What?

#10: Yes, I will start another message to ask about backup strategies once I get all the 02TB SSD drive and boot-up issues resolved!!!

#11: Believe it or not, I did intend to make this system more robust ... which is why I created 64GB and 338GB "recovery" partitions at the very end of the 02TB SSD and 16TB HDD partition tables. My intention was to get everything installed, configured and downloaded before I set this up.

#12: Frankly, I am not as worried about not losing the OS or OS configurations as I am worried about losing my own 1.5GB of specialized files for the long-term programming project I'm getting to work on. Because of this, it has seemed (in the past) that simply making copies of these files onto another HDD every week or so was sufficient for most purposes. But this experience has me wondering ... and I don't really know enough to make a good decision yet. Fact is, I've been working on science and engineering projects on my computers for decades ... and this is the worst disaster that I've experienced yet. I don't know if I was lucky before ... or not. But this experience has made me willing to consider the issue more carefully.

#13: As a general matter ... so everyone out there can give me advice better suited to me personally ... I very much adhere to the KISS principle (namely KEEP IT SIMPLE, STUPID). I very much dislike complex systems with millions of options to configure for every possible situation and user. I'd prefer ... for example ... to simply be able to have a simple way to do the following two things:

----- #1: copy all the latest versions of my programs and the files they access.
----- #2: backup my OS and all settings for my OS and the applications the OS and I use (like software development environment, libraries, etc).

Even if that is wasteful of disk space --- that is simple, and I'd rather pay to store more HDD in the closet than dick around with fancy complex applications. A major part of this is --- my greatest weakness, by orders of magnitude, is my terrible memory for arbitrary factoids (like those typical of complex applications with millions of [interacting] options). That's partly why apps like "testdisk" are difficult for me to comprehend, even though "testdisk" is quite far from the most complicated app.

[maxreason]

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.

Thanks for the tips. From the sound of it, something like those apps you mention sound good for my tastes, because I vastly prefer very simple apps and ways of doing things (versus millions of options and automatic behavior).

Typically what I've done in the past is to not worry about OS and OS-configuration backups at all. What I have done in the past is ... when an OS dies or goes funky, that is the time to get a new computer (if its been years) or a new disk drive, and install the latest and greatest version of Linux Mint. That's what I just did a month ago --- build a new computer because my old computer is starting to develop funky behavior (lock up for a few seconds once an hour or so). That is a Linux Mint v19.10 computer ... not sure exactly when I built it, but I assume about 3 years ago.

My other "simpleton backup approach" is to make a copy of entire directories trees of my software applications and/or all the data-files that my software applications access ... onto an empty directory tree on one of my many HDD ... or just buy yet-another new 16TB drive and copy it there. This has worked pretty well for me ... up until now.

This time I got screwed at the worst possible moment. I had just built a new computer, downloaded and installed the latest and greatest version of Linux Mint (v21.10 in this case) ... downloaded and installed every Linux Mint application that I use and every non-Linux-specific application that I use, configured Linux Mint and the dozens of applications to be the way I want them (which takes a long, long time) ... then downloaded and installed the 1.5GB or so of specialized data files I need for the software development project I'll be working on for the next year or three. And then, just when I was just about done all that, I booted up one day and POOF --- the computer would not boot, the OS did not appear on the boot-up screen, and when I booted into the alternate 16TB HDD version of Linux Mint v21.10 that I also created (as practice before installing the 02TB SSD one) --- the "disks" application shows the 02TB SSD M.2 NVME drive that held ALL the past month of my work was wiped clean (no partitions).

This happened just when I was ready to make backups of the OS and everything else ... plus backups of all my programs and specialized data that took many days to download and install onto the 02TB SSD system boot-up drive.

Talk about worst-possible timing!

Obviously I should have made a backup of "the OS and everything" after I completely configured LM21 to my liking. But I didn't.

Obviously I should have made incremental backups of all that specialized data that I was downloading every 2 or 3 or 5 days. But I didn't.

And boy am I paying the price. Hopefully I learned a lesson ... though I'm still not entirely certain what is exactly the best version of the lesson I should learn to save my butt. At the very least ... what I just mentioned above would have saved me a great deal of pain right now.

I hope "testdisk" can recover the MBR and partition table and partitions on the 02TB SSD. Given how innocent the circumstances around the disaster seem, I strongly suspect all the data I downloaded onto the 02TB SSD are still there and in good shape (along with all the information in the directories that hold that data, and probably the entire directory tree in the main 1.7GB partition where the OS and all my data is.

The question seems to be ... how do I get the [MBR and] partition table fixed. I guess.

Anyone who has suggestions about backup strategies, feel free to mention them. But do remember my preference for the KISS principle!

[maxreason]

##### UPDATE #####

Okay, as I had hoped, the testdisk application apparently does not change anything on the SSD (or HDD) until the last step. Yes, that makes sense and ALMOST goes without saying --- except for something as potentially disastrous as this application where they should have said this clearly and repeatedly so users could play with the application without worry. Maybe it does say somewhere, but I do not recall reading such a statement.

Anyway, for anyone who has a similar problem as me and wants to try testdisk ... I think you can do so without much fear.

Okay, so what happened?

After going part-way through all the steps several times and looking at the output, I finally went through ALL the steps. From my earlier runs it seemed like the "Intel/PC" option produced the best results ... meaning the number and sizes of the partitions proposed by testdisk were closest to what I expected. At the very end ... just before the crucial step where testdisk writes over the partition table (and maybe/possibly MBR too), testdisk displayed roughly 10 sections of the 02TB SSD drive that it said where partitions it could not recover. This was slightly confusing to me, but since none of those proposed partitions that could not be recovered appeared to be real or desired partitions, I decided to ignore that report and continue on and let testdisk attempt to recover the partitions.

!!!!! GULP !!!!!

This was the point at which my disaster could become permanent ... or partially go away (let me recover some data) ... or completely fix the 02TB SSD so it could become my boot drive again.

And so, I pressed the <enter> key to tell testdisk to attempt to fix the 02TB SSD.

Now ... everyone reading this should make their guess as to what happened, before you read on. Okay? Done? No cheating. Okay.

The full answer is ... I am not 100% certain yet. The reason is, testdisk said I must reboot the system to complete the process. However, the 02TB SSD drive appeared on nemo (the file browser application) ... and so I dared to click on the drive name to see what happened.

The short answer is --- the contents of the / AKA "filesystem" directory were displayed ... and the set of directories and files look like what I would expect. Encouraging! Then I opened the /home directory and ... that displayed the /home/max directory. Since my name is max, that too was encouraging. Then was the time to expand the /home/max directory ... gulp. And ... good news! The set of directories and files displayed were roughly what I expected. I only say "roughly" cuz I don't have a good memory and don't remember what set of "dot directories" and "dot files" should be there. But ... looks good as far as I can tell.

Okay, I've tortured you all enough. I expanded a whole bunch of directories in the directory tree, some down three or four levels deep, and "nothing puked" and nothing looked wrong or unexpected. And so ... I'm guessing nothing is lost. But yes, still "just guessing" ... but getting more and more confident.

I've been trying to be careful not to do anything that would write to the 02TB SSD drive. Hopefully just examination of the directory tree with nemo doesn't write to the drive. Not that I know that for sure ... gulp.

A few things I definitely don't know yet ... and won't until I reboot the system ... include:

#1: Will BIOS show this recovered 02TB SSD as one of the system drives. BIOS did not show this 02TB SSD at all after the disaster.
#2: Will BIOS show this recovered 02TB SSD as one of the potential boot drives. BIOS did not show this 02TB SSD after the disaster.
#3: Will BIOS let me boot from this 02TB SSD? Obviously I could not after the disaster.
#4: Will BIOS (or whatever app) display this 02TB SSD in the list of drives I can boot from after power-up? After the disaster, no way.

Truth is, I'm not sure whether it is BIOS that displays the screen with a list of drives to boot from. Maybe that's grub. I dunno. I still don't understand exactly what happens at power-up boot time. If anyone does know ... or knows how I can find out on my system ... please explain.

The final two things I want to report before I power-down the system and power-up again are:

#1: The contents of the MBR is changed. Before testdisk did its thing, the first 80 bytes (0x00 through 0x4F) looked like code. I haven't checked byte-by-byte, but off-hand these first 80 bytes look the same. However, after the 4-byte drive signature field (or whatever the name of that field actually is) at 0x01B8 (0x41ACD963) ... there is now a 4-entry partition table with 4 entries. After the disaster and before the testdisk "recovery" that whole area was 0x00 bytes. At a glance of the hex-dump, the area starting at 0x00101000 appears unchanged or similar (to me).

#2: The following images show what the disks application displayed for:
----- the 02TB SSD after the disaster and before the testdisk "recovery process". See image in previous/following messages (no room herein).
----- the 02TB SSD after the testdisk "recovery process".
----- the 16TB HDD that I also installed LM21 onto.

As you can see:
----- after the disaster the 02TB SSD appeared (to the disks application) to be one never-partitioned empty space.
----- after the testdisk "recovery" the 02TB SSD appears similar to the 16TB HDD (both of which were LM21 boot drives).
----- the 16TB HDD looks like what a moron like me might create to be a LM21 boot drive.

Some comments about the above.

As some of you gurus and wiser folks said ... some of my choices for partitions are stupid and wasteful --- but do work. Like for example, the first partition on both 02TB SSD and 16TB HDD are roughly 64GB, which is insanely larger than any plausible eventuality. Then I've got another 64GB partition (called /spaz or something similar) reserved for ... unspecified and unknown purposes, but potentially something along the lines of backup or recovery. Then there is the 64GB /swap partition ... which is not necessary for modern versions of Linux, but at least "not totally stupid". Then there is the main partition where the OS and everything else gets stored, which is actually perfectly reasonable for a change ... or so I imagine. And then finally there is a 64GB or 338GB /recovery partition with some name or other, possibly /recovery but not necessarily so. This partition is the larger of these two sizes on the 16TB HDD simply because that drive has a great deal of available space.

There is another peculiarity that maybe someone understands and can comment upon. On the disks image of the recovered 02TB SSD drive there is a second longer/larger bar overlaying in parallel with the main OS/user/data partition and the final /recovery partition.

What the hell is that about? And could this somehow explain why the 02TB SSD drive got wiped clean? Namely, if the silly but functional partition layout that I specified got replaced with a single overlay partition, that might explain how the drive got wiped. Or not? Or what? Any ideas? What is this partition parallel to other partitions?

-----

disks app display of 02TB SSD after testdisk recovery

-----

disks app display of 16TB HDD for comparison

-----

See next message for disks display of 02TB SSD after disaster and before testdisk recovery.


##########

After I power-down the system and boot-up again (and look at what BIOS shows and allows with the recovered 02TB SSD), I will report again.

[maxreason]

As a reminder and to compare with images in previous message, here is what the disks application displayed for the 02TB SSD after the disaster and before testdisk recovery.

-----

disks app display of 02TB SSD after disaster and before testdisk recovery

[deepakdeshp]

Have you been able to boot from the 2TB drive?
Have you recovered data? Was recovery 100%?

[maxreason]

Have you been able to boot from the 2TB drive?
Have you recovered data? Was recovery 100%?

I have not yet powered-off the computer yet for various reasons. But I will as soon as I can ... within the next 24 hours.

Then I will reboot and report what I find ... and hopefully be able to mark this thread as solved.

[deepakdeshp]

It's safe to power off IMO. If it doesn't boot off it,you can boot from a live USB and save data by mounting the 2 TB partition.

[maxreason]

It's safe to power off IMO. If it doesn't boot off it,you can boot from a live USB and save data by mounting the 2 TB partition.

Yes, it is probably safe to shutdown, but I want to finish downloading a few huge files (then copy them to another disk drive) before I shutdown.

Which reminds me of one factoid that I'll mention ... just in case it matters. I extremely doubt this was the reason the 02TB SSD boot drive got wasted, because I understand how operating systems are supposed to work, and consider Linux well designed and "prudent" in all necessary ways. But just in case I'm wrong, I'll mention the following fact about what happened when the 02TB SSD boot drive got trashed.

I was in the middle of downloading 5 huge files with the Linux transmission application ... a "torrent download client" if my terminology is correct. That download had already been running for a day or two 24/7 when I decided to shut down the computer and continue the next day.

I understand that any properly designed OS will completely shut down every running application before it starts shutting down its own processes and libraries ... and as a result, it should be perfectly okay to shutdown Linux Mint while an application like Transmission is still running without danger of the OS writing any disk when the power finally shuts off.

Usually I'm overly and unnecessarily "anal" about such things, and do things the unnecessarily safe ways. In this case that would have been to shut down the transmission application until all signs of its presence were gone ... and then shutdown Linux Mint as usual (via the button at the lower-left corner of the display).

However, this time I was in a hurry and "lazy" and I just shut Linux down without first terminating the Transmission torrent application. So the Transmission application was still running and downloading chunks of files and saving them to the 02TB SSD boot disk when I told Linux Mint to shutdown (in the normal way).

I don't believe there is much chance that a well-designed and well-tested operating system like Linux Mint v21.10 would let disaster happen in a situation like I described ... but I at least want to mention this extra factoid here and now --- just in case someone out there thinks LM v21.10 might actually have a glitch of this kind in its design (or wants to tell me what a moron I am for shutting down while apps are downloading and saving data onto disk).

So I ask you ... and anyone else reading this message the following question.

Is it possible that performing a normal shutdown of Linux Mint v21.10 while an application like Transmission is downloading data and storing that data into already-created files on disk (in this case in the /home/max/download/torrent directory the 02TB SSD that was also the LM21 boot disk) ... could trash the MBR and/or partition table on that 02TB SSD disk?

I would say "virtually no chance" based on my years of good experience with Linux and Linux Mint.

What say you ... and others?

PS: And this is why I'm gonna let the currently downloading files finish downloading before I perform a shutdown. Just in case!!! I seem to have recovered the 02TB SSD at least partially ... and don't want to risk trashing the 16TB HDD that I am currently booting-from and saving-to.

But I will finish these downloads in less than 24 hours ... then check out what the testdisk "repaired" 02TB SSD drive looks like in the various BIOS windows ... then boot-up off the testdisk "repaired" 02TB SSD drive ... and see how everything runs (and whether any of the downloaded data files are corrupted). At which point I will report the situation and hopefully be able to mark this thread as SOLVED ... and thank all you very appreciated helpers!

[deepakdeshp]

Before shutdown issue

Code: Select all

sync

command so that the disk image is consistent with the ram. This would have saved it IMO.

[deepakdeshp]

Have you rebooted now? Curious about it.

[maxreason]

Have you rebooted now? Curious about it.

I shutdown transmission then shutdown LM21. Then I powered-up again.

I went into BIOS and found that the 02TB SSD NVME drive exists, but that drive is not listed as a potential boot drive, and no matter what I try while fiddling around in BIOS. When I boot-up after a reset or power-up, the 02TB SSD drive is not displayed as a potential boot drive. However, once I boot-up into LM21 on the 16TB HDD and run the disks application and select the first partition, after "Partition Type" it says "Linux (Bootable)". Yet I cannot find a way to boot-up on the drive

At least I can boot-up on the 16TB HDD still. While in that drive I am able to see the entire directory tree on both the 02TB SSD and the 16TB HDD. I do not see any damage to the directory trees of files, though obviously I can't remember every last directory or file.

Any ideas how I might go about getting the 02TB SSD drive to appear in the boot-up drives during the boot-up process?

[deepakdeshp]

First backup your 2 TB drive files.
Does

Code: Select all

 sudo update-grub

detect that there is bootable 2tb?
If it doesn't try following.

Install grub on to 2 tb. https://www.gnu.org/software/grub/manua ... stall.html
Compare the 16tb bootable partition properties like esp bootbale etc to 2tb using gparted. Replicate it to the 2 tv. Try to boot.

Good luck.

[AndyMH]

Your 2TB nvme drive has an EFI partition on it, p1. Check the contents, you can use disks to mount the partition from your working mint, there should be an Ubuntu folder in there EFI/ubuntu, does it have any files in it?

Mine:

If so, then are the flags boot and esp set on the partition, use gparted to check this?

[maxreason]

Per your request (from deepakdeshp), I am in the process of "create disk image" of the 02TB SSD drive with the disks application, which will take another hour or two. While that is happening, I decided to create a message that contains the basic data about the state of the drives and partitions. This can be a reference when we discuss "whatever issues come next" in subsequent messages.

To get around the 200KB attachment limit I resuscitated an old domain where I can store as many images as I want and link them into these messages. So you should be able to see the output of gparted and disks for all five drives in the system, which are:

drive #0 ::: 02TB_0001 == /dev/nvme0n1 == the 02TB SSD drive that had its MBR and/or partitions tables trashed and started this thread.
drive #1 ::: 16TB_0001 == /dev/sda == the 16TB HDD drive that I also installed LM21 (Linux Mint v21.10) onto and have been booting from.
drive #2 ::: 16TB_0002 == /dev/sdb == the 16TB HDD drive that I just bought to help make this process easier (and backup "anything" to).
drive #3 ::: 08TB_0001 == /dev/sdc == the 08TB HDD drive that I have been using as a random place to store miscellaneous data.
drive #4 ::: 08TB_0002 == /dev/sdd == the 08TB HDD drive that I have also been using as a random place for store miscellaneous data.

drive #0 is the Samsung 980 PRO M.2 NVME drive on the motherboard.
drive #1 is a 3.5" WD red HDD drive and is connected to SATA #1 connector on the motherboard. This drive is identical to drive #2.
drive #2 is a 3.5" WD red HDD drive and is connected to SATA #2 connector on the motherboard. This drive is identical to drive #1.
drive #3 is a 3.5" SG ????? HDD drive and is connected to SATA #3 connector on the motherboard. This drive is identical to drive #4.
drive #4 is a 3.5" SG ????? HDD drive and is connected to SATA #4 connector on the motherboard. This drive is identical to drive #3.

Unfortunately many of those readable names like 16TB_0002 and 08TB_0001 are not displayed by the disks or gparted or other applications. For some reason they seem to sometimes get removed/eliminated/whitespaced when running these applications. Often by not always these names appear in the LM21 file browser. But, of course, we can depend on the /dev/sdx names because they are associated with the physical SATA ports. And, of course, the nvme0n1 drive is the one and only M.2 NVME drive in the system.

BE CAREFUL READING NAMES OF THE IMAGES BELOW ::: 16TB_0001 and 16TB_0002 are easy to confuse, as are 08TB_0001 and 08TB_0002.

####################
####################
####################

The disks and gparted applications each have their advantages, which is why I posted images of both. You can see all the partitions of a single device/disk in gparted, but you can see more detail about each partition in the disks application ... but you need to create one image for each partition in disks, which is why there are so many images below. The images below are grouped by device/drive ... in the same order I summarize them above (from drive #0 to drive #4).

The format of the filenames are as follows (in case you look-at or download these image files by filename):

EXAMPLE #1 ::: format of filenames created by the disks application : (one disks image for each partition)
EXAMPLE #1 ::: filename == 20230527_02TB_0001_nvme0n1_disks_part0001.png
EXAMPLE #1 ::: meaning:
----- 20230527 == date the image was created : YYYYMMDD format
----- 02TB_0001 == drive name
----- nvme0n1 == device name (as in /dev/nvme0n1 or /dev/sda or /dev/sdb and so forth)
----- disks == program-that-created-the-image (in this example, the disks application)
----- partition == the partition for which information is displayed (in cases info on only one partition is displayed)
----- .png == filename extent that indicates file type (in this example the PNG image format)

The following is an example of the above ::: filename
----------
----------
----------

20230527 ::: 02TB_0001 ::: nvme0n1 ::: disks ::: part0001
----------
--------
------
----
--
EXAMPLE #2 ::: format of filenames created by the [gparted] application : (one gparted image per each drive/device)
EXAMPLE #2 ::: filename == 20230527_02TB_0001_nvme0n1_gparted.png
EXAMPLE #2 ::: meaning:
----- 20230527 == date the image was created : YYYYMMDD format
----- 02TB_0001 == drive name
----- nvme0n1 == device name (as in /dev/nvme0n1 or /dev/sda or /dev/sdb and so forth)
----- gparted == program-that-created-the-image (in this example, the gparted application)
----- .png == filename extent that indicates file type (in this example the PNG image format)

NOTE: gparted image filenames do not contain a partition field, since they display information for all partitions for each drive/device.
----------
----------
----------

20230527 ::: 02TB_0001 ::: nvme0n1 ::: gparted ::: all partitions
----------
--------
------
----
--
For some reasons ... probably to force partitions to start at the beginning of a cylinder on sector #0 of head #0 ... the partition process seems to leave small, unallocated (typically roughly 1MB) empty gaps between partitions. This is annoying ... they should extend the previous partitions to the end of the previous cylinder / head / sector so no such gaps exist (or at least give an option to do so). As a result, sometimes these partition applications display those gaps, which is annoying clutter and potentially confusing. If anyone can explain why this nonsense is done by these applications, please let everyone know in your replies.
--
----
------
--------
----------



#####################################################
#####################################################
##### drive/device and partition information for all drives #####
#####################################################
#####################################################

-----
-----

######################################################
##### drive/device == 02TB_0001 == nvme0n1 == 02TB SSD ##### M.2 NVME SSD on motherboard
######################################################

-----
-----

20230527 ::: 02TB_0001 ::: nvme0n1 ::: gparted ::: all partitions
-----
-----

20230527 ::: 02TB_0001 ::: nvme0n1 ::: disks ::: part0001
-----
-----

20230527 ::: 02TB_0001 ::: nvme0n1 ::: disks ::: part0002
-----
-----

20230527 ::: 02TB_0001 ::: nvme0n1 ::: disks ::: part0003
-----
-----

20230527 ::: 02TB_0001 ::: nvme0n1 ::: disks ::: part0004
-----
-----

20230527 ::: 02TB_0001 ::: nvme0n1 ::: disks ::: part0005
-----
-----

20230527 ::: 02TB_0001 ::: nvme0n1 ::: disks ::: part0006
-----
-----
-----
-----

######################################################
##### drive/device == 16TB_0001 == /dev/sda == 16TB HDD ##### SATA drive #1
######################################################

-----
-----

20230527 ::: 16TB_0001 ::: /dev/sda ::: gparted ::: all partitions
-----
-----

20230527 ::: 16TB_0001 ::: /dev/sda1 ::: disks ::: part0001
-----
-----

20230527 ::: 16TB_0001 ::: /dev/sda2 ::: disks ::: part0002
-----
-----

20230527 ::: 16TB_0001 ::: /dev/sda3 ::: disks ::: part0003
-----
-----

20230527 ::: 16TB_0001 ::: /dev/sda4 ::: disks ::: part0004
-----
-----

20230527 ::: 16TB_0001 ::: /dev/sda5 ::: disks ::: part0005
-----
-----
-----
-----

######################################################
##### drive/device == 16TB_0002 == /dev/sdb == 16TB HDD ##### SATA drive #2
######################################################

-----
-----

20230527 ::: 16TB_0002 ::: /dev/sdb ::: gparted ::: all partitions
-----
-----

20230527 ::: 16TB_0002 ::: /dev/sdb1 ::: disks ::: part0001
-----
-----

20230527 ::: 16TB_0002 ::: /dev/sdb2 ::: disks ::: part0002
-----
-----

20230527 ::: 16TB_0002 ::: /dev/sdb3 ::: disks ::: part0003
-----
-----

20230527 ::: 16TB_0002 ::: /dev/sdb4 ::: disks ::: part0004
-----
-----

20230527 ::: 16TB_0002 ::: /dev/sdb5 ::: disks ::: part0005
-----
-----
-----
-----

######################################################
##### drive/device == 08TB_0001 == /dev/sdc == 08TB HDD ##### SATA drive #3
######################################################

-----
-----

20230527 ::: 08TB_0001 ::: /dev/sdd ::: gparted ::: all partitions
-----
-----

20230527 ::: 08TB_0001 ::: /dev/sdd1 ::: disks ::: part0001
-----
-----

20230527 ::: 08TB_0001 ::: /dev/sdd2 ::: disks ::: part0002
-----
-----

20230527 ::: 08TB_0001 ::: /dev/sdd3 ::: disks ::: part0003
-----
-----

20230527 ::: 08TB_0001 ::: /dev/sdd4 ::: disks ::: part0004
-----
-----
-----
-----

######################################################
##### drive/device == 08TB_0002 == /dev/sdd == 08TB HDD ##### SATA drive #4
######################################################

-----
-----

20230527 ::: 08TB_0002 ::: /dev/sdd ::: gparted ::: all partitions
-----
-----

20230527 ::: 08TB_0002 ::: /dev/sdd1 ::: disks ::: part0001
-----
-----

20230527 ::: 08TB_0002 ::: /dev/sdd2 ::: disks ::: part0002
-----
-----

20230527 ::: 08TB_0002 ::: /dev/sdd3 ::: disks ::: part0003
-----
-----

20230527 ::: 08TB_0002 ::: /dev/sdd4 ::: disks ::: part0004
-----
-----
-----
-----

This is the end of the summary of the devices/drives in the system. I will now answer questions and discuss the various issues and problems that remain in separate subsequent messages --- to attempt to keep the thread of these messages easier to follow.

[maxreason]

First backup your 2 TB drive files.

Does

Code: Select all

sudo update-grub

detect that there is bootable 2tb?
If it doesn't try following.

Install grub on to 2 tb. https://www.gnu.org/software/grub/manua ... stall.html
Compare the 16tb bootable partition properties like esp bootbale etc to 2tb using gparted. Replicate it to the 2 tv. Try to boot.

Good luck.

The following is the output displayed by sudo update-grub as you requested:
-----
-----

-----
-----
I notice the next-to-last line says "Adding boot menu entry for UEFI Firmware Settings ...".

... which raises a potentially important point.

From what I can tell, MANY actions I take with these "device" and "partition" applications seems to change things related to:

#1: the MBR.
#2: OTHER devices/drives in the computer.
#3: whether the computer or BIOS or grub looks on this drive (or other drives) for boot information at boot-up time.
#4: whether grub is installed on this (or other drives) and how grub may be configured.
#5: which device/drive has control of "everything" or "some things" at boot time.

I'm getting the feeling that the entire boot aspect of Linux is A TOTAL MESS.

Of course, it may be slightly more likely that it is my brain that is A TOTAL MESS ... but that seems less likely as time passes.

And either way, I DEFINITELY have not found anything in writing that makes totally clear how the whole boot process is intended-to or supposed-to function. If that document exists somewhere, I need to find and read it. But if that document is that million-page completely unreadable UEFI document ... FORGET THAT. That was obviously written by a million politicians high on some seriously harmful drugs who clearly never even heard of the KISS principle.

Let me just add one more comment about how I would like to set up my computer. Because what I want is very straightforward and just HAS to be something lots of other people would want to do too.

And that is --- to have multiple SSD and HDD drives in my computer that ALL have Linux Mint on them (or some functional operating system) so I can boot from whichever one I want. Then, once booted-up onto whichever drive I boot-up onto ... I can see all the other drives as well as my own, and be able to read and write files on those other drives.

Then ... if any drive crashes ... I just boot off one of the other drives. I mean ... DUH. How simple and obvious and practical can you get?

!!!!! BUT !!!!!

The more I putz through all this, the more it seems that all sorts of crazy nonsense is done to OTHER drives whenever you do anything on ANY drive. Like the MBR gets written. Like the boot partitions get erased. Like the format of the boot partition gets changed. Like all sorts of crazy things happen to drives you're not even working on or doing anything with during the boot-up process or the process of adding new drives.

Unless I'm missing something incredibly strange ... the way I envision this stuff should work should be TRIVIAL ... and ISOLATED. In other words, there is NO REASON WHATSOEVER for any program to screw around with the MBR or partitions or grub or loaders or any drive except the one being added or configured.

Seriously. BIOS (or whatever it is that displays the screen that lets you select which device/drive/OS to boot-up on) can simply find which drives can boot up ... and put them in that list ... and then boot-up from the one the user selects. How could anything be easier? And why, why, why, why, why would BIOS or grub or any code involved in the boot-up process dick around with the MBR or partition table or anything else on drives at boot-up time? Just boot-the-frack-up off the drive selected. Right?

Or am I missing something seriously stupido here?

At the very least it seems clear some application is modifying the contents of "other disks" at one or more of these times:

#1: At boot-up time.
#2: When a new drive is being configured.
#3: When the partitions or boot-up capabilities of an old drive are being modified.

Why is this happening? And if you know, exactly WHAT is happening ... and when ... and why?

----------

Minor points. It is probably obvious to you that the 08TB_0001 and 08TB_0002 drives may have been Linux boot drives at one point, but for years they have only been used to store and retrieve data. Actually, I don't think I've ever run any v20 of Linux Mint before. My other Linux computer ... which has been my main (and almost sole) computer for the past 3 or 4 or 5 years, is Linux Mint v19.1 ... not Linux Mint v20.anything. I must have tried them out and "not bothered". Also, it was my FALSE understanding that the normal update process that happens with Linux every few days would update Linux Mint from v18.x to v19.x to v20.x to v21.x and so forth. Dummy me, I guess. Now I understand that I need to do a complete new install to upgrade from "whole number versions" (for lack of a better way to say it).

So ... those 08TB_000x drives have been and can continue to be "not boot drives" ... forever. Or at least until all the data is moved elsewhere and the drives are formatted totally clean again.

OTOH ... my desire is to have the 02TB_0001 nvme0n1 drive and the 16TB_0001 and 16TB_0002 drives ALL contain totally functional latest versions of Linux Mint v21.1 ... and always get updated and so forth. In other words, always be close-to up-to-date and able to boot and run.

Actually, one question (perhaps not for this thread, thought I'm not sure) might be how to now-and-then do a complete bit-for-bit copy of 16TB_0001 to 16TB_0002 ... so they are both identical boot drives. Not sure exactly how to accomplish that ... maybe dd or something on some day that I booted-up on 02TB_0001 and am not accessing either of the 16TB_000x drives?

#####

Final question. After running your first request, namely sudo update-grub ... I don't know what the output means, and therefore I did not continue on and try the second part of your message.

So please let me know what to try next.

BTW, after I removed the old 01TB drive and installed the brand new 16TB_0002 drive and installed LM21 onto it ... the 02TB SSD nvme0n1 drive DID appear in the set of drives I could supposedly boot from at boot-up time! Yeah! EXCEPT ... when I tried to boot-up on it ... it did not work. It got to a point where it said something strange like "BusyBox" and then initramfs ... and then would not boot-up or go further. Not sure what the problem was, but at least the nvme0n1 drive did appear in the options to boot-up from ... so maybe that's good ... but then it would not actually boot-up from it when I selected it. I can boot off the 16TB_0001 and 16TB_0002 drives.

What a mess!

And yes, before I booted-up, I went into BIOS several times, and all 4 of the disk drives are shown ... on the correct SATA ports ... and nothing seems strange (except they are not all listed as drives to boot-up on in the boot section of BIOS. This sorta didn't matter, because even thought 16TB_0002 was not shown as a potential boot drive in BIOS (thought one of the 08TB drives was) ... both of the 16TB_000x drives were shown on the screen during the boot-up process.

Take a look at the images of disks and gparted displays of the drives and partitions ... and let me know what to try now with the 02TB_0001 SSD nvme0n1 drive.

PS: I also have one of those 5-drive "drive bay" gizmos that accepts 5 conventional 3.5" HDD and plugs into any SSD connector to make those drives visible in the file browser. But for now, I'm not gonna plug that in until the basics (inside the PC case) are working sensibly! Right? But I'm a bit on the terrified side ... wondering whether that will totally screw everything up again once we get the basics running. What do you think?

If they are potential trouble, I'll need to get my two computers talking to each other over local area ethernet ... on the assumption that won't confuse the computer.

Thanks for the ongoing help. Much appreciated. I sure wish I could understand all this stuff.

############################
########## YIKES ##########
############################

After I executed that sudo update-grub command ... when I click on the 02TB_0001 in the file browser, it displays a small dialog window that says "unable to mount 02TB_0001". See the following ... plug what gparted and disks now display. Uh, oh?
--
--

--
--

--
--

--
--

[kato181]

You need to read the Forum rules. What you have posted is nothing but gibberish rubbish, none of which is readable, let alone understandable.

[maxreason]

You need to read the Forum rules. What you have posted is nothing but gibberish rubbish, none of which is readable, let alone understandable.

I have read the forum rules. What I posed is not gibberish or rubbish. Unless you cannot read English, what I wrote is readable.

As for "understandable" ... that is a matter of whether you or I or others understand enough of how the various boot systems in Linux function or not to comprehend the discussion. When we don't, we often go to forums like this in an attempt to find people who know more than we do, and who have struggled through the various problems and confusions to help us understand.

Much of what I'm doing in my messages is providing the fundamental information about the devices, drives, partitions and such ... so those who do know more and [hopefully] recognize the problems.

If you don't like this thread ... don't read it. I'm not sure why people like you have nothing better to do than call people names. Go find something that interests you ... and spend your time on that.

[kato181]

Obviously you can't read, show me where I called you any names, You have not done as requested my AndyMH asked you to do hence probably why he hasn't commented further. For one thing there is no such version of LM21.10. Oh by they way, typing in caps is considered as yelling on the internet, you don't need to do it if you want to highlight some text then use a different as you have done at times. Helping others is what we do here, but we don't want to spend time reading what you may think is fine, others will find it a waste of time. You asked for help and instead if doing what the experts ask you to do you post what I class as drivel. But that's my opinion. Good luck on solving your problem.

[maxreason]

Obviously you can't read, show me where I called you any names, You have not done as requested my AndyMH asked you to do hence probably why he hasn't commented further. For one thing there is no such version of LM21.10. Oh by they way, typing in caps is considered as yelling on the internet, you don't need to do it if you want to highlight some text then use a different as you have done at times. Helping others is what we do here, but we don't want to spend time reading what you may think is fine, others will find it a waste of time. You asked for help and instead if doing what the experts ask you to do you post what I class as drivel. But that's my opinion. Good luck on solving your problem.

If you bothered to read my message (and look at the images I posted - look at the 4th image from the bottom), you will notice that I followed instructions in the message from deepakdeshp just previous to AndyMH and that caused some kind of problem that made it impossible to mount the 02TB_0001 drive. Which means, I cannot see the contents of that drive with the file browser. Which means I cannot report to AndyMH (or anyone) what is on the drive --- because the drive cannot be mounted and thus the contents (directories and files) cannot be displayed by the file browser.

Understand? I literally could not do what AndyMH asked. When I can ... I will.

What is the difference between version 21.1 and 21.10 ??? Oh, never mind, I get it. You're just trying to cause trouble.

If you don't like my way to express emphasis (caps), I'm sorry. Actually, no I'm not. You're just trying to cause trouble. I'm not.

I am not just looking for instructions to follow ... I am also trying to understand how things work and why they are done the way they are.

It is obvious that you do not want to read what I write, and that's fine. But I already gave you the solution to that - just don't read my thread. Go away and stop bothering me and everyone else with utterly pointless accusations. As you can easily see, you are incapable of following or understanding even the simplest facts --- like why I can't report what is on a drive that the system can no longer mount.

Go away and let them help (which they were trying to do). You are not helping by making false accusations.

I am also trying to display as much information as possible about the drives and partitions on my computer so the experts have the information they may need to help me.

I did not complain that AndyMH has not replied to me. I'm sure he understands from my message and the image of the error dialog that shows the drive cannot be mounted (due to no object for D-Bus interface says the error dialog window displayed). So I cannot do what he asked --- until they or some other expert tells me how to fix whatever I need to fix in order to be able to mount the drive again.

Please stop your pointless and silly criticisms and let the experts help.