[LG V20 Guides, News, & Discussion] emdroidle:
Tool for writing portions of KDZ files to LG devices. As long as KDZ files for the particular device are available and LGE doesn't change the format in an incompatible fashion, this will handle upgrades. Presently this tool targets the format as is used with UFS devices. The LG G5 and LG V20 are examples; the G6 and V30 may turn out to be compatible.

KDZ files are available for several LG V20 variants. Notably H918TN (US T-Mobile), H990 (non-US single-SIM), H990DS (non-US dual-SIM), H990N (Korea dual-SIM), US996 (US unlocked), and VS995 (US Verizon).

The primary goal of this tool is updating /system and /firmware, though updating other areas is in theory possible.

XDA:DevDB Information

KDZ Writer, Tool/Utility for the LG V20

Contributors

emdroidle

Source Code: https://github.com/ehem/lg-v20-tools

Instructions

Boot into TWRP. Upload an appropriate KDZ for your phone somewhere on your phone. This can be on a SD card, since all known KDZ files are just under 3GB even TWRP's in-memory filesystem is sufficient. Download(the Downloads tab, above), and upload kdzwriter to your phone:

adb push kdzwriter.gz /

Then in a shell (`adb shell`):

gunzip -c /kdzwriter.gz >/sbin/kdzwriter
chmod 755 /sbin/kdzwriter
[STRIKE]umount /system
ln -s /sbin /system/bin[/STRIKE]

The `umount` command may give an error. If you're on TWRP 3.0.2-1 /system won't have been mounted and you'll get "invalid argument"; if you get an error saying "busy" there is a problem. If using version 1.95 or later, the second two commands are unnecessary.

From here you can invoke `kdzwriter` with various arguments to write /system and /firmware:

-v

Increase verbosity. At lower levels not too much is added, at level 3 `kdzwriter` starts gushing debugging information.

-r

Report mode, tells you about how the chunks in the KDZ file match your phone.

-t

Test mode, tells you whether `kdzwriter` has decided the KDZ is an appropriate match for your phone (safety check). If used with other options, `kdzwriter` will run through the write procedure and tell you whether all the steps succeed.

-a

Write areas known safe to apply to the device. As of right now this is /system, /firmware and /cust. (equivalent to -s -m -a)

-s

Write /system. If you only want to update /system, this is the option for you. By default -s will attempt to preserve the kernel modules present on /system and overwrite the ones on the new /system image with those. This is appropriate if you've installed a custom kernel.

-M

Disables preserving kernel modules from the current /system. If you've got a stock kernel you want this option. If /system has been corrupted, this also avoids mounting /system and ensures -s succeeds.

-m

Write /firmware (aka modem).

-c

Write /cust. Some files of these files appear related to VoLTE. I'm unsure whether they're critical or optional. One (seemingly harmless) error message generated when switching regions can be avoided by writing this area.

-k

Write boot (/dev/block/bootdevice/by-name/boot). If you're opting to stay with the stock kernel then you'll want this option. This can also be used to recover from a failed Magisk/SuperSU/Superuser installation.

-P

GPT restoration mode. If a "ROM" has modified the GPTs this will attempt to restore them closer to stock. There are plans to have LineageOS do just this, so I wanted to be prepared to return to stock.

-R

Modified GPT restoration mode. "userdata" is moved closer to the begining of the device potentially allowing additional data to be merged without needing to wipe.

The most common invocation will be `kdzwriter -a <some location>/<KDZ_for_your_device>.kdz`, as noted you can use "-at" to simulate the process and confirm no errors occur.

The -b option has been allocated, but are not yet implemented. A deliberate attempt to minimize flash wear has been made. Blocks will not be rewritten if possible. Empty areas will be discarded/TRIMed.

`kdzwriter` attempts to preserve some files when writing areas. When writing /system unless -M is specified, `kdzwriter` will attempt to preserve kernel modules. When writing /cust, `kdzwriter` attempts to preserve "official_op_resize.cfg" (see GPT restoration mode for details). There are plans for v2.0 to try to preserve the contents of "open_path_mapping.cfg" and "op_list.cfg".

If you get an error message about "Failed while writing /system, major problem, PANIC!" this is most likely to be caused by a corrupt KDZ file. In this case retrying the download is the most likely solution.

Apparently for some devices/KDZ files it is necessary not to skip too many revisions. Notably going from H990N version 10b to version 10o does not work; instead you need to do 10b -> 10e ->10o. This hasn't yet been observed on other devices, but beware big skips can fail.

GPT Restoration mode

There are plans to have a future version of LineageOS hack off a piece of /system to utilize as /vendor. This is reasonable for LineageOS (or another "ROM"), but a problem if you desire to return to stock. As such v1.95 has been brought out which features the ability to restore the GPTs.

Crucial item: In the interest of safety this operation demands a KDZ which is a better match for your device! You will need to use a KDZ file matching what your device was at when you initially rooted! (H990ds10b* or so for most devices)

You can confirm whether a given KDZ is appropriate using the "-t" option. If `kdzwriter -t <someKDZfile>.kdz` gives the message "KDZ appears applicable to this device" then kdzwriter will not use that file for this operation, that command must give the output "KDZ appears applicable to this device and matches original" in order to be acceptable for this operation.

On the H990 some space is stolen from userdata for use as /OP. Everything in /OP appears to be bloatware, but since I'm trying to make it possible to go back close to stock, I've got to do something about /OP. The size of /OP is controlled by the file "/cust/official_op_resize.cfg". As I didn't have a better way of handling it, I simply grab the first line and use that. If /cust is unavailable (hasn't been restored?) a size of 0 will be assumed. If a size of 0 is found, `kdzwriter` will wipe the slice^Wpartition and the space will in fact end up as part of /data (hint, hint).

Important note: Since the normal order is system, cache, cust, OP then userdata, modifying the size of /OP will require wiping /data!

The -R option restores a modified GPT. The modified GPT mode tries to reorders the slices^Wpartitions as userdata, OP, cust, system, cache. The theory is that if cust isn't needed in LineageOS, cust could be removed from the GPT and the space merged into userdata. Since userdata is then first, it could be enlarged without the need to wipe and restore.

Examples

I expect by far the most common usage to be `kdzwriter -a <somekdz>.kdz`, but as typed there extra flags for certain situations:

Recovering from bad flash attempt -sM

If there was a problem when attempting to write /system there is a decent chance it won't be possible to mount /system for saving kernel modules. In this case using `kdzwriter -sM <somekdz>.kdz` is your need. This skips mounting /system at the cost of being unable to preserve kernel modules, you will need to reinstall whatever kernel you were using.

Partial unrooting -k

If you want to switch between Magisk, SuperSU, and Superuser this is your need. `kdzwriter -k <somekdz>.kdz` overwrites the boot/kernel area with the image from the KDZ file. Your next step will likely be to reinstall whatever kernel you were using. Afterwords all traces of a systemless install will have been wiped and you can install a different `su` implementation.

Going mostly back to stock -ak

For owners of the V20s where the stock kernel works, you can use a combination of these two options to update /system and to a newer kernel (you don't want to be hit by DirtyCOW). After doing this you'll need to reinstall whichever `su` implementation you were using.

Version Information

Status: Stable

v1.98a

Identified which check was preventing installation of 20a KDZ files. That is now disabled. There is also a force option which will override the safety check, but please be careful. That safety check was written to try to make it hard to generate bricks...

v1.98

Implemented modified GPT restoration mode. This mode reorders the slices^Wpartitions during restoration. This allows for potentially merging more space into /data without needing to wipe /data again.

v1.95

Found the appropriate compiler flag for setting the runtime linker. Thanks to the TWRP folks, kdzwriter is now a bit easier to use.

Implemented GPT restoration mode. This allows for restoring modified GPTs back to stock. This is valuable if a "ROM" has modified the GPTs. Given how there are plans to have LineageOS do just that, I'm figuring a number of people may be rather interested in this feature.

v1.3

Fixed testing for whether a KDZ is applicable to the device. This should merely be a safety precaution, but I need it there so I don't get fingers pointed my way on failure.

Finally tracked down the issue with kernel module preservation. This is a really stupid bug. There should no longer be any need to reinstall modified kernels after updates!

v1.2

Added additional debugging information around calls to Zlib. There has been a report of difficulty around Zlib so extra information is available. Some of this is only available at verbosity level 3 though.

Created 2017-07-31

Last Updated 2019-01-02

v1.2

MD5: 49b06410f8f90606f9829cc8ff8ed82a

SHA1: ce1f84f579c94e788539e462febc2f2e293a64ff

SHA512: 47a94ae6c6d1157dd406319d2d44ba72c9f954c3f0ad6b892eafbb818d01a7bf9c14b0a9f01ab6f092c07537d3273f8981b83c80ebf67f2cf9e33c26f8838ad3

v1.3

MD5: a412c7fe58722b6e63560c5074bc59b7

SHA1: 8e7e1fbd2edef0ff10516c57a84b642a1a92a758

SHA512: a5b9d3a66bf4237138264a5756f1637ba849a3aeb78d935e0fe6033486de41ad56a0ca5c62b3d94546fd2b4fe86e9edf7958e80481f1f10ef7ef2b6b562a412a

v1.95

MD5: 5f8797b5829ca5a919d1d685404a2726

SHA1: 62d7476ec50a2ea3a682b86654dd1ddc03da0c24

SHA512: ee717f3803e43862dc6faac3788e16267d9661bf98f8fdeebedd6b871dcd4cadb7dc4ee5208dc6072f5f7ba44e46440a759425536a354b530584f824570283c7

v1.98

MD5: 7dfee90d7e0711f5742b94efb81a8b18

SHA1: f020345935b078ebc336e88e3b0623e0792f71ad

SHA512: 71e82f535d33cc64fe023425db0b6d924c6d11677b04843628a9c6ca90cc6700d0a6c5e868c964e31d54f7d3c835d9ecd3b6c33108926da29e75e3be3e1456b2

v1.98a

MD5: 31f207a865b453472271eed29544833e

SHA1: 42ab0486cfc100b52dde9c6bac9bca684eccfde2

SHA512: fe127bece0e25ae4927f3499d708d1533b5fe0a00513de9cb8565ffc24b3e4ee08e9000d828a0177feb4b3b449137836b63cda72cf178b5cd67ae377997a1d37