cancel
Showing results for 
Search instead for 
Did you mean: 
jmcleish
Level 13

EETech inconsistencies with partition counts

I have noticed something very odd today.

Was about to try an eboot on a machine using the standalone EETech v 6.1 (courtesy of Dan Larson) and when i check the disk info it says: 2 partitions (correctly)

P0- SS: 63  SC:76228362 C:    P1-SS:76228488  SC:40965687  D:

eboot hung, so i loaded up EETech (WinPE3 EETech (Dan Larson's) v6.0.2) and it shows 3 patritions!!

P0- SS:63 SC: 76228362 C:    P1-SS:76228425 SC:40965750 unknown   P2-SS:76228488 SC:40965687 D:

It shows the same start sector and sector count as the standalone version, but shows a new patrition inbetween?

On both the Disk Crypt List shows 2 region counts.

I then created  a BartPE USB disk with EETech 6.1.1 as per EETECH instructions.

When this boots it shows 3 partitions on disk 0 as well.

Can anyone explain ths at all?

I actually have seen this on 3 other machines- all 3 of which i had to force decrypt but the D: drives never decrypted.

I have a call in about one remaining pc that we can't recover the D drive from but would like to know why this is showing an extra partition.

ePO 4.5 and EEPC 6.0.2

Thanks

0 Kudos
7 Replies
SafeBoot
Level 21

Re: EETech inconsistencies with partition counts

your unknown partition overlaps your D partition, so it would seem to be a malformed partition table - perhaps a relic from your image process?

Are you using something like GPT drives, mapped drives etc perhaps? EEPC only supports classic MBR drive layouts with proper drive letters.

0 Kudos
dwebb
Level 12

Re: EETech inconsistencies with partition counts

Is it Windows 7 perchance?

0 Kudos
jmcleish
Level 13

Re: EETech inconsistencies with partition counts

Hi, thanks for the replies.

We use ghost - whole disk images (not partition images) and I'm sure they don't use GPT drives.

Its XP i'm afraid.

Why would the standalone disk see it properly and not the other EETech disk?

Another question- if i was to force decrypt the drive would i use the correct information i got from the standalone disk, even though the normal EETech disk says otherwise?

Thanks

Jane

0 Kudos
SafeBoot
Level 21

Re: EETech inconsistencies with partition counts

difficult to say - I would look at the region list first, if that's valid, that's exactly the information you need, otherwise I would use the D: information, as the unknown partition is most likely a logical drive or a relic.

You could look around though using the workspace and work out whether the 63 sector difference is encrypted or not - I expect not though as EEPC would never encrypt an unknown partition type.

0 Kudos
jmcleish
Level 13

Re: EETech inconsistencies with partition counts

Thanks Simon,

here's the region list

(finally found a screen capture for my bartpe!!)

cryptlist.jpg

I looked at all the sectors of the unknown partition and there was only a few characters in the very first sector and when i decrypted it it doesn't look (to me ) like anything ...useable?

unkwn1.jpg

and decrypted:

unkwn2.jpg

do you think that i should use the two partitions as stated in the info from the standalone disk then to do a force decrypt:

P0- SS: 63  SC:76228362 C:    P1-SS:76228488  SC:40965687  D:    as this appears to tie in with the region list?

And do you know why the standalone disk only sees the presumably correct info?

Thanks again

Jane

0 Kudos
SafeBoot
Level 21

Re: EETech inconsistencies with partition counts

I think if the region list is there, you should ignore the partitions completely and follow that - why don't you just do a standard "Remove" - it would seem that the disk information is intact?

You don't even need to consider this for an eBoot even?

That sector was not encrypted to start with - there are NO patterns to encrypted data (thats the point), so a sure sign of no encryption is any runs of the same char, even zeros.

0 Kudos
jmcleish
Level 13

Re: EETech inconsistencies with partition counts

Thanks Simon, I'm not allowed to touch it at the moment, but when I do, I'll try a Remove EE first.

I have noticed that as mentioned previously that when you do a force decrypt (and get an "error getting disk info" error) you take the disk offline first; is it better to take the disk offline before doing a "Remove EE"- or doesn't it matter.

Its just that I've previously had many "Remove EE"  actions hang and wondered if it was a good idea to take the disk offline first or won't it matter? as that would relate to the disk info not being intact rather than the disk being online

Thanks again

Jane

0 Kudos