Can you create a micro SD card image without taking apart your Kobo?

[karl19981]

Hi everyone,

The title summarizes my question. I am curious if anyone has tried creating a micro SD image without the need to take apart your Kobo e-reader, extract the micro SD card, then plug the micro SD card into an SD card reader which plugs into your PC. Instead of going through that hassle, is it possible to create an SD card image through USB and then run the image creation software from there? I understand that micro SD images are available via request in a separate thread, I would like to backup the mods and configs that I do to my future Kobo without having to take it apart each time. I currently have no functioning Kobo to work with currently.

Thank you for your time.

[DNSB]

Only the FAT32 partition is accessible through the USB connection. The two ext4 partitions and the free space are not able to be accessed and copied using a USB connection.

[PeterT]

I know a LONG TIME ago a post was made about a backup of the internal card via netcat.

Take a look at https://www.mobileread.com/forums/sh...&postcount=338

Sent from my Pixel 7a using Tapatalk

[Cootey]

Originally Posted by PeterT

I know a LONG TIME ago a post was made about a backup of the internal card via netcat.

Take a look at https://www.mobileread.com/forums/sh...&postcount=338

Sent from my Pixel 7a using Tapatalk

I can’t wait to try this! Do you know what format that .dat file was that he created? I wonder if dd will work through netcat instead. That will make a mountable disk image.

[Cootey]

TL;DR I’m afraid those steps don’t work anymore. They are nine years out of date.

Details below:

Spoiler:

The first problem is that most of the processes that are listed in those directions don’t exist anymore. The second problem is that, although the principle is to kill any process that accesses /mnt/onboard, there is only one process listed by ps in the modern firmware that does so: tcpsvd. Killing that process is easy. The problem is that something else is accessing that directory that refuses to let me unmount /mnt/onboard.

I ran “lsof +r2 | grep ‘/mnt/onboard’” to see which process was the culprit. It wasn’t good news.

Nickel is what has got its hooks into that directory. You can kill it, but after a few moments, the Kobo reboots. As expected.

I can successfully get netcat running a tunnel to the Kobo, but I can’t finish typing the command to start the backup in another terminal before the Kobo reboots.

As far as I understand, Nickel is the OS. I don’t think it’s possible to suspend nickel without causing the Kobo to crash.

Maybe somebody who knows more about Linux than I do can pipe up and give us their input, but it seems that the answer to the OP’s question is “no”.

[DNSB]

Looking at the instructions, it would seem that tshering was using KSM so nickel would not have been started. You may want to look at the koreader.sh or plato.sh startup scripts to see how they handle killing nickel, sickel, etc.

Plato:

killall -TERM nickel hindenburg sickel fickel adobehost foxitpdf iink dhcpcd-dbus dhcpcd fmon > /dev/null 2>&1

KOReader:

killall -q -TERM nickel hindenburg sickel fickel strickel fontickel adobehost foxitpdf iink dhcpcd-dbus dhcpcd bluealsa bluetoothd fmon nanoclock.lua

sickel needs to be killed since it will trigger when the device is not responding. I.e. when nickel has been killed.

[Cootey]

Originally Posted by DNSB

Looking at the instructions, it would seem that tshering was using KSM so nickel would not have been started. You may want to look at the koreader.sh or plato.sh startup scripts to see how they handle killing nickel, sickel, etc.

Thanks, David.

nickel sickel fickel strickel fontickel?

I love the naming structure. 😃

This is a realm of the Kobo underbelly that I haven’t delved into at all since I’ve never installed Plato or koreader. I was happy with the default reader. However, I’ve been frustrated that I can’t do a dd back up of my Elipsa, so this will be a worthwhile experiment.

[DNSB]

Originally Posted by Cootey

Thanks, David.

nickel sickel fickel strickel fontickel?

I love the naming structure. 😃

This is a realm of the Kobo underbelly that I haven’t delved into at all since I’ve never installed Plato or koreader. I was happy with the default reader. However, I’ve been frustrated that I can’t do a dd back up of my Elipsa, so this will be a worthwhile experiment.

My personal favourite is hindenburg. I just wonder how often the code crashed and burned before that name was applied.

[Aleron Ives]

Please document the process if you manage to get it working! I'd like to image my Libra 2, as well.

[PeterT]

Remember; it's kind of pointless having a backup unless there is a way to restore it!

[Aleron Ives]

The Libra 2 uses an SD card, so once you dissolve the waterproof coating, you can replace it. I don't remember whether the Elipsa is SD or eMMC.

[DNSB]

Originally Posted by Aleron Ives

The Libra 2 uses an SD card, so once you dissolve the waterproof coating, you can replace it. I don't remember whether the Elipsa is SD or eMMC.

The Elipsa and Elipsa 2E use eMMC storage. I've attached an image from the FCC documentation for the N605 Elipsa 2E.

[geek1011]

Just kill nickel and sickel, remount the partitions read-only over SSH ("mount -o remount,ro /" and the same for /mnt/onboard), then use something like "ssh root@kobo dd if=/dev/whatever | dd of=image.img", then reboot. You can also do it over telnet, but it's a little more complicated.

[Cootey]

Originally Posted by PeterT

Remember; it's kind of pointless having a backup unless there is a way to restore it!

🤔 Very true. For some reason I was thinking that if I can backup all the partitions this way, then I can restore them as well, but reading is very different from writing. But this may still be worthwhile pursuing.

The reason this thread excited me initially is because I’m hoping to find a way to restore that doesn’t cause my Elipsa to crash. Making a backup of the mounted drive is easy. However, only my microSD Kobos have allowed me to restore simply by copying the backup over the mounted drive’s contents. This doesn’t work well for the Elipsa.

I suspect the notation and notebook syncing with Kobo’s servers is the difference, not the lack of a microSD card. When you reset the firmware and log back into the Elipsa, the server synced files must have different auth keys (or something). Copying the old content over the new content can cause corruptions or a hard firmware reset.

Instead, I have to manually copy over the side loaded books, as well as the databases in .kobo. Using cp to restore would be so much faster, but dd would make an exact restoration.

[Cootey]

Originally Posted by geek1011

Just kill nickel and sickel, remount the partitions read-only over SSH ("mount -o remount,ro /" and the same for /mnt/onboard), then use something like "ssh root@kobo dd if=/dev/whatever | dd of=image.img", then reboot. You can also do it over telnet, but it's a little more complicated.

Thanks! I’ll give that a shot later tonight. I was only using Telnet bc of the posted steps from 2015.