Restore ;log command for 5.12.* firmware

[MrTick]

This will work if and only if recent jailbreak hotfix was installed before the update.

This script modifies debug_cmds.json file so it includes again ;log command.
It also adds ;mrpi command that launches mrpi (has to be installed in the default extensions location)

{
    ";log" : "/usr/bin/logThis.sh",
    ";mrpi" : "/mnt/us/extensions/MRInstaller/bin/mrinstaller.sh launch_installer",

This is most useful for people that have Kindle updated to >=5.12.2 with jailbreak only.
KUAL installation requires MRPI and MRPI requires ;log command to install KUAL (or maybe there's an easier method I've missed somewhere?...)

Installation:

1. copy emergency.sh to the root USB folder
2. restart your Kindle (Menu->Settings->Restart)
3. verify the script was executed: following files will apper:
   • done_emergency.sh
   • old_debug_cmds.json
   • new_debug_cmds.json
4. restart your Kindle again

If the files from 3. did not appear and you can still see emergency.sh file then try reinstalling the JB hotfix.

After successful execution you can unpack MRPI to USB root, add KUAL package to mrpackages folder and run ;mrpi command.

Note: if anything goes wrong, i.e new_debug_cmds.json looks malformed, copy emergency_revert.sh to USB root, rename it to emergency.sh and restart the Kindle.

EDIT: this debug-list fix can probably be included in JB hotfix, but quoting logThis.sh code:

...
## We could arguably patch the debug command list, but, meh.
...

[Junket]

Originally Posted by MrTick

;log command to install KUAL (or maybe there's an easier method I've missed somewhere?...

;log command MIA in 5.12.2 I believe.

NiLuJe made a hotfix variant of KUAL that can by installed by UYK (Update Your Kindle) instead. See here.

[MrTick]

Originally Posted by Junket

NiLuJe made a hotfix variant of KUAL that can by installed by UYK (Update Your Kindle) instead.

Darn, I knew there should be an easier way

[pavel-s]

Wow, it restored the jailbreak on my PW4 5.12.2! Previously, I tried the UYK method but it didn't work (error 007).

Gorgeous, thanks a lot!

[MrTick]

Originally Posted by pavel-s

Wow, it restored the jailbreak on my PW4 5.12.2!

Awesome! Probably the jailbreak was still there (the bridge at least), as the bridge itself is responsible for running emergency.sh on startup.

[NiLuJe]

Yeah, I didn't want to do it this way because that'd be one more thing to keep track of in the bridge and it's potentially a moving target, plus I'd have had to double-check the depgraph to check when best to patch it, hence that comment in the dispatcher . (Also, I'm lazy).

But, it is an entirely viable approach if you want to bother with it.

[Junket]

^ Typo. You spelt efficient "lazy"

[LastSilmaril]

Thanks for this. Works like a charm.

[MrTick]

Originally Posted by NiLuJe

(...)that'd be one more thing to keep track of in the bridge and it's potentially a moving target, plus I'd have had to double-check the depgraph to check when best to patch it (...)

Then I'll try to maintain this patch as long as I'm able to

Another hotfix-addon I was wondering recently (at least for PW4+) was the serial console access.
New firmware, right after console startup executes /etc/upstart/custom-login:

#!/bin/sh

echo '--- SORRY, LOGIN IS DISABLED ON DEVICE ---'
# Disable Ctrl-C
trap '' 2
# Sleep indefinitely
while true; do sleep 86400; done

Because of that it's no longer possible to login from the serial connection.
So maybe purging custom-login would be a nice hotfix-addon (backwards-compatible and probably easier to maintain also )

[knc1]

Stray thought:
The only real reason for disabling the serial console at a specific point in the start-up sequence is because it was previously enabled in the start-up sequence.


Can you trace back the upstart sequencing to find something else useful about the serial console along upstart's path.
IIRC, there are tools to graph or trace the upstart sequence. Tools that can be run "cold", I.E: only the upstart directory structure is required, not actually executed.

[MrTick]

The custom-login is executed by /etc/upstart/console.conf:

(...)
  # This feature is introduced from Zelda platform. For older platforms, we keep the login unlocked
(...)
if [ "$prodVersion" == "0" -o "$unlockedKernel" == "true" -o "$secureCpu" = "0" ]; then
    #Unlocked Prompt if: unlockedKernel or not prod or not secure cpu
    exec getty -L $BAUD /dev/$UART 2>> $STDERR
else
    exec getty -L $BAUD /dev/$UART -i -n -l /etc/upstart/custom-login 2>> $STDERR
fi

Originally Posted by knc1

there are tools to graph or trace the upstart sequence

I'll check this out, initctl2dot seems to be a good candidate.
Unfortunately I've left my Kindle at work so I need to wait with experiments till tomorrow

[knc1]

Originally Posted by MrTick

The custom-login is executed by /etc/upstart/console.conf:

(...)
  # This feature is introduced from Zelda platform. For older platforms, we keep the login unlocked
(...)
if [ "$prodVersion" == "0" -o "$unlockedKernel" == "true" -o "$secureCpu" = "0" ]; then
    #Unlocked Prompt if: unlockedKernel or not prod or not secure cpu
    exec getty -L $BAUD /dev/$UART 2>> $STDERR
else
    exec getty -L $BAUD /dev/$UART -i -n -l /etc/upstart/custom-login 2>> $STDERR
fi

I'll check this out, initctl2dot seems to be a good candidate.
Unfortunately I've left my Kindle at work so I need to wait with experiments till tomorrow

-o "$secureCpu" = "0"

That condition is the one people are encountering on "serial port" thread.
I suggest that we trash everything of that 'if' statement except the:

exec getty -L $BAUD /dev/$UART -i -n -l /etc/upstart/custom-login 2>> $STDERR

I.E: Keep only that line of the current 'if' statement.

[MrTick]

Originally Posted by knc1

I suggest that we trash everything of that 'if' statement except the:

exec getty -L $BAUD /dev/$UART -i -n -l /etc/upstart/custom-login 2>> $STDERR

I'm pretty sure it's the other one we want to keep

[Junket]

I don't know half of what knc1 does on the subject, but that does look like a typo.

Bad knc1. No posting until you've had coffee. ;p

secure_cpu: 1, production: 1, unlocked: 0

is the state that we don't want to see.

So we'd want to keep the following:

exec getty -L $BAUD /dev/$UART 2>> $STDERR

[knc1]

Originally Posted by Junket

I don't know half of what knc1 does on the subject, but that does look like a typo.

Bad knc1. No posting until you've had coffee. ;p

secure_cpu: 1, production: 1, unlocked: 0

is the state that we don't want to see.

So we'd want to keep the following:

exec getty -L $BAUD /dev/$UART 2>> $STDERR

But it does not say "unlocked", it says "securecpu" (that SoC option blows a physical fuse, which results in '0' being the secure state).

If it does not say what it means, then all bets are off.