I wanted to play with the React OS, and decided to install it on a second-string Lenovo Thinkpad T420 with 4G of RAM and a Samsung SSD of 512G that already had partitions for Windows 7 and Linux Mint 20.1.

Before installing React, I started the computer with a live-disk of Mint, and used GParted to shrink the Mint partition, leaving about 20G of unallocated space. I then restarted the laptop with the boot CD installed, and told React to use the unallocated space and to format it to FAT.

The installation seemed to proceed correctly, but when the CD was removed and the laptop attempted to restart it gave the message: No active partition found_

I restarted the computer with the Mint live-disk and ran GParted again, hoping to have an idea what had happened, but received an error message (see screenshot 1). I removed the SSD and plugged it into another computer, where GParted gave the same error message. The disk itself showed on my desktop as several different volumes. I was disconcerted to see that the total size of the volumes shown was 604G and 537MB ... this on a 512G drive (see screenshot 2).

I attempted to reformat the drive, thinking that was safest ... but wound up with a situation where GParted only saw a 465G drive, and the Windows partition had apparently become invisible.

I returned the hard-drive to the Thinkpad and using the live-disk of Mint, had the disk utility reformat the hard-drive—since it was showing no partitions I hoped it would erase everything, but I saw no changes, until I plugged it back into another computer, where it simply refused to mount.

Since everything I have done so far seems to have made things worse, I thought it was finally time to ask for advice! All I want at present is to regain the entirety of my 512G hard-drive (I still plan to try React, but it can have a third-string computer all to itself).
Thanks!

Attached Thumbnails

   

Maybe just give it a new MBR, or GPT boot segment, then partition & put a filesystem on it, (you will lose all data though).

I think we need to consider how you own or wish to return to windows before we go any farther (or is it further)

As you've discovered, tinkering with these things can cause headaches.

You have to be very careful with chain-loading OSes, because they're not designed to be installed alongside others and tend to not 'play nice' when it comes to sharing space. Windows, ReactOS, the *BSDs and even some Linux distributions fall into this category.

For this reason, if you just want to 'play' or experiment with an OS, you should do so in a virtual machine. This will save you from the issues you've found. Virtual machines can be completely sandboxed, which means that they can't do any damage outside of the space allocated... or they can be an integral part of your network. The point is that errors such as this are completely prevented.

ReactOS is still in it's alpha stage. Things should be expected to go wrong. If there was ever a case for VMs, this is it right here.

1 members found this post helpful.

(this is intended to respond to the earlier comments)

Is the suggestion that in screwing up, I lost the MBR? and that replacing it would regain access to the entirety of the disk?

Yes, I stuck my neck out on this one.

It can be useful having Windows around, but on this hard-drive it is completely dispensable.

I should try a VM, but until now, at any given moment there has always been an older computer at the bottom of the food chain. But I can see that it would have spared me this nuisance.

So I am not hoping to retrieve the hidden partition, only to have the SSD accessing its complete 512G. If it turned out that in some way that part of the hard-drive was gone for good, I would just accept that I had a 465G SSD (I admit that it would rankle).

I'd just use gparted to format the entire drive to a non-journaling fs like ext2, to begin with.
Of course, to do this gparted requires a partition table, probably DOS, but up to you.

Making partitons is a user preference thing. But I think in the past I remember aligning an SSD with gparted is a two-step process. . . maybe not any more. . . .
?

It may be a good time to disk check before proceeding. Suggestion -- see How to Check for Disk Error in Linux

1 members found this post helpful.

A 500.0MB SSD is the same size as a 465.8MiB SSD. All disk size reporting tools don't necessarily indicate what the sizes indicated actually mean. Are you sure all the M and G numbers you are seeing are correct/comparable sizes?

1 members found this post helpful.

If you don't care about this drive OS then you can boot to almost any modern live media and use gnome disks or gparted to or command line fdisk or such to attempt to delete all partitions and create again. As above mentioned you can also create new mbr.

Now as to what is going on you may need to see if you can run smart tools. SSD's could be wearing out. Not sure how much it could be wearing until you check.

1 members found this post helpful.

This sounds erroneous.

This sounds correct. Generally a '500GB' drive will be 465G(ish) between formatting and the shenanigans that hardware and software people play with 'what is a byte' - most disk manufacturers specify a 'megabyte' or 'gigabyte' as n*1000 while many software applications/software types prefer n*1024, and you end up with overlapping terminology like 'MiB' vs 'MB' and so forth (which is not consistently applied (e.g. Microsoft, Apple, the linux world, etc all pick whatever definition suits them), for extra fun). This site tries to explain it some (https://www.majordifferences.com/201...abyte-and.html) but essentially '465G' sounds correct for something advertised as 500GB (and I wouldn't worry about 500 vs 512).

It may already be 'reclaimed' if you're seeing it as an empty 465G volume, but personally I'd run wipefs and then reformat it someways;

where [block device] will be something like /dev/sda

If wipefs returns an error, run again with --force like so:
Then partition it however you like, I like cfdisk so I'd run
It should treat it like a 'fresh' disk and ask you to choose between gpt, mbr, etc before letting you create partitions.

More info: https://linux.die.net/man/8/wipefs

I also agree with jefro's suggestion to check SMART if the disk supports it (although I've seen some SSDs recently that seem not to), but the usual disclaimer about "you're expecting a failing machine to fail in such a way that it can tell you how its failing without the failure affecting the part that checks for whether it is failing" when dealing with SMART applies. Very probably if there was a 'significant' error in SMART, the machine would report this on boot-up (since many modern systems check SMART during POST).

EDIT: I should point out my suggestions here are entirely destructive to any data on the disk, if it wasn't obvious.

1 members found this post helpful.

Checking the paperwork, I see the Samsung SSD is listed as 500G, so obviously my memory misfired on that.
(I have made a mental note, "Take more screenshots" as they are useful evidence in a way in which memory is not!)

Using the Mint live-disk, and running the Disk utility, it shows a 500GB (500107862016 bytes) Contents Unknown.
Running GParted shows 465.76 GiB of unallocated space, but in device information it shows 976773168 Sectors with Sector Size 512, which would seem to be the 500G the Disk utility refers to ...
I am going to mull this over.

post the output of

1 members found this post helpful.

Oh well. I guess I have to bow to reality, and accept the fact that there is no "lost partition" ...
I may not have done anything with the ReactOS, but I now know more about hard-drives and some of the utilities available, so that is something gained.
Thanks to everyone who commented!

Attached Thumbnails