Replacing/upgrading a Mini (or other internal) SD card with Linux

[bobobo1618]

Originally Posted by GeoffR

The main idea seems to be that class 6 and 10 cards have been optimised for large sequential read/write operations at the expense of small random read/writes, but much operating system performance depends on small random writes (such as updating the KoboReader sqlite database).

This comparison for example suggests that class 4 scandisk and silicon power cards are up to 100x faster than patriot class 10 cards for some small random write operations:

http://www.tomshardware.com/reviews/...e,3011-12.html

Originally Posted by GeoffR

The problem of course is that the Kobo probably has to do large sequential reads too, such as when opening a book or loading a cover image. I don't know whether the performance gain in those operations from using a class 10 card would make up for the slower random writes.

Well considering most of the random stuff is most likely asynchronous (the SQLite database will probably be in memory for reads and the Kobo won't wait for the database to be written to disk before it shows you stuff), but the sequential stuff is most likely not, I think I'll recommend going with a class 10 card... Most of the OS stuff will be 4K or over and the Class 10s are the same or better for just about everything there.

And looking at those benchmarks, avoid Kingston.

[murg]

Originally Posted by bobobo1618

the Kobo won't wait for the database to be written to disk before it shows you stuff

Don't be so sure. I don't think that the the Kobo is really a multi-tasking device. Yes, it looks like it does stuff during the idle cycles, but I think that when it is doing main line processing, like writing the database to the disk, it will wait until that operation is done before proceeding to the next.

Originally Posted by bobobo1618

avoid Kingston.

This is always good advice.

[bobobo1618]

Originally Posted by murg

Don't be so sure. I don't think that the the Kobo is really a multi-tasking device. Yes, it looks like it does stuff during the idle cycles, but I think that when it is doing main line processing, like writing the database to the disk, it will wait until that operation is done before proceeding to the next.

It's a Linux device. It supports multi-tasking fine.

As for whether SQLite is asynchronous or not, I can't really say whether or not the Kobo developers implemented it or not but it's quite possible that they did. Really depends on the library they used to write the software.

Honestly, it's unlikely. But it's possible and it'd be nice.

[ewphoenix123]

Quoting myself from another thread:

After doing a lot of research I stumbled over the following thread, listing benchmarks for a lot of microsdhc cards.

xda microsdhc testthread

The card currently in my Kobo is actually pretty good already, with it's 0,3 mb/s random write speed.
Many cards offer substantially worse results in that area, because they are developed for fast sequential r/w speeds, not random access, so chances are high you get a worse card performance wise, if you just pick a new one randomly based on a higher class.

The "Sandisk Mobile Ultra Class 10 UHS-1 microSDHC" line is apparently one of the better variants, with theoretical 4-5 times the access speed.
I ordered myself a 16gb variant (for 11€) and let you guys know if I notice any difference in reality after it arrived.

[GeoffR]

My Glo had a 2GB Sandisk unclassified card, I replaced it with an 8GB Sandisk class 4 card, using gparted to extend the KOBOeReader partition. Everything seems to work as before, no problems, no noticable speed difference. The Glo now reports 7044MB onboard storage. Thanks for the instructions :-)

[Didier]

Hello,
I have successfully extended internal memory of my Kobo GLO with a PNY micro SD / 32 Go, class 6. On the Glo there is no screw at all. Just carefully remove the back cover (not easy but possible with force and patience).

It may be obvious but the drive must be UNMOUNTED for gparted to work on it (if not, all right-clic options are greyed out).

I did a reset (not "reset to factory" option but with the little hole next to the usb port) and all is normal (before that the Kobo was not very responsive).

Total storage memory now : 29759 MB. Whoo !

Many thanks !

This thread deserve to be sticky.

[vugtitan]

Originally Posted by GeoffR

My Glo had a 2GB Sandisk unclassified card, I replaced it with an 8GB Sandisk class 4 card, using gparted to extend the KOBOeReader partition. Everything seems to work as before, no problems, no noticable speed difference. The Glo now reports 7044MB onboard storage. Thanks for the instructions :-)

was that using windows

i mean the article above is linux centric.

can it be done windows by disk imaging.then using gparted to partition and extend partitions?

very few people can understand command based linux.

[vugtitan]

Originally Posted by bobobo1618

You'll need either a full Linux installation or a live USB with at least 4GB of free space. Google "pendrivelinux" and the first result should be an entire site dedicated to telling you how to make a live USB. I recommend Ubuntu, it's easy for new people to use.

So, steps:

1. Open a terminal (if you're on Ubuntu, type terminal in the search box)
2. Plug in the internal SD card from the Kobo Mini
3. Type "sudo fdisk -l" (That's a lower case L for people with silly fonts)
4. You should see a ton of stuff, most importantly, each section should have a header like "Disk /dev/sda: 64.0 GB, 64023257088 bytes, 125045424 sectors". Look for one with "Disk /dev/sd[probably the highest letter]: [Size of your SD card]..." and note the letter, it's important.
5. If you're on a full blown installation, you're about to create a 4GB image of the card, so cd to somewhere useful. If you're on a LiveUSB, look through the results of "fdisk -l" for the /dev/sd[letter][number] that corresponds to a data partition on your hard drive (should be quite large and have a ton of blocks) and type "sudo mount /dev/sd[letter][number] (for example, /dev/sda1) /mnt" then type "cd /mnt".
6. Type "sudo dd if=/dev/sd[letter corresponding to your SD card] of=kobosd.img bs=4M" then wait a bit. It won't show any progress but it's copying 4GB of data from your card.
7. Eject the card from the kobo and insert the new card (of whatever size) and type "fdisk -l" again. Look for the letter again. It will possibly be the same letter that the Kobo SD had.
8. Type "sudo dd if=kobosd.img of=/dev/sd[new letter] bs=4M" and wait again. It'll probably be slower than last time since you're going to the card instead of from.
9. Type "sudo fdisk /dev/sd[new letter of SD"
10. Press "p" and the partitions should be printed. Make a note of the start value of the last partition and copy it or write it down somewhere. Also the number after "/dev/sd[letter", that's important too.
11. Type "d" and when prompted, enter the number you just chose.
12. Type "n" and when prompted for type, just hit enter. Then enter that number again. When it asks for a starting position, enter the start value from before. When it prompts for an end value, just hit enter, this should use the maximum available space.
13. Press "t", "3" then "b" and hit enter.
14. Type "w" then "q"

You're done! You can put the SD back in the Kobo Mini.

I've only tested this with my Mini and a 16GB Class 10 Patriot MicroSDHC card.

If you screw up during the whole fdisk thing, just hit q and start again. Nothing is modified on the disk until you press w.

To get the SD out of (and into) the Mini, all you need to do is pull off the back cover and unscrew the plastic cover behind that. The SD slot is rather obvious and easy to use.

EDIT: The resize method I listed above may have issues with the Kobo picking up the size of the new FS. Ignore the 'sudo fdisk' line and everything below it. Instead run 'sudo gparted' from the console (should be preinstalled on Ubuntu), then select '/dev/sdX' in the top right where 'sdX' is the same one you've been using the whole time. Then right click the bottom item (the label should be 'KOBOeReader' in the list that shows there and click 'resize/move', set 'free space (both before and after) to 0 then click 'resize/move'. Then just click Edit->Apply all operations. It'll give you a warning but that's fine. It's a much easier and technically superior way of doing things.

If you have done the instructions I already put there and find your Kobo isn't detecting the free space, you can put the SD back in, type 'sudo gparted', click the top right thing and select your card (the size should make it recognizable) then right click 'check' then Edit->Apply All Operations. The Kobo should pick it up after that.

that is way too complicated and is really for a linux specialist.

most people can't use command line.

nor can i.

we don't know linux at all or the commands which are very difficult to learn.


the question can windows be used with windows software like some kind of imaging program to image the sd card.

then use some software to expand the unallocated software.

using windows.

[tshering]

Originally Posted by vugtitan

was that using windows

i mean the article above is linux centric.

can it be done windows by disk imaging.then using gparted to partition and extend partitions?

very few people can understand command based linux.

Have a look at the Kobo Glo Memory Upgrade Guide (under windows). The instructions should be valid for the mini too, except how to open the case.

[PeterT]

Originally Posted by vugtitan

that is way too complicated and is really for a linux specialist.

most people can't use command line.

nor can i.

we don't know linux at all or the commands which are very difficult to learn.


the question can windows be used with windows software like some kind of imaging program to image the sd card.

then use some software to expand the unallocated software.

using windows.

But surely since this it's already a noon casual change you should expect to need a certain technical level before attempting it.

[DNSB]

Originally Posted by bobobo1618

This is pure speculation but going off the presence of the recovery partition, I'm guessing it'll copy that to the system partition and do a quick format of the main data partition (but hopefully leave the partition table (resized partition) intact).

In the case of the Glo, that is what happened when I tried a factory reset.

Originally Posted by bobobo1618

Speed is mainly an issue with the screen and CPU. The SD card won't be a bottleneck so won't really change anything unless possibly if you have huge books in which case a class 10 should go faster. Also booting up may go faster with a class 10 but I didn't really notice a huge difference.

When I was playing with the Glo, I found that selecting a uSD card with better small block writes made a very noticeable improvement in the speed of the device. Small block reads also seem to have a noticeable effect but the small block write speed is the one that varies horribly. I found that the SanDisk Class 4 cards gave me the best results.

Originally Posted by bobobo1618

By the way, Class 10 doesn't mean much. It should generally be faster than a lower class card but not in all cases. For example, a really good Class 6 can beat a really bad Class 10 in many areas.

Very often the Class 10 cards have done optimization for speed with large data blocks (writing 10MB on my digital camera). They seem to sacrifice small block speeds to obtain the better large block speeds.

Originally Posted by bobobo1618

Oh and I'm not sure where the idea that a lower class card should be used for the system card came from. Can you give me a link and/or the reasoning they used? I can't think of any good reason to suggest this.

EDIT: Oh and I didn't mention. I'm using a 16GB Patriot card in mine.

I'm one of the people mentioning the lower class cards as being better in some circumstances. This originally came out of a Nook related discussion where some people found their Nook booted from an SD card performed well and others complaining this made their Nook run slower than molasses running uphill in Tuktoyaktuk in January.

I've attached 3 images from various Crystal DiskMark tests I ran on microSD cards (Lexar Class 10, Patriot Class 10 and a SanDisk Class 4 all 8GB) using the internal card reader on my laptop. In my digital and video cameras, the two Class 10 cards worked well. In my Glo, they made it noticeably slower. I suspect this is due to the small block writes where the Class 4 SanDisk was 65 to 171 times faster. The similarity of the sequential read speeds is, I suspect, a limitation of the Ricoh chip used for the card reader.

Regards,
David

[davidfor]

Originally Posted by DNSB

In the case of the Glo, that is what happened when I tried a factory reset.

Since this thread started, I had the "luck" to need to do the investigation.

The factory reset runs "/etc/init.d/rcS". This:

- installs U-Boot and kernal using dd commands
- reformats the other two partitions
- unpacks "/upgrade/fs.tgz" to the rootfs
- unpacks "/upgrade/db.tgz" to the data partition

That is essentially what is done when the firmware is updated, minus the reformatting.

[DNSB]

Originally Posted by davidfor

Since this thread started, I had the "luck" to need to do the investigation.

The factory reset runs "/etc/init.d/rcS". This:

- installs U-Boot and kernal using dd commands
- reformats the other two partitions
- unpacks "/upgrade/fs.tgz" to the rootfs
- unpacks "/upgrade/db.tgz" to the data partition

That is essentially what is done when the firmware is updated, minus the reformatting.

What I'm having fun playing with now is updating the factory firmware. That is, instead of reverting to the version that was in the recovery partition when the device (Glo, in this case) was shipped, I wanted to have the factory reset revert to a later version.

Regards,
David

[davidfor]

Originally Posted by DNSB

What I'm having fun playing with now is updating the factory firmware. That is, instead of reverting to the version that was in the recovery partition when the device (Glo, in this case) was shipped, I wanted to have the factory reset revert to a later version.

I considered doing that. Replacing the files in the upgrade directory with the equivalents from a newer firmware package should work. The database is the only missing file. It should be somewhere in the firmware, but I can't think of where. If not, a logout and in with the desired firmware would should give you the file you want.

[DNSB]

Originally Posted by davidfor

I considered doing that. Replacing the files in the upgrade directory with the equivalents from a newer firmware package should work. The database is the only missing file. It should be somewhere in the firmware, but I can't think of where. If not, a logout and in with the desired firmware would should give you the file you want.

The database is the sticking point now. What I'm looking at is either your suggestion or a factory reset, firmware update and grabbing the database immediately after the update finishes. Having looked through multiple versions of the firmware, I've come to the conclusion that the copy in the recovery partition is the only copy around.

So far, I've managed to freeze my Glo several times but the last time, a pinhole reset and manual copy of the database got it working. At this time, I'm looking at how I'm creating the db.tgz and am booting an Ubuntu virtual machine to try from Linux rather than Windows.

Regards,
David