SATA HAT with unionfs boot problem, urgent help needed


i have set up OMV with unionfs and i already read the posts from @ FBN02

How i fixed the hang at boot and got my sata hat working with unionfs

But i really don’t know how to solve this…

I have moved the fstab mount lines from OMV

/dev/disk/by-uuid/296a9557-48ec-4f58-8773-e520c4a6261b          /srv/dev-disk-by-uuid-296a9557- 
48ec-4f58-8773-e520c4a6261b      ext4    
defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

/dev/disk/by-uuid/a02154f2-1bab-47c0-8edc-3a7b1e7bc028          /srv/dev-disk-by-uuid-a02154f2- 
1bab-47c0-8edc-3a7b1e7bc028      ext4    
defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

/dev/disk/by-uuid/d5dfa04e-a415-4b07-a66c-f9bf5afd455c          /srv/dev-disk-by-uuid-d5dfa04e a415- 
4b07-a66c-f9bf5afd455c      ext4    
defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

/dev/disk/by-uuid/d829eccd-7573-45af-956b-642e43cc776c          /srv/dev-disk-by-uuid-d829eccd- 
7573-45af-956b-642e43cc776c      ext4    
defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

/srv/f9a1d54c-f1c5-447e-aee7-5732e211433c fuse.mergerfs defaults,allow_other,cache.files=off,use_ino,category.create=epmfs,minfreespace=4G,fsname=MeinNAS:f9a1d54c-f1c5-447e-aee7-5732e211433c,x-systemd.requires=/srv/dev-disk-by-uuid-d5dfa04e-a415-4b07-a66c-f9bf5afd455c,x-systemd.requires=/srv/dev-disk-by-uuid-d829eccd-7573-45af-956b-642e43cc776c,x-systemd.requires=/srv/dev-disk-by-uuid-a02154f2-1bab-47c0-8edc-3a7b1e7bc028        0 0

And i can boot now but my drives are not mounted anymore and when i try to mount them manually OMV gives out a error code.

Is there now a final soultion on how to fix this problem? I really struggle with this…i have already reflashed my SD-card for countless times…

i would really appreciate someones help or instructions.

@StephaneP Do you know a solution yet? I have seen in the other post that you wanted to write a wiki entry

Quick update:

I am now able to succesfully start the Pi with the SATA HAT and when i reboot it i can copy the lines into fstab again, then mount the drives with mount -a and then delte the lines again for next reboot.

The only problem is when i do this more then twice the command line gives me a error that it is unable to mount the drives and i have to use a nonempty mount option.

Is there a way to make this more usable and also does the mount and remount thing influence my drives and data? Because from what i know if i mount something with data inside it will make the data look disapear and when you unmount it it will show it again.

Does someone know how to help me?

Long time didn’t play with these commands lines. My NAS is down because I’ve 1 disk failure and waiting for replacment.

May be you can try switch from /srv/dev-disk-by-uuid to /dev/disk/by-label/ ? Always worked for me except below comment.

My main problem after mount all disk in 1 NAS FS : size is wrong : limited to usage of first disk. NEver fouind how solve it before my disk failure.

My command line for disk01 (example):
sudo mount -o defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,,jqfmt=vfsv0,acl /dev/disk/by-uuid/09a95d95-6957-435c-bf3c-c43188fd687d /srv/dev-disk-by-label-disk1

Oh okey sad to hear that your drive failed…

Mhm…okey but can i switch from uuid to label? I didn’t see how i could do that. I just thought that OMV is deciding on its own if it uses label or uuid.

Do you think i can modify my mount lines from OMV? Because yours have mount -o inside and mine not. Mine look a lot different. Maybe you have an idea.

Because my biggest problem is that when i put them in the fstab doc they will mount perfectly. If i put them as suggested in the rc.local they dont mount and also OMV refuses to mount them manually. Only when i put the lines again in fstab i can mount them but then run into the nonempty mount option problem.
I don’t know how i can make them mount on their own except for put them in fstab what will cause a to early mount.
Or might there be a way of put the pi to sleep for a certain time while boot so the sata hat board has enough time to boot up first ?

I am just a noob, what do you think @StephaneP ?

is mantatory

OMV is good product if you don’t request advanced feature like SATA kit :s Next installation i will remove OMV

then is there a way of slowing down the boot process? like a sleep command or something like that that the mount process starts after the sata hat powered up.

The emergency mode ? don’t remember how activate it. Or inside sys log. long time don’t worked on my rpi

Not the emergancy mode. Just for example like you can do on a pc with a sleep command.

For example you put sleep 200 and the boot process is slowed doen (thread on hold) for 200ms.

Thats what i mean. I thought maybe there is something similar available for the pi.

I found a solution.

What i did was:

  1. I let the disk mount commands in stc/fstab untouched


proc            /proc           proc    defaults          0       0
PARTUUID=7a9c3ef1-01  /boot           vfat    defaults          0       2
PARTUUID=7a9c3ef1-02            /       ext4    noatime,nodiratime,defaults    0                                                                                                                                1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
# >>> [openmediavault]
#My disks
/dev/disk/by-uuid/32af1309-18b7-46cc-bbc6-ad9ceca9a64d          /srv/dev-disk-by-uuid-32af1309-18b7-46cc-bbc6-ad9ceca9a64d      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

/dev/disk/by-uuid/297c9eb4-eb1a-4e95-82cd-e56d7e277e22          /srv/dev-disk-by-uuid-297c9eb4-eb1a-4e95-82cd-e56d7e277e22      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

/dev/disk/by-uuid/8b3a5cf6-e592-4272-9cf2-2c125f482205          /srv/dev-disk-by-uuid-8b3a5cf6-e592-4272-9cf2-2c125f482205      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

/dev/disk/by-uuid/d89126ab-bedb-43f1-ab2a-087dfd5be2d5          /srv/dev-disk-by-uuid-d89126ab-bedb-43f1-ab2a-087dfd5be2d5      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,,jqfmt=vfsv0,acl 0 2

#My mergerfs drive merge
/srv/dev-disk-by-uuid-32af1309-18b7-46cc-bbc6-ad9ceca9a64d:/srv/dev-disk-by-uuid-297c9eb4-eb1a-4e95-82cd-e56d7e277e22:/srv/dev-disk-by-uuid-d89126ab-bedb-43f1-ab2a-087dfd5be2d5                /srv/74513a42-7c46-450c-9432-962e25594da8       fuse.mergerfs   defaults,allow_other,cache.files=off,use_ino,category.create=epmfs,minfreespace=4G,fsname=MeinNAS:74513a42-7c46-450c-9432-962e25594da8,x-systemd.requires=/srv/dev-disk-by-uuid-32af1309-18b7-46cc-bbc6-ad9ceca9a64d,x-systemd.requires=/srv/dev-disk-by-uuid-297c9eb4-eb1a-4e95-82cd-e56d7e277e22,x-systemd.requires=/srv/dev-disk-by-uuid-d89126ab-bedb-43f1-ab2a-087dfd5be2d5  0 0

# <<< [openmediavault]

Weniger anzeigen

  1. I only edited the mergerfs drive command by exchanging the defaults with noauto -> location behind “fuse.mergerfs …”

defaults stands for " rw , suid , dev , exec , auto , nouser und async"

noauto stands for not automatic mount during boot.


#My mergerfs drive merge
/srv/dev-disk-by-uuid-32af1309-18b7-46cc-bbc6-ad9ceca9a64d:/srv/dev-disk-by-uuid-297c9eb4-eb1a-4e95-82cd-e56d7e277e22:/srv/dev-disk-by-uuid-d89126ab-bedb-43f1-ab2a-087dfd5be2d5                /srv/74513a42-7c46-450c-9432-962e25594da8       fuse.mergerfs   noauto,allow_other,cache.files=off,use_ino,category.create=epmfs,minfreespace=4G,fsname=MeinNAS:74513a42-7c46-450c-9432-962e25594da8,x-systemd.requires=/srv/dev-disk-by-uuid-32af1309-18b7-46cc-bbc6-ad9ceca9a64d,x-systemd.requires=/srv/dev-disk-by-uuid-297c9eb4-eb1a-4e95-82cd-e56d7e277e22,x-systemd.requires=/srv/dev-disk-by-uuid-d89126ab-bedb-43f1-ab2a-087dfd5be2d5  0 0
  1. Then my System didn’t went into emergancy mode. It now boots totally fine. Only the mergerfs drive is not mounted.

  2. Now i researched how to use the mount command with mount options and created a schedule in OMV to execute


sudo mount /filesystem

on reboot.

Now the disks mount properly and during boot it skips the mergerfs drive, so it won’t fail during boot.

Then with the scheduled mount process, everything is loaded already and OMV then mounts the mergerfs drive.

That’s it.

It should work now. For me it does. 10 reboot tests approved.