MobileRead Forums - View Single Post - Glo Memory Upgrade Mod Guide (With Pictures)

Peter_Cordes · 06-30-2024, 07:24 AM

Since nobody's mentioned this, if you're using a Linux desktop it's very simple: write the firmware .img to the raw device file for your MicroSD card. e.g. with
sudo dd bs=64k if=foo.img of=/dev/XYZ
or
cat foo.img > /dev/XYZ

Both require root, dd can be used with sudo since dd opens the output file. cat with a redirect can't, since the user shell would be trying to do the redirect before sudo runs.

I used this command to extract the zip straight to the microSD block device. (In a root shell from sudo -s, although I could have just used sudo on the dd part of this pipeline)

7z x -so Kobo_N249_Clara_HD_4_38_21908.zip | dd status=progress bs=64k of=/dev/sdXYZ

where /dev/sdXYZ was actually /dev/sdf, my microSD card in a USB adapter. Using a placeholder device filename to protect from overwriting the wrong device with a copy/paste. Make doubly sure you have the right device (check lsblk, and/or dmesg to make sure it's the USB device you just inserted, and run mount to make sure it didn't get automatically mounted).

I only used dd to get a progress indicator (which doesn't include the kernel's write buffers, so it will start fast then slow down as the buffer fills and it has to wait for the actual hardware. A tool like vmstat or iostat -x 5 or dool -D nvme0n1,sda,sdb,sdc,...,sdf 5 will show you actual device read/write MB/s.

I could have just redirected stdout of 7-zip into the device file. (The -so option tells it to extract to standard output)

The image is a full-disk image with a partition table, thus we write it to the whole device, not to a partition. (And not as a regular file into an existing filesystem.) In Windows you need special software for that; in Unix (macOS and Linux) the raw device is accessible as a file in /dev.

You can then use gparted /dev/sdf and use the GUI to resize the FAT32 partition to extend out to the end of the device so you can use all the space. Or apparently factory-reset will do that, too.

update: on my Kobo Clara HD, it locked up very soon after doing the initial setup with the FAT32 partition resized to fill the 32GiB microSD. (With the same failure screen as when the original microSD died).

Re-imaging the original 8GiB image onto it, it seems to be working. Using factory reset from the menu didn't grow the partition to fill the card like some users reported it would, maybe that's only a thing with the firmware for some other models. (The original card that came with the device is 16GiB. I don't know how it was partitioned before it died. Possibly it only used the first 8, as over-provisioning to make the wear-leveling in the microSD controller more efficient, or maybe the firmware image I was sent is different from what was originally on this device. For library books, we don't need a lot of storage so I'm just leaving it at 8G, not trying to grow the partition up to 16. It seems to be working, not locking up at the point it did before.)

----

Feel free to copy/paste this post into a section of one of the main posts for the benefit of Linux users.

(reposted with edits since there seems to be a deadline for editing my previous post? And I don't see a delete button on it.)

06-30-2024, 07:24 AM	#320
Peter_Cordes Junior Member Posts: 3 Karma: 10 Join Date: Jun 2024 Device: Kobo N249 Clara HD	Linux firmware image instructions Since nobody's mentioned this, if you're using a Linux desktop it's very simple: write the firmware .img to the raw device file for your MicroSD card. e.g. with sudo dd bs=64k if=foo.img of=/dev/XYZ or cat foo.img > /dev/XYZ Both require root, dd can be used with sudo since dd opens the output file. cat with a redirect can't, since the user shell would be trying to do the redirect before sudo runs. I used this command to extract the zip straight to the microSD block device. (In a root shell from sudo -s, although I could have just used sudo on the dd part of this pipeline) 7z x -so Kobo_N249_Clara_HD_4_38_21908.zip \| dd status=progress bs=64k of=/dev/sdXYZ where /dev/sdXYZ was actually /dev/sdf, my microSD card in a USB adapter. Using a placeholder device filename to protect from overwriting the wrong device with a copy/paste. Make doubly sure you have the right device (check lsblk, and/or dmesg to make sure it's the USB device you just inserted, and run mount to make sure it didn't get automatically mounted). I only used dd to get a progress indicator (which doesn't include the kernel's write buffers, so it will start fast then slow down as the buffer fills and it has to wait for the actual hardware. A tool like vmstat or iostat -x 5 or dool -D nvme0n1,sda,sdb,sdc,...,sdf 5 will show you actual device read/write MB/s. I could have just redirected stdout of 7-zip into the device file. (The -so option tells it to extract to standard output) The image is a full-disk image with a partition table, thus we write it to the whole device, not to a partition. (And not as a regular file into an existing filesystem.) In Windows you need special software for that; in Unix (macOS and Linux) the raw device is accessible as a file in /dev. You can then use gparted /dev/sdf and use the GUI to resize the FAT32 partition to extend out to the end of the device so you can use all the space. Or apparently factory-reset will do that, too. update: on my Kobo Clara HD, it locked up very soon after doing the initial setup with the FAT32 partition resized to fill the 32GiB microSD. (With the same failure screen as when the original microSD died). Re-imaging the original 8GiB image onto it, it seems to be working. Using factory reset from the menu didn't grow the partition to fill the card like some users reported it would, maybe that's only a thing with the firmware for some other models. (The original card that came with the device is 16GiB. I don't know how it was partitioned before it died. Possibly it only used the first 8, as over-provisioning to make the wear-leveling in the microSD controller more efficient, or maybe the firmware image I was sent is different from what was originally on this device. For library books, we don't need a lot of storage so I'm just leaving it at 8G, not trying to grow the partition up to 16. It seems to be working, not locking up at the point it did before.) ---- Feel free to copy/paste this post into a section of one of the main posts for the benefit of Linux users. (reposted with edits since there seems to be a deadline for editing my previous post? And I don't see a delete button on it.)