( Pine64 3.0.90 ) How to combine haven't use sd card space to mmcblk0p2 ?

    • OMV 3.x
    • ( Pine64 3.0.90 ) How to combine haven't use sd card space to mmcblk0p2 ?

      Hello

      When i need to use SSH upgrade debian jessie security and openmediavault fix the new problem mmcblk0p2 the space was not enough me to upgrade.
      I have read the readme file make it mkfs.btfs /dev/mmcblk0p3 space , after first boot but can't automatically resized /dev/mmcblk0p3 to /dev/mmcblk0p2 , how can i fix it ?


      Thank !

      The readme file note :

      The last partition for data use will be automatically resized on
      first boot to use all available SD card space. Though you need to
      put your filesystem of choice on it (eg mkfs.btrfs /dev/mmcblk0p3)
      Hello,
      My name is joe from pine64 forum because here joe have registered , so random choose Ken this name.

      The post was edited 1 time, last by Ken ().

    • Hi Ken,
      What I should do to use more space, of the sdcard in my case is the following:
      1. Write image to sdcard with Win32diskimager (or your standard procedure in linux).
      2. First boot your board (rpi, pine,...), that will run a script to use all space.
      3. Remove card and insert into a linux machine, to use gparted (sometimes I use gparted live)
      4. Use gparted to resize partition 2 and 3. Resize partition 3 to use less space, and 2 ('omv', is for system /) for use more space.
      5. Insert card again, boot and that's all.

      If you are using a emmc I assume you could do the same steps.
      Greetings,
      David.
      My business server: OMV 3.0.91 | intel J2900 + 4GB DDR3 | 64GB SSD OS Disk | 2x1TB WD raid data disks
      Home Server: File server, FTP, Printing server, Plex, Logitech Media Server, VDR, Minecraft Server, Ark Survival Server, jDownloader: OMV 3.0.91 (kernel 4.10 custom
      ) | MSI B150M PRO VDH | i5-6600T 35W | 16GG RAM DDR4 2133 | 60GB SSD OS disk | 120GG SSD Games (Minecraft+Ark)| 1x4TB+2x2TB WD NAS RED HDDs
      Home automation server: OMV 3.0.63 (kernel 4.x) | RaspBerry Pi 3 | 32Gb microSD Sandisk Xtreme | USB-RS485 | mbusd MODBUS TCP<->RTU GATEWAY | HMI SCADA myscadaHome
    • Ken wrote:

      When i need to use SSH upgrade debian jessie security and openmediavault fix the new problem mmcblk0p2 the space was not enough me to upgrade.
      This means no automatic fs resize has happened and this can either mean you use an SD card smaller than 8 GB (either 4 GB or even smaller or an already broken 8 GB card where available data has been remapped).

      You should check and provide output of 'df -h' and in case you use a 8 GB card or with lower capacity you need to buy a good SD card with at least 16 GB anyway since reliable and affordable SD cards with 8 GB capacity or less don't exist (you only waste your time and your installation will fail later).

      If you're willing to ignore all risks and advises it's as easy as

      Source Code

      1. rm /root/.rootfs_resize && reboot
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • hammondb4 wrote:

      Win32diskimager (or your standard procedure in linux)
      This is a horrible tool since it does not verify what it tried to write. Better avoid it until it got a verify function (it's unbelievable that this has never been added). There exist patched versions (for the simple reason that Win32diskimager is horrible without verify) but today we should simply use Etcher (the sole existence of this tool is that 'burning went wrong' happens way too often and everywhere).

      hammondb4 wrote:

      that will run a script to use all space
      The OMV images for all ARM boards won't try to resize to the full size but only to ~7.3 GB (since this is at least the size an 8GB card should have). If it's less than this size, the resize will fail leading to the user in question running out of disk space soon (see first post of this thread) so the user asks here and gets notified that he's most probably using an SD card that will cause trouble anyway later. So he can save himself and others trying to help a lot of time by replacing the card now.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Ken wrote:

      Maybe script not work
      Exactly. Your SD card shows less than 15500000 sectors capacity (7.3 GB) and this is an indication it needs to be replaced urgently since SD cards of this size are old, slow and cause troubles later anyway (failing rather sooner than later)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Ken wrote:

      i will try to 16GB card
      For satisfying results burn it only with Etcher (no need to decompress, Etcher will verify burning process and save you from some common SD card troubles). It's strongly recommended to always test your SD card with either F3 or H2testw first to check for counterfeit/broken cards. :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • tkaiser wrote:

      Ken wrote:

      i will try to 16GB card
      For satisfying results burn it only with Etcher (no need to decompress, Etcher will verify burning process and save you from some common SD card troubles). It's strongly recommended to always test your SD card with either F3 or H2testw first to check for counterfeit/broken cards. :)
      By now i used samsung 16GB resized my space only 7.32GB.
      Anyway this have been enough my upgrade.
      Your suggest very helpful.

      Thanks

      Hello,
      My name is joe from pine64 forum because here joe have registered , so random choose Ken this name.