OMV 3: Formatting and mounting 4TB usb drive

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • OMV 3: Formatting and mounting 4TB usb drive

      Hey fellows,
      got my Banana Pi up and running, again, but can't get my new 4TB disk working.
      As I've testet the drive using exFat with Windows I know the drive works fine.

      But on Raspbian (based on Jessie) running OMV 3.0.96 I can't get it work.
      Creating a new partition works fine (either in fdisk or on OMV). Formatting it as ext4 seems to work fine as well.
      But I cannot mount my disk.

      When I try to mount it on File System screen, this message occurs:

      Source Code

      1. Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; mount -v --source '/dev/sda1' 2>&1' with exit code '32': mount: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so.






      On details is tells us:

      Source Code

      1. Error #0:
      2. exception 'OMV\ExecException' with message 'Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; mount -v --source '/dev/sda1' 2>&1' with exit code '32': mount: wrong fs type, bad option, bad superblock on /dev/sda1,
      3. missing codepage or helper program, or other error
      4. In some cases useful info is found in syslog - try
      5. dmesg | tail or so.' in /usr/share/php/openmediavault/system/process.inc:175
      6. Stack trace:
      7. #0 /usr/share/php/openmediavault/system/filesystem/filesystem.inc(720): OMV\System\Process->execute()
      8. #1 /usr/share/openmediavault/engined/module/fstab.inc(72): OMV\System\Filesystem\Filesystem->mount()
      9. #2 /usr/share/openmediavault/engined/rpc/config.inc(194): OMVModuleFsTab->startService()
      10. #3 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
      11. #4 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
      12. #5 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
      13. #6 /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc(857): OMV\Rpc\Rpc::call('Config', 'applyChanges', Array, Array)
      14. #7 [internal function]: OMVRpcServiceFileSystemMgmt->mount(Array, Array)
      15. #8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
      16. #9 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('mount', Array, Array)
      17. #10 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('FileSystemMgmt', 'mount', Array, Array, 1)
      18. #11 {main}
      Display All


      Source Code

      1. pi@bpi-iot-ros-ai:~ $ sudo fdisk -l /dev/sda
      2. Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
      3. Units: sectors of 1 * 512 = 512 bytes
      4. Sector size (logical/physical): 512 bytes / 4096 bytes
      5. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      6. Disklabel type: gpt
      7. Disk identifier: 6A3CBCBB-D77C-4CE3-956B-0BBC8531ED48
      8. Device Start End Sectors Size Type
      9. /dev/sda1 2048 7813969886 7813967839 3.7T Linux filesystem
      Display All


      After I did

      Source Code

      1. sudo e2fsck -b 32768 -y /dev/sda

      I get this:

      Source Code

      1. Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; mount -v --source '/dev/sda' 2>&1' with exit code '32': mount: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so.


      No idea how to get my disk working...
    • Source Code

      1. pi@bpi-iot-ros-ai:~ $ dmesg | tail
      2. [ 9438.414067] Dev Sunxi softw311 sda magic does not match for MBR 3:
      3. [ 9438.419985] Dev Sunxi softw311 sda magic does not match for MBR 4:
      4. [ 9438.427648] Dev Sunxi softw311 sda header bad for all MBR copies, MBR corrupted or not present.
      5. [ 9438.433591] Dev Sunxi softw411 sda magic does not match for MBR 1:
      6. [ 9438.439509] Dev Sunxi softw411 sda magic does not match for MBR 2:
      7. [ 9438.446598] Dev Sunxi softw411 sda magic does not match for MBR 3:
      8. [ 9438.453298] Dev Sunxi softw411 sda magic does not match for MBR 4:
      9. [ 9438.460950] Dev Sunxi softw411 sda header bad for all MBR copies, MBR corrupted or not present.
      10. [ 9438.464000] sda: unknown partition table
      11. [11397.432793] EXT4-fs (sda): couldn't mount RDWR because of unsupported optional features (400)
      Display All
    • On unix.stackexchange.com/questio…ted-optional-features-400 I got the info:



      a) Either you have to upgrade the mounter program using a newer distro inside the SD-card.
      b) or you have to backup the files, reformat the SD-card with the same distro (the same ext4 versions) you are doing the mounting, and after the reformat copy the files again to the SD-card.

      So why down OMV / Raspbian format with a newer version of ext4 than that one that is supported for mounting?
      And is there a workaround for upgrading the mounting software?

      As I couldn't get OMV4 previously on Stretch I would like to stay on Jessie first...
    • Source Code

      1. pi@bpi-iot-ros-ai:~ $ sudo df -l /dev/sda
      2. Filesystem 1K-blocks Used Available Use% Mounted on
      3. udev 444888 0 444888 0% /dev
      4. pi@bpi-iot-ros-ai:~ $ partx -a /dev/sda
      5. partx: cannot open /dev/sda: Permission denied
      6. pi@bpi-iot-ros-ai:~ $ sudo partx -a /dev/sda
      7. partx: /dev/sda: failed to read partition table
      8. pi@bpi-iot-ros-ai:~ $ sudo fdisk /dev/sda
      9. Welcome to fdisk (util-linux 2.25.2).
      10. Changes will remain in memory only, until you decide to write them.
      11. Be careful before using the write command.
      12. /dev/sda: device contains a valid 'ext4' signature, it's strongly recommended to wipe the device by command wipefs(8) if this setup is unexpected to avoid possible collisions.
      13. Device does not contain a recognized partition table.
      14. The size of this disk is 3.7 TiB (4000752599040 bytes). DOS partition table format can not be used on drives for volumes larger than 4294966784 bytes for 512-byte sectors. Use GUID partition table format (GPT).
      15. Created a new DOS disklabel with disk identifier 0x92958678.
      16. Command (m for help):
      Display All
    • Source Code

      1. Command (m for help): g
      2. Created a new GPT disklabel (GUID: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A).
      3. Command (m for help): p
      4. Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
      5. Units: sectors of 1 * 512 = 512 bytes
      6. Sector size (logical/physical): 512 bytes / 4096 bytes
      7. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      8. Disklabel type: gpt
      9. Disk identifier: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A
      10. Command (m for help): t
      11. No partition is defined yet!
      12. Command (m for help): p
      13. Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
      14. Units: sectors of 1 * 512 = 512 bytes
      15. Sector size (logical/physical): 512 bytes / 4096 bytes
      16. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      17. Disklabel type: gpt
      18. Disk identifier: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A
      19. Command (m for help): n
      20. Partition number (1-128, default 1): 1
      21. First sector (2048-7813969886, default 2048): 2048
      22. Last sector, +sectors or +size{K,M,G,T,P} (2048-7813969886, default 7813969886):
      23. Created a new partition 1 of type 'Linux filesystem' and of size 3.7 TiB.
      24. Command (m for help): p
      25. Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
      26. Units: sectors of 1 * 512 = 512 bytes
      27. Sector size (logical/physical): 512 bytes / 4096 bytes
      28. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      29. Disklabel type: gpt
      30. Disk identifier: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A
      31. Device Start End Sectors Size Type
      32. /dev/sda1 2048 7813969886 7813967839 3.7T Linux filesystem
      33. Command (m for help): w
      34. The partition table has been altered.
      35. Calling ioctl() to re-read partition table.
      36. Syncing disks.
      37. pi@bpi-iot-ros-ai:~ $ sudo mkfs.ext4 /dev/sda1
      38. mke2fs 1.43.3 (04-Sep-2016)
      39. Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata and journal checksum features.
      40. Creating filesystem with 976745979 4k blocks and 244187136 inodes
      41. Filesystem UUID: 41ce597a-374b-4083-aa7a-5fb2d9853e7d
      42. Superblock backups stored on blocks:
      43. 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
      44. 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
      45. 102400000, 214990848, 512000000, 550731776, 644972544
      46. Allocating group tables: done
      47. Writing inode tables: done
      48. Creating journal (262144 blocks):
      49. done
      50. Writing superblocks and filesystem accounting information: done
      51. pi@bpi-iot-ros-ai:~ $
      52. pi@bpi-iot-ros-ai:~ $
      Display All
      I made the partition table became GPT. Than I added a new partition, which I formatted ext4. But OMV still is unable to mount it.
    • Did this twice. And then created a new FS using OMV.
      But I give it another shot right now ;)


      Brainfuck Source Code

      1. Creating the file system, please wait ...
      2. ===== Wipe signatures from device =====
      3. ===== Create partition =====
      4. Creating new GPT entries.
      5. Disk /dev/sda: 7813969920 sectors, 3.6 TiB
      6. Logical sector size: 512 bytes
      7. Disk identifier (GUID): F7A95302-F4CF-4C6B-B35F-2C2266D2BD5D
      8. Partition table holds up to 128 entries
      9. First usable sector is 34, last usable sector is 7813969886
      10. Partitions will be aligned on 2048-sector boundaries
      11. Total free space is 2014 sectors (1007.0 KiB)
      12. Number Start (sector) End (sector) Size Code Name
      13. 1 2048 7813969886 3.6 TiB 8300
      14. The operation has completed successfully.
      15. ===== Create file system =====
      16. mke2fs 1.43.3 (04-Sep-2016)
      17. Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata and journal checksum features.
      18. Creating filesystem with 976745979 4k blocks and 244187136 inodes
      19. Filesystem UUID: a6dc6279-5e80-4aaa-80c5-cf9c911b6113
      20. Superblock backups stored on blocks:
      21. 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
      22. 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
      23. 102400000, 214990848, 512000000, 550731776, 644972544
      24. Allocating group tables: 0/2980822087/29808 done
      25. Writing inode tables: 0/29808 25/29808 54/29808 75/29808 86/29808 99/29808 109/29808 .........
      Display All
    • ExRaspberry wrote:

      Have spent hours with Raspbian
      Nope, you've wasted hours with one of these crappy pseudo Raspbian images that these irresponsible Banana folks still provide for reasons unknown to me (most probably only to trick unfortunate Banana customers into believing these Bananas would be compatible to Raspberries).

      This Banana crap is a combination of an Raspbian userland with a horribly outdated and insecure kernel with wrong settings.
    • ExRaspberry wrote:

      always searched for expanding Ext4
      The whole issue was covered by the link I posted. The partition gets resized automagically if the SD card is large enough ('8 GB' in size at least). In case it's too small it's just deleting one file and rebooting to get resize to the full size (just read through the link and click on the links there)
    • That's what it is supposed to be. I'm using an 8GB card but it doesn't resize automatically.
      Flashed the image several times using etcher - so there shouldn't be a problem on the sd card.

      Manually triggering update-rc.d firstrun defaults didn't help. So maybe the resize-value is incorrect?


      Just rechecked the 'maybe broken' 16GB microSD card. Etcher has verification problems but it seems to work. Even resizing partition on first boot works like a charme.
      Maybe only etcher has problems velidating checksum? I'll update and run this card a couple of days now. Any suggestion on checking if the image works properly?

      The post was edited 2 times, last by ExRaspberry ().