Hi, Nico and Fathi
https://github.com/96boards/96boards-tools/commit/7d2d6c5d4f3f4a1488fe750244...
Bruce from Lemaker reported this issue when he tries to use 'resize-helper.sh' to resize his SD card on HiKey. Here is his log.
Would you please have a check? Does his procedure correct?
-Guodong
On 27 January 2016 at 10:19, bruce.zou bruce.zou@lemaker.com wrote:
Hi，
昨天聊的这个问题，帮忙看看哈。重启后没有任何变化。root@linaro-alip:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0boot0 179:64 0 4M 1 disk
mmcblk0boot1 179:128 0 4M 1 disk
mmcblk0 179:0 0 7.3G 0 disk
├─mmcblk0p1 179:1 0 1M 0 part
├─mmcblk0p2 179:2 0 1M 0 part
├─mmcblk0p3 179:3 0 1M 0 part
├─mmcblk0p4 179:4 0 8M 0 part
├─mmcblk0p5 179:5 0 2M 0 part
├─mmcblk0p6 179:6 0 64M 0 part /boot/efi
├─mmcblk0p7 179:7 0 256M 0 part
├─mmcblk0p8 179:8 0 256M 0 part /media/linaro/cache
└─mmcblk0p9 179:9 0 6.7G 0 part
mmcblk1 179:192 0 7.4G 0 disk
├─mmcblk1p1 179:193 0 68M 0 part /media/linaro/boot
└─mmcblk1p2 179:194 0 2G 0 part /
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
root@linaro-alip:~#
*Bruce Zou*
*Making Innovation EasyLeMaker Team -- The Professional Makers for Hardware and Software Customization.*
Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055
Email: support@lemaker.org (Technical Support) product@lemaker.org (Product Distribution)
+Akira and Ricardo.
Akira, yes we met the same problem in Lemaker. Bruce Zou from lemaker just reported a similar issue here:
On 27 January 2016 at 11:41, Guodong Xu guodong.xu@linaro.org wrote:
Hi, Nico and Fathi
https://github.com/96boards/96boards-tools/commit/7d2d6c5d4f3f4a1488fe750244...
Bruce from Lemaker reported this issue when he tries to use 'resize-helper.sh' to resize his SD card on HiKey. Here is his log.
Would you please have a check? Does his procedure correct?
-Guodong
On 27 January 2016 at 10:19, bruce.zou bruce.zou@lemaker.com wrote:
Hi，
昨天聊的这个问题，帮忙看看哈。重启后没有任何变化。root@linaro-alip:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0boot0 179:64 0 4M 1 disk
mmcblk0boot1 179:128 0 4M 1 disk
mmcblk0 179:0 0 7.3G 0 disk
├─mmcblk0p1 179:1 0 1M 0 part
├─mmcblk0p2 179:2 0 1M 0 part
├─mmcblk0p3 179:3 0 1M 0 part
├─mmcblk0p4 179:4 0 8M 0 part
├─mmcblk0p5 179:5 0 2M 0 part
├─mmcblk0p6 179:6 0 64M 0 part /boot/efi
├─mmcblk0p7 179:7 0 256M 0 part
├─mmcblk0p8 179:8 0 256M 0 part /media/linaro/cache
└─mmcblk0p9 179:9 0 6.7G 0 part
mmcblk1 179:192 0 7.4G 0 disk
├─mmcblk1p1 179:193 0 68M 0 part /media/linaro/boot
└─mmcblk1p2 179:194 0 2G 0 part /
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
root@linaro-alip:~#
*Bruce Zou*
*Making Innovation EasyLeMaker Team -- The Professional Makers for Hardware and Software Customization.*
Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055
Email: support@lemaker.org (Technical Support) product@lemaker.org (Product Distribution)
I've found even just trying to resize the partition manually with resize2fs results in an error:
root@linaro-alip:~# resize2fs /dev/mmcblk0p9 resize2fs 1.42.12 (29-Aug-2014) [ 198.540333] EXT4-fs (mmcblk0p9): resizing filesystem from 819200 to 1757691 blocks Filesystem at /dev/mmcblk0p9 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 [ 198.603678] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 [ 198.613577] EXT4-fs (mmcblk0p9): resized filesystem to 1757691 Performing an on-line resize of /dev/mmcblk0p9 to 1757691 (4k) blocks. [ 198.688748] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 resize2fs: Invalid argument While trying to add group #25
David
On Wed, Jan 27, 2016 at 10:36 PM, Guodong Xu guodong.xu@linaro.org wrote:
+Akira and Ricardo.
Akira, yes we met the same problem in Lemaker. Bruce Zou from lemaker just reported a similar issue here:
On 27 January 2016 at 11:41, Guodong Xu guodong.xu@linaro.org wrote:
Hi, Nico and Fathi
https://github.com/96boards/96boards-tools/commit/7d2d6c5d4f3f4a1488fe750244...
Bruce from Lemaker reported this issue when he tries to use 'resize-helper.sh' to resize his SD card on HiKey. Here is his log.
Would you please have a check? Does his procedure correct?
-Guodong
On 27 January 2016 at 10:19, bruce.zou bruce.zou@lemaker.com wrote:
Hi，
昨天聊的这个问题，帮忙看看哈。重启后没有任何变化。root@linaro-alip:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0boot0 179:64 0 4M 1 disk
mmcblk0boot1 179:128 0 4M 1 disk
mmcblk0 179:0 0 7.3G 0 disk
├─mmcblk0p1 179:1 0 1M 0 part
├─mmcblk0p2 179:2 0 1M 0 part
├─mmcblk0p3 179:3 0 1M 0 part
├─mmcblk0p4 179:4 0 8M 0 part
├─mmcblk0p5 179:5 0 2M 0 part
├─mmcblk0p6 179:6 0 64M 0 part /boot/efi
├─mmcblk0p7 179:7 0 256M 0 part
├─mmcblk0p8 179:8 0 256M 0 part /media/linaro/cache
└─mmcblk0p9 179:9 0 6.7G 0 part
mmcblk1 179:192 0 7.4G 0 disk
├─mmcblk1p1 179:193 0 68M 0 part /media/linaro/boot
└─mmcblk1p2 179:194 0 2G 0 part /
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
root@linaro-alip:~#
*Bruce Zou*
*Making Innovation EasyLeMaker Team -- The Professional Makers for Hardware and Software Customization.*
Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055
Email: support@lemaker.org (Technical Support) product@lemaker.org (Product Distribution)
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On 28 January 2016 at 13:53, David Brown david.brown@linaro.org wrote:
I've found even just trying to resize the partition manually with resize2fs results in an error:
root@linaro-alip:~# resize2fs /dev/mmcblk0p9
I could be wrong. But is it good to resize rootfs which is in eMMC in a linux system? When we consider the resize requirement, we focus on resize the SD card partition actually (/dev/mmcblk1px), not eMMC.
-Guodong
resize2fs 1.42.12 (29-Aug-2014) [ 198.540333] EXT4-fs (mmcblk0p9): resizing filesystem from 819200 to 1757691 blocks Filesystem at /dev/mmcblk0p9 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 [ 198.603678] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 [ 198.613577] EXT4-fs (mmcblk0p9): resized filesystem to 1757691 Performing an on-line resize of /dev/mmcblk0p9 to 1757691 (4k) blocks. [ 198.688748] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 resize2fs: Invalid argument While trying to add group #25
David
On Wed, Jan 27, 2016 at 10:36 PM, Guodong Xu guodong.xu@linaro.org wrote:
+Akira and Ricardo.
Akira, yes we met the same problem in Lemaker. Bruce Zou from lemaker just reported a similar issue here:
On 27 January 2016 at 11:41, Guodong Xu guodong.xu@linaro.org wrote:
Hi, Nico and Fathi
https://github.com/96boards/96boards-tools/commit/7d2d6c5d4f3f4a1488fe750244...
Bruce from Lemaker reported this issue when he tries to use 'resize-helper.sh' to resize his SD card on HiKey. Here is his log.
Would you please have a check? Does his procedure correct?
-Guodong
On 27 January 2016 at 10:19, bruce.zou bruce.zou@lemaker.com wrote:
Hi，
昨天聊的这个问题，帮忙看看哈。重启后没有任何变化。root@linaro-alip:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0boot0 179:64 0 4M 1 disk
mmcblk0boot1 179:128 0 4M 1 disk
mmcblk0 179:0 0 7.3G 0 disk
├─mmcblk0p1 179:1 0 1M 0 part
├─mmcblk0p2 179:2 0 1M 0 part
├─mmcblk0p3 179:3 0 1M 0 part
├─mmcblk0p4 179:4 0 8M 0 part
├─mmcblk0p5 179:5 0 2M 0 part
├─mmcblk0p6 179:6 0 64M 0 part /boot/efi
├─mmcblk0p7 179:7 0 256M 0 part
├─mmcblk0p8 179:8 0 256M 0 part /media/linaro/cache
└─mmcblk0p9 179:9 0 6.7G 0 part
mmcblk1 179:192 0 7.4G 0 disk
├─mmcblk1p1 179:193 0 68M 0 part /media/linaro/boot
└─mmcblk1p2 179:194 0 2G 0 part /
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
root@linaro-alip:~#
*Bruce Zou*
*Making Innovation EasyLeMaker Team -- The Professional Makers for Hardware and Software Customization.*
Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055
Email: support@lemaker.org (Technical Support) product@lemaker.org (Product Distribution)
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
When working right, resize2fs should be perfectly safe on the rootfs. The kernel/tool has supported online resize for quite some time. I also seem to remember it working with older releases as well.
Otherwise, I have an 8GB eMMC device, with half of the space unused. I guess another alternative would be to make another partition and put an additional 4GB filesystem there.
David
On Wed, Jan 27, 2016 at 10:58 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 28 January 2016 at 13:53, David Brown david.brown@linaro.org wrote:
I've found even just trying to resize the partition manually with resize2fs results in an error:
root@linaro-alip:~# resize2fs /dev/mmcblk0p9
I could be wrong. But is it good to resize rootfs which is in eMMC in a linux system? When we consider the resize requirement, we focus on resize the SD card partition actually (/dev/mmcblk1px), not eMMC.
-Guodong
resize2fs 1.42.12 (29-Aug-2014) [ 198.540333] EXT4-fs (mmcblk0p9): resizing filesystem from 819200 to 1757691 blocks Filesystem at /dev/mmcblk0p9 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 [ 198.603678] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 [ 198.613577] EXT4-fs (mmcblk0p9): resized filesystem to 1757691 Performing an on-line resize of /dev/mmcblk0p9 to 1757691 (4k) blocks. [ 198.688748] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 resize2fs: Invalid argument While trying to add group #25
David
On Wed, Jan 27, 2016 at 10:36 PM, Guodong Xu guodong.xu@linaro.org wrote:
+Akira and Ricardo.
Akira, yes we met the same problem in Lemaker. Bruce Zou from lemaker just reported a similar issue here:
On 27 January 2016 at 11:41, Guodong Xu guodong.xu@linaro.org wrote:
Hi, Nico and Fathi
https://github.com/96boards/96boards-tools/commit/7d2d6c5d4f3f4a1488fe750244...
Bruce from Lemaker reported this issue when he tries to use 'resize-helper.sh' to resize his SD card on HiKey. Here is his log.
Would you please have a check? Does his procedure correct?
-Guodong
On 27 January 2016 at 10:19, bruce.zou bruce.zou@lemaker.com wrote:
Hi，
昨天聊的这个问题，帮忙看看哈。重启后没有任何变化。root@linaro-alip:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0boot0 179:64 0 4M 1 disk
mmcblk0boot1 179:128 0 4M 1 disk
mmcblk0 179:0 0 7.3G 0 disk
├─mmcblk0p1 179:1 0 1M 0 part
├─mmcblk0p2 179:2 0 1M 0 part
├─mmcblk0p3 179:3 0 1M 0 part
├─mmcblk0p4 179:4 0 8M 0 part
├─mmcblk0p5 179:5 0 2M 0 part
├─mmcblk0p6 179:6 0 64M 0 part /boot/efi
├─mmcblk0p7 179:7 0 256M 0 part
├─mmcblk0p8 179:8 0 256M 0 part /media/linaro/cache
└─mmcblk0p9 179:9 0 6.7G 0 part
mmcblk1 179:192 0 7.4G 0 disk
├─mmcblk1p1 179:193 0 68M 0 part /media/linaro/boot
└─mmcblk1p2 179:194 0 2G 0 part /
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
root@linaro-alip:~#
*Bruce Zou*
*Making Innovation EasyLeMaker Team -- The Professional Makers for Hardware and Software Customization.*
Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055
Email: support@lemaker.org (Technical Support) product@lemaker.org (Product Distribution)
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
hi,
we have indeed noticed issues when doing resize2fs on the release images. we are using the Android make_ext4fs utility to create the ext4 images , even for Linux, and it seems to be causing issues when we have 'large' filesystem (e.g. several GBs). The last time we looked into that with Fathi was before the holidays, and we haven't got back to it (at least I haven't).
make_ext4fs is a tool that does 2 things: * creates an ext4fs from a local directly * sparse the image using Android/fastboot sparse format ( https://android.googlesource.com/platform/system/core/+/master/libsparse/spa... )
It can in theory be replaced by: * mkfs.ext4 (standard linux tool) * img2simg tool from Android that creates a sparse image
However we have noticed some slight differences in the sparse images produced by the 2 processes: while make_ext4fs produces image with 'DONTCARE' blocks, img2simg uses FILL blocks (see sparse_format for details). And that change was breaking the tools we use to create the SD image that flashes images on the DragonBoard.. Well i understand this is not a good excuse to not pursue.. and I think we should get back to this topic, and use mkfs.ext4fs instead of make_ext4fs tool to create our Linux images. But that involves quite a bit of changes in many of our jobs.. Many we can start with Hikey builds for now, and in the mean time i can look at fixing the problems with the SD image tools for DragonBoard...
Fathi: do you agree? Do you have time to work on that? Anyone else willing to help?
nico
On Thu, Jan 28, 2016 at 7:02 AM, David Brown david.brown@linaro.org wrote:
When working right, resize2fs should be perfectly safe on the rootfs. The kernel/tool has supported online resize for quite some time. I also seem to remember it working with older releases as well.
Otherwise, I have an 8GB eMMC device, with half of the space unused. I guess another alternative would be to make another partition and put an additional 4GB filesystem there.
David
On Wed, Jan 27, 2016 at 10:58 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 28 January 2016 at 13:53, David Brown david.brown@linaro.org wrote:
I've found even just trying to resize the partition manually with resize2fs results in an error:
root@linaro-alip:~# resize2fs /dev/mmcblk0p9
I could be wrong. But is it good to resize rootfs which is in eMMC in a linux system? When we consider the resize requirement, we focus on resize the SD card partition actually (/dev/mmcblk1px), not eMMC.
-Guodong
resize2fs 1.42.12 (29-Aug-2014) [ 198.540333] EXT4-fs (mmcblk0p9): resizing filesystem from 819200 to 1757691 blocks Filesystem at /dev/mmcblk0p9 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 [ 198.603678] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 [ 198.613577] EXT4-fs (mmcblk0p9): resized filesystem to 1757691 Performing an on-line resize of /dev/mmcblk0p9 to 1757691 (4k) blocks. [ 198.688748] EXT4-fs warning (device mmcblk0p9): reserve_backup_gdb:969: reserved block 192 not at offset 191 resize2fs: Invalid argument While trying to add group #25
David
On Wed, Jan 27, 2016 at 10:36 PM, Guodong Xu guodong.xu@linaro.org wrote:
+Akira and Ricardo.
Akira, yes we met the same problem in Lemaker. Bruce Zou from lemaker just reported a similar issue here:
On 27 January 2016 at 11:41, Guodong Xu guodong.xu@linaro.org wrote:
Hi, Nico and Fathi
https://github.com/96boards/96boards-tools/commit/7d2d6c5d4f3f4a1488fe750244...
Bruce from Lemaker reported this issue when he tries to use 'resize-helper.sh' to resize his SD card on HiKey. Here is his log.
Would you please have a check? Does his procedure correct?
-Guodong
On 27 January 2016 at 10:19, bruce.zou bruce.zou@lemaker.com wrote:
Hi，
昨天聊的这个问题，帮忙看看哈。重启后没有任何变化。root@linaro-alip:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0boot0 179:64 0 4M 1 disk
mmcblk0boot1 179:128 0 4M 1 disk
mmcblk0 179:0 0 7.3G 0 disk
├─mmcblk0p1 179:1 0 1M 0 part
├─mmcblk0p2 179:2 0 1M 0 part
├─mmcblk0p3 179:3 0 1M 0 part
├─mmcblk0p4 179:4 0 8M 0 part
├─mmcblk0p5 179:5 0 2M 0 part
├─mmcblk0p6 179:6 0 64M 0 part /boot/efi
├─mmcblk0p7 179:7 0 256M 0 part
├─mmcblk0p8 179:8 0 256M 0 part /media/linaro/cache
└─mmcblk0p9 179:9 0 6.7G 0 part
mmcblk1 179:192 0 7.4G 0 disk
├─mmcblk1p1 179:193 0 68M 0 part /media/linaro/boot
└─mmcblk1p2 179:194 0 2G 0 part /
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
root@linaro-alip:~#
*Bruce Zou*
*Making Innovation EasyLeMaker Team -- The Professional Makers for Hardware and Software Customization.*
Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055
Email: support@lemaker.org (Technical Support) product@lemaker.org (Product Distribution)
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On 28/01/16 09:36, Nicolas Dechesne wrote:
It can in theory be replaced by:
- mkfs.ext4 (standard linux tool)
- img2simg tool from Android that creates a sparse image
However we have noticed some slight differences in the sparse images produced by the 2 processes: while make_ext4fs produces image with 'DONTCARE' blocks, img2simg uses FILL blocks (see sparse_format for details). And that change was breaking the tools we use to create the SD image that flashes images on the DragonBoard.. Well i understand this is not a good excuse to not pursue.. and I think we should get back to this topic, and use mkfs.ext4fs instead of make_ext4fs tool to create our Linux images. But that involves quite a bit of changes in many of our jobs.. Many we can start with Hikey builds for now, and in the mean time i can look at fixing the problems with the SD image tools for DragonBoard...
What type of blocks does ext2simg produce?
On other platforms Paul Lui has reported some interesting differences between images from img2simg and images from ext2img .
Daniel.
On Thu, Jan 28, 2016 at 10:43 AM, Daniel Thompson daniel.thompson@linaro.org wrote:
On 28/01/16 09:36, Nicolas Dechesne wrote:
It can in theory be replaced by:
- mkfs.ext4 (standard linux tool)
- img2simg tool from Android that creates a sparse image
However we have noticed some slight differences in the sparse images produced by the 2 processes: while make_ext4fs produces image with 'DONTCARE' blocks, img2simg uses FILL blocks (see sparse_format for details). And that change was breaking the tools we use to create the SD image that flashes images on the DragonBoard.. Well i understand this is not a good excuse to not pursue.. and I think we should get back to this topic, and use mkfs.ext4fs instead of make_ext4fs tool to create our Linux images. But that involves quite a bit of changes in many of our jobs.. Many we can start with Hikey builds for now, and in the mean time i can look at fixing the problems with the SD image tools for DragonBoard...
What type of blocks does ext2simg produce?
On other platforms Paul Lui has reported some interesting differences between images from img2simg and images from ext2img .
to follow up on that.. after a bit of discussion (on irc) and testing, it looks like we should be able to replace make_ext4fs by mkfs.ext4 + ext2simg. And we would get images built properly: the filesystem would be created with linux standard tools, and the resulting sparse image has DONTCARE blocks which is better too.
I did a quick test on my dragonboard, and I could flash the resulting image fine, and resize-helper.sh could do its job properly too.
can someone try on hikey the following:
1. download the latest debian rootfs 2. simg2img <rootfs> <rootfs.raw> 3. dd if=/dev/zero of=image.img xxx 4. mkfs.ext4 image.img 5. mount image.img and <rootfs.raw> 6. cp -a <rootfs.raw mount> --> <image.img mount> 7. ext2simg <image.img> <s_image.img>
and then flash the resulting image on hikey and test if the resize works?
On Thu, Jan 28, 2016 at 02:06:50PM +0100, Nicolas Dechesne wrote:
to follow up on that.. after a bit of discussion (on irc) and testing, it looks like we should be able to replace make_ext4fs by mkfs.ext4 + ext2simg. And we would get images built properly: the filesystem would be created with linux standard tools, and the resulting sparse image has DONTCARE blocks which is better too.
I did a quick test on my dragonboard, and I could flash the resulting image fine, and resize-helper.sh could do its job properly too.
can someone try on hikey the following:
- download the latest debian rootfs
- simg2img <rootfs> <rootfs.raw>
- dd if=/dev/zero of=image.img xxx
- mkfs.ext4 image.img
- mount image.img and <rootfs.raw>
- cp -a <rootfs.raw mount> --> <image.img mount>
- ext2simg <image.img> <s_image.img>
I wonder if I have problems with either my simg2img/img2simg or my fastboot:
Steps 1-7 are fine, but when I tried flashing the resulting image:
% fastboot flash system hikey-rootfs2.simg target reported max download size of 524288000 bytes error: write_sparse_skip_chunk: don't care size 1306170156 is not a multiple of the block size 4096 error: write_sparse_skip_chunk: don't care size 781824812 is not a multiple of the block size 4096 error: write_sparse_skip_chunk: don't care size 257540908 is not a multiple of the block size 4096 fastboot: core/libsparse/sparse.c:153: write_all_blocks: Assertion `pad >= 0' failed. zsh: abort (core dumped) fastboot flash system hikey-rootfs2.simg
Do we have official binaries for these tools? I build the simg2img/img2simg right out of https://android.googlesource.com/platform/system/core .
David
On Thu, Jan 28, 2016 at 6:59 PM, David Brown david.brown@linaro.org wrote:
I wonder if I have problems with either my simg2img/img2simg or my fastboot:
you should use ext2simg, not img2simg. It should come in android-tools-fsutils (debian/ubuntu)
nico
On Thu, Jan 28, 2016 at 07:03:45PM +0100, Nicolas Dechesne wrote:
On Thu, Jan 28, 2016 at 6:59 PM, David Brown david.brown@linaro.org wrote:
I wonder if I have problems with either my simg2img/img2simg or my fastboot:
you should use ext2simg, not img2simg. It should come in android-tools-fsutils (debian/ubuntu)
Yes, it works fine with ext2simg. I'm kind of surprised by that, given that img2simg is supposed to be fairly general.
But, with these steps, the first boot does resize the rootfs to fill out the remaining space.
David
Le 28 janv. 2016 20:03, "David Brown" david.brown@linaro.org a écrit :
On Thu, Jan 28, 2016 at 07:03:45PM +0100, Nicolas Dechesne wrote:
On Thu, Jan 28, 2016 at 6:59 PM, David Brown david.brown@linaro.org
wrote:
I wonder if I have problems with either my simg2img/img2simg or my fastboot:
you should use ext2simg, not img2simg. It should come in android-tools-fsutils (debian/ubuntu)
Yes, it works fine with ext2simg. I'm kind of surprised by that, given that img2simg is supposed to be fairly general.
Good. I had noticed that img2simg wasn't working fine for me on db410 neither... Glad that we found one that works at least..
I haven't submitted changes in CI jos for db410 to use mkfs.ext4+ext2simg. Fathi is testing that right now. If it works fine we will update all jobs for all images..
But, with these steps, the first boot does resize the rootfs to fill out the remaining space.
Awesome.
David
Thanks Nicolas, Daniel, and Fathi.
-Guodong
On 29 January 2016 at 04:10, Nicolas Dechesne nicolas.dechesne@linaro.org wrote:
Le 28 janv. 2016 20:03, "David Brown" david.brown@linaro.org a écrit :
On Thu, Jan 28, 2016 at 07:03:45PM +0100, Nicolas Dechesne wrote:
On Thu, Jan 28, 2016 at 6:59 PM, David Brown david.brown@linaro.org
wrote:
I wonder if I have problems with either my simg2img/img2simg or my fastboot:
you should use ext2simg, not img2simg. It should come in android-tools-fsutils (debian/ubuntu)
Yes, it works fine with ext2simg. I'm kind of surprised by that, given that img2simg is supposed to be fairly general.
Good. I had noticed that img2simg wasn't working fine for me on db410 neither... Glad that we found one that works at least..
I haven't submitted changes in CI jos for db410 to use mkfs.ext4+ext2simg. Fathi is testing that right now. If it works fine we will update all jobs for all images..
But, with these steps, the first boot does resize the rootfs to fill out the remaining space.
Awesome.
David
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
这下面是验证过程，用resize-helper.sh不行。还是要用mkfs.ext4+ext2simg直接对img操作呀？
$ sudo apt-get install realpath
$ wget https://github.com/fboudra/resize-helper/raw/master/resize-helper.sh
$ chmod u+x resize-helper.sh
$ sudo ./resize-helper.sh
root@linaro-alip:~# chmod u+x resize-helper.sh
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
Bruce Zou
Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization.
Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055
Email: mailto:support@lemaker.org support@lemaker.org (Technical Support) mailto:product@lemaker.org product@lemaker.org (Product Distribution)
http://www.lemaker.org/ http://www.lemaker.org/
发件人: Guodong Xu [mailto:guodong.xu@linaro.org] 发送时间: 2016年1月29日 9:26 收件人: Nicolas Dechesne nicolas.dechesne@linaro.org 抄送: David Brown david.brown@linaro.org; dev dev@lists.96boards.org; 潘成源 oldpan.pan@lemaker.com; bruce.zou bruce.zou@lemaker.com 主题: Re: [Dev] Problem using ./resize-helper.sh to resize SD card partition size
Thanks Nicolas, Daniel, and Fathi.
-Guodong
On 29 January 2016 at 04:10, Nicolas Dechesne <nicolas.dechesne@linaro.org mailto:nicolas.dechesne@linaro.org > wrote:
Le 28 janv. 2016 20:03, "David Brown" <david.brown@linaro.org mailto:david.brown@linaro.org > a écrit :
On Thu, Jan 28, 2016 at 07:03:45PM +0100, Nicolas Dechesne wrote:
On Thu, Jan 28, 2016 at 6:59 PM, David Brown <david.brown@linaro.org mailto:david.brown@linaro.org > wrote:
I wonder if I have problems with either my simg2img/img2simg or my fastboot:
you should use ext2simg, not img2simg. It should come in android-tools-fsutils (debian/ubuntu)
Yes, it works fine with ext2simg. I'm kind of surprised by that, given that img2simg is supposed to be fairly general.
Good. I had noticed that img2simg wasn't working fine for me on db410 neither... Glad that we found one that works at least..
I haven't submitted changes in CI jos for db410 to use mkfs.ext4+ext2simg. Fathi is testing that right now. If it works fine we will update all jobs for all images..
But, with these steps, the first boot does resize the rootfs to fill out the remaining space.
Awesome.
David
_______________________________________________ Dev mailing list Dev@lists.96boards.org mailto:Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Mon, Feb 29, 2016 at 10:36 AM, bruce.zou bruce.zou@lemaker.com wrote:
这下面是验证过程，用resize-helper.sh不行。还是要用mkfs.ext4+ext2simg直接对img操作呀？
$ sudo apt-get install realpath
$ wget https://github.com/fboudra/resize-helper/raw/master/resize-helper.sh
$ chmod u+x resize-helper.sh
$ sudo ./resize-helper.sh
root@linaro-alip:~# chmod u+x resize-helper.sh
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
I see the same thing on my HiKey
g.
Me too. When I fix this via gparted*, the boot loader fails to find an launch the system on that partition.
David
* Doesn't matter whether I run gparted on an Intel or ARM machine, neither work.
On Mon, 2016-02-29 at 11:29 +0000, Grant Likely wrote:
On Mon, Feb 29, 2016 at 10:36 AM, bruce.zou bruce.zou@lemaker.com wrote:
这下面是验证过程，用resize-helper.sh不行。还是要用mkfs.ext4+ext2simg直接对img操作呀？
$ sudo apt-get install realpath
$ wget https://github.com/fboudra/resize-helper/raw/master/resize-h elper.sh
$ chmod u+x resize-helper.sh
$ sudo ./resize-helper.sh
root@linaro-alip:~# chmod u+x resize-helper.sh
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
I see the same thing on my HiKey
g. _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Can you confirm the below email to solve this bug？ -------------------------------------------------------------------------------- Thanks Nicolas, Daniel, and Fathi.
-Guodong
On 29 January 2016 at 04:10, Nicolas Dechesne nicolas.dechesne@linaro.org wrote:
Le 28 janv. 2016 20:03, "David Brown" david.brown@linaro.org a écrit :
On Thu, Jan 28, 2016 at 07:03:45PM +0100, Nicolas Dechesne wrote:
On Thu, Jan 28, 2016 at 6:59 PM, David Brown david.brown@linaro.org wrote:
I wonder if I have problems with either my simg2img/img2simg or my fastboot:
you should use ext2simg, not img2simg. It should come in android-tools-fsutils (debian/ubuntu)
Yes, it works fine with ext2simg. I'm kind of surprised by that, given that img2simg is supposed to be fairly general.
Good. I had noticed that img2simg wasn't working fine for me on db410 neither... Glad that we found one that works at least.. I haven't submitted changes in CI jos for db410 to use mkfs.ext4+ext2simg. Fathi is testing that right now. If it works fine we will update all jobs for all images..
But, with these steps, the first boot does resize the rootfs to fill out the remaining space.
Awesome.
David
-----邮件原件----- 发件人: David Rusling [mailto:david.rusling@linaro.org] 发送时间: 2016年2月29日 22:09 收件人: Grant Likely grant.likely@linaro.org; bruce.zou bruce.zou@lemaker.com 抄送: dev dev@lists.96boards.org; 潘成源 oldpan.pan@lemaker.com 主题: Re: [Dev] 答复: Problem using ./resize-helper.sh to resize SD card partition size
Me too. When I fix this via gparted*, the boot loader fails to find an launch the system on that partition.
David
* Doesn't matter whether I run gparted on an Intel or ARM machine, neither work.
On Mon, 2016-02-29 at 11:29 +0000, Grant Likely wrote:
On Mon, Feb 29, 2016 at 10:36 AM, bruce.zou bruce.zou@lemaker.com wrote:
这下面是验证过程，用resize-helper.sh不行。还是要用mkfs.ext4+ext2simg直接对img操作呀？
$ sudo apt-get install realpath
$ wget https://github.com/fboudra/resize-helper/raw/master/resize-h elper.sh
$ chmod u+x resize-helper.sh
$ sudo ./resize-helper.sh
root@linaro-alip:~# chmod u+x resize-helper.sh
root@linaro-alip:~# ./resize-helper.sh
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Error: Partition doesn't exist.
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 506880 (4k) blocks long. Nothing to do!
I see the same thing on my HiKey
g. _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
-
bruce.zou -
Daniel Thompson -
David Brown -
David Rusling -
Grant Likely -
Guodong Xu -
Nicolas Dechesne