Instructions for patching firmware 4.3.9084

[anacreon]

Originally Posted by dmapr

In the latest firmware versions the device remembers your last selection, so you choose once and it stays that way unless you change.

The problem is that now calling a dictionary is considered a selection, so when I want to look in my books or in the book I mostly have to choose from the list.

[baskerville]

Originally Posted by oren64

Only 4.3.8966.sh in Linux/Mac, it will make KoboRoot.tgz file, you might want to read instructions again in post #1.

No: the shell script runs $PATCH32LSB_BIN (one of the binaries in tools/).

Please notice the difference between:

$ zipinfo patch_kobo_4038966.zip
Archive:  patch_kobo_4038966.zip
Zip file size: 513518 bytes, number of entries: 19
drwxr-xr-x  3.0 unx        0 bx stor 17-Mar-17 13:32 patch_kobo_4038966/
-rwxr-xr-x  3.0 unx     1315 tx defN 17-Mar-17 13:30 patch_kobo_4038966/4.3.8966.sh
drwxr-xr-x  3.0 unx        0 bx stor 17-Mar-09 07:34 patch_kobo_4038966/4.3.8966_source/
-rw-r--r--  3.0 unx    62335 tx defN 17-Mar-17 15:56 patch_kobo_4038966/4.3.8966_source/libnickel.so.1.0.0.patch
-rw-r--r--  3.0 unx      343 tx defN 17-Mar-17 13:32 patch_kobo_4038966/4.3.8966_source/libadobe.so.patch
-rw-r--r--  3.0 unx    69771 tx defN 17-Mar-17 13:39 patch_kobo_4038966/4.3.8966_source/nickel.patch
-rw-r--r--  3.0 unx     6890 tx defN 17-Mar-17 13:34 patch_kobo_4038966/4.3.8966_source/librmsdk.so.1.0.0.patch
drwxr-xr-x  3.0 unx        0 bx stor 15-Jan-12 02:54 patch_kobo_4038966/tools/
-rwxr-xr-x  3.0 unx    17069 bx defN 15-Jan-05 11:25 patch_kobo_4038966/tools/patch32lsb-i386-Linux
drwxr-xr-x  3.0 unx        0 bx stor 14-Apr-28 07:30 patch_kobo_4038966/tools/7za920/
-rw-r--r--  3.0 unx     1254 tx defN 10-Nov-18 06:09 patch_kobo_4038966/tools/7za920/readme.txt
-rw-r--r--  3.0 unx    91020 bx defN 10-Nov-18 06:08 patch_kobo_4038966/tools/7za920/7-zip.chm
-rw-r--r--  3.0 unx     1162 tx defN 10-Mar-12 22:06 patch_kobo_4038966/tools/7za920/license.txt
-rw-r--r--  3.0 unx   587776 bx defN 10-Nov-18 06:27 patch_kobo_4038966/tools/7za920/7za.exe
-rwxr-xr-x  3.0 unx    51112 bx defN 15-Jan-12 02:06 patch_kobo_4038966/tools/patch32lsb-Darwin
-rwxr-xr-x  3.0 unx   121278 bx defN 15-Jan-05 11:25 patch_kobo_4038966/tools/pa32lsb.exe
-rwxr-xr-x  3.0 unx    20181 bx defN 15-Jan-05 11:25 patch_kobo_4038966/tools/patch32lsb-x86_64-Linux
-rw-r--r--  3.0 unx    20973 tx defN 15-Jan-05 11:25 patch_kobo_4038966/tools/patch32lsb.c
-rw-r--r--  3.0 unx     5061 tx defN 17-Mar-17 13:30 patch_kobo_4038966/4.3.8966.bat
19 files, 1057540 bytes uncompressed, 509540 bytes compressed:  51.8%

And:

$ zipinfo patch_kobo_4039084.zip
Archive:  patch_kobo_4039084.zip
Zip file size: 508399 bytes, number of entries: 19
drwx---     3.1 fat        0 bx stor 17-Apr-12 22:28 patch_kobo_4039084/
-rwxa--     3.1 fat     5061 bx defN 17-Apr-12 09:01 patch_kobo_4039084/4.3.9084.bat
-rw-a--     3.1 fat     1315 bx defN 17-Apr-12 18:34 patch_kobo_4039084/4.3.9084.sh
drwx---     3.1 fat        0 bx stor 17-Apr-12 22:28 patch_kobo_4039084/4.3.9084_source/
-rw-a--     3.1 fat      344 bx defN 17-Apr-12 18:29 patch_kobo_4039084/4.3.9084_source/libadobe.so.patch
-rw-a--     3.1 fat    51048 bx defN 17-Apr-12 22:26 patch_kobo_4039084/4.3.9084_source/libnickel.so.1.0.0.patch
-rw-a--     3.1 fat     6890 bx defN 17-Apr-12 18:30 patch_kobo_4039084/4.3.9084_source/librmsdk.so.1.0.0.patch
-rw-a--     3.1 fat    69771 bx defN 17-Apr-12 19:39 patch_kobo_4039084/4.3.9084_source/nickel.patch
drwx---     3.1 fat        0 bx stor 17-Apr-12 19:41 patch_kobo_4039084/tools/
drwx---     3.1 fat        0 bx stor 17-Apr-12 19:41 patch_kobo_4039084/tools/7za920/
-rw-a--     3.1 fat    91020 bx defN 10-Nov-18 18:08 patch_kobo_4039084/tools/7za920/7-zip.chm
-rwxa--     3.1 fat   587776 bx defN 10-Nov-18 18:27 patch_kobo_4039084/tools/7za920/7za.exe
-rw-a--     3.1 fat     1162 bx defN 10-Mar-13 10:06 patch_kobo_4039084/tools/7za920/license.txt
-rw-a--     3.1 fat     1254 bx defN 10-Nov-18 18:09 patch_kobo_4039084/tools/7za920/readme.txt
-rwxa--     3.1 fat   121278 bx defN 15-Jan-05 23:25 patch_kobo_4039084/tools/pa32lsb.exe
-rw-a--     3.1 fat    51112 bx defN 15-Jan-12 14:06 patch_kobo_4039084/tools/patch32lsb-Darwin
-rw-a--     3.1 fat    17069 bx defN 15-Jan-05 23:25 patch_kobo_4039084/tools/patch32lsb-i386-Linux
-rw-a--     3.1 fat    20181 bx defN 15-Jan-05 23:25 patch_kobo_4039084/tools/patch32lsb-x86_64-Linux
-rw-a--     3.1 fat    20973 bx defN 15-Jan-05 23:25 patch_kobo_4039084/tools/patch32lsb.c
19 files, 1046254 bytes uncompressed, 504725 bytes compressed:  51.8%

[oren64]

I don't have any experience with Linux/Mac so it hard to me to help you.

First I don't see you copy Kobo firmware 4.3.9084 "kobo-update-4.3.9084.zip" to 4.3.9084_source/ subdirectory.
Than you need to run /4.3.9084.sh from the command line.

[patrik]

Originally Posted by oren64

I don't have any experience with Linux/Mac so it hard to me to help you.

First I don't see you copy Kobo firmware 4.3.9084 "kobo-update-4.3.9084.zip" to 4.3.9084_source/ subdirectory.
Than you to run /4.3.9084.sh from the command line.

As provided that cannot be done, that's why you get this reaction.

For someone who knows *nix, there is no problem setting the execution bit, but having to do so, takes away any trust that whoever put this together knows what they were doing. If something as simple as this is wrong, what else...

As much as I/we appreciate you doing this while GeoffR is away, it's probably a good idea to make sure it's being done as correct as possible.

[jsonora]

4.3.9084.sh and tools/patch32lsb-* in the patch_kobo_4039084.zip don't have execute permission, so the command can't be run. Linux/Mac users need the execute bit set:

chmod +x 4.3.9084.sh tools/patch32lsb-*

[jackie_w]

Originally Posted by patrik

For someone who knows *nix, there is no problem setting the execution bit, but having to do so, takes away any trust that whoever put this together knows what they were doing. If something as simple as this is wrong, what else...

As much as I/we appreciate you doing this while GeoffR is away, it's probably a good idea to make sure it's being done as correct as possible.

What a despicable response to someone who was only trying to help out in unusual circumstances!

Many users visiting this thread will have neither knowledge of nor access to Linux/Mac. oren64 has freely admitted to being one of them. This is supposed to be a community forum where ideas/hacks are freely shared. Rather than jeering from the sidelines why don't you do something positive with your time? Perhaps you could make the necessary file permission corrections and share them. I'm sure oren64 will be happy to include them in the patch archive.

[patrik]

Originally Posted by jackie_w

What a despicable response to someone who was only trying to help out in unusual circumstances!

I'm glad you showed us how to not give a despicable response...

Many users visiting this thread will have neither knowledge of nor access to Linux/Mac. oren64 has freely admitted to being one of them. This is supposed to be a community forum where ideas/hacks are freely shared. Rather than jeering from the sidelines why don't you do something positive with your time? Perhaps you could make the necessary file permission corrections and share them. I'm sure oren64 will be happy to include them in the patch archive.

That's exactly my point. For those exact "many users" it may or may not work. Isn't that something to put attention on?

A lot of people here, me included, is very grateful for the patches and the enormous job GeoffR (and others) does making the patches available.

Since this is patching how the OS operates, there is always a risk involved. I'm sure we are many that want to minimize that and make sure as few people as possible risk to brick their devices.

Making sure the patch-package is as correct as possible is hopefully a good thing to minimize that risk. If someone is unsure about this, it is probably a good idea to ask for help and be very upfront with what they can and cannot do.
Information about linux/mac and potential problems would be useful in the very first post of this thread, of which I'm sure you agree.

We all want a nice unbricked device with working patches. It would be fantastic if Oren wants to help out when GeoffR is not available, I'm sure when he/she has talked about the details with GeoffR, he/she will do a great job in the future.


This is a great community and I'm very, very grateful for all the help I, and others, get here on a daily basis. We all learn, help others and develop. Learning from feedback is a needed skill to continue learning, whether it's about e-readers, language (please remember that we are many non-native english speakers here) or communication skills. I gave Oren feedback, you gave me feedback. I think you overreacted and was rude, but I will learn from it, thank you.

[Terisa de morgan]

Yes, but even not being an English native speaker, there's a difference between saying things as you have told instead of "There's a problem with the script, I can send you a patch, so the following people who gets it don't find it and a warning could be put in the first message about this problem".

And I'm not an English native speaker myself, so mistakes can be found.

[dmapr]

Originally Posted by anacreon

The problem is that now calling a dictionary is considered a selection, so when I want to look in my books or in the book I mostly have to choose from the list.

I'm not sure I understand. We were talking about the search on the home page, how does calling a dictionary affect that?

[oren64]

I didn't know there is a problem with Linux/Mac, maybe I should have ask someone to test it before I release it.

I don't know what causing the problem in Linux/Mac, so if someone want and help I will appreciate that, at the meantime it only work on Windows.

The only change I made is to 4.3.9084.sh file is "FIRMWARE_VERSION=4.3.9084", I didn't change the files in the tool folder.

[patrik]

Originally Posted by oren64

I didn't know there is a problem with Linux/Mac, maybe I should have ask someone to test it before I release it.

I don't know what causing the problem in Linux/Mac, so if someone want and help I will appreciate that, at the meantime it only work on Windows.

The only change I made is to 4.3.9084.sh file is "FIRMWARE_VERSION=4.3.9084", I didn't change the files in the tool folder.

Ok, I took your patch-file, unzipped, changed execution bits for the linux scripts, and zipped again. I have _not_ tested this on my kobo.

[PeterT]

Originally Posted by oren64

I didn't know there is a problem with Linux/Mac, maybe I should have ask someone to test it before I release it.

I don't know what causing the problem in Linux/Mac, so if someone want and help I will appreciate that, at the meantime it only work on Windows.

The only change I made is to 4.3.9084.sh file is "FIRMWARE_VERSION=4.3.9084", I didn't change the files in the tool folder.

Unlike Windows, Unix derived systems (such as linux and OSX) have a concept where files need to be "flagged" in order to be executable. This flagging is done by marking the file as executable, and is normally done by the command "chmod +x file_name".

If you look at the listings in

Originally Posted by baskerville

No: the shell script runs $PATCH32LSB_BIN (one of the binaries in tools/).

Please notice the difference between:

$ zipinfo patch_kobo_4038966.zip
Archive:  patch_kobo_4038966.zip
Zip file size: 513518 bytes, number of entries: 19
drwxr-xr-x  3.0 unx        0 bx stor 17-Mar-17 13:32 patch_kobo_4038966/
-rwxr-xr-x  3.0 unx     1315 tx defN 17-Mar-17 13:30 patch_kobo_4038966/4.3.8966.sh

And:

$ zipinfo patch_kobo_4039084.zip
Archive:  patch_kobo_4039084.zip
Zip file size: 508399 bytes, number of entries: 19
drwx---     3.1 fat        0 bx stor 17-Apr-12 22:28 patch_kobo_4039084/
-rwxa--     3.1 fat     5061 bx defN 17-Apr-12 09:01 patch_kobo_4039084/4.3.9084.bat
-rw-a--     3.1 fat     1315 bx defN 17-Apr-12 18:34 patch_kobo_4039084/4.3.9084.sh

you should see the differences.

[boriar]

But from within windows is imposible to change any file and not lose all unix flags

[PeterT]

Originally Posted by boriar

But from within windows is imposible to change any file and not lose all unix flags

Maybe; but in that case either ask for help or remve the unix portions unti someoe can correctly build it.

[Terisa de morgan]

Originally Posted by PeterT

Maybe; but in that case either ask for help or remve the unix portions unti someoe can correctly build it.

It looks like @patrik did it four messages above. And yes, unless you have cygwin in windows, you cannot make "chmod +x" over a file.