• 状态 TI Thinks Resolved
  • 已锁定 已锁定
  • 个回复 13 个回复
  • 答案 5 答案
  • 名订阅用户 15 名订阅用户
  • 次查看 1608 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM625: 编译shell自启

AM625: 配置rootfs大小

hao teng
Intellectual 480 points
Part Number: AM625

使用rootfs.ext4制作500M的跟文件系统，重新刷入emmc后使用df  -Th查询只有470M，无法使用emmc全部7个G大小。原因init.d/resize_rootfs.sh中判定并未执行成功，想问一下需要这个和什么有关，是否是写入emmc时未全覆盖导致的么。

  • 0
    TI__Mastermind 27060 points

    您好

    resize_rootfs.sh脚本通常用于在启动过程中自动调整根文件系统的大小，以适应不同大小的存储设备。该脚本会检测存储设备的大小，并根据需要进行调整。如果该脚本未成功执行，可能会导致文件系统大小不正确。

    关于您的问题，有几个可能的原因导致根文件系统大小不正确：

    1. resize_rootfs.sh脚本未正确执行

    2. 写入eMMC时未完全覆盖

    3. 分区表设置错误

  • 0 回复 Gary Lu
    Intellectual 480 points

    resize_rootfs.sh脚本的确未执行，因为在parted时就显示没有free了，我是直接通过mmc write，从rootfs的起始扇区写入rootfs.ext4文件大小个扇区，导致rootfs正常启动后使用parted /dev/mmcblk0p2 unit % print free查询到是100%。

  • 0 回复 hao teng
    TI__Mastermind 27060 points

    您好，

    您使用了 `mmc write` 命令直接将 `rootfs.ext4` 文件写入了 `rootfs` 分区的起始扇区，导致整个分区被占满，没有剩余的空间。这可能是导致 `resize_rootfs.sh` 脚本未执行的原因。

  • 0 回复 hao teng
    TI__Mastermind 27060 points

    您可以尝试以下步骤：

    1. 找到 `resize_rootfs.sh` 脚本所在的路径。

    2. 运行 `resize_rootfs.sh` 脚本手动调整 `rootfs` 分区的大小。

    3. 如果脚本成功执行，它将会自动调整 `rootfs` 分区的大小，并释放一些空间。

    4. 如果脚本执行失败或者没有解决问题，您可以尝试手动调整 `rootfs` 分区的大小。

  • 0 回复 Gary Lu
    Intellectual 480 points

    感谢回复，通过直接resizefs操作可以直接扩充到7g，今天在查询过程中突然发现resize_rootfs脚本，在自动检查free判断通过，实在想不通原因

  • 0 回复 hao teng
    Intellectual 480 points

    我的rootfs，是通过mmc write，重新从ddr写入mmc，通过mmc part 查询起始片扇和终止扇区约7g内存，我只写入制作的ext4，500M，为何脚本中parted只检测到500m制作的ext4空间，是否与mmc write前没擦除有关？

  • 0 回复 hao teng
    TI__Mastermind 27060 points

    您好，个人认为 `resize_rootfs` 脚本，它可能是一个自动化脚本，用于检查可用的空闲空间并自动调整根文件系统的大小。该脚本可能会检查当前系统中的可用空间，并根据一些预定义的规则或条件来判断是否可以进行文件系统的扩展。

    您在查询过程中发现 `resize_rootfs` 脚本通过了自动检查，并且判断可以进行文件系统的扩展，那么这可能是因为系统中有足够的空闲空间，并且满足了脚本中定义的条件。

  • 0 回复 hao teng
    TI__Mastermind 27060 points

    如果您使用 `mmc write` 命令将 ext4 文件系统写入 MMC 设备，并且 MMC 设备的起始扇区和终止扇区都足够大，那么您应该能够在 MMC 设备上看到完整的文件系统大小。

    如果您使用 `mmc part` 命令查询 MMC 设备的分区信息，但只看到了 500MB 的空间被分配给了 ext4 分区，那么可能是因为在写入 ext4 文件系统之前，您没有正确地擦除 MMC 设备上的数据。

    在写入新的文件系统之前，建议使用 `mmc erase` 命令或其他合适的擦除命令来清除 MMC 设备上的数据。这样可以确保新的文件系统被正确地写入到 MMC 设备上，并且可以正确地被识别和使用。

  • 0 回复 Gary Lu
    Intellectual 480 points

    操作后df -Th还是只查询到了474M大小。目前是/dev/mmcblk0p2大小就是474M，导致挂载到dev/root的大小为474M，resize_rootfs脚本中parted /dev/$BOOT_DEV unit '%' print free 为100% 474M，今天再尝试解决一下，实现不行就直接操作resize扩展固定大小了

  • 0 回复 hao teng
    Intellectual 480 points

    目前使用fdisk -l 分区查询到/dev/mmcblk0和mmcblk0p2的分区都是正确的，只有/dev/root的大小不正确只有400M，

  • 0 回复 hao teng
    TI__Mastermind 27060 points

    这可能是由于文件系统没有正确识别或者没有正确地扩展到整个磁盘空间。

  • 0 回复 Gary Lu
    Intellectual 480 points

    目前就是使用df -Th和fdisk -l查到的内存大小不一致，分配空间已经是全部导致脚本中if无法执行，但是/dev/root的还是默认的大小。resize_rootfs好像在dfu烧写或者mmc write，直接替换mmc中跟文件系统后都无法顺利执行，放弃了，直接每次resizes解决吧，

  • 0 回复 hao teng
    TI__Mastermind 27060 points

    您好，个人认为如果你尝试使用 resize_rootfs 命令进行调整，但是没有成功，可能需要进一步排查问题。在一些嵌入式系统中，可以使用专门的工具来进行文件系统大小的调整，例如 resize2fs（对 ext 文件系统有效）或者其他针对特定文件系统的调整工具。确保在调整文件系统大小之前，你已经正确地调整了分区大小，以确保文件系统可以利用到更多的存储空间。

    另外，如果你发现使用 resize_rootfs 命令在 dfu 烧写或者 mmc write 后无法顺利执行，可能需要检查一下是否有其他操作导致了这个问题。可能需要进一步排查是不是有其他操作导致了文件系统大小的异常情况。

    最终，手动调整文件系统大小只是一个权宜之计，长期来看，最好的解决方案是找到并解决导致文件系统大小不一致的根本问题。