Resize root into max space

Installing and Using OpenWrt
1

The compilation creates the partitions as set up in the "image options". Creation of the minimalistic image is very handy - resulting .img file is small, and takes short time to copy.

By default, the root file system is 104 MB in size. The target storage device the image is copied to is 8GB. Is there any proven automated way (within the script) to extend root partition for the remaining device? I have investigated the matters, there're a number of ways, but I feel I am going to invent the bicycle.

If doing it myself I would, at the time of copy, examine the size of the target device, and modified the partition table's second entry size to occupy the whole disk, but I have got a problem not understanding how CHS values are calculated for the image (and if they ever matter). Then, on the image's first boot, I would extend the ext4 partition using resize2fs.

But again, given the nature openwrt images are created, I would expect someone have already developed the solution for this issue.

2

I build my own images and use the following to achieve this, adjust to fit your needs:

CONFIG_TARGET_ROOTFS_PARTSIZE=512
CONFIG_TARGET_KERNEL_PARTSIZE=32

So 1/2 gig for rootfs and 32 M for kernel space.

1 Like
3

I use this on nanopi r4s, to increase the space:

https://openwrt.org/docs/guide-user/advanced/expand_root

You can also check this:

https://openwrt.org/docs/guide-user/installation/installation_methods/sd_card

1 Like
4

Thanks! Would it be possible to do without parted/resizepart? I can do this on the image's MBR itself before writing. Does CHS information make any sense in the image (and if yes, how it is calculated)?

Edit: ok, I figured out the CHS properties of the default image: heads per cluster = 4, sectors per cluster = 63. Resulting image fills the whole CHS possible space.

Here's more info on dummy CHS, the main question remains if CHS is used by the openwrt software.

5

Depends on your purpose of the extra space. Resizing the root partition might not be the best use case. An extra partition immediately after the last partition created by the OpenWrt image is a more convenient & solid solution IMO.

2 Likes
6

I'm using this to resize the rootfs:

CONFIG_TARGET_ROOTFS_PARTSIZE=448

(it's snapshots default also)

My build sysupgrade code size is >80MB included the app Docker.

All the rest room of the eMMC, formated an ext4 overlay disk by cfdisk, and used by the docker.

Then I could run the native databse + native grafana + portainer Containers in the docker (>1GB code size).

When I do sysupgrade+keep Settings, all Containers in the docker, auto mounted and no need to re-install. All old data in the database still there, this is very important.

Now, my router (RAX3000M-emmc) = an openwrt router + a docker running any linux softwares. My separate linux server is no-use.

RPi + sdcard + ext4: how to resize root partition
7

Agreed. In this case the root volume is used as a fallback storage location and there's another device is being mounted above it at specific path. With this suggestion there will be two file system mounts overlaying each other. This adds some complications in terms of fault management and setup. I'd just increase fallback root fs in order to ensure if overlay-mounted device has failed, there will be some time to detect the failure until root fs becomes full.

8

parted -f -s /dev/mmcblk1 resizepart 2 100%
just touches the final sector size of the root fs, doing some ugly changes to end CHS - 03 ff ff to 03 e0 ff which anyway have no sense without changing CHS or all other partitions and driver supporting CHS getting disk's CHS configuration from somewhere.

9

If I understand correctly what you said, you misunderstood the extra partition I suggested. The extra partition is on its own and it's not an overlay neither running overlayfs.

RadioOperator got it right...btw.

You don't have to be constrained by OpenWrt which is more focussed on tiny systems. For larger systems, there should be a better way.

See my thread for some of the high-level discussion of the extra partition: Strategy of setting up OpenWrt on 'large' system for easy upgrade, security & expansion for long haul

10

When talking "overlay" I meant the fact of one file system mounted over another and not type of file system. Thus there is root with /some_directory, then there will be this additional same disk partition mounted over /some_directory ("laying over" contents of the root fs), and then there will be another partition from different device mounted into /some_directory location ("laying over" the mounted over mounted). I have never tried it and not sure how it will behave if it's ever possible.

11

Not "over", "into". You would mount a file system into another, that's common practice.

1 Like
12

Thanks, I seem confused everyone. Mount fs "into" mount point. And I though saying that mounted fs would appear to the user over original would be the correct statement.

13

Use this for the rootfs. For the rest of the space, create a partition for storage/data. So long as you do not exceed the values above, that partition will continue to exist untouched by OpenWrt on image updates. Make sense?

14

Thanks. Surely it makes sense. What's about mounting several devices/volumes into the same location? How is the mount order tracked within the system? What is going on when some of those mounted devices fail?

15

Not sure what you mean... use your "data" partition as such. For example, mount it to /mnt/data and point config files for daemons you want to write out to that location there rather than their defaults. Alternatively you can use a bind mount.

16

You don't, because you can't. Mount points need to be distinct from each other.

Edit: I believe you still confuse mount points with overlays. A mount point appears very much like a directory and if entered will transparently show the contents of the mounted file system (i.e. the partition) within that "directory". Nothing is overwritten.

Then that "directory" is empty.

See fstab, usually they are mounted by their UUID.

17

Yes, let me explain again.
Machine is having internal storage, which is being booted from, and this is the one which I try to extend. Machine will also have removable storage (card), which is expected to hold the data. But in case card fails, I want to ensure application keeps writing data to internal storage.

The mount point is, logically, somewhere within the root file system structure.

Thus

  • either extend internal root file system letting falling back to it in case mounted card fails;
  • create additional partition on the internal storage and mount it somewhere, and then mount in the same mountpoint the card "above" or "over" that already mounted internal storage partition - not sure it would work properly in case intermediate mount device files, or how system manages two consecutive mounts to same mountpoint, or even if it is possible.

Edit: multiple mounts are allowed, however system (df for example) displays data for last mount

/dev/mmcblk0p1          129364     38264     88972  30% /mnt
/dev/mmcblk0p2          129364     38264     88972  30% /mnt

/dev/mmcblk0p1 on /mnt type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p2 on /mnt type ext4 (rw,relatime)
18

I do not believe you can have two identical filesystems configured as such. If you have an internal SSD, statistically it will be more reliable and faster than any card or USB stick. I recommend you stop using external and just use the solution I outlined above.

I think you're making the situation too complex by introducing concepts of mounts "above" or "over." Again, define a mount point of your choosing such as /mnt/data and configure your daemons that need this storage as such.