Kenneth Davis

finally applied :-) At worst will not hurt and at best prevents a race condition that could corrupt the stack. Thank you. this can be closed

no I lost the ability to do more than add comments here a decade+ ago

now supported in upcoming xcopy 1.7

This is resolved in 0.85a release. Please close bug.

just realized the picture says 2TB, which answers question 1

Off hand it looks like different LBA <-> CHS translation calculation is being used between the different OSes; not sure if its a bug or a result of different means of calculating. So I can setup a proper test environment, please clarify a few steps with the setup: 1) how big is your virtual hard drive? e.g. 2GB raw 2) are each of the three partitions you are creating the same size? e.g. all 500MB, all 1GB, etc 3) you say FDISK and FORMAT from MSDOS 6 works, but later versions cause the issue with...

This bug can be closed then (by whomever has access to do so) and I will create another bug to track upx --lzma support

I need to look into the upx decompressor logic to see why though; the kernel jumps past the config section, then jumps past size bytes (where size is the packed kernel size) to the trailer which shifts the kernel down and then jumps to the start of the packed kernel. I wonder how much stack the lzma decompressor needs or if it is some other change ... Please let me know if changing the UPX setting gets your compiled kernel to boot for you?