Free Space: 0% Turris Omnia

For Developers
1

Trying to custom build a FW for my Turris Omnia and have resulted with no storage? If I go to the software page or use opkg it says there is not enough storage and reports 0% free space.

I have no idea what needs to be changed. Please help. Onboard storage is 8GB.

OpenWrt 18.06-SNAPSHOT, r7706-f1803e3492
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 503.3M 1.2M 502.1M 0% /tmp
tmpfs 512.0K 0 512.0K 0% /dev

2

Too many packages, not enough flash would be my first guess.

Edit: Use of initramfs rather than flash-backed file systems as outlined in the following posts appears to be the issue.

3

That looks like you have flashed an initramfs image.

2 Likes
4

I select the board type in make menuconfig then enable LUCI and add the driver I need in make kernel_menuconfig. That's pretty much all I did.

Flash is 8GB so it feels like there are some partitions missing or something? My running router (different hardware) has like 5 partitions and I've done the same thing really > select board, enable LUCI. Should I make a pull request?

5

Most build situations for already-ported devices never require kernel reconfiguration through make kernel_menuconfig. What exactly did you need to change?

6

All partitions are missing.
There is no filesystem on flash...
just the RAMdisk tmpfs data.

Have you read the Turris flashing instructions from the commit introducing the support?

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9f3f61a0d968fbe7b93899f948f3c34612683ba6

The same advice is in wiki:
https://openwrt.org/toh/turris_cz.nic/turris_cz.nic_omnia#installation

Based on that, I think that you may have missed the final mount step & actual sysupgrade step in the initramfs approach.

(But without practical Turris experience, that is a pure guess)

7

@jeff I needed to add the aacraid driver for my Adaptec RAID card I want to integrate and could not seem to run make kernel_menuconfig with the TurrisOS build.

@hnyman I did not read that information. I'm on the high end of the novice spectrum where I know what I'm doing kindof but not really :stuck_out_tongue: Still learning.

Method 1 - USB 'medkit' image w/o serial

  • Copy openwrt-mvebu-turris-omnia-sysupgrade.img.gz and
    omnia-medkit-openwrt-mvebu-turris-omnia-initramfs.tar.gz to the root of a
    USB flash drive formatted with FAT32 / ext2/3/4 / btrfs / XFS.
    Note that the medkit MUST be named omnia-medkit*.tar.gz
  • Disconnect other USB devices from the Omnia and connect the flash drive
    to either USB port.
  • Power on the Omnia and hold down the rear reset button until 4 LEDs are
    illuminated, then release.
  • Wait approximately 2 minutes for the Turris Omnia to flash itself with
    the temporary image, during which LEDs will change multiple times.
  • Connect a computer to a LAN port of the Turris Omnia with a DHCP client
  • (if necessary) ssh-keygen -R 192.168.1.1
  • ssh root@192.168.1.1
    $ mount /dev/sda1 /mnt
    $ sysupgrade /mnt/openwrt-mvebu-turris-omnia-sysupgrade.img.gz
  • Wait another minute for the final OpenWrt image to be flashed. The Turris
    Omnia will reboot itself and you can remove the flash drive.

:dizzy_face: I'll try that. I was wondering why there were two files and assumed sysupgrade was not what I wanted since I was flashing the full thing. TurrisOS comes as 1 'medkit' file.

8

Ran the sysupgrade and it killed the ethernet ports lol. I'll make sure the right drivers are loaded. :frowning:

9

I'm not seeing the switch driver specified anywhere so I'm going to assume there is another issue. I'll try enabling the WIFI and then run the sysupgrade to see what may have happened.

edit looks like it soft bricked. Had to drag out a serial com.
Wrong Image Format for bootm command
ERROR: can't get kernel image!
There's a thread somewhere that supposedly fixes this.

edit looks like I can't use a nano so I had to overwrite my project mega board -_-
ran the commands:
env default -a
saveenv
and now the recovery is working normally again.
Recompiled OpenWRT and will give it another go.

10

Success! However I only have 256MB of storage but I'm pretty sure I know where to fix that.

Thank you again for your help pointing me in the right direction :slight_smile:

11

I have 18.06.5 installed and I only have 256MB of storage, how did you get it back?

12

the eMMC partition size set for the mvebu target is not tailored to the 7.3GB available on the TO.

You could look up the source code but if I am not mistaken it creates only a 512 MB or 1014 MB partition initially. Depending on the filesystem deployed on the mmcblk0 partition you could probably resize (expand) both - the partition and the filesystem - with userland tools.

13

Thanks for the info, the partition layout is

root@Turris:~# ls /dev/ | grep mmc*
mmcblk0
mmcblk0boot0
mmcblk0boot1
mmcblk0p1
mmcblk0p2
mmcblk0rpmb

And

root@Turris:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.0M      3.0M         0 100% /rom
tmpfs                  1011.8M      1.3M   1010.5M   0% /tmp
/dev/loop0              251.4M     41.6M    139.7M  23% /overlay
overlayfs:/overlay      251.4M     41.6M    139.7M  23% /
tmpfs                   512.0K         0    512.0K   0% /dev

How do i figure out what these partitions are used for, boot0 and boot1 I think are obvious p1 p2 and rpmb partitions are the ones I should be looking at, can you point me in the right direction?

14

logread | grep partition might provide a hint, else there are

  • lsblk
  • block info
  • blkid
  • mount

mmcblk0 would be the block device with the 7.3GB capacity

15

logread | grep partition doesnt return any info,

root@Turris:~# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0          7:0    0 253.4M  0 loop /overlay
sda            8:0    1  57.6G  0 disk 
└─sda1         8:1    1  57.6G  0 part 
mtdblock0     31:0    0     1M  0 disk 
mtdblock1     31:1    0     7M  0 disk 
mmcblk0      179:0    0   7.3G  0 disk 
├─mmcblk0p1  179:1    0  16.3M  0 part 
└─mmcblk0p2  179:2    0 256.3M  0 part /rom
mmcblk0boot0 179:8    0     4M  1 disk 
mmcblk0boot1 179:16   0     4M  1 disk 
mmcblk0rpmb  179:24   0     4M  0 disk 

root@Turris:~# /sbin/block info
/dev/loop0: UUID="7acebbaf-355b-4d19-b41b-208bdd6b7f6b" VERSION="1.10" MOUNT="/overlay" TYPE="f2fs"
/dev/mmcblk0p1: UUID="0A9C-AE5E" LABEL="NO NAME" VERSION="FAT16" TYPE="vfat"
/dev/mmcblk0p2: UUID="5193d8b0-64a4e088-a92a51e7-60814ed2" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/sda1: UUID="faed2be9-a4b1-4453-b91a-538a875dd657" LABEL="Turris" VERSION="1.0" TYPE="ext4"

root@Turris:~# mount
/dev/mmcblk0p2 on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/loop0 on /overlay type f2fs (rw,noatime,lazytime,background_gc=on,no_heap,user_xattr,inline_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

Am I correct that its mmcblk0p2 that is the partition that will need expanding?

16

Not sure but likely yes, though I do not understand the purpose of

loop0 7:0 0 253.4M 0 loop /overlay

Expanding the partition is two-fold:

  • adjusting the partition table (probably needs reboot for the adjustment to be propagated to the kernel)
  • adjusting the filesystem (after the aforementioned reboot) - squashfs - to the expanded partition space

That said I am not familiar with the intricacies of squashfs and whether it can be aligned to an adjusted partition size or how that would be achieved.
It may not even be possible and instead one would need to generate a custom build image instead.

fair :warning: - tinkering with the partition table and/or the size of a file system could render the node unstable or unusable

17

Actually no, seeing that the file system is mounted read-only...

18

Oh well, reading [1 2] would indicate overlay being the part to look into.

Supposedly you could resize mmcblk0p1 and leverage it as overlay and leave the whole squshfs part on mmcblk0p2 undisturbed.

Supposedly this should work:

  • resize the mmcblk0p1 partition (which appears unused) with fdisk /dev/mmcblk0p1 (if not familiar with fdisk look up its man pages)
  • reboot node (to propagate the adjusted partition table to the kernel)
  • format the mmcblk0p1 partition with the file system of your preference
  • create a mount point (LuCI or editing /etc/config/fstab via ssh) that mounts the mmcblk0p1 partition on /
  • reboot the node

[1] https://openwrt.org/docs/techref/file_system
[2] https://openwrt.org/docs/guide-user/additional-software/extroot_configuration

19

I will try something and let you know. If I don't reply I've almost certainly broken something :smile:
Edit: fdisk -l

Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x15729631

Device         Boot Start    End Sectors   Size Id Type
/dev/mmcblk0p1 *     2048  35327   33280  16.3M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      36864 561663  524800 256.3M 83 Linux

This is just the relevant info for the partition, the asterisk on mmcblk0p1 under the boot heading makes me nervous to touch it.
If i create another partition on the device and use that as extroot, do you think that might work?

20

Makes probably sense to create another partition. extroot may not be necessary just

should work, at least that would be my understanding derived from [1]

Please ignore /rom and /overlay and use exclusively / for your daily routines!

But then I might be wrong and extroot is necessary after all.