Analyze Boot Record

syg00 · 08-12-2017, 08:31 AM

You can safely create a single partition to cover the entire disk - the only problem will be alignment of the start of the partition as mentioned. Can also be safely deleted if it doesn't work. Use whatever tool you originally used to create the partition, that way hopefully it will align similarly.

jlinkels · 08-12-2017, 02:29 PM

First off: be extremely careful using parted. As you see, it does not obey the command line parameter /dev/sdf which you used. Instead, it accesses all partitions. By default /dev/sda. You can select another device. But if you don't it will use /dev/sda. If you write a new partition without telling parted while you are in the parted command shell it will write to /dev/sda. Don't ask how I know this.

Anyway, IMHO not just the partition table is gone but everything else might be as well. So then you put a lot of effort into restoring the partition table, but it is useless.

Anyway, lets assume it is the partition table.

Did you reboot the system recently? After /dev/sdf went bad? If you did not reboot, cat these files:

Code:

cat /sys/block/sda/sdf1/start
cat /sys/block/sda/sdf1/size

Select /dev/sdf in parted, create a partition with this start sector and that size. Write to disk. Because the OS still assumes these values you don't have to reboot.

If you did reboot the system after /dev/sdf was inaccessible, try to find out what values were used. I bet it is equal to your /dev/sda1. Query the sector start and size for /dev/sda in parted. Select /dev/sdf. Create the new partition with these values.

Make sure you work and count in sectors everywhere. Even if your partition size is somewhat off, it does not matter. The start should be correct.

jlinkels

Garrett85 · 08-12-2017, 08:54 PM

Quote:

Originally Posted by syg00

You can safely create a single partition to cover the entire disk - the only problem will be alignment of the start of the partition as mentioned. Can also be safely deleted if it doesn't work. Use whatever tool you originally used to create the partition, that way hopefully it will align similarly.

It was either created in Gparted or it was created during the installation of my Mint system, I don't remember but it was one of those two options for sure. I see that you're saying I can safely delete if it doesn't work, does that mean that if my data would still be safe after creating this new partition table? Assuming of course that my data is still safe at all. Thanks.

Garrett85 · 08-12-2017, 09:00 PM

Quote:

Originally Posted by jlinkels

Select /dev/sdf in parted, create a partition with this start sector and that size. Write to disk. Because the OS still assumes these values you don't have to reboot.

If you did reboot the system after /dev/sdf was inaccessible, try to find out what values were used. I bet it is equal to your /dev/sda1. Query the sector start and size for /dev/sda in parted. Select /dev/sdf. Create the new partition with these values.

Make sure you work and count in sectors everywhere. Even if your partition size is somewhat off, it does not matter. The start should be correct.

jlinkels

Yes, the computer has been restarted many times since this happened.
What command should I run now. The SSD isn't in the computer anymore, it's outside the box and I've been connecting it through a USB/SATA connector to the front of my box so it usually get's the last available ID in /dev/sd? now.

jlinkels · 08-13-2017, 09:18 AM

Unplug and replug the USB adapter with the SSD attached. Check the end of /var/log/syslog. It should tell you which sd? was attached. Substitutes /dev/sdf in my example with the correct name of /dev/sd? you just attached.

jlinkels

Garrett85 · 08-13-2017, 01:24 PM

Quote:

Originally Posted by jlinkels

Unplug and replug the USB adapter with the SSD attached. Check the end of /var/log/syslog. It should tell you which sd? was attached. Substitutes /dev/sdf in my example with the correct name of /dev/sd? you just attached.

jlinkels

user@mothership ~ $ cat /var/log/syslog
Aug 13 13:04:28 mothership anacron[962]: Job `cron.daily' terminated
Aug 13 13:04:28 mothership anacron[962]: Normal exit (1 job run)

I was able to validate that my home directory SSD that I am now attaching through USB is /dev/sde.

Code:

user@mothership /sys/block/sde $ sudo cat /sys/block/sda/sde1/start
cat: /sys/block/sda/sde1/start: No such file or directory
user@mothership /sys/block/sde $ sudo cat /sys/block/sda/sde/start
cat: /sys/block/sda/sde/start: No such file or directory
user@mothership /sys/block/sde $ sudo cat /sys/block/sde/start
cat: /sys/block/sde/start: No such file or directory
user@mothership /sys/block/sde $ sudo cat /sys/block/sde1/start
cat: /sys/block/sde1/start: No such file or directory
user@mothership /sys/block/sde $ cat /sys/block/sda/sde1/size
cat: /sys/block/sda/sde1/size: No such file or directory
user@mothership /sys/block/sde $ cat /sys/block/sda/sde/size
cat: /sys/block/sda/sde/size: No such file or directory
user@mothership /sys/block/sde $ cat /sys/block/sde1/size
cat: /sys/block/sde1/size: No such file or directory
user@mothership /sys/block/sde $ cat /sys/block/sde/size
488397168

I didn't see a file 'start' inside /sys/block/sde

Code:

user@mothership /sys/block/sde $ pwd
/sys/block/sde
user@mothership /sys/block/sde $ ls
alignment_offset  bdi  capability  dev  device  discard_alignment  events  events_async  events_poll_msecs  ext_range  holders  inflight  integrity  power  queue  range  removable  ro  size  slaves  stat  subsystem  trace  uevent
user@mothership /sys/block/sde $ cat size
488397168
user@mothership /sys/block/sde $ cat stat
      66        5     2330      116        0        0        0        0        0       64      116
user@mothership /sys/block/sde $ stat size
  File: 'size'
  Size: 4096      	Blocks: 0          IO Block: 4096   regular file
Device: 12h/18d	Inode: 28079       Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-08-13 13:16:10.410324509 -0500
Modify: 2017-08-13 13:16:10.410324509 -0500
Change: 2017-08-13 13:16:10.410324509 -0500
 Birth: -

I typed in this last command my mistake but later found that stat was a program independent of this directory, this directory just happened to have a stat file in it. Thanks.

jlinkels · 08-14-2017, 04:22 AM

Are you really sure?

Since you are using Ubuntu I expect to see something in /var/log/syslog when you attach the SSD drive. Because you see the drive in /sys/block/sde it seems that it actually mounted the SSD. But it mounted /dev/sde, not /dev/sde1 so that it not useful for you recovery.

You must be sure that this is the correct drive.

Try this:

Code:

tail -f /var/log/syslog

while you unlug and replug the drive. When that does not tell anything, try

Code:

tail -f /var/log/messages

jlinkels

Garrett85 · 08-19-2017, 01:12 PM

Quote:

Originally Posted by jlinkels

Are you really sure?

Since you are using Ubuntu I expect to see something in /var/log/syslog when you attach the SSD drive. Because you see the drive in /sys/block/sde it seems that it actually mounted the SSD. But it mounted /dev/sde, not /dev/sde1 so that it not useful for you recovery.

You must be sure that this is the correct drive.

Try this:

Code:

tail -f /var/log/syslog

while you unlug and replug the drive. When that does not tell anything, try

Code:

tail -f /var/log/messages

jlinkels

It is being picked up in the /dev directory but I don't think it's mounting anywhere.

user@mothership ~ $ sudo tail -f /var/log/syslog

Code:

[sudo] password for garrett: 
Aug 19 13:07:24 mothership kernel: [  134.860686] sd 10:0:0:0: [sde] 488397168 512-byte logical blocks: (250 GB/233 GiB)
Aug 19 13:07:24 mothership kernel: [  134.861652] sd 10:0:0:0: [sde] Write Protect is off
Aug 19 13:07:24 mothership kernel: [  134.861657] sd 10:0:0:0: [sde] Mode Sense: 28 00 00 00
Aug 19 13:07:24 mothership kernel: [  134.862653] sd 10:0:0:0: [sde] No Caching mode page found
Aug 19 13:07:24 mothership kernel: [  134.862659] sd 10:0:0:0: [sde] Assuming drive cache: write through
Aug 19 13:07:24 mothership kernel: [  134.869965]  sde:
Aug 19 13:07:24 mothership kernel: [  134.873046] sd 10:0:0:0: [sde] Attached SCSI disk
Aug 19 13:07:24 mothership kernel: [  135.071022] EXT4-fs (sde): no journal found
Aug 19 13:07:27 mothership colord-sane: io/hpmud/musb.c 2095: Invalid usb_open: Permission denied
Aug 19 13:07:27 mothership colord-sane: message repeated 3 times: [ io/hpmud/musb.c 2095: Invalid usb_open: Permission denied]
[CURSOR CONTINUES]

user@mothership ~ $ sudo tail -f /var/log/messages

Code:

tail: cannot open '/var/log/messages' for reading: No such file or directory
tail: no files remaining

When I plug it into the USB this is what the desktop gives me.

Quote:

Error mounting /dev/sde at /media/garrett/86e3838b-7c18-4870-8a7b-684255629264: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/sde" "/media/garrett/86e3838b-7c18-4870-8a7b-684255629264"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sde,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.

and `dmesg | tail` gives me this

user@mothership ~ $ dmesg | tail
[ 434.879323] scsi 11:0:0:0: Direct-Access Disk Name DXT0 PQ: 0 ANSI: 2 CCS
[ 434.879883] sd 11:0:0:0: Attached scsi generic sg5 type 0
[ 434.881000] sd 11:0:0:0: [sde] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[ 434.882000] sd 11:0:0:0: [sde] Write Protect is off
[ 434.882006] sd 11:0:0:0: [sde] Mode Sense: 28 00 00 00
[ 434.883458] sd 11:0:0:0: [sde] No Caching mode page found
[ 434.883466] sd 11:0:0:0: [sde] Assuming drive cache: write through
[ 434.889938] sde:
[ 434.893016] sd 11:0:0:0: [sde] Attached SCSI disk
[ 435.093428] EXT4-fs (sde): no journal found

jlinkels · 08-19-2017, 05:03 PM

OK, it is quite clear and correct. /dev/sde is your USB. Ubuntu tries to automount and it fails. It might be that your partition table is corrupted or not. If it is not corrupted your drive is.

You can try to use parted to create a partition. If parted sees a partition starting at sector 2048 and extending over the entire disk the partition table is not likely corrupt.

If it doesn't see it, create one. Use the start sector as proposed by parted and extend the size over the entire drive. This is most likely the was the disk was initially set up.

If this fails, you have to fall back to forensic software like Photorec. I have never used it so I cannot explain anything about how to use it.

If you are in parted make sure that you are working on /dev/sde. And then once more.

jlinkels