Jump to content











Photo
- - - - -

grub4dos error 15, encrypted drive

grub4dos error 15 encrypted read problem

  • Please log in to reply
19 replies to this topic

#1 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 14 August 2013 - 08:38 AM

Hi everybody

 

I have this configuration

 

a notebook with the followint hard drives

  • internal OCZ-VERTEX3 SSD drive.
  • external sata SSD drive

windows 7 is installed on internal drive and it has

  • boot partition - not encrypted (never was)
  • c: system volume - encrypted with BitLocker
  • d: - originally this was encrypted too, but I turned off

(originally - means that this is an office notebook, not set up by me)

 

my problem is that grub4dos can list and read files from all volumes (USB flash, hard drives), except 

  • c: unable to mount the partition (this is natural and is not the problem)
  • d: error 15 (failed to read the file - why?)

 

it can list only the root files/directories in d:, but cannot go deeper, and cannot read any flie (even in root).

the external hard drive, is ok, I am able to boot winxp from vhd file on external drive, or usb.

even the boot partition is ok, can be listed, can be read.


Edited by kikos, 14 August 2013 - 08:39 AM.


#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 14 August 2013 - 08:41 AM

What size is the SSD? What size are the partitions?

Are the problem files past the 137GB point on the drive?

Could be a BIOS bug - what is the system and BIOS date?



#3 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 14 August 2013 - 08:52 AM

Thanks for the reply

 

disk 0

  • boot 356 MB
  • C: 106.03 GB NTFS (BitLocker Encrypted)
  • D: 117.19 GB NTFS

 

BIOS Version/Date Hewlett-Packard 68SCF Ver. F.29, 1/4/2013

 

I can check whether the file is past 137GB or not and tell you, but mind that listing the files is also a problem.

only the root can be listed, anything else leads to error 15.

 

by the way what is with 137GB - is it a general limitation?

 

(what is system date?)



#4 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 14 August 2013 - 09:04 AM

A 2013 BIOS should be OK for accessing internal drives...

 

I meant what is the system (model) and BIOS date - lol!

 

The 137GB limitation is often found even on modern BIOSes when accessing USB drives but rarely seen when accessing internal SATA drives.

 

For instance, I have an EeePC circa 2009 and it's BIOS can only access the first 137GB of a USB HDD if I boot from the USB HDD.



#5 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 14 August 2013 - 09:43 AM

indeed I forgot to tell the system

hp elitebook 8460p

 

seems I don't have the right tools to see the location of the file.

for example I put d:/file.txt and try to "cat" from grub4dos - still I have the same problem.

 

wincontig tells start cluster and end cluster both are 4,795,950 - but I don't know the cluster size (can I check somehow?)

mydefrag can show the map for the whole disk, but locating the file in such map is a problem. is there a more comfortable tool for such things?

 

but anyway - don't you think that listing the files cannot be related to 137GB?

I guess this is another problem.

 

is it possible that encryption has something to do here?



#6 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 14 August 2013 - 09:49 AM

by the way the problem is only in grub4dos.

all other OS-es (linuxes, xp, win7 live, winxp live ...) that I can boot using grub4dos, can see drive d: with no problem.

 

do you think I should try grub or grub2?

 

also changing the hard drive mode to IDE from BIOS does not change the situation anyhow.


Edited by kikos, 14 August 2013 - 09:53 AM.


#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 August 2013 - 11:16 AM

There have been in the past some issues, but they were "casual" and to a "lesser extent".
We had one issue for a logical volume inside Extended:
http://reboot.pro/to...-of-file-names/
 
And one about extremely slow "find" (still in a logical volume, but in this case this should be not "determinant"):
http://reboot.pro/to...-vs-long-delay/
 
But nothing like what you describe.
 
What EXACT version of grub4dos are you using?
 
Try running myfragmenter to find the clusters involved:
http://reboot.pro/to...sible/?p=172732
http://www.msfn.org/...-2#entry1017553
 
Then try, from grub4dos to run the blocklist command:
 
 
blocklist (hd0,1)/myfile.ext
 
The cluster size 99.99% will be 8 sectors or 4,096 bytes, you can use almost *anything to check, but try from grub4dos:
 
 
cat --hex --skip=13 --length=1 (hd0,1)0+1
Of course replace (hd0,1) with the actual volume and myfile.ext with the actual file.


I am assuming that you already ran a CHKDSK and a DEFRAG on that volume.
 


My "guts" :w00t: (i.e. no rational explanation for this guess :ph34r:) is that in *some* cases *something* connected to some of the "advanced" and "more obscure" features of NTFS, possibly related to "hard" or "soft" links, or to the strange case of files being AT THE SAME TIME fragmented and contiguous [1] *somehow* make grub4dos NTFS driver to "fail" or to become extremely unresponsive, like if it enters an almost endless loop.

:cheers:
Wonko
 
[1] Believe it or not ;):
http://sandersonfore...-and-fragmented!
http://www.forensicf...ewtopic/t=9456/

#8 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 14 August 2013 - 01:17 PM

thank you guys.

 

I think first I need to run chkdsk (in evening)

 

if this does not help - I will come with more details.



#9 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 14 August 2013 - 02:51 PM

guys I did these experiments

 

  • tried the same on other identical notebook from our office with all encryption off - NO PROBLEMS
  • turned off encryption on my C: - C: is ok, D: is not
  • defragmented and CHKDSK-ed D: - no difference

outputs from grub4dos commands

  • cat - 0000000D: 08
  • blocklist - Error 15: File Not Found

 

seems that I have some mess on D:, but don't know what ...

 

I don't know, if I format D: will it brake something with BitLocker stuff?

our IT guys say that BitLocker is very picky and boot process can be easily broken - don't know if they think so, or just say so for whatever reason.



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 August 2013 - 04:11 PM

The "queer" thing is that the only parts that grub4dos should actually check/look into are the MBR partition table (and not the MBR CODE) and the PBR BPB (Bios Parameter Block) (and NOT the PBR CODE).
 
The partition table in the MBR MUST be "unencrypted", as otherwise the BIOS would never be able to initiate the booting, I believe.
 
Checking it's contents it's easy from grub4dos:

cat --hex --skip=446 (hd0)
The BPB of a "bitlockered" volume should also be "clean", in the sense that it should remain the same as that of the same volume NON-bitlockered with the only exception of course of the volume ID which is "renewed" when formatting, in your case the volume "D:" is however seemingly not even "bitlockered", as only volume "C:" is (and at least limited to the "cluster size", your "plain" result of "8" confirms this)
 
The fact that both the ls and the blocklist command fail sounds more an issue of some kind with the $MFT (which should not at all be an issue, in the sense that in theory there is no reason why a "non-bitlockered" volume should have it's $MFT changed :unsure:.
 
But all in all your latest results seem like to exclude a connection with bitlocker, so only some "queer" values in the $MFT (that need to be additionally "transparent" to native Windows tools/OS BUT affect the grub4dos NTFS driver/interpreter) must be the culprit. :ph34r:
 
The needed tests to be performed in order to understand the cause of the issue may be long and troublesome (you will need to image/clone/re-format/bitlocker/un-bitlocker a "test machine"/"test device"), if you are game for it, it would be very interesting but - don't want to put you down in any way :), mind you - it will need some serious commitment on your side (as you are the one that will have to do most of the work).
 
AGAIN, which EXACT version of grub4dos are you using?
I NEED this piece of info to exclude preliminarily the possibility that you are using a buggy, obsolete or more generally "inappropriate" version.
 
:cheers:
Wonko

#11 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 14 August 2013 - 04:22 PM

guys I did these experiments

  • tried the same on other identical notebook from our office with all encryption off - NO PROBLEMS

When you say 'identical' - do you mean the notebook is same model, same BIOS version and same size HDD and same sized partitions?



#12 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 14 August 2013 - 04:31 PM

this may be my fault - I'll check tomorrow - when in the office.

 

some months ago, I was searching for a way to install grub4dos and the first thing to get from google is wingrub - some GUI - installer of buggy grub4dos.

soon I understood that I can use another installer bootlace.com, and copy grldr.

but the best I could find was grub4dos-0.4.4 (2009-03-31(r66) 0.4.4 official release) (latest version of some aging repo)

 

is this buggy?

only today I found about "chenall grub4dos" while digging this forum.

and only this search lead me to here https://code.google..../downloads/list

 

is this the best place to download? I will try tomorrow if this is ok.
if this does not help, then I'll need to go through all details.

meanwhile - identical means everything is the same - model, hdd model, size ... except I'm not sure on BIOS version the other computer's BIOS can be older I think.



#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 August 2013 - 04:47 PM

but the best I could find was grub4dos-0.4.4 (2009-03-31(r66) 0.4.4 official release) (latest version of some aging repo)
 
is this buggy?
only today I found about "chenall grub4dos" while digging this forum.
and only this search lead me to here https://code.google..../downloads/list

Yes, that is a version known as being VERY buggy :ph34r: of the very old 0.4.4. series.

For the record the ONLY version of the 0.4.4 series that one should EVER use is the grub4dos-0.4.4-2009-10-16 :
http://reboot.pro/to...16641-grub4dos/
AND NOT ANY previous version.

What you (and anyone else) should use today (unless EXPRESSLY guided to use a different version by someone "expert" with grub4dos) is the LATEST version with a "c" in the filename AND marked as "Featured" on this page:
http://code.google.c.../downloads/list
which at the moment of this writing is grub4dos-0.4.5c-2013-03-03
http://code.google.c...-03.7z&can=2&q=

:cheers:
Wonko

#14 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 15 August 2013 - 08:25 AM

I've just updated grub4dos (0.4.5c) - this did not help :(

 

unfortunately this is my office work computer, and re installing the system takes one day (our IT team writes an image of win7) and after I need two days for full setup.

so considering that I have to work (also :) ), this eliminates the possibility of long examination of everything, because I will destroy the system definitely :)

 

also I'm not an expert to debug the contents of MFT - it is useless activity for me :(

 

the only possibility for me that I see is - clean up D: (without formatting) and see if things are getting better.

by the way currently I have some amount of symlinks (soft) on my D: (~100 file links, and few folder links), but this is my working setup.

so I'll need some time, to do this clean up.

 

do you guys see any other possibility for me?



#15 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 15 August 2013 - 08:29 AM

Try running chkdsk and defragging your D: drive ?

 

If possible, swap over the HDD between the two 'identical' systems and see if the problem follows the HDD or the system?



#16 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 15 August 2013 - 08:49 AM

chkdsk, defrag - have done yesterday (not a restart schedule, but windows unmounted

 

swap hdd - ...

 

I'm not even allowed to disable encryption. in our office everything is done for us not being able to multiboot ...

so I cannot have such activity of disassembling notebooks - mine and other guy's :)

 

I just disabled encryption, because I'm not taking the notebook to home - it stays here, not under my responsibility.

 

 

all my efforts are for the sake of some fun (boot xp from vhd, from internal hdd - not from usb, or external), so this should not critically conflict with my work :)


Edited by kikos, 15 August 2013 - 08:53 AM.


#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 August 2013 - 03:04 PM

Yep, as said, though I have no evidence/experience/documentation to support the (still "educated") guess, testing after having removed (of course having properly backed up the system) the softlinks may solve the issue.

Idea :idea:

(cannot say if at all possible given your very understandable constraints :dubbio:).

 

Can you resize (shrink) slightly the volume and create a (very small) additional, new one and move all the softlinks to this new volume?

 

:cheers:

Wonko



#18 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 15 August 2013 - 05:28 PM

today I created softlinks on C: - 1024 softlinks to files .. but this didn't mess C:, it is still visible from grub4dos (as it is de-crypted now)

I'm thinking about cleaning D: until I get it working hopefully



#19 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 August 2013 - 05:53 PM

today I created softlinks on C: - 1024 softlinks to files .. but this didn't mess C:, it is still visible from grub4dos (as it is de-crypted now)

I'm thinking about cleaning D: until I get it working hopefully

Good :), though this may be only part of the story.

I mean IF the issue is somehow connected with soft links, it is possible that the way you have created them now on C: (after all the "normal" files that are on C: are already there) produces something *different* from the way the D: drive was - over the time - *mixed* with softlinks and "normal" files. :unsure:

 

Still, IF the issue is - as I suspect - connected with *something* in the $MFT (and CHKDSK or DEFRAG don't change this *something*) the only practical way to have a "pristine" $MFT is to backup, format the D: drive, then restore, and the app chosen to do the backup and restore needs to be "file oriented". (as opposed to more "exact" backup methods such as imaging the volume).

As said, a lot of work involved in the testing/toubleshooting. :(

 

:cheers:

Wonko



#20 kikos

kikos

    Newbie

  • Members
  • 17 posts
  •  
    Armenia

Posted 24 August 2013 - 10:23 AM

I have just formatted D:

 

now grub4dos is ok with D: too.

so - I could not manage to find the root of the problem.

 

later I will encrypt C: back - I hope it will not mess the things.

 

Thank you all :)







Also tagged with one or more of these keywords: grub4dos, error, 15, encrypted, read problem

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users