File Share Encryption

Our new batches of Sandy Bridge based Core i7 Mac's have been rendered unbootable after installing and encrypting with PGP WDE.   

We can make it past the bootguard, but are greeted with the apple logo and a spinning wheel that spins indefinitely (it never times out). 

A decrypt does not solve the problem.   Rebooting into single user mode and running fsck -fy shows disk errors that are unrepairable (even after running multiple times).   I would think this is a fluke except it has happened on multiple Macs, all of them the same hardware revision. 

All are running OS X 10.6.6

Anybody else experiencing this?

The new mac's boot into 64-bit mode by default.  It's been a while, but I seem to recall that PGP only supports 32-bit mode.  If you force boot into 32-bit (google for instructions - I think it's CMD-3-2), it might work.

 

MacBookPro8,2

 

Same issue, though, I don't even get the apple logo after the bootguard password has been entered correctly.

WDE does support 64-bit mode.

We've also successfully encrypted a Sandy Bridge MacBook successfully - we're trying to figure out what we're doing differently.

Meanwhile, if anyone reading this thread has successfully encrypted a new MacBookPro, I'd be interested in hearing from you as well.

I've enabled the 64-bit kernel by default on my 2010 MBP, and there are no problems with WDE.

Oh well, it was worth a try.  The only other thing is that they have a unique build of 10.6.6 and 10.6.7.

 

To the OP:  Did you try to restore a clone from a previous hardware iteration?  That will not work - you need to use the migration wizard, or rebuild from scratch.  We've had a number of issues pop up on people who've tried that.

MacBookPro8,2, 8gigs mem, 750hd (stock OSX 10.6.6, install OS from Apple-supplied DVD, no upgrades, nothing)

PGP 10.1.1 installs fine

The WDE process encrypts just fine, on boot, nothing. bootguard prompt <password correct> then nothing:

1) Migration Assistant -> Installed PGP -> WDE -> blank screen after bootguard

2) Installed PGP -> WDE -> Mac Question Mark Folder after bootguard.

There is a difference in kernels that are supplied now:

1) MacBookPro3,1 has Kernel 10.7.0 (with 10.6.7 update)

2) MacBookPro8,2 has Kernel 10.7.3 (with 10.6.7 update)

We're using builds from scratch.   Our previous images for other hardware revisions no longer work on the new hardware. 

Our test scenarios are very similar:

 

1.) build from scratch -> install pgp -> WDE -> reboot and can get past bootguard but just get the Apple logo with a spinning circle under it that never ceases. 

I think the main difference is we've got SSD's in our Macs as a standard build, but that *shouldnt* matter.   

In call cases, decrypting the drive does not resolve the issue - still remains unbootable.  

 

I have booted into single user mode and with verbose booting.   In all cases it appears the mac is finding itself with irreparable catalog files. (according to fsck).  This is even on decrypted macs after they had been encrypted.   Not sure what to make of that.

I would love to know what your process is for that - maybe we can identify something we're doing different / wrong?

 

Darn, I was hoping for something easy :-).  I suspect it has to do with the unique build of OSX for the new machines, and I'll bet the boot EFI is different.

The only idea I've got is to try this:

1) Repartition the disk (GPT of course) - not just erase, then reinstall from DVD

2) Upgrade to 10.6.7 using the combo updater

3) Repair permissions

4) Install PGP

5) Reboot (verify that you can)

6) WDE from the GUI

As I was speaking with some of the Apple techs, one thing became apparent in the conversation. Apple has addressed Thunderbolt into its boot.efi, enabling the booting through such devices, etc. Apple's techs stating that was the major changes. Obviously, older hardware does not support that. In lieu of this, pgp, upon WDE the HDD, has overwritten the bootloader with PGP's build(?), which would knock out Thunderbolt drivers(?) thus causing issues with the bootloading *after* it has passed to the root partition from the boot partition...

Just to confirm, mounting WDE-encrypted external media (USB) worked just fine. So the guess has to be in OSX's transition from boot to root drives, hence pgpboot.efi.

WDE is supported at 64bit mode (reviewing the Extensions), though the application itself is still 32bit.

MBP 2010 models don't contain Sandy Bridge nor Thunderbolt.

Hugely valueable input here - and it makes some sense.  It does not explain why PGP / Symantec are claiming to have been able to encrypt Sandybridge based machines, but at least gives some information as to possibilities as to why it's broken for us. 

Still curious if PGP/Symantec can give a root cause explanation (and fix) for it, as we're unable to deploy new Mac's until this is resolved.  

Correct.  I too have run in 64 bit mode without problems on older 2010 models (that's what I currently run, until I can get one of the new Sandybridge Macs to encrypt without boot failure).  This is only the new 2011 models. 

just wondering, have you gotten in touch with PGP support about this issue? did they confrim that this is a bug with sandybridge machines?

Yes - I have had a ticket open with support for over a week.  They last responded on March 17th and have failed to respond to subsequent requests for followup.  We're a silver level of support, and find this unacceptable.  I have also attempted to escalate this through the symantec sales rep for our region but have not yet received any further input.  

They also have not confirmed that there's a problem.   They had asked me what version of PGP Desktop I was using (10.1.1), and whether decrypting the machines solved the boot problem (no.) 

I've gotten more response from the peer-support forums than from paid support :-/

yeah, support seems to be either overwhelmed or completely unresponsive. (i have tickets opened since 2/16 with NO response.) sales is also unresponsive.

Our regional sales reps told me yesterday that they would escalate and get me some sort of response "soon".  I tried to follow up with them (via email admittedly, as I am traveling abroad at the moment) today but have yet to receive a response.  

Troubling trend.  I'm beginning to wonder if they are in breach of contract at this point as they are not rendering the contractually agreed upon level of support.  They're on the verge of losing us as a customer over this issue.

Considering that they unilaterally discontinued the chat support option for Bronze support, without compensation or comment, I suspect that there's weasel language in the agreement that allows them to escape.

With PGP prior to the acquisition, for all their faults, you had good support people, who spoke english, understood the products, and responded to issues.  Symantec has a long long long history of poor product support, and it looks like that's being brought to PGP.

Perhaps they're working so hard on testing 10.6.7 or fixing the download process that they can't answer the ticket ;-)

This is a very good reason why I'm looking forward to 10.7's built in WDE.  Assuming that Apple doesn't do something stupid (like build in a Genius-bar backdoor), it'll probably be 'good enough' for my needs (and for many of my coworkers).  The only features it won't have are corporate management and key escrow - which aren't critical for most customers (the biggest use case is to recover data when someone forgets a password, which can be solved with unencrypted backups via Time Machine or other products...or letting users just take the risk of data loss).

 

I'm also not able to boot after installing PGP WDE 10.1.1 on my new MacBook Pro 15" (early 2011). If I understand things correctly PGP / Symantec already knows that PGP WDE fails to boot on these new machines, but I haven't read anything about it on their website! The least they could have done is inform their customers about this problem so they could have opted not to install PGP WDE until there was a fix for this problem!

Is the only know solution at the moment to restore a backup and not use PGP WDE?

I've also tried to call them, but they redirected me to this forum. I regret having paid for additional support just a few months ago. The Symantec support seems non existant! And this seems to be a major problem!

I hope they start answering soon and get us a fix. Luckly Lion will have builtin WDE support and this seems to be the last time I pay Symantec to support a product. The least they could do is communicate about this problem. Would have saved me 2 days of work.

Chris

Symantec support is aware of an issue, but have yet to be able to reproduce it on their test systems.  If you could post your system specs that would help in trying to find the common denominator between those machines that have issues. I finally was able to get a response and troubleshooting dialog going with support. 

Also - is anybody else able to report whether or not they're seeing disk catalog corruption after decrypting an unbootable machine (then booting into single user mode and running fsck)?   We've seen that on multiple machines that exhibit this behavior,  all of them hang on boot due to corrupt catalog files that are irrecoverable. 

 

 

We've been doing some significant testing and have discovered a few things:

1. The issue appears to be isolated to SSD's.  We've swapped out the SSD in one of our machines which was exhibiting this behavior and replaced it with spinning disk and did not see this issue after encrypting. 
2. The issue further appears to be isolated to Apple factory installed SSD's.  We replaced the Apple Factory installed SSD with an Intel SSD and - while we still had a weird issue - we were able to encrypt and (after using a recovery disk to boot) boot into the OS multiple times without issue.

We're currently testing a theory that it's a difference between revisions of Apple SSD's.   We believe the new Sandybridge based Macs come with a new revision of the SSD's, which may have a difference in drive firmware causing an issue.  We're testing with an older Apple SSD which has worked fine in previous models of MBP using the new hardware to see if the issue persists. 

 

I beg to differ. I have a 750GB HDD (your Apple-factory drive) and it exhibits the same issue (and I believe several other posters have 750GB HDD). It might be the fact that Apple is using a HDD that isn't listed anywhere on Toshiba's website (MK7559GSXF) and therefore, some Apple "spice" is most likely going on different under-the-hood.

That's entirely possible - I can only report on what we're seeing on our end.   If we encrypt with Apple SSD's that come stock with the machine, it bricks.   If we swap that out with a spinning disk, it works fine and if we replace the Apple SSD with an Intel SSD it works fine* 

It could well be that Apple's factory drives are to blame. 

 

* initial reboot fails to boot, but using the recovery disk works and subsequent reboots work.

Can you verify your SSD drives might be running Advanced Sector Format or Advanced Format technology (http://en.wikipedia.org/wiki/Advanced_Format)?  It appears that the factory supplied 750GB Apple HDD are running this, but the 500GB Apple HDD are not; which could provide some insight as to why Symantec/PGP Techs are having issues reproducing the problem and could possibly throw everything off... just a guess.

Apple does use a unique Firmware (even on the same model number) on their drives, so that could be the issue.

 

The Advanced Format challenge also makes a lot of sense.  I think we've seen issues encrypting the 3GB WD drives for the same reason.

Without confirmation from Symantec, but using their Windows (10.1) release notes the issue appears to be Advanced Format (AF) 4k native sector mode. Again, this is addressing the Sandy Bridge (Intel 6 Chipsets) with drives that have AF in 4k native mode OS -> HW -> Disk (4k physical). AF 512e drives shouldn't be affected because they do a OS -> HW -> Disk translation (512 byte logical -> 4k physical).

PGP Desktop Windows 10.1 Release Notes: Encrypting drives: Any drives with a sector size other than 512 bytes are not supported by PGP WDE and cannot be encrypted. [21126]

Apple OSX Developers (verbal) statement: Any drive manufactured that supports AF 4k native sector mode, OSX will indeed take advantage of this technology.

... I guess the wait will be on from Symantec PGP to address this issue.

You'd think PGP would detect that, and block the encryption.  Oh well.  I've alerted my internal users.

Not really, older macs translated to 512e mode to address this issue. It wasn't until the new hardware came out that manifested the advanced format 4k native mode problem. PGP would have needed an advanced copy of Apples release to know.

Yes - but they still could have been performing a check to "future proof" it.  The idea of 3k native mode AF isn't exactly brand new.  So while they couldn't have known in advance that Apples new hardware would use 4k native mode, they could have had error handling in place to prevent encryption on it when detected. 

We're likely going to start swapping out the SSD's we've got with ones that do not do 4k Native AF until this issue is resolved.  

They definitely knew enough to put it in the windows release notes, so it could have been in the code.

 

if (sector size < 512) then dontencrypt();

 

Assuming that this is the issue, but from all appearances it looks like it.  The 500GB hard drives in the new units appear to encrypt properly.

Maybe it's that simple, maybe it's not. I don't want to get into understanding the complexity of coding WDE at 512 vs 4096. It also depends on if the controller supports 4k native vs 512e. There are various combinations that happen. At the Mac level of hardware, there will be most likely less combinations to address. If hw controller eq sandy bridge or greater and drive is 4k native, then 4k sectors. Linux has hdparm -tT /dev/sda that you can figure logical and physical sectors of the hdd rather easily, but osx doesn't have this. For the record, Apple's 500gb drive with the MacbooPro8,2 model is a Hitachi hts545050b9a302, originally manufactured in 2008, predating the 4k advanced sector format.

I've got a new 2011 Macbook Pro (sandy bridge i7) with the 500gb disk, and and have it set up for Boot Camp with Windows 7. That's all been working for the last week, even got development environment installed and compiled Firefox under both OSes.

Today I installed PGP WDE, and while I _am_ able to boot into OS X, booting into Windows fails... The text-mode "bootguard stage 2" screen comes up, then a low-res graphical PGP desktop screen fades in. But it looks corrupted at the bottom and immediately fades out, leaving me at a black screen with a blinking cursor. System seems dead at this point, even the LED on the caps lock key won't light up.

So, seems there are indeed problems with PGP WDE on these new machines. :( Wonder how long it will take to get a fix. Sigh.

I guess the hardware is just different enough to cause problems for code running this early in boot. I noticed after getting the machine that memtest86+ 4.1 hangs when it starts, and even the new 4.2 version with Sandy Bridge support starts but then immediately dumps out a page of hex debug info and hangs.

I have been able to install and encrypt two sandy bridge Model ID MAcbook Pro8,2 devices with out incident. Kernel version 10.7.1. So far I have not been able to recreate the issue.Confirmed that 64-bit is enable

To all, please give HDD size and model number when responding to this thread. It helps in identifying the problem.

Here is the HDD information. Thanks for the reminder. Please let me know if more information is needed.

TOSHIBA MK5065GSXF:

  Capacity:     500.11 GB (500,107,862,016 bytes)
  Model:        TOSHIBA MK5065GSXF                     
  Revision:     GP005B 
  Serial Number:                   11T4C5GUT
  Native Command Queuing:       Yes
  Queue Depth:  32
  Removable Media:      No
  Detachable Drive:     No
  BSD Name:     disk0
  Rotational Rate:      5400
  Medium Type:  Rotational
  Partition Map Type:   GPT (GUID Partition Table)
  S.M.A.R.T. status:    Verified
  Volumes:
  Capacity:     209.7 MB (209,715,200 bytes)
  Writable:     Yes
  BSD Name:     disk0s1
Macintosh HD:
  Capacity:     499.76 GB (499,763,888,128 bytes)
  Available:    482.72 GB (482,716,352,512 bytes)
  Writable:     Yes
  File System:  Journaled HFS+
  BSD Name:     disk0s2
  Mount Point:  /
Boot OSX:
  Capacity:     134.2 MB (134,217,728 bytes)
  Writable:     Yes
  BSD Name:     disk0s3

... And that drive (TOSHIBA MK5065GSXF) is most likely either a native 512 or 512e sector drive ... Therefore you will work fine.

After talking in depth with Toshiba's technical support regarding the MK7559GSXF, there is no way to enable AF 512e mode. It is strictly a AF 4Kn mode drive, which means, regardless of the booting of OSX into 32bit/64bit, WDE will not work. The thought of a nvram "switch" came to mind, but if the drive is 4Kn, this would render the drive unusable. Apple techs are unsure if there is even such a switch available... callbacks await.

For the SSD's that ship with the Macs (They're Toshiba, but I can't remember the exact model), booting into 32 bit mode DID resolve the issue for us.  The process was to do a fresh rebuild,  set the kernel architecture to use 32 bit instead of 64 bit - persistent through reboot,  reboot,  install PGP and encrypt.  Subsequent reboots all went off without a hitch.   This is NOT ideal, as you're not really leveraging the full power of the platform and are likely to eventually suffer performance degredation because of this,  but it's at least a workaround that appears to work.   That is assuming that your drive is not a strictly AF 4kn mode drive. 

 

Hi,

 

Here is some additional information on a setup that doesn't work with PGP 10.1.1.

 

General:

Model Name: MacBook Pro

  Model Identifier: MacBookPro8,2

  Processor Name: Intel Core i7

  Processor Speed: 2,2 GHz

  Number of Processors: 1

  Total Number of Cores: 4

  L2 Cache (per Core): 256 KB

  L3 Cache: 6 MB

  Memory: 4 GB

  Boot ROM Version: MBP81.0047.B04

  SMC Version (system): 1.69f1

 

HDD:

Hi guys! Yesterday i tried to replace my 750GB hard drive in my macbook 2011 to 160GB and i can confirm that problem still persist. MacOs boot fine with pgp encryption enabled but on windows is the same pgp screen that is fade out and only blinking cursor left over... Somebody here suggested that the problem with pgp for windows is that it doesn't support 4KB sectors as modern disk have. But it's not a case because this 160GB is pretty old, so i think that pgp is not compatible with sandy bridge architecture from some reasons... We have to wait, and there is nothing to do with this problem now until pgp (symantec) will not fix this problem in next version. Regards. Artur. My config: Macbook Pro 2011 (8.2), 2.3ghz core i7, 4gb ram, 750GB toshiba hdd MK7559GSXF (also tried Seagate ST9160821AS)

 

Partially related - this issue appears not to be limited to Mac's.   The first in our shipment of new Sandybridge based Dells is exhibiting this same behavior. This appears to be a larger issue.

Might I suggest a warning on the encryption blog?

Does PGP have any announcement/promise/update as to when this issue will be resolved?

Here we go again...interest, then silence.

no update as to when it will be resolved...

http://www.symantec.com/business/support/index?page=content&id=TECH156926

The latest I heard (yesterday) is that this is appearing not be be related to the Sandy Bridge processors, but rather to the 4k sector size.

is there an update as to when this issue will be fixed?

 

I can't offer anything specific, but it sounds like something not easily done, and may take some time.

obviously we need more info, please let management know that this is a serious issue and requires attention. there should be WEEKLY updates on this forum/blog post (anywhere really) about the status of this issue.

 

- Sarah

To my knowledge they still can't fully reproduce the issue.  

It's possible that there are two issues happening:

 

1.) advanced format 4kn sector drives. 

2.) Apple is using an undocumented TRIM call that's most likely getting past PGP's filters.

 

I'd imagine one is more easily fixed than the other.

I don't have anything to do with what bug, fix, etc. is placed where in level of priority, but I suspect that the more people who make a feature request for support of sector size other than 512, the greater priority it will receive. 

can we get official updates here?

i have three tickets open with support about this issue. support is overwhelmed and is unable to give me updates. I think this open forum would be an awesome place to have PGP win us over and be super-communicative to it's customers about this issue. you guys have the tools, you need to use them.

The information I am reporting is from the work I see on the bug reports.  I can't offer more.

I have to say, it's not like this change in sector size was a surprise - it's been coming for years.  There was even a comment in the windows release notes that it's not supported, so it's a known architectural issue with PGP.

I took a clean OSX image installed from the included system disks and cloned it to both the included 128GB SSD and a third-party spindle drive.  I installed the 500GB drive and encrypted the image and ran for a week without issue.  When I switched back to booting from the original SSD it ran fine until encryption.  As the drive began to encrypt it tanked.

These two images were exact duplicates and all of the other hardware did not change.

anything?

I heard from Support this week.  That update was to tell me that there was no update, they don't know what's wrong and don't have an ETA for a fix, but that they do know that there IS a problem.   

 

For an issue that has existed for well over a month they know surprisingly little about what the problem is.

I’m not sure it’s related but I had similar symptoms to the Win7 on boot camp issue (booting only Win7 - no boot camp or any other OS).

On a Dell E6520 running Win7 x64 with a mechanical HD (320GB w/ 4KB blocks) & Intel IGP + Nvidia NVS 4200M for video.

After one successful reboot after WDE had encypted the HD, subsequent boots would hang with “Initialization loading” after a brief appearance of the bootloader screen and I couldn’t boot off of a recovery CD, either. It would say this onscreen:

“Loading password authentication driver
loading stage2
PGPWDE disk data are corrupted. Please use PGP recovery disk.”

I noticed that the bottom of the boot loader screen had some video corrupt.  So, I turned off Optimus in the BIOS. When I turn that off (which forces it to run solely on the Nvidia discrete card), I am able to boot just fine (the bootloader prompt now comes up & Windows boots). I did another Optimus on/off dance and was able to reproduce the problem & fix.

I have a ticket open w/ Symantec for my company (so far, no response - 25 hours on a critical ticket <sigh>).  I'm the first user of the new Dell laptops the company just bought (I also am the PGP/Universal Server admin, thankfully) - I hope this gets fixed soon.

I hope it helps.

We've got similar issues with new Dells. 

 

FWIW Check Point's FDE (PointSec) product works fine on the new Dells,   AND they've got a mac client to be released soon that fixes issues with the Sandy Bridge based MBP's.  

Since neither the windows nor mac programs have been fixed, I doubt this can be taken as an indication of a lack of Mac support.  On the other hand, if PGP can't even get the windows version fixed, then it must be a deeper architectural problem. 

More than a month now, and still no notice on the Encryption Blog (which we were told is the venue for communicating issues).  The only notice there is the incorrect, ineffective instructions to gain access to our entitled software.  Not even a patch to prevent PGP from encrypting an unsupported drive while they work on a solution.  So it's business as usual (no communication, no updates, no information, customers-are-mushrooms) for PGP/Symantec. 

Strike Two.

I finally got a response Wednesday at 8pm my time and the tech said this is the first he's heard of this issue.  I pointed him to this thread :-)

wow... how on earth could it be the first he's heard of the issue?  are they really not telling their own support personnel that there's a problem?!

We are sitting on new hardware inventory unable to rollout because of this issue! Can we at least get an update? Even if it's a month, that could help prepare us.

Don't hold your breath.  I've beaten up on Symantec a lot, but in this case, this behavior has been going on for a long time - almost 5 years.  This one really surprises me - Mac users are used to lousy treatment from PGP, since we're a small population and the Mac team is grossly under resourced.  Given that this impacts the much larger windows community, I would have expected at least some communication.  Since there's been none, I have to question the competence of the entire management chain at PGP - this isn't a fiduciary/financial/earnings issue.  It's a technical one, and no remotely reasonable policy would prevent providing updates to impacted customers.

That being said, given the long history of lousy customer communication, you shouldn't expect any information until a fix is released (and, given past performance, not even then since the email notification system is unreliable at best).  Of course, that's assuming you can even download the patch since PGP refuses to fix their problem with entitlements.

Since this is a cross-platform fundamental architectural issue, that the last word was 'we don't know what to fix', and that we've heard absolutely nothing that 'ones on the way',  my best guess is that we're at least another couple of months out from any fix (though we may see an interim release that detects it, and prevents encryption).  I would also guess that there's a 50/50 chance of a simultaneous release on all platforms, and a 50/50 chance that it'll be out for Windows (probably only Win7) 1-4 months before the Mac.  No inside information behind those, just a very flat head from many years of beating my head against the wall on these kinds of issues.

 

 

 

Since Symantec doesn't seem interested in taking notice of the problem (at least not publicly), maybe it's time to exert pressure from another angle.

What if we all call up our VARs & manufacturers and tell them that we need to return the 100s/1000s of devices we have purchased because they don't work with PGP WDE and Symantec has no fix available?  I bet if Dell, HP, Apple, Intel, et al. called up Symantec things would change in a hurry.

Just a thought :-)

Please go here for PC issues (there is a suggested fix):

https://www-secure.symantec.com/connect/forums/pgp-wde-boot-screen-bypassed-and-cannot-authenticate-windows-7-pro

This is a thread about Mac issues with PGP.

Also, if you have a Mac with Bootcamp and the blinking cursor problem on the windows 7 side. There is a service pack that is being released for that and it should be available next month  (May 2011) to fix that issue.

Here are the developments from PGP Development on this issue. THis is a known issue, there is a bug report. We are working on a fix ASAP. This is the highest priority in PGP right now, it's in a company wide escalation status.

* 2009-2011 Macbook Pros when forced to run in 64bit kernel mode.  Note
distinction between kernel version / mode and OS. You can determine this
information via "uname -a" in Terminal.

* In OSX 10.6.6 and OSX 10.6.7

* Apple 128GB SSDs, Apple 256GB SSDs, and Third Party SSDs.

Issue currently seems to be isolated to SSDs only.  No internal evidence points
to these items being the culprit:

* 750GB Spinning Disk
* Sandy Bridge
* TRIM, 4K sectors

Symptoms are as follows:

* Disk I/O during encryption or decryption in x64 kernel mode will show Disk
I/O errors in /var/log/kernel.log

Workarounds:

* Fully encrypt or decrypt drive in 32bit kernel mode. 

Furthermore, they even came on to say this:

Sandybridge CPU architecture is irrelevant and coincidental.  

It appears to be Sandybridge because that's what all the new Macs are. 
However, all the new Sandybridge Macs are ALSO configured to boot in a x64
kernel (rather than 32bit).  

We were able to force the issue out in a older motherboard when we changed it
to use the x64 kernel.

However we are very interested if you have customer configurations that
challenge this statement.  Specifically I'm VERY interested if there is a
sandybridge + spinning disk with same issue

Thanks for the update.

FWIW, Mac Pro's have booted 64-bit for a while, and many folks are running 64-bit on their older MB and MBP's without issue.  Does the issue go away if you force the new machines to boot in 32-bit mode?

Specific reports of the issue on 750 GB drives:

https://www-secure.symantec.com/connect/forums/sandy-bridge-macs-unable-boot-after-encrypting-pgp-1011#comment-5367551

https://www-secure.symantec.com/connect/forums/sandy-bridge-macs-unable-boot-after-encrypting-pgp-1011#comment-5367741

FYI, on the Sandy Bridge bootloader problem (at least the one I reported recently for Win7-64 on a Dell 6520), Symantec is aware of the issue (I spoke to support earlier today).  The PC (non-Mac) support guys weren't aware of this thread and before this week they really didn't have any PC users calling in about it.

The support guy also said that they have received a lot of calls this week and that he forwarded the info from my ticket to engineering.  They initially were delayed in investigating it due to lack of hardware to duplicate the problem but apparently that's no longer an issue.

The good news is the programmers are aware of the issue and, if I remember the conversation correctly, have reproduced it.  Now it is just a matter of finding the problem in the code and fixing it.

It could be a few months or longer.

As far as my previous comment about heating things up, he also said that they have some premium customers (very large companies) complaining about it.

He also said there's a KB article that will go up soon about the issue (still being written).

We also talked about how this subject doesn't belong in this thread or this forum :-)  So, anyone else with this specific problem please post it in a new thread in the appropriate forum.

Lastly, please keep in mind that my comments here are NOT an official statement from Symantec.  While I'm reporting what I remember being told I could be wrong, it's subject to change, your mileage may vary, etc., etc.

 

Edit: PGP_Ben (the support tech I talked to) beat me to it :-)

"Does the issue go away if you force the new machines to boot in 32-bit mode?" yes it does. and changing the default boot to 32-bit mode fixes it as well (according to our reports from the Dev team).

AFS may play a part (but not solely) into this though, we are still looking into that as a possibility as well.

I am owning a (brand)new 13 inch MacBook Pro (Sandybridge purchased in March 2011, now with Mac OS 10.6.7) using PGP 10.1.1 where booting into Win7-64bit using BootCamp is not possible – I have opened a threat in this forum some time ago:

https://www-secure.symantec.com/connect/forums/problems-booting-windows-boot-camp-using-pgp-wde-mac

My Mac has a 500 Gb spinning disk, booting into Mac OS after PGP-encryption works normally, however booting into Win7-64bit fails after short appearance of the PGP bootloader. Currently the HDD is decrypted.

Information retrieved via terminal with the “uname –a” command:

Darwin Storks-MacBook-Pro.local 10.7.3 Darwin Kernel Version 10.7.3: Sun Mar  6 13:37:56 PST 2011; root:xnu-1504.14.2~1/RELEASE_X86_64 x86_64

Hope this information is useful and helps to resolve this issue asap

Stork

The bootcamp issue is a different problem than the problem described in this thread. Please be sure that you are posting in the right thread for your problems.  The solution that you are looking for is down below under the bootcamp problem:

Problems booting Windows 7 after encrypting the drive using PGP Whole Disk Encryption

Solution: Get with support and sign up for the service pack that should be addressing this issue

Please post in the following forum thread if you would like to post about this problem:

https://www-secure.symantec.com/connect/forums/problems-booting-windows-boot-camp-using-pgp-wde-mac

-------------------

Certain Dell Notebooks and other models that are encrypted with PGP Whole Disk Encryption are getting a Stage 2 - Initializing loader error after encrypting the hard drive

Workaround: Try disabling the Nvidia "optimus" setting in the BIOS for those laptops that support it. If it's only an integrated Intel Chip, try updating the Intel Video card driver.

Forum thread article for this issue:

https://www-secure.symantec.com/connect/forums/pgp-wde-boot-screen-bypassed-and-cannot-authenticate-windows-7-pro

 --------------------

After encrypting your Mac with PGP Whole Disk Encryption you are no longer able to boot the hard drive to Mac OSx

Workaround: try booting your Mac OSx kernel to 32-bit mode instead of 64-bit. For more information see this link from Apple:

http://support.apple.com/kb/ht3773

Forum thread article for this problem:

https://www-secure.symantec.com/connect/forums/sandy-bridge-macs-unable-boot-after-encrypting-pgp-1011

So, why is it I could run in 64 bit mode (configured to default boot to 64 bit using the boot.plist file) on all previous generation MBP's without issue, but with this generation I can't?

 

I don't have a definitive answer for you yet. But we are just going by what the developers have tried thus far.

A question I have for you though, is if you have tried the latest version of PGP Desktop on those mac's booting 64-boot mode?  It may not have been a problem with PGP Desktop 10.0 or even older versions, but the new drivers for PGP Whole Disk could be part of the issue.

If I had a DEFINITIVE answer for you, we probably wouldn't be dicussing this problem in the thread though. Because we would have a solution to the problem. Right now, we are still just chasing down the root cause (so I don't have the definitive answer that you are looking for) sorry for that.

So far, in their testing, they have been able to reproduce the issue booting older mac's on 64-bit mode with the latest release, PGP Desktop 10.1, on our macbooks.

I will try to keep you guys up to date if we have a solution. I wish we already did have a solution, for that I'm sorry as well.

Q: In regards to 750GB Disks and problems

It is unclear if customers are seeing the same issues as what the bug is logged for, Do you see Disk I/O error in /var/log/kernel.log?  We're very interested if they see this, but we have not been able to get the Disk I/O error with a 750GB spinning disk while in 64bit kernel mode.

Q: So why can I run in 64 bit in previous generations?

 Not sure, but it could be when customer decided to switch over to 64 bit kernel (from 32bit) and what he was doing while encrypting the drive.

 This is a good segue into our current analysis:

Currently we've isolated the error to the conversion process from plain text drive to encrypted drive.  Basically when this happens a separate thread is handling all other disk I/O as they occur and are placed in a queue.  Somehow during that process we are getting read or write errors from the kernel as the "handle other disk i/o queue while I'm encrypting/decrypting queue" is running.

This leads into an interesting side case:  If there is no extraneous disk I/O during the conversion process, you could potentially NOT see the error at all.

 Currently we're tracking down what's going on in the conversion queue.

 

What this means to end users/IT technicians:

Try encrypting the disk booted into 32-bit mode. Or don't do any activity on the mac, but the encryption and see if that works. You should even be able to boot into 64-bit mode after the encryption process is done if I understand what they are saying in the bug correctly. It's purely an issue with encrypting the drive under 64-bit kernel mode and having heavy activity on the machine while encrypting that is causing the problem.

Did you encrypt your hard drive running 64-bit mode. I would also recommend testing the encryption with doing things like copying files in finder at the same time. This is highly reproducible by doing so.

If your disk drive doesn't support the 512e  (512byte emulation mode). Almost all of the new modern SSD drives and spinning disk drives support this mode. If your drive doesn't support it. It will definetely not work with PGP Desktop.  You could possibly see if a firmware update addresses this problem, but I'm not sure if firmware updates can turn this feature on or include it if not already included in the hardware...

Are people still being affected by this issue? I would like to be able to gather some more feedback for the development team so that we can find a fix for this problem.

note: this is only for machine that have spinning disk drives and this problem. we have gathered enough information on the SolidState Disk drives affected by this issue.

Here is what they are stating:

If you indeed have a spinning disk, helping us isolate a minimal set of Disk
I/O events to trigger Disk I/O errors is most helpful.  Include what functions you are doing in MacOSx at the time to cause the encryption to fail.

If you have a spinning disk and Mac OSx encryption corruption problems.  Send me your:
 
/var/log/kernel.log
 system_profiler > my_system.txt

Will you please gather this information off your machine and then send me a private message in the forum. I would like to gather this information and forward it off.

At least at my company (a very large PGP customer), everyone has stopped trying until after you guys release a fix.  They can't risk losing data, and given the time to backup, test encrypt, restore after an immediate failure (or living in fear of a future failure if it does appear to work) isn't something they're willing to do.   Our impacted folks are switching to FileVault, running the Lion Preview with WDE instead, or something similar.

Hi I know that you guys have "sour grapes" towards PGP right now. I can understand your concern in time to backup, encrypt, test, etc. I completely understand that. we are still looking for feedback because up till this point development has only been able to reproduce this issue with Solid State Disk drives. Obviously other users are reporting issues with spinning disk drives. Development is pretty much determined that they know what the issue is, but if we can prove that spinning disks are affected also with some evidence and logs that will help them to be sure that we are fixing both problems.

While I can understand the need to try out other encryption products if PGP is not working for you. I would be VERY, VERY hesitant to put a Preview/Developer version of software on there with Encryption.  That is just asking for trouble. That's my two cents...

No disagreement on the developer/preview option (and I haven't done it myself).  FileVault is another thing - well tested, but it breaks Time Machine pretty badly, so it's sort of a race to the bottom in terms of which issue is more important.  If I had a new machine today, I'd go with FV and suffer through the TM issues for the next couple of months until 10.7 is out (once PGP is off the machine....)

The sour grapes have been carefully cultivated by PGP since the delays releasing a 10.5 compatible version - I think that's 5 years now.   PGP was the only viable game in town for years, so we put up with the horrible communication, lousy treatment, delayed support, and buggy software. 

That changes this summer. 

 

And just for the record, I appreciate your presence here in the forums and the information you're providing - thank you!

We have found that if you encrypt the disk while doing nothing else on the machine, it works fine. Furthermore, booting into 32-bit mode just to encrypt the drive is a viable workaround as well. It's only when the laptop is booted into 64-bit mode and you are doing other disk related activities while encrypting that it causes a problem.

Suggestions to resolve this:

Option 1) Encrypting in 32-bit mode

- Boot into 32-bit mode on the mac for encryption

More more information see this article:

http://support.apple.com/kb/ht3773

- Once succesfully encrypting you are fine to boot back into 64-bit mode

Option 2) Don't do anything else on the computer while encrypting the disk

- For this, I would suggest launching PGP Desktop. Encrypt the drive and just leave it sit. Don't do any file copies, virus scan's, email, web browsing, etc. Then come back when it's done encrypting and reboot.

We have found this issue to be more common on new macbook pro's with the SSD drives. Therefore, if you want to avoid the issue altogether before we release an update you could purchase a macbook pro with the spinning disk drives instead.

I recognize that all of these are painful, and they are workarounds. But something to meet the needs until our development team finds the problem. I can assure you that they are researching it and going through lots of testing to try and isolate the problem. This problem has proven very difficult for our programmers to debug for some reason. That is what we've been told.

Ben

Thank you for your feedback and the welcoming response at the end. I would agree with you that PGP has had a rocky road with the Mac's since being aquired by Symantec. But I'm being reassured that things will get better. I have seen my own share of issues with PGP software on the Mac. But I have also seen my share of issues with PGP on the PC. Furthermore, I have seen my share of issues with encryption in general (on mac or PC).  At least with PGP you have a product has been around for years and is arguably one of the best disk encryption products out there in existence for the mac.

I had an iPhone using FileVault once (didn't even realize that it got turned on). iTunes encyrpted the backups and when I did a firmware update and tried to restore, it wouldn't let me restore.  I lost everything that I had on my phone. And you know what Apple's response was to all this? "Sorry, there is nothing we can do, When you encrypt the iPhone you are at your own risk."

At least with PGP you have the corporate backing on your encryption. Enterprise level support that is 24/7.  Not only that, you don't get told "sorry you are on your own because you enabled encryption". Furthermore, I spend time every day assisting customers with corrupted disks that were encrypted and recovering data or trying to repair their system. I'm not convinced Apple would go that far to help an end user, not unless they were paying for the complete "Apple Care" package. Just my two cents.

Those that are interested in getting this problem resolved. Please contact me through the forum and I would like to get in touch with you to gather some information from you.

Thanks!

Ben

Actually, it's not just since the acquisition - it's been at least the last 5 years.  Long delays with 10.5 and 10.6 support, the 10.6.5 debacle.  Product quality/stabliity has declined recently, and the delays are getting worse.  I know for a *fact* that the 10.6 production build was available roughly a month before it was released.

Be careful about support.  You work for a company that unilaterally changed our Bronze support T's and C's, and cut off the chat support without compensation.

So far PGP has been the only real option for a Mac.  That changes in a few months.    Unless PGP has DAY ONE support for 10.7, I expect you'll lose most customers. 

Given that you guys weren't able to release a 10.6.5 fix until after 10.6.6 was released, I'm not holding my breath. The minor advantages that PGP has (enterprise key management) aren't worth the continual issues with data loss, drive corruption, and lack of support for new hardware and OS software.

Hi Ben,

Just wanted to report that the workaround succeeded on a new machine with a WD 750 GB spinning disk over the weekend (I did not try it under 64-bit mode).  It took 2x as long to do 750GB as it did to do the 500GB on my old machine for what it's worth (the newer drive is faster).

Thanks, I have provided your feedback to the dev team. I also mentioned the difficulty in encrypting the drive in 32-bit mode. Because this causes the encryption process to run a lot slower. They are working on new developments. I wish I had more solid information to give you. but I do know that this a high priority for them.  The more data that we can collect from affected machines and logs we can collect on this machines. The easier it will be for us to resolve this matter. Also, postive feedback like that the workaround is working, is good also. Since it's helps us isolate where the problem lies.

No problem - understand, that I *want* you guys to succed.  Just very very frustrated that the company seems unable to do so.