You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background - I am using the pidock repo to create a raspi image that has a variety of development tools pre-installed. I came across the problem below during this process. Overall, I am very thankful that you put these scripts together. Even as part of debugging the issue I found, I learned quite a bit.
Please let me know if the proposed solution is acceptable and if I may push it to your repo on a branch. I would rather have it go to your mainline then to create yet another fork of your work.
Problem
When using the CUSTOM_IMG_SIZE option, the maximum image size is still limited by the size of the "source" image (raspbian.img). If subsequently the Dockerfile is used to install enough applications to exceed the "source" image size, the compose.sh step ends up failing with a "No space left on device" error during the step "sudo tar xf custom-root.tar -C /mnt --numeric-owner"
Root cause
The compose.sh step "sfdisk ${CUSTOM_IMG_NAME} < "${PT_FILENAME}" transfers the partition sizing from the "source" image to the destination. This means that even though the destination may have 4GB reserved by default, the new destination partition will be the size of the source partition, with free space left over.
Solution
Immediately after creating the two partitions from the partition_table.txt file, invoke sfdisk to expand partition 2 to use all available space on the destination image. The command to do this is
echo ", +" | sfdisk custom.img -N 2
where ", +" tells sfdisk that the second (partition size) argument "+" it is looking for as input should increase partition size to capacity. Alternately a number can be added to increase the partition by a specific size, but that seems unnecessary here.
Example output:
dd if=/dev/zero of=./custom.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 6.59568 s, 651 MB/s
+ sfdisk custom.img
Checking that no-one is using this disk right now ... OK
Disk custom.img: 4 GiB, 4294967296 bytes, 8388608 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
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0x43f6ece2.
custom.img1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 256 MiB.
custom.img2: Created a new partition 2 of type 'Linux' and of size 1.5 GiB.
custom.img3: Done.
New situation:
Disklabel type: dos
Disk identifier: 0x43f6ece2
Device Boot Start End Sectors Size Id Type
custom.img1 8192 532479 524288 256M c W95 FAT32 (LBA)
custom.img2 532480 3686399 3153920 1.5G 83 Linux
The partition table has been altered.
Syncing disks.
+ echo ', +'
+ sfdisk custom.img -N 2
Checking that no-one is using this disk right now ... OK
Disk custom.img: 4 GiB, 4294967296 bytes, 8388608 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: 0x43f6ece2
Old situation:
Device Boot Start End Sectors Size Id Type
custom.img1 8192 532479 524288 256M c W95 FAT32 (LBA)
custom.img2 532480 3686399 3153920 1.5G 83 Linux
custom.img2:
New situation:
Disklabel type: dos
Disk identifier: 0x43f6ece2
Device Boot Start End Sectors Size Id Type
custom.img1 8192 532479 524288 256M c W95 FAT32 (LBA)
custom.img2 532480 8388607 7856128 3.7G 83 Linux
The partition table has been altered.
Syncing disks.
Testing
Verified that with the addition of this command, a destination image is created which has more used disk space than the source image.
The text was updated successfully, but these errors were encountered:
Thanks for addressing this and taking the time to upstream it. It was clunky about partition vs image sizes and this is a good fix. Push what you want and I'll merge
Background - I am using the pidock repo to create a raspi image that has a variety of development tools pre-installed. I came across the problem below during this process. Overall, I am very thankful that you put these scripts together. Even as part of debugging the issue I found, I learned quite a bit.
Please let me know if the proposed solution is acceptable and if I may push it to your repo on a branch. I would rather have it go to your mainline then to create yet another fork of your work.
Problem
When using the CUSTOM_IMG_SIZE option, the maximum image size is still limited by the size of the "source" image (raspbian.img). If subsequently the Dockerfile is used to install enough applications to exceed the "source" image size, the compose.sh step ends up failing with a "No space left on device" error during the step "sudo tar xf custom-root.tar -C /mnt --numeric-owner"
Root cause
The compose.sh step "sfdisk ${CUSTOM_IMG_NAME} < "${PT_FILENAME}" transfers the partition sizing from the "source" image to the destination. This means that even though the destination may have 4GB reserved by default, the new destination partition will be the size of the source partition, with free space left over.
Solution
Immediately after creating the two partitions from the partition_table.txt file, invoke sfdisk to expand partition 2 to use all available space on the destination image. The command to do this is
where ", +" tells sfdisk that the second (partition size) argument "+" it is looking for as input should increase partition size to capacity. Alternately a number can be added to increase the partition by a specific size, but that seems unnecessary here.
Example output:
Testing
Verified that with the addition of this command, a destination image is created which has more used disk space than the source image.
The text was updated successfully, but these errors were encountered: