Archive

Author Archive

Does AppleCare Care?

December 16, 2016 4 comments
I will try to keep my personal biases and frustrations away from this post and point readers only to facts and my personal experience dealing with Apple Support. I will keep names and places anonymous intentionally.

 

FileVault 2 has an issue. Period. The issue mostly shows up with MacBook Pros, early 2015, 13″ models for some reasons although people have reported the issue on other models too. The issue shows up when FileVault is turned on and even after the encryption process has been fully completed. If you happen to cold reboot your Mac from power off or for some reason you had to hard reset the MacBookPro, it comes back up and presents you with an EFI pre-boot login screen. Unless you enter the username and password for an user who can decrypt your drive, your hard drive is still encrypted.  The problem is, because of this issue, your built in trackpad and keyboard is mostly un-operational and irresponsive. If you attach an external keyboard and mice, it does seem, at least to me, to be working and I can use them to key in my userID and password and log-in. If I am not carrying one (most people who travel light won’t), I am out of luck.

This issue has shown up not only in my personal MacBookPro but also on a work MacBookPro of the same model. Discussing the problem with people at work, we came to the conclusion that perhaps MacBookPro is really running slow at that point, so slow that the trackpad seems to be missing the interrupts most of the time. If you keep wriggling your trackpad mice, it does seem to move a little bit and then get stuck all over again. Same with built-in keyboard. Some keystrokes occasionally register but for the most part, the keyboard is non-operational to the extent that one can not successfully type the password and log into the machine.

The issue has been seen by many others and reported by quite a few. Take a look at this and this. NVRAM and SMC reset does not help. Neither does booting in safe mode. If you disable FileVault, everything is good. If you re-enable the FileVault, the issue comes back once more.

When I first spoke to AppleCare about this, I was eventually transferred to a sr. advisor. She promptly told me that they have not seen the issue before (although it’s kind of hard to imagine this given so many others have found the issue). Then after back and forth with her trying to explain what I see and what I did to debug this further (I told them upfront that I am a Sr. engineer and I know my way around computers), she eventually told me to wipe off my MacBook Pro erasing all my data and software and reinstall a fresh copy of MacOS Sierra and then try to reproduce it. I was really taken aback by this. What was unique about my setup which Apple can not reproduce on their own? The hardware and software both came from Apple! There is ample evidence that that the issue happens on other people’s system too. We ourselves have seen this on two different MacBookPros. Surely they can try to reproduce this on their own in their own labs without asking me to disrupt my work and my life right? At the very least, she could go back and ask the software team if they had seen the issue or heard other customers reporting about it. Without making an effort to do any investigations on their side, it felt like they were passing the buck on to the customer to solve the issue for them.

Nevertheless, I told her to send me a loaner Mac where I could reproduce the problem without disrupting my life and at the same time expressed my frustrations on twitter.

AppleCare on twitter promptly caught on my case ID and set me up with another sr. advisor. I spent another hour explaining my issue on a Monday, telling him that I do have a short term solution – disabling FileVault on my MBP and that I needed a long term solution because turning off FileVault forever is not an option for me.  He said he would escalate the issue to the software team and get back to me on the following Friday at 9:30 AM. We put this down on our calendars. That Friday came and went. I waited for his call and his call never came. He had left me his work phone# and extension and I left a message for this guy. No response! That evening, completely frustrated at this point, I started another chat session with a third sr. advisor. I explained the issue again. She was nice and friendly and asked me how my experience with Apple Care had been so far. I told her honestly that it’s been really poor. She looked around for some EFI updates for my MBP but there wasn’t any.  She asked me if she should generate another escalation for me to which I said yes. I got her contact info and she said it would take three days for the escalation team to get back to her. So she should get back to me the following Wednesday (I spoke to her the evening of that Friday when sr. advisor 2 was supposed to get back to me). The following Wednesday came and went. No emails. No calls. No chat. I sent her a couple of emails asking about the progress of my case. No response! I looked around my spam folder(I use gmail) and there was nothing there either. I waited patiently for two more days and then on the following Saturday scheduled an appointment with the Genius Bar at a certain mall in Vancouver, Canada. I also finally wiped off my MBP, did a fresh install of OSX El Capitan and was able to reproduce the problem with a few retries.

Saturday morning I spoke to a fourth (!!) sr. advisor over chat, told her what I did, what I was thinking and where I was. I told her about my reservation ID at the genius bar later that day. At the genius bar, the guy was able to reproduce the issue with their Apple Service Toolkit. In fact it was such a slow process with FileVault that they had to turn off the FileVault to run the toolkit. Built in keyboard and trackpad was completely un-operational! I told the guy “now you see I am not bullshitting and you can see why I am so frustrated!”.  I told him that we have seen the same issue on a work MBP where the same genius bar had replaced the logic board and apparently doing so, the issue went away (I don’t know why that could be the case but since I have not designed FileVault2, I won’t speculate). The guy took notes (it began with “Customer stated when turning on FileVault …”) , generated a work authorization. We agreed that they would change the logic board and if the issue persisted, we can safely conclude that it was not a HW issue.

Almost a week later, today, Friday I got an email that the MBP was ready for pickup. I went to the mall to pick it up. The moment I turned on my MBP, I realized they they have not even tried enabling FileVault on the machine where the core of the issue lied. They left the software exactly how I had dropped it off. They replaced logic board with a new one, found the “same issue” (not sure what the issue was really) and so conveniently replaced my old logic board back into the machine! They replaced the flex cable in the process. However, they failed to even read the first line of the notes (“turning on FileVault”) and diagnose and hopefully fix the real issue for which I spent an entire hour with the Genius Bar the Saturday before! I have left my MacBook with the Genius Bar guys for further diagnosis. I bought a new MacBook during Apple’s one day Thanksgiving deal this year and I am lucky I did because that’s the only personal laptop I have right now. When I get back my old MBP, I am thinking of returning this MacBook (special holiday season return policy applies on this new MacBook).

Update 1 : Saturday evening I got a call from the genius bar saying that my MBP was ready for pickup (again). Next day, I got back my MacBook Pro. The Genius Bar had replaced the flex cable and IO board in the process and I was told that they did a thorough examination of my laptop hardware. If the issue still persisted, we can definitely rule out HW as the cause of the problem. I have restored my files, application and settings and so far so good. I am keeping my fingers crossed though on this. From what I have seen, I have  strong feeling that the issue is not HW related (how is it that the issue only shows up when FileVault 2 is turned on and on EFI pre-boot login screen and not always with or without encryption, logged in or not ?). However, if it is, I am glad that my laptop was covered under AppleCare and at the very least, I did not have to spend any money (except spending all the additional time going back and forth with AppleCare).

Update 2: I had written an email to Tim Cook pointing him to this blog. Today I got a call from <Name Withheld> from Apple. Among other things, it’s a great relief to know that if the issue came back up, I won’t be in a infinite loop talking to apple care explaining all over again the history of the problem. I will be able to talk to someone much senior in the tech team about this and hopefully make a progress. That’s a sweet gesture. Thanks Tim.

Update 3: It has been more than three months since my visit to Apple Store. Ever since I got back my MBP, I have not had the same issue again. I have reset my MBP a few times, rebooted it a few times and I wasn’t able to reproduce the problem. So I consider this issue closed. Thanks Apple!

 

 

 

Advertisements
Categories: Uncategorized

VMware fusion

March 23, 2013 Leave a comment

DHCP configuration : /Library/Preferences/VMware Fusion/vmnet8/dhcpd.conf

restart networking : 

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –stop

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –start

 

Sample dhcp config :

 

###### VMNET DHCP Configuration. Start of “DO NOT MODIFY SECTION” #####
# Modification Instructions: This section of the configuration file contains
# information generated by the configuration program. Do not modify this
# section.
# You are free to modify everything else. Also, this section must start
# on a new line
# This file will get backed up with a different name in the same directory
# if this section is edited and you try to configure DHCP again.

# Written at: 03/21/2013 23:16:47
allow unknown-clients;
default-lease-time 1800; # default is 30 minutes
max-lease-time 7200; # default is 2 hours

subnet 172.16.185.0 netmask 255.255.255.0 {
range 172.16.185.128 172.16.185.254;
option broadcast-address 172.16.185.255;
option domain-name-servers 172.16.185.2;
option domain-name localdomain;
default-lease-time 1800; # default is 30 minutes
max-lease-time 7200; # default is 2 hours
option netbios-name-servers 172.16.185.2;
option routers 172.16.185.2;
}
host vmnet8 {
hardware ethernet 00:50:56:C0:00:08;
fixed-address 172.16.185.1;
option domain-name-servers 0.0.0.0;
option domain-name “”;
option routers 0.0.0.0;
}
####### VMNET DHCP Configuration. End of “DO NOT MODIFY SECTION” #######

host arbs {
hardware ethernet 00:0C:29:21:38:14; ## <– MAC addr of VM
fixed-address 172.16.185.100;
}

host ubox {
hardware ethernet 00:0C:29:16:50:02;
fixed-address 172.16.185.101;
}

Categories: Uncategorized

Use DNS 323 to intall Ubuntu using TFTP Boot

May 22, 2011 Leave a comment

I got this all working on my dns 323. Here’s what I did :

  1. Install ipkg following instructions from here : http://wiki.dns323.info/howto:optware
  2. Do a ipkg list.
  3. You will need two packages, xinetd and tftpd.
    # ipkg list |grep xinetd
    xinetd - 2.3.14-9 - Highly configurable, modular and secure inetd
    # ipkg list |grep tftp
    atftp - 0.7-9 - Advanced TFTP server and client
    linksys-tftp - 1.2.1-1 - TFTP Client customized for a non-standard tftp authentication process.
    tftp-hpa - 5.0-1 - A tftp package


    Install tftp-hpa and xinetd using ipkg install
  4. Create or modify /opt/etc/xinetd.d/tftp file like this :

    #
    # ftp://ftp.kernel.org/pub/software/network/tftp/
    #
    service tftp
    {
    flags = REUSE
    socket_type = dgram
    protocol = udp
    instances = 30
    wait = yes
    user = root
    server = /opt/sbin/in.tftpd
    server_args = -s /mnt/HD_a2/tftpboot
    cps = 100 2
    log_on_success = HOST PID
    log_on_failure = HOST
    disable = no
    }
  5. Start xinetd daemon
  6. Download the Ubuntu boot image from here : http://archive.ubuntu.com/ubuntu/dists/natty/main/installer-amd64/current/images/netboot/. Copy the contents to /mnt/HD_a2/tftpboot or where ever your config file points to. This will install Ubuntu Natty 64 bit on your system.
    If you want anything else, install the corresponding tftp boot image from the ubuntu server. For example, for Maverick 32 bit, this will be the location : http://archive.ubuntu.com/ubuntu/dists/maverick/main/installer-i386/current/images/netboot

    At this time, you should test your tftp server.

    From any machine with a tftp client, do this :

    tftp X.X.X.X
    tftp> get pxelinux.0
    Received 14928 bytes in 0.4 seconds

    where X.X.X.X is the IP of the tftp server. This should work. If it fails, you know you did something wrong.
  7. Modify the udhcpd config file. If the IP address of your dhcp server is X.X.X.X then, add the following lines in /etc/udhcpd.conf :

    boot_file pxelinux.0            #default: (none)
    siaddr X.X.X.X #default: 0.0.0.0
    option tftp X.X.X.X

    Then restart udhcpd process:

    #killall udhcpd
    # udhcpd

At this point you have done two things :

  • Installed and configured a tftp server that serves the boot kernel image and initializes the ubuntu setup.
  • Configured the native dhcp server in DNS 323 so that it tells the client what the name of the PXE boot kernel image name is.

Note that upon reboot, your customizations to /etc/dhcpd.conf will be lost.DNS 323 installs pristine copies of config scripts every time it reboots (see /etc/rc.sh). You can automate installation  by scripting the steps in funplug.sh.

Also note that you need to disable any other dhcp servers that you might have in the network so that when your machine boots, it only gets dhcp response from your configured server.

Categories: Uncategorized

Mount LVM based volumes from a loopback device (disk image)

December 15, 2010 Leave a comment

Recently I needed to extract some files from the root partition in a full disk backup image taken with dd. I didn’t notice when I took the disk image, but the disk only contained two primary partitions: /boot and an LVM physical volume containing the rest of the partitions as LVM logical volumes. I don’t work with LVM much manually, so I had to look up the commands to get it to find physical volumes and activate volume groups. Here’s the full process of mounting LVM logical volumes from a full disk image:

There are two ways to get to the LVM partition on this disk, and I’ll cover both: 1) the manual offset finding way and 2) the easy way.
First, the easy way: make sure the loopback module is inserted with the max_part parameter, which causes the automatic creation of loopback subdevices for individual partitions. An easy way to make sure is to remove it and re-insert with the right parameter: modprobe -r loop && modprobe loop max_part=63
Next, mount the whole disk image loopback: losetup /dev/loop0 sda.img. Now you should see /dev/loop0p1,/dev/loop0p2, etc. for all of the individual partitions. Now you’re already done — you can go directly to the next section to deal with LVM directly.
If you can’t do the easy method, mount the whole disk image loopback to look at the partition offsets: losetup /dev/loop0 sda.img
Now that /dev/loop0 looks just like the block device image, so check out the partition table sector offsets with fdisk: fdisk -u -l /dev/loop0. I use sector offsets (-u flag) rather than cylinders because they are easier to work with and some partitions may not fall on cylinder boundaries. My image shows something like this:
Disk /dev/loop0: 250 GB, 250056737280 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488392065 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/loop0p1 * 63 401624 200781 83 Linux
/dev/loop0p2 401625 488392064 243987187 8e Linux LVM
Now, remove the whole disk image from /dev/loop0: losetup -d /dev/loop0 and set /dev/loop0 to just the LVM partition by adding the partition offset. Here, the second partition starts at sector 401625, and each sector is 512 bytes, so the offset is 205632000. Run losetup /dev/loop0 sda.img -o205632000
Now whichever method you used, you have a loopback device with the LVM physical volume partition: /dev/loop0p? (2 in my case) if you used the easy way, or /dev/loop0 if you used the manual offset method. Get LVM to recognize the physical volume and activate the volume groups:

Tell LVM to scan for new physical volumes: lvm pvscan
Activate the volume groups: lvm vgchange -ay (it will print something like 2 logical volume(s) in volume group “VolGroup00” now active).
Now you can finally mount the LVM logical volumes. Run lvm lvs to list the logical volumes. Each should appear in /dev/mapper, typically with the device name (volume group name)-(logical volume name), like VolGroup00-LogVol00.
When you are done, unmount all logical volumes and deactivate the volume groups with lvm vgchange -an. Now you can reclaim the loopback device by using losetup -d /dev/loop0.

Copied from : http://www.thegibson.org/blog/archives/467

Categories: Linux/Linux kernel

Issues with building Xen from source

December 7, 2010 Leave a comment

Folks, I am back working on Xen and once again, I am bumping into issues getting xen up and running on various distros. I will enumerate some of the issues that I am facing in this blog as I go along :

  • Ubuntu python is weird. The site.py library does not import modules from /usr/lib/pythonx.y/site-packages ! Instead it imports from /usr/lib/pythonx.y/dist-packages ! Check the site.py module and you can see it yourself! The workaround is to create a symlink or install custom packages in /home/localuser/.local/lib/pythonx.y/site-packages and have site.ENABLE_USER_SITE set to True.
  • Categories: Uncategorized

    Why you should save SHSH blobs for 3GS/iPhone 4

    August 18, 2010 Leave a comment
    Image representing iPhone as depicted in Crunc...
    Image via CrunchBase

    Avid iPhone hackers know that in order to be safe, they need to store their SHSH blobs for their jailbreaked phone so that if something goes wrong, they can restore their phone. However, even if you do not plan to jailbreak your phone, you should still save your SHSH blobs. Here’s why:

    When Apple releases a new firmware for their iPhone/iPod touches, Apple encourages everyone to update their firmware to their latest and greatest release. Old firmwares have vulnerabilities that hackers and jailbreakers effectively use to customize/install non-approved applications into the device. Eventually Apple comes up with a fix and plugs the holes. When you upgrade to the latest firmware from Apple, iTunes goes through a process known as signature verification. It is similar to public key exchange. What it does is that it creates a hash value based on the ECID value of your device (more on this later) and your installed firmware. iTunes then sends a request for the SHSH blob to the iTunes server. The response from the server which has the SHSH blob itself which is then used to authenticate the firmware installation (iOS 4.0 and above has an embedded ECID blob and in other cases, they are generated locally).  iTunes can then activate your newly installed firmware. Unfortunately, there is a signing period for each new firmware. When a new firmware is released, the signing period for the old firmware is terminated within a few days of the release. What this means is that once you have upgraded your device to the new firmware,  you can no longer ‘restore’ your device to an old firmware once it’s signing period has closed. Thus, you are stuck and can no longer go back.

    You might ask why would one like to go back? One common issue I have seen people often discussing is that how their old Apple 3G iPhone became irritatingly slow once they installed iOS 4. This will always be an issue with old hardware. As operating systems are being written more and more in consideration with the capabilities of the newer hardware, installing the same OS on an old hardware will make it crawl. We all had this same experience in the PC world. Recall what happened when you installed Windows XP on a PC that once had plenty of horse power for Windows 95! In such situations, often it is best to go back and install an old (and possibly unsupported) operating system on your old hardware or, if you have money, upgrade to newer hardware. The same goes true in the mobile world too.  Therefore, as much as Apple would love you to install their shiny new release, it might be a better idea to go back and downgrade. Unfortunately, once they have closed the signature window, you have no way to go back. Jailbreakers have the same problem too – when they want to go back to an old firmware that had a known vulnerability that they could take advantage of for jailbreaking, they can’t without storing a copy of their SHSH blob against their old firmware (the one that they want to downgrade to).

    So how can you save the SHSH blob for your device. Simple. There’s a small utility known as tiny-umbrella (http://thefirmwareumbrella.blogspot.com/). You can download the utility for Mac or Windows or Linux. Download and run the utility (you might have to provide administrator’s username and password). Now connect your iPhone or iPod touch to your computer, first making sure iTunes has been installed). tiny-umbrella will detect your device and correctly decode it’s firmware revision and build, ECID:

    8/18/2010 20:08:45.187 Device Detected -
    Device: iPhone3GS 4.0.1 (8A306)
    Model: XXXX
    Name: Ani’s iPhone
    UUID: XXXX
    Baseband: 05.13.04XXX

    Select the server as ‘cydia’. If cydia does not have the SHSH blob, it will automatically contact Apple server and send the reply back to you (and cache it at the same time). Click  ‘save SHSH’. Now tiny-umbrella will contact cydia and get back to you with the following messages:

    08/18/2010 20:14:53.221 Processing SHSH Request...

    08/18/2010 20:14:53.241 Asking CYDIA for SHSH blobs for iPhone3GS 4.0.1(8A306)...

    08/18/2010 20:14:57.965 SHSH SUCCESSFULLY saved! [Click Here to Open]

    08/18/2010 20:14:58.004 You have saved your SHSH locally and the request was sent to CYDIA. This means that CYDIA DOES have your SHSH. Do NOT bug semaphore about the Cydia home page showing this version.

    08/18/2010 20:14:58.029 Caching shsh files...

    08/18/2010 20:14:58.070 Found [1] shsh files to cache...

    08/18/2010 20:14:58.140 Cached [1] shsh files

    08/18/2010 20:15:32.709 TSS Server has cached the following files:

    08/18/2010 20:15:32.729 iPhone3GS 4.0.1 (8A306)-

    08/18/201020:15:32.739 Devices with ECIDs matching the above AND restoring to the exact firmware version listed above will succeed!

    08/18/2010 20:15:32.752 *Please note that iPad and iPad3G share the exact same SHSH. If you see iPad above and you have an iPad3G THEY WILL WORK JUST FINE. There is just no way for me to tell the difference between iPad and iPad3G from the SHSH alone.

    Now click on the ‘click here to open’ link. It will open the file in Finder/Explorer and the file will have a .shsh extension. It’s just an xml file with the requisite blobs.

    Now the downgrading part. Once you have saved the blobs locally, you can start a local TSS server using the same tiny-umbrella tool. It starts a local server that iTunes can be made to talk to. Modify your /etc/hosts so that the domain gs.apple.com points to your localhost (127.0.0.1). This way, when iTunes connects to gs.apple.com, it will actually connect to your local tiny-umbrella server. Now when iTunes asks for the signatures, the responses can be easily faked using the cached value of your blobs. You can then safely downgrade your firmware at a later time when you need it.

    Alternative way to find your ECID:

    Reboot your device in DFU mode and connect it to your Mac. From apple-menu->About this mac->more info navigate to Hardware-> USB section on your left. Find the entry corresponding to your USB device. It should read something like this:

    Product ID: 0x1227
    Vendor ID: 0x05ac (Apple Inc.)
    Version: 0.00
    Serial Number: CPID:8920 CPRV:15 CPFM:03 SCEP:03 BDID:00 ECID:000000XXXXXXXXXX SRTG:[iBoot-359.3.2]
    Speed: Up to 480 Mb/sec
    Manufacturer: Apple Inc.
    Location ID: 0xABCD
    Current Available (mA): 500
    Current Required (mA): 100

    As you can see, the ECID value can be found in HEX (obfuscated due to privacy here).

    Note: You can read more about SHSH blob from Wikipedia: http://en.wikipedia.org/wiki/SHSH_blob

    More info about iPhone 3G:

    According to what I have read, you can always downgrade your iPhone 3G (not 3GS) firmware from 4.x to 3.x.x without requiring to save SHSH blobs. I do not have a 3G phone, so I can’t manually test it out. In other words:

    iPhone 3G and older: downgrade from iOS 4.x.x  to 3.x.x => SHSH blobs not required (there is no embedded SHSH blobs in the 3.x firmware and the device has no ECID).

    iPhone 3G and older: downgrade from iOS 4.x.x to 4.0.0 => SHSH blobs required (from iOS 4.0 onwards, apple has included soft SHSH blobs in the firmware itself).

    iPhone 3GS and above: Downgrade from 4.x to any => SHSH blobs required (3GS and iPhone 4 has ECID that can be used for the RSA challenge).

    Categories: iPhone

    How to find out which package a file belongs to

    August 6, 2010 Leave a comment

    If you want to figure out which package a file belongs to you can use rpm to find out (On a system that uses rpm). Which package does /bin/bash belong to?

    [root@host ~]# rpm -qf /bin/bash
    bash-3.0-19.3

    So /bin/bash belongs to bash-3.0-19.3

    The -q option lets rpm know that you want to do a query of the database. The f lets you query the package containing the file you specify.

    Here’s another query:

    [root@host ~]# rpm -qf /usr/bin/xargs
    findutils-4.1.20-7.el4.1
    [root@host ~]#

    yum lets you get info on the findutils package:

    [root@host ~]# yum info findutils
    Setting up repositories
    update 100% |=========================| 951 B 00:00
    rpmforge 100% |=========================| 1.1 kB 00:00
    base 100% |=========================| 1.1 kB 00:00
    addons 100% |=========================| 951 B 00:00
    extras 100% |=========================| 1.1 kB 00:00
    Reading repository metadata in from local files
    Installed Packages
    Name : findutils
    Arch : i386
    Epoch : 1
    Version: 4.1.20
    Release: 7.el4.1
    Size : 231 k
    Repo : installed
    Summary: The GNU versions of find utilities (find and xargs).

    Description:
    The findutils package contains programs which will help you locate
    files on your system. The find utility searches through a hierarchy
    of directories looking for files which match a certain set of criteria
    (such as a filename pattern). The xargs utility builds and executes
    command lines from standard input arguments (usually lists of file
    names generated by the find command).

    You should install findutils because it includes tools that are very
    useful for finding things on your system.

    So, if you are using a system that uses RPM/YUM, you can easily find out the packages that files on your filesystem belong to

    Categories: Linux/Linux kernel