This is a cache of https://discuss.96boards.org/t/emmc-partition-not-getting-increased-beyond-3-1gb/1079. It is a snapshot of the page at 2024-10-31T04:48:21.704+0000.
[eMMC] Partition not getting increased beyond 3.1GB - DragonBoard410c - 96Boards Forum

[eMMC] Partition not getting increased beyond 3.1GB

Hi,

I am using the Linaro build rootfs - linaro-vivid-alip-qcom-eragon410-arm64.img.gz.

But, when I do a df -h, I am just seeing the partition size as:
/dev/disk/by-partlabel/rootfs 2.0G 1.2G 741M 63% /

I tried to run the resize-helper script, but with that, I am just getting the partition to increase to:
/dev/disk/by-partlabel/rootfs 3.1G 2.0G 1.2G 63% /

instead of 7.1G which is the available eMMC.

I flashed the updated gpt_both0.bin, but still I am seeing the same issue.

Please let me know if I need to change any thing to make use of the remaining eMMC.

Thanks,
Sunny

hi,

based on the information you provide , i am assuming you are not using an image ‘based’ on the linaro release, but not our release directly. You seem to be using the downstream images from eInfochips for Eragon 410c platform. And as the file name seem to indicate it is a very old version based on ubuntu Vivid. We have added support for automatically resizing the rootfs in the Linaro release in Feb 2016, and we already had switched to Debian at that time.

If the above is correct, please check with eInfochips directly on how to get their image updated to our latest release.

Hi ndec,

Thank you for the reply.

You are correct.

The latest images works correctly.

I just wanted to know, that is there any changes that I can do to use the old rootfs i.e. the ubuntu Vivid ?

I tried to update the gpt_both0.bin with the partition.xml having the rootfs size as 6000000 (in KB) and also tried to change the cmdline arguments to cmdline=“root=/dev/disk/by-partlabel/rootfs rw rootwait console=ttyMSM0,115200n8 blkdevparts=mmcblk0:6G(rootfs)” to the kernel, but neither of this works.

So was curious to know the reason.

Thanks,
Sunny

hey,

it is not a problem with the GPT which is probably correct. when flashing the GPT table it will fixup the size of the last partition to fit the entire space. So I suppose the partition size is correct if you check with gdisk tool on the board.

the main issue is with the file system itself and how it was generated. At the time this image was built we were using an android tool to create the rootfs image , not the standard linux mkfs tools. and we noticed that the android ‘mkfs’ tool had issues with ‘large’ sizes, and it would prevent the online resizing to work well. There are a bit more details in this commit message when we made the switch to the new tools:

https://git.linaro.org/ci/job/configs.git/commit/?id=7778af8510205652e855b2a2bd54ea31c2ffd04f

so if you really want to keep your image, you can, but you need to regenerate the rootfs image. Something along these lines should work (on your PC):

1. create the raw image with the original image from einfochips
simg2img <linaro-vivid-xxx.img> linaro-vivid.img

2. loop mount the raw img
mkdir rootfs
mount -o loop linaro-vivid.img ./rootfs

3. create a new rootfs image with the linux mkfs tools and with the content of the original image:
 
# the size can be small here, we will resize automatically on the first boot.
mkfs.ext4 -L rootfs linaro-vivid-new.img.raw 2G
mkdir rootfs2
mount -o loop  linaro-vivid-new.img.raw rootfs2
cp -a rootfs/* rootfs2

4. create the fastboot sparse image

ext2simg -v  linaro-vivid-new.img.raw  linaro-vivid-new.img

I just typed the command, so there could be a few typos/issues, but you get the idea. on debian/ubuntu you will need to install android-tools-fsutils package.

You can then flash into rootfs linaro-vivid-new.img and let it boot. then you can run the following script on the your board:

It will resize the rootfs to fill up the entire actual partition size. then df -h should report the maximum size…

If it works, please report it to einfochips, so that they properly document that somewhere…

note that the resize-helper script is there in our latest images, and it is executed automatically on first boot. You need to run it only once (per board) after flashing the rootfs image.

Hi ndec,

Thank you for your prompt reply.

I am trying your steps.

But the Step 3, mkfs.ext4 -L rootfs linaro-vivid-new.img.raw 2G
is not working.

I went through the man for mkfs.ext4, and re-arranged the arguments:
sudo mkfs.ext4 rootfs/ -L linaro-vivid-new.img.raw

but I am getting the below error:
mke2fs 1.42.9 (4-Feb-2014)
rootfs/ is not a block special device.
Proceed anyway? (y,n) y
mkfs.ext4: Device size reported to be zero. Invalid partition specified, or
partition table wasn’t reread after running fdisk, due to
a modified partition being busy and in use. You may need to reboot
to re-read your partition table.

I am trying to find a solution.

If you get a chance, then please do let me know.

Really appreciate your help though.

Thanks,
Sunny

the command I provided is working for me:

$ sudo mkfs.ext4 -L rootfs linaro-vivid-new.img.raw 2G
mke2fs 1.43.3 (04-Sep-2016)
Creating regular file linaro-vivid-new.img.raw
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: a2ad9355-b12f-4104-9a93-951b273452b5
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 

what did not work for you? You cannot change the order of args. -L is used to provide a name for the filesystem.

Hi ndec,

I am getting the below error:

sunny@linux:test$ sudo mkfs.ext4 -L rootfs linaro-vivid-new.img.raw 2G
mke2fs 1.42.9 (4-Feb-2014)
Could not stat linaro-vivid-new.img.raw — No such file or directory

The device apparently does not exist; did you specify it correctly?

Thanks,
Sunny

I am using ubuntu. Does it create a problem ?

I am able to see the rootfs mounted when I use the “mount” command.

Thanks,
Sunny

yes it is working fine for me. linaro-vivid-new.img.raw is a new file that the mkfs.ext4 tool will create. Are you sure that the file does not exist before you run the command?

the ‘-L rootfs’ in the command has nothing to do with the ‘rootfs’ folder actually. it is just a label. In fact you can remove ‘-L rootfs’, it’s optional anyway…

you can do it on ubuntu, it’s fine.

try this:

mkfs.ext4 -v foobar.img 2G

and if it doesn’t work, share the entire output.

Hi ndec,

Sorry, but it is still not working. I made the directory as testfs instead of rootfs, since I am already in the directory named rootfs.

Please see the below log:


sunny@linux:rootfs$ simg2img linaro-vivid-alip-qcom-eragon410-arm64.img linaro-vivid.img
sunny@linux:rootfs$ mkdir testfs
sunny@linux:rootfs$ sudo mount -o loop linaro-vivid.img ./testfs
sunny@linux:rootfs$ mkfs.ext4 -v foobar.img 2G
mke2fs 1.42.9 (4-Feb-2014)
Could not stat foobar.img --- No such file or directory

The device apparently does not exist; did you specify it correctly?
sunny@linux:rootfs$ ls
linaro-vivid-alip-qcom-eragon410-arm64.img  linaro-vivid.img  testfs
sunny@linux:rootfs$ ll
total 2631704
drwxrwxr-x  3 sunny sunny       4096 Dec  2 15:54 ./
drwxrwxr-x  3 sunny sunny       4096 Dec  2 15:32 ../
-rwxrwxr-x  1 sunny sunny 1344689424 Dec  2 12:36 linaro-vivid-alip-qcom-eragon410-arm64.img*
-rw-rw-r--  1 sunny sunny 2147483648 Dec  2 15:55 linaro-vivid.img
drwxr-xr-x 21 root  root        4096 Jan  1  1970 testfs/
sunny@linux:rootfs$ 

Thanks,
Sunny

ok… i figured it out… it’s because you are using an old version of mkfs tools. you can replace the mkfs command i put earlier with this set of commands:

sudo dd if=/dev/zero of=foobar.img bs=1M count=2048
sudo mkfs.ext4 -F -L rootfs foobar.img

this would work with any version of mkfs tools.

Hi ndec,

I really appreciate for your efforts and help.

I am able to boot with the new filesystem.
NOTE: You need to run the resize-helper once the board boots the first time, and then reboot to see the effect.

Just to put all the steps together:

1. create the raw image with the original image from einfochips
simg2img <linaro-vivid-xxx.img> linaro-vivid.img

2. loop mount the raw img
mkdir temp_rootfs
sudo mount -o loop linaro-vivid.img ./temp_rootfs

3. create a new rootfs image with the linux mkfs tools and with the content of the original image:
# the size can be small here, we will resize automatically on the first boot.
sudo dd if=/dev/zero of=foobar.img bs=1M count=2048
sudo mkfs.ext4 -F -L temp_rootfs foobar.img
mkdir rootfs2
mount -o loop foobar.img rootfs2
cp -a temp_rootfs/* rootfs2

4. create the fastboot sparse image
ext2simg -v foobar.img linaro-vivid-new.img

where foobar.img is the raw input image, and linaro-vivid-new.img is the output (ext4) image.

sudo fastboot erase rootfs
sudo fastboot flash rootfs linaro-vivid-new.img

Create a new file resize-helper in /usr/sbin from this link.

chmod +x resize-helper

Run the resize-helper, and reboot the board.

Now check the partition with:

df -h

Thanks.

Special thanks to ndec for the support.

Regards,
Sunny