The TinyCoreLinux project for the Raspberry Pi is called piCore Linux and suits my requirements very well. So I want to use it. Therefore I need to "remaster" the image file and add further files.

When I download the current release I get a zip archive with the file piCore-7.0.img which can be directly burned to a SD card and used. Works fine.

But how to remaster the piCore-7.0.img file, add new files & scripts and create a new image file, ready to be burned to a SD card?

I looked around the web but most tutorials are really dated or deal with ISO images of TinyCoreLinux.

I tried the method suggested here, and in this case fdisk says:

$ fdisk -l piCore-7.0.img
Disk piCore-7.0.img: 47 MB, 47676928 bytes
Units = sectors of 1 * 512 = 512 bytes
         Device Boot      Start         End      Blocks   Id  System
piCore-7.0.img1            8192       69631       30720    c  W95 FAT32 (LBA)
piCore-7.0.img2           69648       93119       11736   83  Linux

Therefore the boot partition should be mountable using mount -v -o offset=4194304 -t vfat piCore-7.0.img tmp/. But when I try to mount the rootfs using mount -v -o offset=35659776 -t ext4 piCore-7.0.img tmp2/ I get an error:

mount: enabling autoclear loopdev flag
mount: going to use the loop device /dev/loop1
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
  • add them to your running system and then make a new disk image. Aug 31, 2016 at 11:52

2 Answers 2


Its quite simple to modify raspberry pi image files. The only requirement is a linux box and qemu-arm-static if you wish to run commands within the context of the image (aka in a chroot). The basic steps are:

Loopback mount the image:

sudo losetup --find --show "piCore-0.7.img"
> /dev/loop0

Mount the loopback devices partition, most pi images have two partitions, boot and the root but your might vary.

sudo mount /dev/loop0p2 /mnt
sudo mount /dev/loop0p1 /mnt/boot

From here you can add/delete/modify any file in /mnt and it will change in the .img file. Once you are done simply unmount and detach the loop back (see below).

If you need to run a command inside the image then you can chroot into it. For this you need qemu-arm-static to emulate an arm cpu and allow you to run arm binaries once inside a chroot. Assuming you have it installed:

sudo mount -t proc none /mnt/proc
sudo mount -t sysfs none /mnt/sys
sudo mount -o bind /dev /mnt/dev

sudo mv /mnt/etc/resolv.conf /mnt/etc/resolv.conf.bak
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin/

sudo chroot /mnt /usr/bin/bash

From here you can run any command to manipulate the image. Once finished setting it up how you want exit the chroot and do some cleanup:

sudo rm /mnt/etc/resolv.conf
sudo mv /mnt/etc/resolv.conf.bak /mnt/etc/resolv.conf
sudo rm /mnt/usr/bin/qemu-arm-static

sudo umount /mnt/dev
sudo umount /mnt/proc
sudo umount /mnt/sys

sudo umount /mnt/boot
sudo umount /mnt
sudo losetup --detach "/dev/loop0"

You can find these steps and more details in my blog post about doing this with archlinux arm images. The process is very similar for any raspberry pi distro.

Note that you can mount the image directly, but with losetup you do not need to worry about offsets and various other things. It also allows you to manipulate the partitions/filesystem should you wish to.

  • Really nice explanation, but after the losetup step in /dev I only have loop0 and not (as expected) loop0p1 ... etc. You might download the image here and try it yourself.
    – mythbu
    Aug 31, 2016 at 14:07
  • mythbu's right; this methodology is not substantially different from the one at the end of the question. The download is only 35 MB BTW but you may want to have a look at my answer first.
    – goldilocks
    Aug 31, 2016 at 14:10

The issue is that the partition table lists the second partition's size as exceeding the end of the image. The first clue about this is the error in dmesg when trying the mount:

EXT4-fs (loop0): bad geometry: block count 11736 exceeds size of device (11735 blocks)

Blocks here are 1 KiB, so this number squares with the sector count I get from fdisk -l on piCore-7.0.img:

Device          Boot Start   End Sectors  Size Id Type
piCore-7.0.img1       8192 69631   61440   30M  c W95 FAT32 (LBA)
piCore-7.0.img2      69648 93119   23472 11.5M 83 Linux

Since 23472 / 2 = 11736. The total space here should be:

(8191 + 61440 + 17 + 823472) * 512 = 47677440

The 17 is for the gap between the partitions (look at the start and end sectors in the table). The image, however, is only 47676928 bytes (presumably the actual filesystem is smaller than the partition, so this is a trivial discrepancy that will not matter if you are writing it onto a larger SD card).

47677440 - 47676928 = 512

If we add the MBR (512 bytes) to this, that's a 1 KiB block, matching the "bad geometry" error. Somebody at tiny core needs a calculator ;)

So I tried this to pad the image size, and subsequently the mount worked:

dd if=/dev/zero of=zero bs=512 count=4000

Creates two MiB of blank. Use more if this still doesn't work. You can probably combine that command with the next one but for simplicity:

cat zero >> piCore-7.0.img

Note the >> to add to the end, not overwrite. Now this will succeed:

mount -rv -o offset=35659776 piCore-7.0.img whatever_directory

You don't actually need the fs type here.

However, you may (or may not) be disappointed with what's inside -- because tiny core is busybox based, I believe the runtime root fs is in a .tgz file there, but I am not a busybox user, so that's as far as I go. Likely if you start digging around you'll figure it out, and again, you are modifying the image with it mounted like this.

  • @mythbu I re-wrote this a bit after realizing the image file is smaller than the partition table says it should be (missed the 17 block pad initially). So my "somebody at tiny core needs a calculator" comment is sort of serious, you may want to report this as a bug -- they did not shave a KB off the image for any practical reason, it's a mistake.
    – goldilocks
    Aug 31, 2016 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.