Score:1

restore ext4 HD after creating GPT partition table

de flag

I have a windows10 - ubuntu 18.04 dual boot computer. Three drives on it:

  1. 512 GB SSD with ubuntu system

ubuntu drive

  1. 1 TB HD with windows system

windows drive

  1. 1 TB HD Ext4 formatted (the problematic one) for extra data storage

While working on Windows 10, I wanted to get access to the Ext4 HD but forgot it was Ext4. Entered computer managment ->storage and switched the disk from offline to online. Windows asks should it create GPT or MBR partition table. Something like (didn't do a screenshot at the moment :) )

GPT

Chose GPT and then windows created 17MB partition and remaining space marked as raw data (screenshoots taken in ubuntu).

GPT partition Unallocated Space

At this point I realized I didn't do what I wanted to do so went back to ubuntu without doing anything else.

Reading online found Testdisk and used it on the problematic HD. 1.- Created log file (full log file content added at the end of the post)

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org


TestDisk is free data recovery software designed to help recover lost
partitions and/or make non-booting disks bootable again when these symptoms
are caused by faulty software, certain types of viruses or human error.
It can also be used to repair some filesystem errors.

Information gathered during TestDisk use can be recorded for later
review. If you choose to create the text file, testdisk.log , it
will contain TestDisk options, technical information and various
outputs; including any folder/file names TestDisk was used to find and
list onscreen.

Use arrow keys to select, then press Enter key:
>[ Create ] Create a new log file
 [ Append ] Append information to log file
 [ No Log ] Don't record anything

2.- Selected problematic disk

Select a media (use Arrow keys, then press Enter):
>Disk /dev/sda - 1000 GB / 931 GiB - WDC WD10EZEX-08WN4A0
 Disk /dev/sdb - 1000 GB / 931 GiB - WDC WD10EZEX-22MFCA0
 Disk /dev/sdc - 4000 GB / 3725 GiB - WD Elements 25A1


>[Proceed ]  [  Quit  ]

Selected partition type following Testdisk suggestion

Disk /dev/sda - 1000 GB / 931 GiB - WDC WD10EZEX-08WN4A0

Please select the partition table type, press Enter when done.
 [Intel  ] Intel/PC partition
 [EFI GPT] EFI GPT partition map (Mac i386, some x86_64...)
 [Humax  ] Humax partition table
 [Mac    ] Apple partition map
>[None   ] Non partitioned media
 [Sun    ] Sun Solaris partition
 [XBox   ] XBox partition
 [Return ] Return to disk selection



Hint: None partition table type has been detected.
Note: Do NOT select 'None' for media with only a single partition. It's very
rare for a disk to be 'Non-partitioned'.

3.- Select type of Analysis

Disk /dev/sda - 1000 GB / 931 GiB - WDC WD10EZEX-08WN4A0
     CHS 121601 255 63 - sector size=512

 [ Analyse  ] Analyse current partition structure and search for lost partitions
>[ Advanced ] Filesystem Utils
 [ Geometry ] Change disk geometry
 [ Options  ] Modify options
 [ Quit     ] Return to disk selection

4.- Performed Superblock as suggested

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63

     Partition                  Start        End    Size in sectors
>   P ext4                     0   0  1 121601  80 63 1953525168 [data]

 [  Type  ] >[Superblock]  [  List  ]  [Image Creation]  [  Quit  ]

Superblock results

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63

     Partition                  Start        End    Size in sectors

  ext4                     0   0  1 121601  80 63 1953525168 [data]
superblock 32768, blocksize=4096 [data]
superblock 98304, blocksize=4096 [data]
superblock 163840, blocksize=4096 [data]
superblock 229376, blocksize=4096 [data]
superblock 294912, blocksize=4096 [data]
superblock 819200, blocksize=4096 [data]
superblock 884736, blocksize=4096 [data]
superblock 1605632, blocksize=4096 [data]
superblock 2654208, blocksize=4096 [data]
superblock 4096000, blocksize=4096 [data]

To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device

>[  Quit  ]

As shown above, Testdisk did 'it's magick' and suggested to use fsck.ext4 -p using specific block number and block size

sudo fsck.ext4 -p -b 32768 -B 4096 /dev/sda
[sudo] password for alfonso: 
data was not cleanly unmounted, check forced.
data: Group 1 inode bitmap does not match checksum.
FIXED.
data: Group 0 block bitmap does not match checksum.
FIXED.
data: 65949/61054976 files (0.7% non-contiguous), 189540323/244190646 blocks

After doing this I got access to the problematic HD and all data seems intact when mounted.

Ext4 HD


lsblk output, after running fsck.ext4, as suggested in comments

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0 175,4M  1 loop /snap/postman/133
...
loop28        7:28   0  61,9M  1 loop /snap/core20/1169
sda           8:0    0 931,5G  0 disk /media/alfonso/data
sdb           8:16   0 931,5G  0 disk 
├─sdb1        8:17   0   529M  0 part 
├─sdb2        8:18   0    99M  0 part 
├─sdb3        8:19   0    16M  0 part 
└─sdb4        8:20   0 930,9G  0 part 
sr0          11:0    1  1024M  0 rom  
nvme0n1     259:0    0   477G  0 disk 
├─nvme0n1p1 259:1    0   619M  0 part /boot/efi
├─nvme0n1p2 259:2    0 214,4G  0 part /
├─nvme0n1p3 259:3    0  34,5G  0 part [SWAP]
└─nvme0n1p4 259:4    0 227,5G  0 part /home

However, upon rebooting I came back to a HD with a GPT table and no data :( I repeated the fsck.ext4 command as above and got the data back again.

So my question is, how can I make the fsck.ext4 changes permanent? so I do not need to run it everytime I boot ubuntu.

Thanks for your help



Testdisk LOG file content

Fri Oct 22 17:35:35 2021
Command line: TestDisk

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
OS: Linux, kernel 4.15.0-161-generic (#169-Ubuntu SMP Fri Oct 15 13:41:54 UTC 2021) x86_64
Compiler: GCC 7.2
ext2fs lib: 1.44.1, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: ncurses 6.0
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size       1953525168 sectors
/dev/sda: user_max   1953525168 sectors
/dev/sda: native_max 1953525168 sectors
/dev/sdb: LBA, HPA, LBA48, DCO support
/dev/sdb: size       1953525168 sectors
/dev/sdb: user_max   1953525168 sectors
/dev/sdb: native_max 1953525168 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors, sector size=512
Hard disk list
Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - WDC WD10EZEX-08WN4A0, S/N:WD-WCC6Y0VJ3LD1, FW:02.01A02
Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - WDC WD10EZEX-22MFCA0, S/N:WD-WCC6Y6FAJ869, FW:01.01A01
Disk /dev/sdc - 4000 GB / 3725 GiB - CHS 486397 255 63, sector size=512 - WD Elements 25A1, FW:1014

Partition table type (auto): None
Disk /dev/sda - 1000 GB / 931 GiB - WDC WD10EZEX-08WN4A0
Partition table type: None

Interface Advanced
recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
   P ext4                     0   0  1 121601  80 63 1953525168 [data]
     ext4 blocksize=4096 Large_file Sparse_SB Backup_SB, 1000 GB / 931 GiB
search_superblock

block_group_nr 1

recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 262144 (block=32768, blocksize=4096)

block_group_nr 3

recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=3/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 786432 (block=98304, blocksize=4096)

block_group_nr 5

recover_EXT2: "e2fsck -b 163840 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=5/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 1310720 (block=163840, blocksize=4096)

block_group_nr 7

recover_EXT2: "e2fsck -b 229376 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=7/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 1835008 (block=229376, blocksize=4096)

block_group_nr 9

recover_EXT2: "e2fsck -b 294912 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=9/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 2359296 (block=294912, blocksize=4096)

block_group_nr 25

recover_EXT2: "e2fsck -b 819200 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=25/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 6553600 (block=819200, blocksize=4096)

block_group_nr 27

recover_EXT2: "e2fsck -b 884736 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=27/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 7077888 (block=884736, blocksize=4096)

block_group_nr 49

recover_EXT2: "e2fsck -b 1605632 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=49/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 12845056 (block=1605632, blocksize=4096)

block_group_nr 81

recover_EXT2: "e2fsck -b 2654208 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=81/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 21233664 (block=2654208, blocksize=4096)

block_group_nr 125

recover_EXT2: "e2fsck -b 4096000 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=125/7452, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190646
recover_EXT2: part_size 1953525168
Ext2 superblock found at sector 32768000 (block=4096000, blocksize=4096)
  ext4                     0   0  1 121601  80 63 1953525168 [data]
superblock 32768, blocksize=4096 [data]
superblock 98304, blocksize=4096 [data]
superblock 163840, blocksize=4096 [data]
superblock 229376, blocksize=4096 [data]
superblock 294912, blocksize=4096 [data]
superblock 819200, blocksize=4096 [data]
superblock 884736, blocksize=4096 [data]
superblock 1605632, blocksize=4096 [data]
superblock 2654208, blocksize=4096 [data]
superblock 4096000, blocksize=4096 [data]

To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device

TestDisk exited normally.
PonJar avatar
in flag
I find it odd that the device you are trying to fix is /dev/sda and not /dev/sda1, although I can see it’s shown as /dev/sda in the disks app. Have you tried targeting /dev/sda1 with the fsck command and what is the output of lsblk. Did you unmount the drive before running fsck
Alfonso avatar
de flag
Hi @PonJar thanks for the comment, before running fsck.ext4 /dev/sda1 was a small 17MB partition with the GPT partition table. This partition is gone after fsck.ext4 as seen in the img. Very similar issue, and same solution (run fsck.ext4 on /dev/sda was posted here https://forum.cgsecurity.org/phpBB3/viewtopic.php?t=8028 ). I will try running lsblk
PonJar avatar
in flag
@heynnema do you have any insight on this one? I’ve not seen a filesystem that appears to be on the device rather than on a partition. I’d recommend backing up the data to another location, repartitioning and restoring the data.
Alfonso avatar
de flag
Maybe it is worthy to add that the HD was not partitioned to start with, and testdisk automatically detected this and suggested the superblock analysis and fsck.ext4 command. Same thing than in the link of my previous command.
heynnema avatar
ru flag
Is there any actual/real data on the /dev/sda drive? `fsck` should be run on a partition (/dev/sda1), not a device (/dev/sda). Currently your /dev/sda shows no partitions. If there's really not any important data on sda, then use `gparted` to install a fresh new GPT partition table (this will wipe the drive), then create one or more partitions based on your needs.
Alfonso avatar
de flag
Hi @heynnema , actually yes. I had the HD quite full, over 700 GB ... The HD was never partitioned because I only wanted it to store extra data for the ubuntu system. I already copied everything in an external HD but I would like to understand how/why the HD returns to the 17 MB GPT parition + ~1TB of unallocated space configuration when I reboot the system. Thanks!
heynnema avatar
ru flag
Since the drive was never partitioned, I don't know how you were able to store any data on it. Bizarre. Since you've got it backed up, do as in my last comment.
Alfonso avatar
de flag
Thanks again for your interest @heynnema , I think I directly formated the whole HD as Ext4 with no partition table but it was long ago so I do not remember the details. I added the testdisk details of what I did just in case is useful
Score:1
bj flag

Super thanks to you bro for your guide

I lost all my data in 4tb hdd previously used in ubuntu as non-partitoned disk with ext4, as you did I installed windows and when boot in it and start disks management I simply pressed "initialize as gpt" and then after returning to ubuntu I was shocked when saw unallocated space, but not all my data omg zomg

Thanks to you and google, I found this thread and done all like you and return all my data, but this few hours was very nervous haha Thanks again and do backups for all of your important data ALWAYS

David avatar
cn flag
Please don't add "thank you" as an answer. Once you have sufficient [reputation](https://askubuntu.com/help/whats-reputation), you will be able to [vote up questions and answers](https://askubuntu.com/help/privileges/vote-up) that you found helpful. - [From Review](/review/late-answers/1295538)
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.