yashsingh1/xdaforums huggingface dataset:
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
you never tried flashing full firmware? That has worked for me countless times, but I even narrowed it down to the file you need to flash. I was getting the corrupt system error and flashing the full firmware update fixed but I was curious which file(s) in particular was doing the job, because as many of us have experienced, stock boot and recovery were not doing the trick. Anyway, the first file I tried did it and it was aboot! So, what are we doing that modifies bootloader? Or does flashing stock bootloader clear a flag that we're tripping?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
are you checking getprop ?

cause (as far as i can see) the updater considers the system/emmc "corrupt" if it doesnt find:

[ro.boot.veritymode]: [enforcing]
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] JamesRC:
Trying to understand this thread!

Do we have enough info to root the HTC 10 but keep OTA capability, without losing radio functionality? I'm seeing mixed messages from the various threads.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] topjohnwu:
The OTA thing is still unclear. What I experienced is that once it's broken, it cannot be fixed. Someone did restore the ability to receive OTAs by flashing firmware though, however it doesn't work for me. If you plan to S-OFF, then the OTA thing shouldn't bother you, since here on XDA we can always upgrade our phone in the un-official way. I hosted a thread in the General Section with all stock related information and resources, once an update is available just keep an eye on it :)

About the data decryption issue, it is done in intention by HTC. Developers are finding ways to fix this issue, but if you plan to use stock rom, you have to keep your data encrypted in order to make the radio signal working. I posted a modified SuperSU to set encryption on by default, also written a script to wipe encrypted data without missing your internal storage. Check them out :)
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] 5m4r7ph0n36uru:
One question: does your bootloader state software status official or software status modified. Just recognized that mine, even after S-OFF, restoring LeeDroid's stock backup and stock firmware 1.30.401.1, as well as flashing TWRP afterwards states software status official. A little bit weird as - due to the changes done - it should state modified as long as no RUU has been flashed. At least this is what we got during the M9 days.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] Captain_Throwback:
S-OFF disables that flag, so it'll always show "Official".
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] JamesRC:
Thanks, I'm not planning to get s-off so will wait until it's cleared up!
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
This is very thorough testing, but I think once you checked for its the very first time and were approved for it, it's very hard to fail the check. Likewise if you do something that causes your first check to fail nothing will get your device to pass the check except flashing aboot. Just my experience with it. Played all day yesterday with downgrading and trying to break ota and found one it passes once I couldn't break it again.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
the device was

completely

wiped on more than one occasion .... i did not do this "happy go lucky style" .... and even when it wasnt completely wiped, i made sure to be in airplane mode, and delete any data "leftovers" from checkin and updater, then rebooting, then..... you get my point ;)

i'm pretty sure, if i want to break it, i can even without wiping so much :cyclops:
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
Did you ever reflash bootloader? It seems ota check is written there. Can you explain any other reason flash aboot and only aboot immediately restores ota?

I wasn't trying to imply your testing was happy go lucky, just that it was incomplete, since you were never able to break ota and repair it.

Upon receipt of the device I tried to make sure I took precaution to immediately create a pristine system image and boot image backup and worked with others to create a stock recovery backup. I restored all three before checking for ota and it still failed.

I hope this post doesn't come across as argumentative. I appreciate and respect the work you do here. I'm just trying to figure out WHY ota is breaking and WHY the usual method ( restore system image, boot and recovery) does not fix it.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
no worries, i wasnt trying to be "argumentative" or similar, just sharing my personal experience

... seems I'm not the only one, and the "panic" button, may (or not) have been pressed a little too soon (imho)

there are quite a few people in this thread that probably know things a lot better than i do, but there's always a learning experience involved, my 2 cents

anyway, no, i did not reflash bootloader (not sure which one you mean anyway), nope the check is not there either

to put it

very simply

, here's how i perceive it:

1) checkin ... well does exactly that, and checks in (checking current fingerprint, etc for something newer)

2) Updater will then come back and tell you there's an update (if checkin approves)

.... but it will also tell you about "variant system" (eg cid, mid) and other errors (even little things like insufficient space), in this particular one it also checks the flag i mentioned, and will tell you emmc is corrupt

3) if checkin is OK, and Updater is OK, the download will commence and be put in some "location"; cant remember the exact location (something like /data/...updater.../files), but i did let it download, even though i had the file

(oh and yeah, the download url is in the logcat)

4a) once it's downloaded (and Updater is OK with it ... not corrupt, etc), it "hands" over to recovery, which will run the updater-script (for the normal patch)...

4b) once recovery is happy, and has updated (yes, i did a fail the first time around on purpose) then recovery will "hand over" to hosd for the firmware flashing

a few reboots later, and yep, all is updated

amongst the "weird" things:

* i had TWRP installed, (checkin and updated didnt care ... as far as i can tell, they dont even access look at the block devices)

* i could have easily asked twrp to do the flashing, but i wanted stock recovery

* switching between stock recovery and twrp has no effect on encryption

* no i did not mess around with firmware at all (well other than twrp)

* i did mess with boot.img more than enough... didnt break anything

* i did have systemless SuperSU (in various forms) around..... even when the OTA went through successfully

* etc

i'm pretty sure i can break it as well as "not break" it, but in your particular case (perhaps i havent read back enough), i see no logs, and no exact (i mean very precise) information of what is actually going on

* where does your OTA actually "break"

* what state is your phone in

* what have you "modded"

* screenshots

* logcats

* etc
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] topjohnwu:
[MENTION=2605798]nkk71[/MENTION]

What I think that [MENTION=1162986]Captain_Throwback[/MENTION] and you got no problems because both of you have S-OFF in the first place. I got the device so early that there is no S-OFF method available at the time.

It seems that S-OFF will disable some flags, so modifying the system won't cause issue.

I modified my system when I was only HTCDev unlocked, and I cannot receive OTAs afterwards, even if I restored system and boot back to stock.

So I think even if you try to modify system, you could not manage to break OTAs.

I'll try to flash some partitions from RUUs and find if I'm able to clear the flag.

This should most likely be the conclusion I guess.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
I got corrupt system message with s-off my first hour with the device.

Here was my initial process:

Unbox device

Unlock with HTC dev

Flash twrp

Enter twrp in read-only mode

Make system image backup plus boot

Wipe data ( this was before your awesome wipe script and supersu install zip

Sideload supersu 2.71 ( direct from chainfire)

Boot to system

Download sunshine and s-off

After sunshine installed on the final reboot I received a prompt for startup pin, even though I had no security setup on the device, so I rebooted to twrp and wiped data again

Possibly it was due to using supersu without your script?

Also, your op is inaccurate in that it's impossible to take an ota with a system/ recovery version mismatch. I've taken the ota many times, and assisted countless others to take it, with 1.21.617.3 system and boot and 1.53.617.5 recovery.

---------- Post added at 12:54 AM ---------- Previous post was at 12:25 AM ----------

aboot_signed.img from the ota's firmware package. https://drive.google.com/file/d/0B8OH6sFjVE1ld1ptNTFEaEc3Rms/view?usp=drivesdk

Broken in this context refers to the image in the op stating "There was an unexpected error and the file system may be corrupt. Please contact HTC support for further assistance."

I've gotten and fixed this error several times and assisted others to fix the error as well. When one gets the error, restoring pristine system image and stock boot and recovery do not fix it. After restoring, when you go to download the ota, you still get the error above.

However...

Fastboot flashing a zip with only aboot_signed.img (and android-info.txt, obviously) immediately restores ones ability to take ota. So given that information, how can you say with certainty that there is no check in the bootloader?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
[MENTION=4470081]topjohnwu[/MENTION], I'll restore back to 1.21 later tonight, and try to break the OTA update and will let you know what turns up.

but even though s-off "could" potentially make things easier, I wasn't S-OFF till after step 8.... and all the steps before that were accepting the OTA without any issues.

The only thing I made sure of, was to always have an encrypted data partition... ie, avoid messing with an encrypted data partition unless the "phone state" has changed (eg bootloader unlock, s-off)

That's for example why (phone state has changed):

* After HTCdev unlock, I booted the system (no TWRP, no SuperSU), because I wanted to have it encrypt

* After S-OFF, and the system booted but wasnt able to decrypt (due to "phone status change"), I went to TWRP and formatted data (only the format, no SuperSU, no flashing stuff), then reboot so encryption kicks in

[MENTION=5957136]jollywhitefoot[/MENTION], regarding flashing "aboot" i dont really see how that restores the ability for the OTA.... unless the RUU mode flash, has either reencrypted a previously non-encrypted data partition, or restored "the property" that triggers the system to *think* it's corrupt.

I'll do some more checking into the code later, but from the Updater.apk (other than the usual bootloader, mid and cid checks.... which depending on which, would give you an error like "Variant system detected"), the only thing in the Updater.apk that is being checked is ro.boot.veritymode and if it's not set to enforcing will set the "system emmc corrupt" flag.

But I'll check more into it later.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nenebear:
Updater.apk/ ... /strings.xml

<string name="[COLOR="Red"]msg_update_unable_rooted[/COLOR]">"There was an unexpected error and the file system may be corrupted.
Please contact HTC support for further assistance."</string>

<string name="[COLOR="Red"]msg_update_unable_rooted[/COLOR]">"發生未預期的錯誤，檔案系統可能已損毀。
請聯絡 HTC 支援獲得進一步協助。"</string>
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
http://xdaforums.com/showpost.php?p=66587635&postcount=40
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
FYI. I'm always flashing firmware in download mode, not ruu mode. Thanks for testing further.

JWF
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
breaking stuff now.... :p :eek::eek:

will be back later-ish....

EDIT: interesting.....

EDIT2: very interesting, for some reason you broke verity ... and yeah, my bad, that's actually in aboot it seems (the verity check, nothing to do with the OTA)

and i didnt break it, and dunno why (yet?) .... but even with an unencrypted device:

1- flash twrp

2- restore stock system + boot 1.21.401.1

3- format data & cache (full format so i can confirm they mount in twrp just fine)

4- flash supersu (normal systemless mode)

5- boot up, and device is not encrypted

and can confirm:

[ro.crypto.state]: [unencrypted] -> so no radio

but

[ro.boot.verifiedbootstate]: [orange]

[ro.boot.veritymode]: [enforcing]

--> so OTA is still accepted
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] topjohnwu:
How about trying to modify the system??
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
did that already, didnt break veritymode, which is still the "problem"

seems to get set very early on .... looks like possibly/probably in aboot (as [MENTION=5957136]jollywhitefoot[/MENTION] mentioned, but it has nothing to do with the actual OTA "check" which is still done by the apk's) EDIT: so thanks mate ;)

aboot just passes on to boot and then to rom whatever it has

.... but doesn't mean anything conclusive as of yet... you guys are getting a non veritymode=enforced flag

which is breaking the OTA

even with (dm-verity removed, system mounted and messed with, etc), i am still able to "receive" the OTA.... dont need to test, but it wont apply cause i already messed up system

hmm: Question, did you guys ... oh, nvm.... i'll let you know when i "break" it.... dont even know why i'm doing it

i should be restoring stuff from previous phone to this one.... that 10 hasnt seen a homescreen, let alone anything else since i got it :crying::crying:
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] topjohnwu:
I have done the same thing a month ago when I got my phone :)

What I mean is that I modified my system BEFORE I S-OFF my phone.

Before the device is S-OFF, it might set some flags to the firmware and prevent OTAs to show up.

Here is my pg1fs.img and pg2fs.img. The flags are most likely to locate here.

Would you compare mine and yours and see if you can find any difference?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
Dude, I'm telling you... once fixed I had a hell of a time trying to break it again.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
thanks, i'll lcheck those, but not sure that's what i was looking for.

overreaction, my bad :(

.... but i do seriously dislike that word

figured it out, will write it up in a bit
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
My bad. I didn't realize that word carried negative connotation for you. It's just another word for bro, or guy around these parts.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] Kisakuku:
Huh?

http://xdaforums.com/one-m9/general/how-to-disable-remaining-write-t3171735
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] Captain_Throwback:
What? That's a post from a different device forum (and for an unrelated topic). How's that relevant here?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] Kisakuku:
Guess I should have elaborated beyond "Huh" )

It sounded like a general statement, not just specific to the 10, so I quoted a thread from the M9 forum showing how to reset the tampered / modified flag when S-OFF. In my experience with Sunshine on M9, the flag had to be reset manually. Is this not the case for the 10?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] Captain_Throwback:
I'm only telling you what I've been told for this specific device. I can't speak to other devices.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] Kisakuku:
Gotcha. Well, the official/modified flag on your M8 with hboot 3.19 had to be reset as well. So I guess this is indeed a new thing.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
first off, sorry [MENTION=5957136]jollywhitefoot[/MENTION] that word just doesnt work well with me, i know what it means, how it's used (harmless), it just hits a nerve

My Final Conclusion

As I have suspected it's the

[ro.boot.veritymode]: [enforcing] --> good

vs

[ro.boot.veritymode]: [logging] --> BAD, and will result with the

"There was an unexpected error and the file system may be corrupted. Please contact HTC support for further assistance."

encryption has nothing to do with it by the way.

So here's a breakdown of what happens during a normal boot.

1) aboot starts, "does stuff" :o

2) then hands over to boot.img for further processing

3) which should eventually end up with a booting the ROM

This is what a normal (verity=enforcing) would look like:

aboot part:
...
[510] read_device_info_mmc:read device info from mmc
[520] htc_read_device_info: verity_mode = enforcing
....

kernel/boot.img part:
...
...

How to break it

(DO NOT DO THIS): have your boot.img use verified boot (ie verity checking on a

modified

system partition, by having the "verify" flag in fstab), since system won't pass the check, this will happen:

aboot is still OK:
...
[500] read_device_info_mmc:read device info from mmc
[510] htc_read_device_info: verity_mode = enforcing
...

BUT once it hits the kernel/boot.img
....
[ 2.737990] c0 466 fs_mgr: Enabling dm-verity for system (mode 1)
[ 2.801811] c1 53 device-mapper: verity: verity_verify_io:io_real_digest=a48df664 io_want_digest=a43baac3
[ 2.801826] c1 53 device-mapper: verity: 259:30: data block 0 is corrupted
[ 2.802645] c1 53 device-mapper: verity: verity_verify_io:io_real_digest=5c67cc54 io_want_digest=5864f2b1
[ 2.802659] c1 53 device-mapper: verity: 259:30: data block 1 is corrupted
[ 2.808372] c0 6 device-mapper: verity: verity_verify_io:io_real_digest=2a70e9c0 io_want_digest=7bafd223
[ 2.808386] c0 6 device-mapper: verity: 259:30: data block 243 is corrupted
[ 2.826504] c1 53 device-mapper: verity: verity_verify_io:io_real_digest=6dff1798 io_want_digest=b40f453c
[ 2.826520] c1 53 device-mapper: verity: 259:30: data block 950780 is corrupted

unfortunately no matter what you restore in TWRP, any following bootup will already be set to "logging" from aboot (because one or several partitions have been "flagged",

so the kernel/boot.img verification won't matter any more

...
[530] read_device_info_mmc:read device info from mmc
[540] htc_read_device_info: verity_mode = logging
....

this will be passed on to kernel/boot.img and then to the ROM, which the Updater will now consider a corrupt emmc

How to fix:

In order to get veritymode back to enforcing, you need to "erase" the devinfo partition, please head over to this thread for more information.

Quick summary:

For S-OFF devices: please follow [MENTION=1162986]Captain_Throwback[/MENTION]'s method using "fastboot erase devinfo"

For S-ON devices: you'll need to flash an RUU-Mode flashable zip containing the "erasepartition: devinfo" command
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
Awesome work here. Thanks.

And again, my apologies for touching a nerve.

Are you saying you don't have stock aboot to restore?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
no worries, .... i'm sure you can understand when a "nerve" get's hit.... water under the bridge

i havent tried aboot yet, nor ruu (only a ruu mode stock boot.img)

but i'm just shocked about how many partitions got messed up along the way, .... guess I'll try an aboot flash first, before going for firmware and/or ruu.... though some of those partitions aren't usually affected by RUU flashing, which is the weird-ish part

I can still get system to boot on most occasions, though very finicky

---------- Post added at 19:06 ---------- Previous post was at 18:28 ----------

can you link me (in PM if you prefer, the exact version you are using),,,, i'm still trying to figure out the erase flags
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
Full update package, includes aboot.

https://drive.google.com/open?id=0B8OH6sFjVE1ld1ptNTFEaEc3Rms

but, removing everything except aboot and android-info works too
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
is that the exact android-info.txt you have successfully used? ... just trying to be very specific, i wanna know which part of hosd is making/breaking things

i already know mine, fraked up some other things, but that's probably due to different android-info's (.... well the flags set in there ...)
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
Yes. I didn't edit android-info at all.

I have fixed OTA (the ability to download AND install) by flashing the entire package I shared with you (as-is).

And also by removing everything except signed_aboot and android-info.

But I have never modified any of the files within the package.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
thanks

havent tried it yet.... but did that package survive several reboots? (i can get an veritymode=enforced boot on the first try, but not on multiple reboots)

once i managed to break it.... yeah, not nice... i could start restoring my partitions, but that's not the point of this particular exercise :eek::eek:
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] topjohnwu:
Have you compared the partition with hex editor?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] jollywhitefoot:
you mean, multiple reboots before attempting to download ota or multiple reboots before actually installing it?

I probably never tested multiple reboots before checking if OTA became available in system settings. But I definitely had multiple reboots before downloading and installing the OTA.

So, like the process usually was...

Break OTA

Flash aboot

reboot

check for ota (successfully got notification that update was available)

after that, it varied...

most of the time after checking I would:

reboot to downloader

flash TWRP

format data

<do various things to try and break ota again, such as install superSU, wipe encryption in TWRP, push modified system file to device, boot to system and edit system files, etc>

Check to see if the OTA still said it was available and it always was

reboot to system and try ota (still successful)

reboot to download mode and flash stock recovery

reboot to system

download and install OTA

I'm a little busy with work today, but maybe tonight or tomorrow I can play with this again. I'll test breaking ota, flashing aboot and then rebooting several times before checking to see if an ota is available.
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] nkk71:
yes i did, which partition are you interested in?

it could be frp (which would be very bad)

or it could just be offset 0xE0 in ....

.... dunno didnt bother checking any furhter

yep, meant multiple reboots, i was able to get back to "enforcing" (for one reboot), but then it ended up back into "logging", which just breaks things

anyway i, fully RUU'd back and things "seem" to hold for now

C:\ADB\ADB_10>adb shell "getprop | grep verity"
[ro.boot.veritymode]: [enforcing]
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] wiQbold:
Hi at all

I tried your the 'getprop grep verity'

It is also logging for me. Which problems causes that?

I changed a lot in system, delete Google and all that s stuff.

the only thing I recognized that I have to verify a new googleaccount

By phonenumber..

Can I get back? In whats problems will I ran? Is this a big problem?

And how can I strip the rom without triggering the(se) flags?
[HTC 10 ROMs, Kernels, Recoveries, & Other Developm] 5m4r7ph0n36uru:
This fact will break your OTA capability. Mine is logging as well at the moment. Seams by the above mentioned a RUU is able to do the job and get the device back to enforcing. Will do this as soon as I got some time and report back.