Expanding the root filesystem. Losetup problem/

Hello,

I have installed OpenWrt on an aarch64 system that has a rather large nvme disk.
(A ten64 board from Travers)
Looking for a way to do this I found this page:

I followed the instructions, but while the root partition was expanded, the root filesystem was not. Digging a bit deeper it appears that the script that is supposed to expand the filesystem exists, becuase losetup is not available.

Well, lets install it then...

root@OpenWrt:/# opkg install  losetup 
Unknown package 'losetup'.
Collected errors:
 * opkg_install_cmd: Cannot install package losetup

Oops...

So how do I proceed. And why did losetup disappear?

Your image uses squashfs file system. I had similar problem , could not solve and return to ext4 image. Then using gparted its very easy to do what you need.

You need to do opkg update first, to get the package lists...

The filesystem used for the root filesystem is ext4, so this cannot be it.

I did that. This did not fix the issue.

I did just like that - installed image of OpenWrt containing ext4 file system to my micro SD card. Then - BEFORE first boot connected this card to my Kali VM using VMWare workstation (I'm using Microsof PC with WMware). Then I was able to use gparted to extend minimal 105Mb default partiton to all available space on micro SD card, and it booted succesfully on the the device Raspberry Pi 4. I can use all space now.

the guide starts with this note:
This instruction expands OpenWrt root partition and filesystem on x86 target.

whether it is relevant or not, is losetup available for aarch64 target am not sure but why do not you build your own image with larger rootfs?

1 Like

Very odd, all the usual tools are available on my ARM box:

$ for p in losetup parted fdisk; do opkg info $p ; done
Package: losetup
Version: 2.39-2
Depends: libc, libsmartcols1
Status: unknown ok not-installed
Section: utils
Architecture: aarch64_cortex-a53
Size: 47709
Filename: losetup_2.39-2_aarch64_cortex-a53.ipk
Description: losetup is used to associate loop devices with regular files or block devices,
 to detach loop devices and to query the status of a loop device

Package: parted
Version: 3.6-1
Depends: libc, libparted, libreadline8, libncurses6
Status: unknown ok not-installed
Section: utils
Architecture: aarch64_cortex-a53
Size: 30938
Filename: parted_3.6-1_aarch64_cortex-a53.ipk
Description: GNU Parted manipulates partition tables. This is useful for
 creating space for new operating systems, reorganizing
 disk usage, copying data on hard disks and disk imaging.

Package: fdisk
Version: 2.39-2
Depends: libc, libblkid1, libsmartcols1, libfdisk1, libncursesw6
Status: unknown ok not-installed
Section: utils
Architecture: aarch64_cortex-a53
Size: 59606
Filename: fdisk_2.39-2_aarch64_cortex-a53.ipk
Description: a menu-driven program for creation and manipulation of partition tables

It shouldn't matter in this case, since he's got a "real disk" and not some funky physical device. All the usual plain-old-Linux tools should work fine.

Please provide the output of these two commands:
ubus call system board
df -T

(yes that is upper case "T".)

That should help us see what you are dealing with. Thanks.

I guess I'm the bad guy :frowning:
You, really, do not need to expand the filesystem unless you have an extremely large amount of packages you want to install or for the experience.

You can do it if you want to but the only way I know of (and as others have said) is to use the ext4 firmware put in another Linux machine and use gpart.

go to system/software and look how much you are using as a reference.

Um, they just call it ext4; its not the filesystem. :expressionless:

Last time I looked it was fat32.

edit

nope, it is fat16 :smile:

hm, but that was not really my point, was it ...
let me expand it: (regardless why losteup is not available, normally opkg update && opkg install losetup should work but it is not worked for OP for some reason) instead of enlarge a live filesystem why not build a custom image with the required rootfs size? it is much easier short term and long term as well, less error prone. fire up an imagebuilder docker and run it with desired ROOTFS_PARTSIZE parameter.

Hello, this is for example my partitions list -


As we can see, /root partition is taking 5Gb space of microSD card. there is also very tiny /boot FAT16 partition. I did not extend /root to entire size of SD card (full size is 64Gb). It is interesting to see how it is set up on @kristvanbesien side.

A bit of background: I have a ten64 board. That is an 8 core arm system with 10 ethernet interfaces and some nifty hardware for network acceleration. It also has a 5G card in it, and 256Gb nvme disk.

Traverse, who makes these boards, has its own OpenWRT distro. You can install it on flash, or on to the hard disk. So I tried to install it on the harddisk, and then wanted to expand the root filesystem. One of the scenarios I am investigating is to install docker on it, and run some more services on it.

When I install OpenWRT on it the filesystem I end up with is ext4. So I expected to be able to follow the procedure from the doc, but losetup is not available for aarch64 it would appear...

Anyway. I am now thinking to do this differently. Maybe just install OpenWRT in Flash, and just mount the nvme disk, to be used as storage for docker.

Or I just throw Fedora on it....

If your device - ten64 board can boot up from external USB, then I think you can wright image of bootable gparted on USB (there is such ready to use ISO image), boot your device from USB and extend OpenWRT partition on your nvme disk. But your installation on the disk must use ext4 filesystem, not the other squashfs one. This is all that comes to mind how to solve your issue.

Which aarch64 variant? Where are your feeds pointing (cat /etc/opkg/distfeeds.conf)?

$ opkg info losetup
Package: losetup
Version: 2.39-2
Depends: libc, libsmartcols1
Status: unknown ok not-installed
Section: utils
Architecture: aarch64_cortex-a53
Size: 47709
Filename: losetup_2.39-2_aarch64_cortex-a53.ipk
Description: losetup is used to associate loop devices with regular files or block devices,
 to detach loop devices and to query the status of a loop device