MobileRead Package Installer

[eschwartz]

Originally Posted by Ruskie_it

Apart from JB and MKK, which one of the following:

Rescue pack
Coward Rescue pack
SS
python
usbnetwork

Will survive firmware upgrade and won't require to be reapplied through mrinstaller after upgrade to latest fw?

Only the rescue pack, because the latest jailbreak brides it.

[Ruskie_it]

Originally Posted by eschwartz

Only the rescue pack, because the latest jailbreak brides it.

I'm sorry, but from your "but" clause I am not sure we understood each other. I asked which one DO WILL survive. If the RP will survive there is no need to be bridged...
Were you saying, instead, that RP is the only one the WILL NOT survive, unless you have applied the latest jb?

Oh never mind. You said "because". My bad.

[eschwartz]

Originally Posted by NiLuJe

@eschwartz: Yep, the staging directory not being cleared on error is a bug, will fix .

And, yep, the mntroot issue is also a bug (you have AcxE installed, I haven't, my check was too dumb to take that into account).

In the meantime, do restart without running MRPI, because your rootfs is currently rw!

Il'l fix that when I get back later this evening, thanks .

Thanks, and sorry for forgetting about AcxE.

Also, I do have kterm, so I assume mntroot ro is (and was) sufficient... Thanks for the warning. Did MRPI fail to remount ro at the end, because of uncaught errors? If so, might be best to explicitly do so at the end.

[knc1]

It might make even more sense to just use the mount/umount commands themselves, rather than the Lab126 mntroot scrip.
(mount/umount has much saner error behavior)

Providing our own mount/umount that does not require 'root' permission to run is also a possibility.

[NiLuJe]

@Ruskie_it: Assume nothing survives except what's explicitely listed in the JB: JB, MKK, RP, CRP.

@eschwartz: Nope, it didn't even try to mntroot ro, because my error handling is currently messy as hell ^^.

@knc1: Yup, but I like the safety & logging features of lab126's mntroot, so if I were to do it myself, it would pretty much look like the existing mntroot script in the end .

[NiLuJe]

And here comes v1.4.N, which should fix the severe incompatibility with AcXE reported by @eschwartz . Thanks .

[eschwartz]

Finally got a chance to try this out, and it's working very nicely. for this, and thanks for getting it working with AcXE and stuff!

Now I have all my packages updated to snapshots, without taking hours, I like it. Very smooth. Especially when it works.

[knc1]

Dogs are doing their 4am catscan of the front yard (searching for stray cats in their territory).

Me, well, the old say, idle hands ....

Observations on reading mrinstaller.sh:

Your sourcing /etc/rc.d/functions twice for legacy devices.

The commands:

mount -o,remount rw <device>
Does not return an error if already mounted rw;
Does not return an error if mounted ro and succeeds in changing to rw
I.E: return code == 0 it either did it or it already was

mount -o,remount ro <device>
Does not return an error if already mounted ro;
Does not return an error if mounted rw and succeeds in changing to ro
I.E: return code == 0 it either did it or it already was

AND there is no call reference counting - you only need one rw to change a ro mount, regardless of how many times it was remounted ro.
Same with ro and one or more prior calls to rw.

So I am still pretty sure you can bit bucket all of the awking and greping and other crap from the mntroot script.
You can trust the kernel to 'get it right' without checking up on it.

Note:
Another thing mis-understood by Lab126 when they wrote that script (and repeated here by other posters) - -
Changing the mount status of '/' does not change the mount status of any of the other sub-mounts in the tree.

Those ro/rw status settings are **per mount point** !!

General Note:
There are only two (maybe three) special cases to the above:

The mount point is backed by storage that does not support write (cramfs, squashfs, others) - -
'mount' should return a correct error code, but this is busybox mount - it should be tested to behave correctly.

The mount point is mounted with an errors=ro option and errors have been encountered - -
same as above - 'mount' should return a correct error code
I.E: you can umount and mount a file system with errors but not over ride with the remount option.(*)
Something else to be checked to see if busybox mount gets it correct.

The third case comes up when using network file systems -
Which is going to be a rare case for a Kindle outside of the Lab126 development setup.
(Hmm... which might explain why they wrote mntroot script to begin with.)

A trivia note:
the command:
mount -o,remount <device>
(notice the lack of any ro or rw specification)
will cause the kernel to flush all of that mount point's buffers
(if the backing store supports write, if it hasn't been errors=ro set ro, and for some kernel versions, isn't VFAT )

Edit:
(*) something about what I wrote in that sentence is bothering me - I may have made a mistake in that description.

[NiLuJe]

@knc1:

Good catch on the functions thing, c/p oversight that I distinctly remember fixing, but that must have been on another KUAL extension ;p.

Good to know how mount is *supposed* to behave, I'll take a look at it, but since the defensive approach is in there now, it'll probably stay, can't hurt to be too careful [well, unless you botch the checks like I initially did ^^] .
BB mostly seems to honor what the mount() syscall returns... .

[evlap]

Thanks for your work, NiLuJe.

Will it be possible to use your package installer on FW 5.6.1.0.2? Desperately looking to install KOReader.

Thanks

[knc1]

Originally Posted by evlap

Thanks for your work, NiLuJe.

Will it be possible to use your package installer on FW 5.6.1.0.2? Desperately looking to install KOReader.

Thanks

Yes, but -

MrPi requires the Kindle be jailbroken.

FW 5.6.x can not (currently) be jail broken, but if a recent (ver >= 1.14) was installed **prior to** installing 5.6.x, then the old JB will survive and can be updated.

There are many recent posts related to firmware version 5.6.x -
You can learn more of the details in them.

[jacobt13]

I am not sure if this is a good thread for this... just a quick question to be sure...

My kid turned off the Airplane mode on my Kindle Paperwhite2 by mistake and I didn't realize it. When my KUAL extensions weren't working (font and screensaver), I didn't realize that the thing had updated and tried to uninstall, reinstall thinking there was a glitch after my son was messing with it. Long story short, I finally realized that the Kindle was WiFi connected and that it had updated. Since I uninstalled the KUAL, I am out of luck until a new jailbreak comes around for this update.... right?

[NiLuJe]

@jacobt13: If your jailbreak was in a sane state before the OTA update, all might not be lost. Try this.

(And, yes, FWIW, that's a question better suited for the JailBreak thread ).

[jacobt13]

Originally Posted by NiLuJe

@jacobt13: If your jailbreak was in a sane state before the OTA update, all might not be lost. Try this.

(And, yes, FWIW, that's a question better suited for the JailBreak thread ).

Sorry for putting it in the wrong thread - I wasn't sure where it would be best!

Unfortunately, since I first uninstalled - thinking it was a glitch on my end, even though it was working before it updated, this won't work for me. I am so angry at myself for letting it happen... and Amazon, too! I just want to use a better font than the ones they offer and they make it so complicated! Grrrr! Anyway, thanks for the quick response. I will just be patient!

[NiLuJe]

@jacobt13: Uninstalled what, exactly? Because if you only uninstalled the JailBreak/MKK, provided you haven't done a factory reset, you should still be able to use this .

(My uninstallers tend to be on the conservative side of things, because uninstalling stuff is usually overkill anyway ^^).