"It's not what you can do, it's what you can get done."

Saturday, October 4, 2014

ImageX /check vs /verify

Because I can never remember, and the Technet documentation is not helpful in this regard:

/Check - Calculate Checksums (Check.Checksum. Got it!)

/Verify - Just compares source and destination.

From http://windowsitpro.com/systems-management/deploying-and-error-checking-imagex

The /verify option works as you might imagine: It double-checks that either a capture or apply operation didn't accidentally drop any bits along the way. WIM files are pretty large, and although network and disk read/write operations already contain built-in checks, just one misplaced byte can render the image or system useless. The /verify option helps prevent that from happening. After either applying or capturing a windows image, ImageX compares the source data and its copy, searching for (and correcting) differences. ImageX enables the /verify option by default whenever applying or capturing over a network connection, but it doesn't do that when working with local external storage, so it's never a bad idea to add the /verify option. (It will, of course, slow things down a bit.)

The /check option has a similar purpose but a slightly different and perhaps more efficient approach. If you include /check when capturing an image, ImageX creates a hash of every 10MB chunk of ImageX data, then embeds those hashes in the resulting WIM. Including /check on an apply operation causes ImageX to check the applied image by re-computing hashes on that image, then comparing those computed hashes with the embedded ones. Thus, /check certifies not only that a WIM wasn't mis-copied during the apply operation but also that a WIM hasn't become corrupted while stored. Why use /verify, then? Why not just always use /check? The answer is that /check can't do its job on an apply operation if no one specified /check on the capture. If the WIM lacks embedded hashes, /check can't check the hashes. The /verify option, in contrast, doesn't need hashes, so it can always help.

Tuesday, July 22, 2014

ATT LG Optimus G ("Geeb" E970) data partition

For when an encrypted phone just won't recognize the PIN even though it's correct.

cat fstab.e970
# Android fstab file.
#                                            nd options>  
# The filesystem that contains the filesystem checker binary (typically /system)
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHEC

/dev/block/platform/msm_sdcc.1/by-name/boot         /boot           emmc    defa
ults                                                        defaults
/dev/block/platform/msm_sdcc.1/by-name/recovery     /recovery       emmc    defa
ults                                                        defaults
/dev/block/platform/msm_sdcc.1/by-name/system       /system         ext4    ro,b
arrier=1                                                    wait
/dev/block/platform/msm_sdcc.1/by-name/cache        /cache          ext4    noat
ime,nosuid,nodev,barrier=1,data=ordered                     wait,check
/dev/block/platform/msm_sdcc.1/by-name/userdata     /data           ext4    noat
ime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc     wait,check,encryptab
/dev/block/platform/msm_sdcc.1/by-name/persist      /persist        ext4    nosu
id,nodev,barrier=1,data=ordered,nodelalloc                  wait
/dev/block/platform/msm_sdcc.1/by-name/modem        /firmware       vfat    ro,u
id=1000,gid=1000,dmask=227,fmask=337                        wait
/dev/block/platform/msm_sdcc.1/by-name/sns          /sns            ext4    nosu
id,nodev,barrier=1,data=ordered                             wait,check

# vold-managed volumes
/devices/platform/msm_sdcc.3/mmc_host/mmc1/         /storage/sdcard1 auto   defa
ult voldmanaged=sdcard1:auto
~ # mke2fs -t ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata
mke2fs -t ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
752192 inodes, 3008512 blocks
150425 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3082813440
92 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
~ # exit

Make windows recognize Android USB driver (For sideloading in Recovery)

Can't get ADB to talk to your android? Get the sad "not recognized" sound when you plug in USB in recovery mode? The trick is to check device manager and get the hardware ID, then add that to the .inf. (Using the USB driver included w/ the ADK.)


Latest driver is here: http://developer.android.com/sdk/win-usb.html

I just added %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_D001
to the "[Google.NTamd64]" section.

Info found in http://forum.xda-developers.com/showthread.php?t=2535960