[M2][Medium] Format micro card as 8GB at least, enlarge fat partition(10/5)

[droneboost]

• Background The 6GB edition of rootfs image doesn't have correct volume size with linux "df" command and window resource explorer.
• TODOs Fix "firmware" partition size.
• Outputs bithollow/tools/mksd6.sh

[droneboost]

I've create tools/mksd6.sh for creating 6GB rootfs image with two partitions as below: firmware: 2GB - 1MB root: 4GB - 1MB

Sector Size = 512, Block Size = 1024

[onceme]

Why 6 not 8?

[droneboost]

An 8G SD card or USB Disc don't have actual 8*1023^3 bytes space.

[onceme]

Not even 7?

[droneboost]

7.5GB in usual case, for the sake of safe, I set the rootfs image size to 6GB.

[droneboost]

The 6G image include kernel 4.1.5 + latest Debian jessie rootfs works well, i'd like to close this issue.

[onceme]

Good.

[droneboost]

Close it.

[onceme]

I tried mksd6.sh, seems the partition size of root and firmware are incorrect.

bit@bithollow:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.9G  518M  3.1G  15% /
devtmpfs        483M     0  483M   0% /dev
tmpfs           487M     0  487M   0% /dev/shm
tmpfs           487M   13M  474M   3% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           487M     0  487M   0% /sys/fs/cgroup
/dev/mmcblk0p1  6.0G  112M  5.9G   2% /boot/firmware

[droneboost]

root@bithollow:/home/bit# fdisk /dev/mmcblk0
Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/mmcblk0: 7.4 GiB, 7948206080 bytes, 15523840 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device         Boot   Start      End Sectors Size Id Type
/dev/mmcblk0p1         2048  4194303 4192256   2G  c W95 FAT32 (LBA)
/dev/mmcblk0p2      4194304 12582911 8388608   4G 83 Linux

[onceme]

Have you checked your 'df -h'? How do you explain that?

[droneboost]

'df -h' result on my board is same as your's. Still not quite sure why this happen. Under checking.

[droneboost]

Seems we didn't zero the first sector of the first fat32 partition in mksdX.sh.

''' The bottom line is that if you use sfdisk to change the size of a DOS partition table entry, then you must also use dd to zero the first 512 bytes of that partition before using DOS FORMAT to format the partition. For example, if you were using sfdisk to make a DOS partition table entry for /dev/hda1, then (after exiting sfdisk and rebooting Linux so that the partition table information is valid) you would use the command "dd if=/dev/zero of=/dev/hda1 bs=512 count=1" to zero the first 512 bytes of the partition. '''

[droneboost]

df -h on 2G rootfs image with kernel 3.18:

root@bithollow:/home/bit# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       1.8G  1.2G  447M  74% /
devtmpfs        483M     0  483M   0% /dev
tmpfs           488M     0  488M   0% /dev/shm
tmpfs           488M  6.5M  481M   2% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           488M     0  488M   0% /sys/fs/cgroup
/dev/mmcblk0p1  1.9G   14M  1.9G   1% /boot/firmware
tmpfs            98M     0   98M   0% /run/user/1000

[droneboost]

estimate 3 days to fix this issue.

[droneboost]

finally, solved this problem by add "--sizelimit" to losetup e.g. sudo losetup /dev/$LOOP_DEV rpi.img -o $((2048_512)) --sizelimit $((4194304_512))

[droneboost]

The reason of "apt-get clean" or "rm" can not reduce rootfs image is that "rm" only mark the link count of the file's inode down to 0, and leave the block data on the disk as it was, it doesn't do the sort of block bits reset to zero operation, that's why some file recover tools can restore deleted file.. Once you add some file or install some software to the rootfs, you inflate the rootfs. (I do remember there is some sort of image deflate tool in VMWare) Meanwhile bzip2 take the rootfs image file as an ordinary file, it is no-sensible of file delete inside the rootfs, so currently, the practical way to make a minimized rootfs image is by adding necessary software components but not by removing unnecessary ones.