Return to Answer

The issue is that the partition table lists the second partition's size as exceeding the end of the image (which it does). 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.

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.

The issue is that the partition table lists the second partition's size as exceeding the end of the image (which it does). 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 (likely 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, which likely is the general case).

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.

The issue is that the partition table lists the second partition's size as exceeding the end of the image (which it does). 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.

The issue seems to be that mount or losetup sees the partition table as listing the second partition's size as exceeding the actual size 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 + 23472) * 512 = 47668736

I'm not sure if that includes the MBR, which is trivial (512 KiB), but the image is 47676928 bytes anyway.

I tried this though, and it 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.

The issue is that the partition table lists the second partition's size as exceeding the end of the image (which it does). 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 (likely 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, which likely is the general case).

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.