SD Card not being used entirely - uncertain causes

    • OMV 4.x
    • Resolved
    • SD Card not being used entirely - uncertain causes

      Hi everyone

      I tried to search for a solution for this online, but came empty handed.
      Everytime I tried to use Etcher to flash the SD card with an installation of OMV for an SBC (I'm using Odroid XU4) the resulting partition is almost always under the total size of the SD card and I end up with a huge amount of empty space that I'm having trouble reassigning to /root folder.

      Steps taken:
      I'm using windows for Etcher because I only have a mini SD card connection on my Surface tablet and my Linux machine has no way to flash the SD card.
      1) downloaded the recent OMV for SBC
      2) formatted the card using Windows
      3) flashed it using etcher and the file
      4) in most cases either only 1/2 of the card or in some cases only 1GB of the entire space (even for 64gb card) are used for the /root and the rest remains empty
      5) I tried to do fdisk/resize2fs afterwards but because I'm doing it from the Odroid itself, it never works as intended (tells me the files are being used)
      6) interestingly, even though I use parted to change the partition size and fdisk to create a new partition, the space allocation remains unchanged

      In all cases, when I do df-h the space shown seems to be correct and is displayed as it should be displayed (so e.g. 64gb card was showing 63gb free following the parted/resize2fs method) but when I login into web interface of OMV, it shows the old data and eventually says "no more space"

      Do I need to format my cards as ext4 filesystem before doing the flashing with OMV?
      Any idea why the partition always comes out so small?

      Thank you!
    • Mr.Grape wrote:

      whatdamat wrote:

      Etcher is the right way.
      Personally, I did not have such problems. Burn the image and start sbc wait for the installation to finish. The standard installation creates two partitions and leaves the rest empty.


      Have you read readme.txt?
      And what about mkfs.btrfs /dev/mmcblk0p3

      If you must necessarily use windows to conveniently manipulate Linux-specific partitions, you can download GParted. And either boot from usb or as VM in virtualbox with added usb / sd adapter. Works well and you can operate partitions on the sd card at will.

      So when you use Etcher it creates correct size partitions?

      I just tried it again (on Windows though) and it keeps making 1gb btrfs with all of the essential files, leaving about 300 free MB of space and the rest is left as unassigned unallocated space.

      is mkfs.btrfs /dev/mmcblk0p3 recommended way of doing this instead of expanding mkfs.btrfs /dev/mmcblk0p2 ?
    • No need to partition anything since partitions will be overwritten when writing the image. The rootfs is limited to ~7.3 GB by intention: since OMV won't use much space and you can not use the OMV/rootfs partition to put a data share on it. So the basic idea is to generate a resize rule that will limit the rootfs size to below 8 GB and create another partition you can manually format and then use as a data share).

      Speaking of 'resize rule' I uses Armbian's mechanism: docs.armbian.com/Developer-Gui…rtitioning-of-the-sd-card

      So there's a file /root/.rootfs_resize which defines the partition resizing rules. By deleting the file you get default behaviour (not recommended!) to resize the rootfs to the maximum. Such a large partition is of no use at all since OMV won't use the empty space (only Plex users might benefit from since Plex stores its databases on the rootfs without adjusting default paths).

      BTW: while partitioning an SD card prior to writing is pretty much useless using SD Formatter on Windows or macOS to do exactly this is a very good idea but for a different reason. This task will not only uselessly partition the card but also do a full capacity TRIM which restores SD card performance on old cards: docs.armbian.com/User-Guide_Ge…#how-to-prepare-a-sd-card
    • whatdamat wrote:

      I don't get the 7.1gb at all, it constantly comes out as 1gb and the rest is empty space
      That's what usually happens when the SD card is less than 8 GB in size. The resize rule defined in /root/.rootfs_resize exceeds the card's capacity and so resizing the card failes. Deleting /root/.rootfs_resize and rebooting should 'fix' this but if the resizing fails due to card's capacity being less than 8 GB this is also a reminder that no one should use such cards these days any more. At least not in SBC.

      There exists not a single SD card showing good random IO performance with less than 8 GB. All those low capacity cards are slow crap by today's standards. Better replace them now with a great performing A1 rated card (SanDisk Ultra A1 is pretty cheap too): forum.armbian.com/topic/954-sd…findComment&comment=49811
    • whatdamat wrote:

      is mkfs.btrfs /dev/mmcblk0p3 recommended way of doing this instead of expanding mkfs.btrfs /dev/mmcblk0p2 ?
      Exactly. Since expanding the rootfs is of no use with OMV. It's just wasted 'disk' space.

      In your situation with a 2GB SD card this won't help of course since there's no additional partition and the rootfs has not been resized (Armbian ships with a shrinked down partition to ~125% that will be resized on first boot -- in OMV we use a strict resize rule for the reasons explained above).

      So the best you could do is to buy a great performing A1 rated SD card and clone your installation. The next best option is to delete the /root/.rootfs_resize file and reboot to be at least able to use the full capacity of your 2GB card (minus 5% since our resize rules take care of old and crappy cards and leaves some safety headroom for the card's controller preventing to fill the entire card since all cards with capacities below 8 GB are horribly slow and will start to collapse if you completely fill them since their controllers are cheap garbage and they usually have 0 overprovisioning area)
    • Thanks for a quick and concise reply

      I tried it on 3 separate cards now, 8gb class 6 16gb class 10 and 64gb class 10
      The partition seems to come out at 1gb every time, which is really strange

      I'll try the deleting .rootfs route now

      PS the reason I was trying to use smaller cards is because I had a lot of old ones lying around collecting dust and I wanted to reuse them for something, so it actually works super well with Renegade ROC SBC and I have a backup on an ancient HD running on that 2gb card - works like magic so far

      But I've been really struggling with newer/bigger cards not knowing about the /root/.rootfs_resize rule.

      I'll try it right now
    • whatdamat wrote:

      The partition seems to come out at 1gb every time, which is really strange
      After writing the image or after first boot?

      The partition is resized during first boot.
      Odroid HC2 - armbian - Seagate ST4000DM004 - OMV4.x
      Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - Intenso SSD 120GB - OMV4.x
      :!: Backup - Solutions to common problems - OMV setup videos - OMV4 Documentation - user guide :!:
    • macom wrote:

      The partition is resized during first boot
      That's the reason I implemented a mandatory reboot on all the OMV images at first boot since with some combinations of kernel/filesystem a fs resize doesn't work without reboot.

      In case a user interferes with this first reboot OMV is in a bad state anyway (OMV installation not fully finished). So partition resize should just work given users do not disrupt this first reboot (IIRC this can also happen if the board has no internet connection on first boot to install latest updates but I don't remember all details right now since this has all happened April/May 2017)
    • Mr.Grape wrote:

      One of the OP card is supposedly 64GB. Maybe fake 64GB?
      No, the symptoms are different. The FTL (flash translation layer) completely abstracts physical from logical view. 'Resizing' a flash media partition on counterfeit products will not exceed the native capacity of the card. All these writes are just appended to the card and once the real capacity is exceeded bad/strange things will happen (the card either not accepting any new writes at all or starting to overwrite stuff from the beginning)
    • Thanks for your help everyone

      I wasn't able to change the default size as I wanted, but ended up going with the suggested mmcblk1p3 extension instead.
      The mandatory reboot happens as soon as I plug in the sd card, so erasing the file mentioned above didn't do anything after.

      I guess had I erased it prior to the first reboot (which I can't due to lack of sd card reader on my linux machine) it may have worked, alas I'll just have to live with it for now.

      PS the 1gb partition was definitely my mistake, I didn't realize that the partition would change once you plugin the card into the device.