We are trying to resize (shrink) the second partition (/dev/mmcblk0p2) on a live system from init ram file system (Initramfs and tmpfs). We succeeded to include the following tools in the init-ram-filesystem “parted e2fsprogs e2fsprogs-resize2fs e2fsprogs-tune2fs e2fsprogs-mke2fs”.
When running resize2fs in the init ram file system we only got segmentation faults any ideas why this is not working ? has this got something to do with a possible incorrect /etc/mtab files or is something special configured in the normal image to extend the partition initial
You’re a bit brief here. You’re also left out what version of SW and HW you’re using, so following some thoughts triggered by what I guess you’re asking.
The update.sh script creates a root file system which is a little bit larger than the sum of what is copied into it.
Upon first boot a systemd service enlarges this to the full partition size of the partition it lives in with resize2fs (or to the full size of the blockdevice if the partition size in the mbr exceeds the size of the actual block device) . Once that is achieved the service is disabled.
Why do you want to shrink the partition? Have a look at the update.sh script which does the partitioning. You could set the second partition to the correct size before writing it to the module.
The Toradex Easy Installer also allows to partition your system through configuration from the PC side.
Having said that I don’t see why that should not be working. I believe that the mbr is correct, e.g. the partition fit on the eMMC. If that is not the case maybe there could be one of the problems.
What do you mean by segmentation faults? Do the tools you call in the system booted with the initramfs segfault, or, when you reboot with the resized partition as the rootfs you get segfaults?
What exact commands did you execute, with what output?
We are getting the segmentation fault errors inside the initram fs system when we are running resize2fs. We are running with image v2.7.0 b1 generated init ram fs on a v2.6.0 b1 image on Colibri imx6 dual lite.
We are trying the init ram fs system because we want to create an extra partition where we can store the firmware for future updates. We updated live systems in the field from sd card and U-boot scripting but this gave us mixed results.
The Toradex easy installer would also be an option for us but, we are not able to remote get our modules into recovery mode. Is it possible to install the Tezi enviroment remote on the sd card or anything and configure U-boot to boot this?
You probably could mount a SD card, download Tezi to it, change U-Boot environment to boot into it (using fw_setenv) and let Tezi do the work. However, Tezi is inside a FIT image, which older U-Boot versions do not support. Also this is really a use-case which we did not design Tezi for… Hence I generally would not recommend doing this. Tezi is really meant for a first time installation. And in this use-case scenario you can easily configure the partition layout in the image.json file. However, since you try to re-partition modules in field, Tezi is not really helpful.
In the end, the approach you are taking is not that far from what Tezi is doing: Running from a initramfs to modify the real rootfs… I guess if you really need to preserve the content on the root file system, there is no way around figuring out what makes resize2fs to crash.
What version of resize2fs are you using? Maybe it is this bug?
Im currently thinking that problems is related to the way we deployed resize2fs using yocto. We changed the following recipe (/docker-workspace/git/toradex-rimotemanager-docker/data/oe-core/layers/meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-debug-image.bb)
I tried this by NFS booting with our V2.7 image and installing parted from the angstrom feeds.
One try was successful, one ended also in a segmentation fault, e.g.:
root@colibri-imx6:~# umount /dev/mmcblk0p2
root@colibri-imx6:~# fsck.ext3 /dev/mmcblk0p2
e2fsck 1.43 (17-May-2016)
rootfs contains a file system with errors, check forced.
...
rootfs: 23117/192640 files (2.7% non-contiguous), 127020/885760 blocks
root@colibri-imx6:~# resize2fs /dev/mmcblk0p2 900M
resize2fs 1.43 (17-May-2016)
Resizing the filesystem on /dev/mmcblk0p2 to 230400 (4k) blocks.
Segmentation fault (core dumped)
After upgrading to e2fsprogs 1.43.4 in openembedded-core which includes the patch Stefan referenced the resizing worked. e.g:
root@colibri-imx6:~# umount /dev/mmcblk0p2
root@colibri-imx6:~# e2fsck -f /dev/mmcblk0p2
e2fsck 1.43 (17-May-2016)
...
rootfs: 23117/192640 files (2.7% non-contiguous), 127020/885760 blocks
root@colibri-imx6:~# resize2fs /dev/mmcblk0p2 900M
resize2fs 1.43.3 (04-Sep-2016)
Resizing the filesystem on /dev/mmcblk0p2 to 230400 (4k) blocks.
The filesystem on /dev/mmcblk0p2 is now 230400 (4k) blocks long.
root@colibri-imx6:~# parted /dev/mmcblk0
GNU Parted 3.2
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: MMC 004GE0 (sd/mmc)
Disk /dev/mmcblk0: 3959MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 4194kB 21.0MB 16.8MB primary fat16 lba
2 21.0MB 3649MB 3628MB primary ext3
(parted) resizepart 2 1200MB
Warning: Shrinking a partition can cause data loss, are you sure you want to
continue?
Yes/No? Yes
(parted) mkpart p ext3 1200MB 3800MB
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? i
(parted) print
Model: MMC 004GE0 (sd/mmc)
Disk /dev/mmcblk0: 3959MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 4194kB 21.0MB 16.8MB primary fat16 lba
2 21.0MB 1200MB 1179MB primary ext3
3 1200MB 3800MB 2600MB primary ext3 lba
(parted) q
Information: You may need to update /etc/fstab.
root@colibri-imx6:~# mkfs.ext3 /dev/mmcblk0p3
mke2fs 1.43 (17-May-2016)
/dev/mmcblk0p3 contains `zlib compressed data' data
Proceed anyway? (y,n) y
Discarding device blocks: done
Creating filesystem with 634765 4k blocks and 158720 inodes
Filesystem UUID: 494e2c56-cbd6-4c7b-8ded-88d7ae4e92c8
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
root@colibri-imx6:~#
Not sure what you exactly mean with static compilation, OE uses dynamic compilation by default and makes sure that all library/dependencies get built & deployed too. Max’ answer with cherry-picking the fixes into your openembedded-core layer should do it.