Tab Mini C boot loop. Help please.

[Renate]

Originally Posted by Pentam

It also crashes about 18 seconds after I unplug the USB cable...

A new rec.img is up. Try that.

[Pentam]

Originally Posted by Renate

A new rec.img is up. Try that.

We are one step further, but not quite there yet. Flash drive gets recognized ok, but there seems to be some problem with mounting it:

ttyscreen has started
Waiting for flash drive... Ok
Could not make dir for mount
Waiting for flash drive...

[Renate]

Originally Posted by Pentam

...there seems to be some problem with mounting it:

The problem is if you try to do it twice.
I just put up a new version, try that.

[Pentam]

Originally Posted by Renate

The problem is if you try to do it twice.
I just put up a new version, try that.

Ok, thanks. That gave different results.
For a USB-C SD reader and a USB-C drive I get

Flash partition of unknown type 0b

and for USB-A with OTG adapter

Flash partition of unknown type ee

[Renate]

Because of the amazing demand we've had for compatibility with ancient cylinder/head/sector formatted flash drives that has now been added and is available as a download.

I know, Logical Block Addressing is too 21st century.

For true retro style we will be adding 8 bit FAT compatibility.
Unfortunately there will be some problems with the 8MB file size limitation.

[Pentam]

Originally Posted by Renate

Because of the amazing demand we've had for compatibility with ancient cylinder/head/sector formatted flash drives that has now been added and is available as a download.

I know, Logical Block Addressing is too 21st century.

For true retro style we will be adding 8 bit FAT compatibility.
Unfortunately there will be some problems with the 8MB file size limitation.

I thought there could be nothing wrong with using FAT32 formating in a current Windows. Seems like they still use the same tool they introduced ages ago in Win95.

SORRY!

Reformated the flash drive in Linux and tried again. Now it gets recognized.

ttyscreen has started
Waiting for flash drive... 0
Mounted flash of type vfat
payload.bin found
payload_properties.txt found
Starting update in  0
ui_print Step 1/2

Now the devices crashes about 40 seconds after the start of the update step 1 (blue LED, EDL mode, screen stays unchanged).

[Renate]

There's FAT32 CHS and FAT32 LBA and exFAT.

Try it again. My Poke5 stopped once halfway through.
But I'm not sure if it were my code at the time or the properties.
It does a lot of stuff in the first half.
Keep your eye on the blinky LED on the flash.
Also, it may have switched slots on you.
Not a problem, but you might have to reflash recovery to the new slot.

Did you get a log out of it? autolog.txt on the flash
Just code quote the payload_properties.txt

[Pentam]

Originally Posted by Renate

There's FAT32 CHS and FAT32 LBA and exFAT.

Try it again. My Poke5 stopped once halfway through.
But I'm not sure if it were my code at the time or the properties.
It does a lot of stuff in the first half.
Keep your eye on the blinky LED on the flash.
Also, it may have switched slots on you.
Not a problem, but you might have to reflash recovery to the new slot.

Did you get a log out of it? autolog.txt on the flash
Just code quote the payload_properties.txt

Fourth time is a charm?
First three times it crashed quite quickly. Autolog.txt was empty each time.
In the fourth attempt I got a lot further (see attached screenshot and log).

payload_properties.txt:

FILE_HASH=jnps6pG3tKOouugCDuYVNL+EyUSyQgJW9chrp7Dk6Po=
FILE_SIZE=1552088218
METADATA_HASH=F32NLM2GgywpJ9KvLf0G0cTvFhrpuM5ZKExcHS6YhDE=
METADATA_SIZE=94429

[Renate]

It should not say "Waiting for flash" at the end unless

• You typed "start autoupdate" again
• You're using an old version

The log does not indicate any problem, just that it stopped when writing vendor.
The division between stdout and stderr by the update engine is stupid.

Try again using the new download.

Errors accumulate easily on flash drives.
Reformat, write the two files, chkdsk /f

[Pentam]

Originally Posted by Renate

It should not say "Waiting for flash" at the end unless

• You typed "start autoupdate" again
• You're using an old version

The log does not indicate any problem, just that it stopped when writing vendor.
The division between stdout and stderr by the update engine is stupid.

Try again using the new download.

Errors accumulate easily on flash drives.
Reformat, write the two files, chkdsk /f

I have tried over and over and over with several different flash drives. In 4/5 of the cases it the update fails rather quickly with autolog.txt being empty. In all other cases the update fails sooner or later. I once got quite far, but it failed all the same (log attached).

I am starting to suspect a hardware error...

[Renate]

That failed at product. Was the last time a failure at vendor?
It is failing at different spots, isn't it?

Here's the trimmed-down logs from mine (good) and yours (bad):
(They are different devices so the hashes are not supposed to be the same.)

== GOOD ==

ActionProcessor: finished DownloadAction with code ErrorCode::kSuccess
ActionProcessor: starting FilesystemVerifierAction
	Hash of boot: p7Hqd9v1wuKI7lLLkZbXyQ6q8N7+Wcho0bePpmNS9tg=
	Hash of dtbo: b0LvfQxEzhhv6XoLPcLBcTHbRKFGYY93ko/32fyYPdI=
	Hash of product: RPBwsDz0NTGcPQzkZP1bKsG6y8Kv8tkLleREUgzpUbI=
	Hash of system: w+8HH1av4Io+jLQSOOPU8IMPrFO4JTDOp1pXiW2SjC0=
	Hash of system_ext: mHEq7QZ14rhRSUe0El7COBrEkHakZjDqNk+1u818IBA=
	Hash of vbmeta: YpvAClGrpMpk7vj13ePLeSgRK9fK3M9Akc+IlURkWrs=
	Hash of vbmeta_system: ND2lcx0jmmM3NYYXzK0xs/z1DhXQTAzQJTlyHkJc4A8=
	Hash of vendor: BvdgwFrPsGYRDHIcldkNVYDv/m+KXlF71T4007bazN8=
	Hash of xbl: rD5nVc9pLohGdh85TPY+du4yEixZh2WYH509ysy8POA=
ActionProcessor: finished FilesystemVerifierAction with code ErrorCode::kSuccess

== BAD ==

PartitionInfo new modem sha256: 9T6r9vOmVqnYNjIQOobJc45ftSESKfsYYWSWht2p+54= size: 40488960
PartitionInfo new product sha256: jvuR+pJgk3OimbtNZhZZ8s2B2wHv+z6lSm8NA/dygD8= size: 459763712
...
ActionProcessor: finished DownloadAction with code ErrorCode::kSuccess
ActionProcessor: starting FilesystemVerifierAction
	Hash of boot: V1kNtiYXrWTGawiBxww1EZsrKckmYR/5p15eQSVrluY=
	Hash of dtbo: IqDqDNdfPmAUOq9MvDwC1LtDv/9FiwhQexpQj5CczZU=
	Hash of modem: 9T6r9vOmVqnYNjIQOobJc45ftSESKfsYYWSWht2p+54=
	Hash of product: YHKAJhju/XflE039+XNJeaRAu2tkTDi2KXE5PivS2LE=
	New 'product' partition verification failed.

I just updated my Poke5 another two times (both slots) and it went perfectly.

Mmm, if you have a Type C hub with PD (takes power in) you might try that.
I don't think it's worth buying one though unless you have a use for it.

The other thing is, use a Python payload dumper and dump payload.bin on your desktop.
It will tell you whether all the files in it are straight replace or whether some are incremental.

When you have product (as uncompressed single image) you can generate the SHA256 of that, then encode that with Base64 and it should be the same as either the first or the second hash. I just checked that on a few of my partitions and it all checks out.

[Pentam]

Originally Posted by Renate

That failed at product. Was the last time a failure at vendor?
It is failing at different spots, isn't it?

Yes it is failing at a different spot every time.

Mmm, if you have a Type C hub with PD (takes power in) you might try that.
I don't think it's worth buying one though unless you have a use for it.

I guess I have one around somewhere. Will give it a shot later

The other thing is, use a Python payload dumper and dump payload.bin on your desktop.
It will tell you whether all the files in it are straight replace or whether some are incremental.

Maybe a stupid question: How can I tell the difference? Comparing the hashes of those that worked?

[Renate]

If the blocks in the partitions are not contiguous then you're hashing on old data.
The payload dumper will tell you if the blocks are not contiguous.
When it dumps you can hash.

It still could be a non-contiguous problem when you get different results each time.
You've got two slots, so that's at least two scenarios, maybe more.