OMV 3: Formatting and mounting 4TB usb drive

ExRaspberry · 14. Januar 2018

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:

Code

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:

Code

Error #0:
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,
       missing codepage or helper program, or other error


       In some cases useful info is found in syslog - try
       dmesg | tail or so.' in /usr/share/php/openmediavault/system/process.inc:175
Stack trace:
#0 /usr/share/php/openmediavault/system/filesystem/filesystem.inc(720): OMV\System\Process->execute()
#1 /usr/share/openmediavault/engined/module/fstab.inc(72): OMV\System\Filesystem\Filesystem->mount()
#2 /usr/share/openmediavault/engined/rpc/config.inc(194): OMVModuleFsTab->startService()
#3 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
#4 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
#5 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
#6 /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc(857): OMV\Rpc\Rpc::call('Config', 'applyChanges', Array, Array)
#7 [internal function]: OMVRpcServiceFileSystemMgmt->mount(Array, Array)
#8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
#9 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('mount', Array, Array)
#10 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('FileSystemMgmt', 'mount', Array, Array, 1)
#11 {main}

Alles anzeigen

Code

pi@bpi-iot-ros-ai:~ $ sudo fdisk -l /dev/sda


Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 6A3CBCBB-D77C-4CE3-956B-0BBC8531ED48


Device     Start        End    Sectors  Size Type
/dev/sda1   2048 7813969886 7813967839  3.7T Linux filesystem

Alles anzeigen

After I did

Code

sudo e2fsck -b 32768 -y /dev/sda

I get this:

Code

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...

ExRaspberry · 14. Januar 2018

Code

pi@bpi-iot-ros-ai:~ $ dmesg | tail
[ 9438.414067] Dev Sunxi softw311 sda magic does not match for MBR 3:
[ 9438.419985] Dev Sunxi softw311 sda magic does not match for MBR 4:
[ 9438.427648] Dev Sunxi softw311 sda header bad for all MBR copies, MBR corrupted or not present.
[ 9438.433591] Dev Sunxi softw411 sda magic does not match for MBR 1:
[ 9438.439509] Dev Sunxi softw411 sda magic does not match for MBR 2:
[ 9438.446598] Dev Sunxi softw411 sda magic does not match for MBR 3:
[ 9438.453298] Dev Sunxi softw411 sda magic does not match for MBR 4:
[ 9438.460950] Dev Sunxi softw411 sda header bad for all MBR copies, MBR corrupted or not present.
[ 9438.464000]  sda: unknown partition table
[11397.432793] EXT4-fs (sda): couldn't mount RDWR because of unsupported optional features (400)

Alles anzeigen

ExRaspberry · 14. Januar 2018

ExRaspberry · 14. Januar 2018

On https://unix.stackexchange.com…ted-optional-features-400 I got the info:

Zitat

https://unix.stackexchange.com…ted-optional-features-400

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...

ExRaspberry · 14. Januar 2018

Code

pi@bpi-iot-ros-ai:~ $ sudo df -l /dev/sda
Filesystem     1K-blocks  Used Available Use% Mounted on
udev              444888     0    444888   0% /dev
pi@bpi-iot-ros-ai:~ $ partx -a /dev/sda
partx: cannot open /dev/sda: Permission denied
pi@bpi-iot-ros-ai:~ $ sudo partx -a /dev/sda
partx: /dev/sda: failed to read partition table
pi@bpi-iot-ros-ai:~ $ sudo fdisk /dev/sda


Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


/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.


Device does not contain a recognized partition table.
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).


Created a new DOS disklabel with disk identifier 0x92958678.


Command (m for help):

Alles anzeigen

ExRaspberry · 14. Januar 2018

Code

Command (m for help): g
Created a new GPT disklabel (GUID: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A).


Command (m for help): p
Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A






Command (m for help): t
No partition is defined yet!


Command (m for help): p


Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A






Command (m for help): n
Partition number (1-128, default 1): 1
First sector (2048-7813969886, default 2048): 2048
Last sector, +sectors or +size{K,M,G,T,P} (2048-7813969886, default 7813969886):


Created a new partition 1 of type 'Linux filesystem' and of size 3.7 TiB.


Command (m for help): p
Disk /dev/sda: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5EF935D5-872A-47BD-8BDE-930D9EE75D6A


Device     Start        End    Sectors  Size Type
/dev/sda1   2048 7813969886 7813967839  3.7T Linux filesystem




Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.


pi@bpi-iot-ros-ai:~ $ sudo mkfs.ext4 /dev/sda1
mke2fs 1.43.3 (04-Sep-2016)
Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata and journal checksum features.
Creating filesystem with 976745979 4k blocks and 244187136 inodes
Filesystem UUID: 41ce597a-374b-4083-aa7a-5fb2d9853e7d
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544


Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks):
done
Writing superblocks and filesystem accounting information: done


pi@bpi-iot-ros-ai:~ $
pi@bpi-iot-ros-ai:~ $

Alles anzeigen

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.

ExRaspberry · 14. Januar 2018

I even tried to format the disk using gparted on an lubuntu-machine and then reconnect it to my Banana Pi - same problem...

macom · 14. Januar 2018

Have you tried to wipe the drive in the GUI of OMV? Quick should be enough.
Then create the FS again.

ExRaspberry · 14. Januar 2018

Did this twice. And then created a new FS using OMV.
But I give it another shot right now

Code

Creating the file system, please wait ...
===== Wipe signatures from device =====
===== Create partition =====
Creating new GPT entries.
Disk /dev/sda: 7813969920 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): F7A95302-F4CF-4C6B-B35F-2C2266D2BD5D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7813969886
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)


Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      7813969886   3.6 TiB     8300  
The operation has completed successfully.
===== Create file system =====
mke2fs 1.43.3 (04-Sep-2016)
Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata and journal checksum features.
Creating filesystem with 976745979 4k blocks and 244187136 inodes
Filesystem UUID: a6dc6279-5e80-4aaa-80c5-cf9c911b6113
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848, 512000000, 550731776, 644972544


Allocating group tables:     0/2980822087/29808           done                            
Writing inode tables:     0/29808   25/29808   54/29808   75/29808   86/29808   99/29808  109/29808  .........

Alles anzeigen

tkaiser · 14. Januar 2018

Zitat von ExRaspberry

pi@bpi-iot-ros-ai

Seriously? You prefer one of those shitty Banana Raspbian images from the vendor over the official OMV images for your device? Well, I think you deserve the 100% unnecessary troubles you're running into

ExRaspberry · 14. Januar 2018

Well, I should give the OMV image a chance. Just downloading right now

//Edit: wipping and formatting on the Raspbian-image didn't work, again. Waiting for the OMV-image right now...

macom · 14. Januar 2018

Make sure to carefully read and follow the instructions on the download page.

ExRaspberry · 14. Januar 2018

Damn it. Works like a charme!
Have spent hours with Raspbian and it didn't work. But using OMV-image it works out of the box!

Thanks!

tkaiser · 14. Januar 2018

Zitat von ExRaspberry

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 · 14. Januar 2018

Well, just broke the image by updating. Figured out I had to expand filesystem first, but it didn't work with fdsik recreating partition and resize2fs (which worked properly using the raspbian image). So what's the trick to expand filesystem on this image?

tkaiser · 14. Januar 2018

Zitat von ExRaspberry

So what's the trick to expand filesystem on this image?

Expand root system to use all of SD card

ExRaspberry · 14. Januar 2018

As far as I understand resizing should be done automatically on first boot?
Or can I start the .rootfs_resize manually, as mine still is 863MB...

Code

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  863M  592M  201M  75% /

ExRaspberry · 16. Januar 2018

Just installed lubuntu on an old notebook to see what's going on in gparted (as I'm not used to use partitioning software in CLI). Didn't know the OMV image is using Btrfs - always searched for expanding Ext4. Maybe I have better luck right now

tkaiser · 16. Januar 2018

Zitat von ExRaspberry

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)

ExRaspberry · 16. Januar 2018

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?

Jetzt mitmachen!