Updates:

Forums updated to SMF version 2.1.1

Removing files from an EFI System Partition?

Started by david-c, February 01, 2022, 10:19:47 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

david-c

I have previously used an old hard drive as 'storage' on an Android TV box.

I had to reset the box and now the hard drive has to be re-formatted in order to become usable again.

However, I need to get a lot of movies off the hard drive before doing that but the problem is it was formatted by Android as an 'EFI System' Partition which does not 'open' or show its contents in either Windows, Android or Linux on my laptop.

Are there any linux programmes (except Photorec) that might do the job?

Otherwise, is there a linux terminal 'command' that will guarantee access to that EFI partition and enable me to remove the files intact?

Thanks.
david-c

Keith

Hello David - and welcome to the Forum.

First off:  please tell us about your Linux system - as much as possible:   it's best to prepare for posting by reading https://linuxforums.org.uk/index.php?board=209.0 where you will find much useful info that will help people to advise you.  You will find also on the Forum page a link to Forum Rules - please read that also. 

As I understand it, EFI is platform independent so ought to be readable, but I'm no expert.
If you are attaching the offending HDD to your computer as an external device, then try this in a terminal to see if the system can see it:df -h | grep "media"If that shows your attached drive, then change to the directory listed ("/media/david/...." or whatever) and issue the commandls -lhPlease copy/paste the output in your reply. 

Keith


Brian000

Hi,

I have no experience with EFI file systems myself, but if Keiths suggestion doesn't bear any fruit, it may be worth looking at something like "Hirens Boot CD".  I've used this for similar tasks in the past.  It's a collection of freeware on a bootable image.  While I see there is a new 64bit version, I've only used the old (and much smaller) version 15.

https://www.hirensbootcd.org/hbcd-v151/

......There are alternatives..... https://alternativeto.net/software/hiren-s-bootcd-pe/

SeZo

From what I read about EFI System Partition, that the OS does not automatically mount them.
These are formatted FAT32 so they should be readable.

List partitions (replace x with drive in question):
sudo fdisk -l /dev/sdx

The list of partitions on the disk: Look for the EFI system partition in the list.

Mount it (replace x and 1 with the actual partition number:
sudo mkdir /mnt/EFI
sudo mount /dev/sdx1 /mnt/EFI


Change directory to:
cd /mnt/EFI
ls

This should list the files or folders

david-c

Many thanks for the replies.

Re: Keith: I use Upup 2019 version (puppy linux) on an old laptop. The problem drive is a Hitachi SATA hard drive 80gb which I have previously been using as a large USB storage device on a Droid (Android) TV Box. The files I am wanting to retrieve were on /dev/sdb2 but it appears they may have disappeared for good.

I have tried all the commands that have been suggested so far. The output is listed below:

# df -h | grep "media"
# fdisk -l /dev/sdb
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdb: 74.5 GiB, 80026361856 bytes, 156301488 sectors
Disk model: HTS541680J9SA00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A00ABF37-421A-489C-915A-95A51CB536B7

Device     Start       End   Sectors  Size Type
/dev/sdb1   2048     34815     32768   16M EFI System
/dev/sdb2  34816 156301454 156266639 74.5G EFI System
# mkdir /dev/sdb2 /mnt/EFI
mkdir: cannot create directory '/dev/sdb2': File exists
mkdir: cannot create directory '/mnt/EFI': File exists
# mount /dev/sdb2 /mnt/EFI
mount-FULL: /mnt/EFI: /dev/sdb2 is not a block device.
# cd /mnt/EFI
# ls

# mkdir /dev/sdb1 /mnt/EFI
mkdir: cannot create directory '/mnt/EFI': File exists
# mount /dev/sdb1 /mnt/EFI
mount-FULL: /mnt/EFI: /dev/sdb1 is not a block device.
# cd /mnt/EFI
# ls
#
#




/dev/sdb1 is 16mb, and /dev/sdb2 comprises the rest of the 80gb drive.

No files have been revealed on either /dev/sdb2 or /dev/sdb1.



If I can I will try "Hirens" as suggested by Brian000.

I will post again if I manage to find a solution.


Keith

It certainly doesn't look promising.  Good luck with the "hirens" - it's beyond me - and it might be your best bet for retrieving files.
If you can't bear to lose the files then there are companies that specialise in file retrieval, although the cost might not be trivial.

I web-searched for "companies retrieve files from broken hard drives" and found lots of DIY advice and specialist companies, so you might get some ideas there if all else fails. 

Keith

SeZo

You seem to be mixing up the instructions:
Quote# mkdir /dev/sdb2 /mnt/EFI
Where did you get that?

Start again:
sudo fdisk -l

Make sure /dev/sdb is the correct drive.
then as it is a GPT
You may need to install parted
sudo apt install parted
sudo parted /dev/sdb print

post the returned to see if the partitions are as expected

david-c

Re: SeZo reply of 2 Feb 2022

# fdisk -l /dev/sdb
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdb: 74.5 GiB, 80026361856 bytes, 156301488 sectors
Disk model: HTS541680J9SA00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A00ABF37-421A-489C-915A-95A51CB536B7

Device     Start       End   Sectors  Size Type
/dev/sdb1   2048     34815     32768   16M EFI System
/dev/sdb2  34816 156301454 156266639 74.5G EFI System
# mkdir /mnt/EFI
# mount /dev/sdb2 /mnt/EFI
mount-FULL: /mnt/EFI: special device /dev/sdb2 does not exist.
# cd /mnt/EFI
# ls
#



re: SeZo reply of 5 Feb 2022

# fdisk -l /dev/sdb
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdb: 74.5 GiB, 80026361856 bytes, 156301488 sectors
Disk model: HTS541680J9SA00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A00ABF37-421A-489C-915A-95A51CB536B7

Device     Start       End   Sectors  Size Type
/dev/sdb1   2048     34815     32768   16M EFI System
/dev/sdb2  34816 156301454 156266639 74.5G EFI System
# parted /dev/sdb print
Error: /dev/sdb: unrecognised disk label
Model: Hitachi HTS541680J9SA00 (scsi)                                     
Disk /dev/sdb: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
#


Thanks again to everyone who has tried to help resolve this problem - I think I will have to accept that the files that I was trying to retrieve are probably gone forever.

Keith

There is always the the expensive option of employing a specialist data recovery company - it depends on how valuable the file information is to you.

Keith


Brian000

Firstly, i'm not sure I'd recommend this if you intend to send the drive to a professional service, but there are options to fix an unmountable drive.  Just before you throw the disk in the bin, those may be worth looking at.  Many of the aforementioned recovery CDs contain unformatters and disk scanners, which may be able to find your files - they produce a lot out output and you need a similar sized disk to recover to.....  it's not quick either... but if you consider the data lost, and the drive scrap - it nay be worth a go.

steve57

Just for interest, I have a TV set that has the function to record TV programmes to an external hard drive. However, if after you've recorded something you then plug the drive into a PC, you'll be lucky if it even recognises it, let alone reveal any of it's contents.

I haven't figured out the ins and outs of it, what format it's using or anything else, but I can't help wondering if it's all deliberate, perhaps to protect copyright, or something like that? Either way I don't bother using it, more hassle than it's worth, and I've got other recording equipment.