Score:0

Ubuntu

I unmounted ext4 (Ubuntu OS) with gparted. Now it is unallocated. What is happening?

nfs

2/10/23, 1:57 PM

A quick summary:
I have 500 GB SSD. There is only Ubuntu 20.04 installed in it. I wrote win10.iso file inside of its EFI System Partition with dd command. After that I couldn't boot. Then I boot Ubuntu from usb. boot-repair told me to open 1mb (or something like that) space. I followed some instructions yet I failed. I would like the save the at least home folder. Half of the SSD was used. EFI part already overwritten but ext4 section where Ubuntu is installed is not overwritten.

Image (gparted): Initial situation. Before doing any gparted process.
Image (gparted): Information about EFI System Partition /dev/sda1
Image (gparted): After deleting EFI and Unmounting ext4

Here is what I did:

I opened gparted.
I delete the EFI system partition (/dev/sda1)
(For a second I thought it is better to unmount the ext4 to prevent some mistakes. It was late night.)
I unmounted ext4 on gparted (/dev/sda2)

Right after I unmounted dev/sda2 partition -> /dev/sda1, /dev/sda2, unallocated (1.02MiB), collapsed into 1 unallocated file system.

I didn't write anything on the ssd (as far as I know) after this happened.

I only used fdisk -l, lsblk -s, df, mount/umount commands.

Terminal Output (ubuntu-usb): fdisk -l output -> sdb. , File system name was changed to sdb after booting from usb(ubuntu)
Terminal Output (ubuntu-usb): fsck - N /dev/sdb output
Terminal Output (ubuntu-usb): Disk /dev/sdb specs, fdisk -l output

After a lot of anxious reading I have some ideas, questions ...
Here is what I derived:

I may have deleted the thing that called partition table.
People offer using testdisk. But before testdisk -> Should or Shouldn't I use dd or ddrescue or dd_rescue to copy the disk. Some people suggest take the copy of SSD. Then take the copy of that copy and work on it.

I seek your help and your experience in order to understand what happened.
How can I pick a safe approach.
Thank you,

UPDATES:

I am able to see my files with testdisk.
gdisk output shows that MBR:protective, GPT:present
There is only 1 partition. testdisk output is:
Linux start(65 101 37) end(60801 47 46) size_in_sector(975720448)
Before doing anything you can take a exact copy of your disk with ddrescue. Please read the part about ddrescue in testdisk documentation.
After taking a copy of your disk, It is a useful practice to take the copy of that copy and work on the latter copy.
I run testdisk on latest copy and made many experiment on it.
By following the testdisk documentation I saved my datas.

Command Outputs:

sudo gdisk -l /dev/sda:

GPT fdisk (gdisk) version 1.0.5  

Partition table scan:  
  MBR: protective  
  BSD: not present  
  APM: not present  
  GPT: present  

Found valid GPT with protective MBR; using GPT.  
Disk /dev/sda: 976773168 sectors, 465.8 GiB  
Model: Samsung SSD 860   
Sector size (logical/physical): 512/512 bytes  
Disk identifier (GUID): xxxxx   
Partition table holds up to 128 entries  
Main partition table begins at sector 2 and ends at sector 33  
First usable sector is 34, last usable sector is 976773134  
Partitions will be aligned on 2048-sector boundaries  
Total free space is 976773101 sectors (465.8 GiB)  

Number  Start (sector)    End (sector)  Size       Code  Name

testdisk Outputs:

Image (testdisk): Partition output

Tue Oct 12 14:21:50 2021
Command line: TestDisk /debug

TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <[email protected]>
https://www.cgsecurity.org
OS: Linux, kernel 5.8.0-43-generic (#49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021) x86_64
Compiler: GCC 9.2
ext2fs lib: 1.45.5, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: ncurses 6.1
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size       976773168 sectors
/dev/sda: user_max   976773168 sectors
/dev/sda: native_max 976773168 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop6 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop7 - 0 B - 0 sectors, sector size=512
Hard disk list
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - Samsung SSD 860
Disk /dev/sdb - 15 GB / 14 GiB - CHS 14664 64 32, sector size=512 - SanDisk Cruzer Force, FW:1.00
Disk /dev/loop0 - 2109 MB / 2012 MiB - 4120632 sectors (RO), sector size=512
Disk /dev/loop1 - 53 MB / 51 MiB - 104536 sectors (RO), sector size=512
Disk /dev/loop2 - 32 MB / 31 MiB - 63664 sectors (RO), sector size=512
Disk /dev/loop3 - 229 MB / 218 MiB - 448496 sectors (RO), sector size=512
Disk /dev/loop4 - 58 MB / 55 MiB - 113592 sectors (RO), sector size=512
Disk /dev/loop5 - 67 MB / 64 MiB - 132648 sectors (RO), sector size=512

Partition table type (auto): Intel
Disk /dev/sda - 500 GB / 465 GiB - Samsung SSD 860 EVO 500GB
Partition table type: Intel

Interface Advanced
Geometry from i386 MBR: head=256 sector=63
check_part_i386 1 type EE: no test
 1 P EFI GPT                  0   0  2 60801  80 63  976773167

Analyse Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63
Geometry from i386 MBR: head=256 sector=63
check_part_i386 1 type EE: no test
Current partition structure:
 1 P EFI GPT                  0   0  2 60801  80 63  976773167

Warning: Bad ending head (CHS and LBA don't match)
No partition is bootable

search_part()
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63

recover_EXT2: s_block_group_nr=0/3722, s_mnt_count=206/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 121965056
recover_EXT2: part_size 975720448
Filesystem created: Sun Jun 21 00:15:40 2020
Last mount time:    Sat Oct  9 21:29:00 2021
     Linux                   65 101 37 60801  47 46  975720448
     ext4 blocksize=4096 Large_file Sparse_SB, 499 GB / 465 GiB

Results
   * Linux                   65 101 37 60801  47 46  975720448
     ext4 blocksize=4096 Large_file Sparse_SB, 499 GB / 465 GiB

Hint for advanced users: dmsetup may be used if you prefer to avoid rewriting the partition table for the moment:
echo "0 975720448 linear /dev/sda 1050624" | dmsetup create test0

interface_write()
 1 * Linux                   65 101 37 60801  47 46  975720448
simulate write!

write_mbr_i386: starting...
write_all_log_i386: starting...
No extended partition

TestDisk exited normally.

204

0 + 0

filesystem

partitioning

gparted

data-recovery

ddrescue

Organic Marble

2/10/23, 2:17 PM

Do you have backups of your data?

1

Reply

nfs

2/10/23, 2:27 PM

@Organic Marble Unfortunately, I have not.

0

Reply

mook765

2/10/23, 2:38 PM

You overwrote the content of your EFI System Partition (ESP) which holds your bootloader, that's why you couldn't boot after your `dd`-command. You will not be able to restore the original content of this partition but you have to create a new one and reinstall the bootloader there if you want to use the system again. The other partition should be easily recovered with testdisk. Maybe not a bad idea to create a copy of the drive first, just for the case anything goes wrong during your recovery atempts.

2

Reply

nfs

2/10/23, 2:47 PM

@mook765 What I would like to do is recover the data in 460gb section. Half of it was used. I can't understand how it can be deleted under a second. There I would like to save the Home folder etc.

0

Reply

mook765

2/10/23, 2:56 PM

I'd guess you deleted this partition yourself without the intention to do so. Should be easy to recover, try testdisk...

1

Reply

nfs

2/10/23, 3:40 PM

@mook765 do you have a suggestion for creating a copy of the disk?

0

Reply

Yvain

2/10/23, 10:46 PM

You CAN simply recreate the partition table with fdisk and partitions will be here untouched

0

Reply

oldfred

2/11/23, 3:57 PM

If it is a gpt partition table, the backup at the end may still be there. Your dd totally overwrote the beginning of the drive including partition table and all data up to the size of the ISO. If MBR, there is no backup partition table. If ISO smaller that ESP & first partition and data is in second or further on drive, then testdisk may be able to restore it. What does this show? `sudo gdisk -l /dev/sda`

1

Reply

nfs

2/11/23, 5:09 PM

@oldfred thank you very much. I guess I started to understand the case. When I used dd to write on Efi, dd has stopped due to lack of space in the EFI system file. It was about 500MB. I have added the `sudo gdisk -l /dev/sda` output under the post, right after *Thank you,* part.

0

Reply

Soren A

2/11/23, 6:21 PM

The before screenshot shows /dev/sda, the after one /dev/sdb that is two different disks ...

0

Reply

oldfred

2/11/23, 6:49 PM

You cannot run fsck on a drive like sda, only on a ext4 formatted partition like sda2. But now you are not showing any partitions, just that drive is gpt? Not sure what erased backup partition table data, perhaps you did remove all partitions before the dd. Note that dd's nickname is Data Destroyer and rarely if ever should be used.

0

Reply

nfs

2/11/23, 7:23 PM

@oldfred While I was using the Ubuntu on the ssd(which was sda2) I wrote on EFI(sda1). Then I shutdown and of course It didn't boot. Then I started Ubuntu from usb stick. I deleted EFI with gparted. After I deleted Efi, ext4(sda2) was still there (maybe on ram? I didn't refresh). After that, I unmounted the ext4(sda2). Then it became unallocated. I only used dd to write on EFI(sda1). Unallocated drive(ssd) is gpt. Thank you for the note :) I didn't know that actually :(

0

Reply

oldfred

2/11/23, 9:21 PM

Unless efi(sda1) was as large as Windows ISO, the dd would have written into efi, but not stopped until full ISO copied, overwritting at least the beginning of sda2. If would not stop when sda1 was full.

0

Reply

nfs

2/11/23, 9:39 PM

@oldfred It stopped automatically. It didn't write on it. If this is the case, as you said, gpt has back-up partition table at the end of the GUID Partition Table Scheme. Shouldn't I be able to recover it with the back-up?

0

Reply

nfs

2/11/23, 9:42 PM

@Yvain which commands should be followed in order to achieve recreating process?

0

Reply

oldfred

2/12/23, 2:33 AM

But gdisk for whatever reason shows no partitions. It does say gpt. When primary is damaged, it says it is using the backup & you have to run gdisk repair commands to fix partition table. If you know exact start & end of partitions, you can manually rebuild table, but usually testdisk is a lot easier. repair gpt: http://www.rodsbooks.com/gdisk/repairing.html If it shows partitions: More repair info use p, v & w to write the partition table. If not correct just use q to quit. : http://askubuntu.com/questions/386752/fixing-corrupt-backup-gpt-table/386802#386802

0

Reply

Yvain

2/12/23, 7:34 AM

@nfs, you must boot a live media and use fdisk on the drive to restore, add a gpt or mbr partition table (should be the same that you had before) and keep the partitions signature (there will be a prompt). Then reboot the live usb but press 'c' on boot menu.

0

Reply

Yvain

2/12/23, 7:35 AM

Use the grub cmdline to boot the system with the broken efi, once in use 'grub-install --efi-directory /boot/efi. You might have to format the efi partition in fat32 beforehand. Good luck

0

Reply

nfs

2/12/23, 11:37 AM

@Yvain thank you for the instructions.

0

Reply

nfs

2/12/23, 11:46 AM

@oldfred how should I proceed with testdisk. Should I first recover the files if possible then save the partition table? Or is it possible to recover files without fixing partition table?

0

Reply

oldfred

2/12/23, 1:08 PM

I have not had to use testdisk. But if deeper search sees files, back them up. Some have seen them & then failed at recovery & everything was gone. If you end up having to use photorec, you do not get full file name, just extension. It takes forever as it just scans entire drive for anything that looks like a file. The comparing & grepping to see files can take days to determine file names. Photos do have internal date info that you can use to rename.

0

Reply

nfs

2/12/23, 3:48 PM

@oldfred I've just tried testdisk. With "quick search" option I was able to reach my files. I haven't backed up yet. I added the **log_file** and a ```image``` at the end of my post. It seems like I can reverse the situation but I can't understand what is the deal, what information is missing. Beside the problem there is also a option to take image of a disk in testdisk. Should I use it? I've checked its documents. It uses dd command.

0

Reply

oldfred

2/12/23, 4:48 PM

Did you back up files while you could? Most suggest image copy of a drive is always the safest choice & then only work on image, so if wrong choice or error you still have original. It almost looks like testdisk is finding partition starts at 0? And that would be an error. Back up files first, if possible as suggested before.

0

Reply

nfs

2/12/23, 10:13 PM

@oldfred I couldn't quite understand the subject about error and wrong choice. --- But I'll try to explain. I have an hypothesis. When i deleted EFI(sda1) first 500 mb of the SSD deleted. It is true that I overwrite the EFI(sda1) partition. But the reason why gparted detected it correctly was probably the EFI partition still flagged as boot and esp and it had a partition table. I believe if I deep search I could bring back the EFI partition(overwritten version).

0

Reply

nfs

2/12/23, 10:16 PM

@oldfred I thank you for bringing up the backup situation. I have one big concern about backup due to my lack of knowledge in this field. If I (correctly) back up the SSD to aexternal drive, is there a chance I won't be able to find the files again in the SSD? ---

0

Reply

oldfred

2/13/23, 2:31 AM

I thought testdisk gave a backup choice. While testdisk often works, we have seen cases where users lose everything. Not sure then if user error, or data was just not recoverable. Back up of important and even less important data is always the first thing you should do whether using Linux or Windows.

0

Reply

nfs

2/23/23, 6:04 PM

Hello @oldfred, I've managed to save the partition with testdisk. before that I took a ddimage of the disk and a copy of the copy. I wored on the last copy. Thank you very much for your help and explanations. -- I, still, haven't saved the ssd entirely. I am trying to figure out why some file system creation dates are before than the official one. I added the images of it at the end of the post if you like to check it.

0

Reply

oldfred

2/23/23, 8:31 PM

System folders often have the date ISO created or released. I would not worry about any system files or folders unless you modified system settings in /etc (I change grub but copy into /home so normal backup includes that). I would drill down /home/nfs ? and look for any of your files including hidden files that would be settings you made and all your data files. You probably should not use nfs as a user name in system, if you did. That also is an application.

0

Reply

nfs

2/25/23, 8:00 PM

@oldfred thank you. As you stated these are probably the date of ISO creation. I've finally figured it out with your help and recovered my data. Thank you very much. I am going to update the post. -- Now, I went back where I started. I can see my ext partition. but it is slightly different. on sda2(ext4) gparted doesn't say mnt/boot/... and first 2048 sector included in the 513 mb EFI part. Should I open a new question or continue from here?

0

Reply

oldfred

2/26/23, 12:50 PM

Not sure if you have to totally reinstall or can create new ESP - efi system partition as FAT32 and just totally reinstall grub with Boot-Repair or chroot. If grub install does not work then you need a new install. You may be able to do a "dirty" install where you do not format partition. Any files you edited that are in install will be overwritten, but if not formatted your data on drive will still be there. You would still need to restore /home for your settings. https://help.ubuntu.com/community/Boot-Repair & https://sourceforge.net/p/boot-repair/home/Home/

0

Reply

nfs

2/28/23, 11:45 AM

@oldfred thank you for all your help. It was immensely helpful.

0

Reply

Score:2