Resize partitions on live systems

Hi Support,

We are trying to resize (shrink) the second partition (/dev/mmcblk0p2) on a live system from init ram file system (http://developer.toradex.com/knowledge-base/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

Hi

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?

What is the output of

fdisk /dev/mmcblk0
   p
   q

Max

Hi Max,

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?

I check the version and we are using v1.4.3

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)

With the following content:

PACKAGE_INSTALL = “initramfs-debug busybox base-passwd parted e2fsprogs gdbserver e2fsprogs-resize2fs e2fsprogs-tune2fs e2fsprogs-mke2fs ${ROOTFS_BOOTSTRAP_INSTALL}”

I assume we need to cross compile the e2fs-progs outside oe with static compliation in order to get this to work?

Hi

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:

[layers/openembedded-core]$ git cherry-pick 8b9668c b51bb93

And rebuilding the image.

Then with NFS (or initramfs boot):

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:~# 

After a reboot with the rootfs from the eMMC:

root@colibri-imx6:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               891352    442844    434204  50% /
...
/dev/mmcblk0p1           16334      4942     11392  30% /media/mmcblk0p1
/dev/mmcblk0p3         2433636      3788   2302896   0% /media/mmcblk0p3
tmpfs                    50964         0     50964   0% /run/user/0

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.

I tested with Max his patch and your right Stefan it works like a charm now.
Thanks for the great and fast support.