| 2021-08-15 19:14:10 |
Bill Yikes |
description |
I'm starting with a 2.5gb image of a TomTom device which was created using dd. There is no partition table, so the vfat filesystem begins on the very first sector.
$ dd if=/dev/sdd of=image_file_2.5gb.dd
This is a migration to a 4gb sd card. So I used fdisk to see the full size of the target media, and allocated a file to match:
$ fallocate -l 4008706048 image_file_4gb.img
Copied the contents bit-for-bit:
$ dd if=image_file_2.5gb.dd of=image_file_4gb.img conv=notrunc
Finally the vfat filesystem thereon must be stretched:
$ fatresize -s max image_file_4gb.img
fatresize 1.1.0 (20201114)
part(start=0, end=7829503, length=7829504)
Segmentation fault
It resembles this bug:
https://github.com/ya-mouse/fatresize/issues/6
but that bug was supposedly fixed 3 yrs prior to version 1.1.0. |
I'm starting with a 2.5gb image of a TomTom device which was created using dd. There is no partition table, so the vfat filesystem begins on the very first sector.
$ dd if=/dev/sdd of=image_file_2.5gb.dd
This is a migration to a 4gb sd card. So I used fdisk to see the full size of the target media, and allocated a file to match:
$ fallocate -l 4008706048 image_file_4gb.img
Copied the contents bit-for-bit:
$ dd if=image_file_2.5gb.dd of=image_file_4gb.img conv=notrunc
Finally the vfat filesystem thereon must be stretched:
$ fatresize -s max image_file_4gb.img
fatresize 1.1.0 (20201114)
part(start=0, end=7829503, length=7829504)
Segmentation fault
It resembles this bug:
https://github.com/ya-mouse/fatresize/issues/6
but that bug was supposedly fixed 3 yrs prior to version 1.1.0.
Workaround:
It's worth noting that the segfault can be avoided if the smaller image is copied to a larger SD card, and “fatresize -s max” is run on the unmounted device (e.g. /dev/sdd). |
|
| 2021-08-15 19:14:42 |
Bill Yikes |
description |
I'm starting with a 2.5gb image of a TomTom device which was created using dd. There is no partition table, so the vfat filesystem begins on the very first sector.
$ dd if=/dev/sdd of=image_file_2.5gb.dd
This is a migration to a 4gb sd card. So I used fdisk to see the full size of the target media, and allocated a file to match:
$ fallocate -l 4008706048 image_file_4gb.img
Copied the contents bit-for-bit:
$ dd if=image_file_2.5gb.dd of=image_file_4gb.img conv=notrunc
Finally the vfat filesystem thereon must be stretched:
$ fatresize -s max image_file_4gb.img
fatresize 1.1.0 (20201114)
part(start=0, end=7829503, length=7829504)
Segmentation fault
It resembles this bug:
https://github.com/ya-mouse/fatresize/issues/6
but that bug was supposedly fixed 3 yrs prior to version 1.1.0.
Workaround:
It's worth noting that the segfault can be avoided if the smaller image is copied to a larger SD card, and “fatresize -s max” is run on the unmounted device (e.g. /dev/sdd). |
I'm starting with a 2.5gb image of a TomTom device which was created using dd. There is no partition table, so the vfat filesystem begins on the very first sector.
$ dd if=/dev/sdd of=image_file_2.5gb.dd
This is a migration to a 4gb sd card. So I used fdisk to see the full size of the target media, and allocated a file to match:
$ fallocate -l 4008706048 image_file_4gb.img
Copied the contents bit-for-bit:
$ dd if=image_file_2.5gb.dd of=image_file_4gb.img conv=notrunc
Finally the vfat filesystem thereon must be stretched:
$ fatresize -s max image_file_4gb.img
fatresize 1.1.0 (20201114)
part(start=0, end=7829503, length=7829504)
Segmentation fault
It resembles this bug:
https://github.com/ya-mouse/fatresize/issues/6
but that bug was supposedly fixed 3 yrs prior to version 1.1.0.
Workaround:
It's worth noting that the segfault can be avoided if the smaller image is copied to a larger SD card, and “fatresize -s max” is run on the unmounted device (e.g. /dev/sdd) instead of running it on an image file. |
|
