Delay boot in OMV

1. offizieller Beitrag

    Is it possible to delay the boot process in OMV under fstab or something?


    For example if i want my Sata hat for my raspberry pi to start up bfore OMV is trying to mount the disks.


    like a sleep command or something.

    My problem was that docker started before all my disks were mounted. So a lot of my containers didn't work properly. So I added (OMV 6) an override file /etc/systemd/system/docker.service.d/override.conf and added my disks there with the commands




    [Unit]

    Requires=srv-dev\x2ddisk\x2dby\x2duuid\x2d025fdf48\x2dd69c\x2d480d\x2db9b0\x2dd407189a9a2b.mount

    After=srv-dev\x2ddisk\x2dby\x2duuid\x2d025fdf48\x2dd69c\x2d480d\x2db9b0\x2dd407189a9a2b.mount



    to find the mounts you can use:

    systemctl list-unit-files | grep ".mount"


    btw. in OMV4 the config file was

    /etc/systemd/system/docker.service.d/openmediavault.conf

    Okey but is this also possible on general boot of OMV?

    to delay the OMV boot process that the software of my sata hat can properly start before OMV finishes boot and tries to mount the disks.

    Zitat von macom

    Try to add a scheduled job that is running at reboot with command mount -a

    I tried that and it shows me a mount nonempty error. Why it shows a nonempty mount option error? What is the difference when i manually mount the disks and between they get automatically mounted by the system?


    But i have a different problem. My sata hat loads later in the boot process and omv tries to mount my disks before the sata hat controller is loaded. So OMV doesn't detect the disks and stays in a boot loop.

    One way to partially fix that was to put the mount command lines from the /etc/fstab into the /etc/rc.local and delete them in etc/fstab and after successfull boot i have to copy the lines again over to etc/fstab and then manually mount -a the disks.

    This would work but sometimes the nonempty mount option error occurs which makes my disks unusable.


    So that is why i search a way of maybe delaying the boot sequenz or whatever to let my sata hat load first before OMV tries to mount the disks.

    I tried it with

    Code
    boot_delay=30

    in the /boot/config.txt but that also didn't solve the problem...

    Because mount -a only works if the mount commands are in etc/fstab but if i let them inside etc/fstab then by the next boot the rpi stays in a boot loop until i delete them in etc/fstab again. And so on...


    I guess you understand my problem here...


    Any ideas of you (i am only a noob :( ) I guess you maybe have better ideas.


    I would really appreciate help because i feel kind of lost...

    Can you post the output of the original fstab? Inside a code box >_


    sudo cat /etc/fstab

    Zitat von macom

    Try to add a scheduled job that is running at reboot with command mount -a

    Shouldn't the command be: mount -o remount -a


    Curious on this one, :/

    Zitat von Soma

    Can you post the output of the original fstab? Inside a code box >_


    sudo cat /etc/fstab

    Yes i will


    This is my original /etc/fstab above

    Zitat von Soma

    Shouldn't the command be: mount -o remount -a


    Curious on this one, :/

    I don't know... :/

    Since you have a merged FS, I can't help you much (no knowledge about it).


    [ENTERING SPECULATION MODE]

    Maybe the SATA HAT (or the FUSE.mergerFS) needs some specific module preloaded on the initramfs that is not on the current Pi kernel.

    Guessing this since I need it for BTRFS on the Pi, for e.g.

    fstab - Mount merged partition at boot, fuse module missing - Server Fault

    /etc/fstab - fuse-compatible alternative to nofail - Unix & Linux Stack Exchange

    [/ENDING SPECULATION MODE]



    I can see that you have 4 drives:

    /dev/disk/by-uuid/8b3a5cf6-e592-4272-9cf2-2c125f482205 # This looks to be individual. Where is it plugged?

    /dev/disk/by-uuid/32af1309-18b7-46cc-bbc6-ad9ceca9a64d #\

    /dev/disk/by-uuid/297c9eb4-eb1a-4e95-82cd-e56d7e277e22 # |-> These 3 are merged. Where are they plugged?

    /dev/disk/by-uuid/d89126ab-bedb-43f1-ab2a-087dfd5be2d5 #/


    Can you provide details about the SATA HAT?

    Brand, model, etc


    Also, how is it powered? The HAT I assume it's from the Pi but what about the drives?

    What power adapter are you using to feed all that juice?

    maybe yes...who knows...:/ This is what i try to figure out. What in the radxa forum was discribed was that the adapter is not loaded directly from the pi s hardware. It gets loaded afterwards. I guess that is the problem why the OMV is to early with detection if the disks are mounted or not.

    But i don't understand why this was not a problem earlier. Because i run the quad NAS setup for over 1 and a half year with no issues. Just with merger FS there are suddelny problems with the detection of the disks...

    Yes sure! you are right about the configuration. One is individual and 3 are merged.

    I chose so because i want to run snapraid and want the one single drive be the parity and the 3 others be the data disks.


    The model of the sata hat is this one from allnetchina. It is a quad sata hat. https://shop.allnetchina.cn/co…-4?variant=31200524697702


    This is the instruction on it: https://wiki.radxa.com/Dual_Quad_SATA_HAT


    The 3 disks merged together are disk a,b,d and parity is drive c


    Zitat von Soma

    Also, how is it powered? The HAT I assume it's from the Pi but what about the drives?

    What power adapter are you using to feed all that juice?

    I use a

    Model : YHY-1200500

    p/N:WL120060CB-R

    output: 12V, 5A -> 60W


    what came with the set with the sata ha together. It powers directlx the sata hat and is connected over the OI pins to the raspberry pi 4. Until now it always delivered good, no issues.

    Zitat von Copaxy

    But i don't understand why this was not a problem earlier. Because i run the quad NAS setup for over 1 and a half year with no issues. Just with merger FS there are suddelny problems with the detection of the disks...

    Well, this narrows down what is the root of the problems you're having, since it was working fine before that, ;)

    Is there an easy way to revert to what you had prior to the mergerFS? If you're willing to, of course.


    Found this on github (although RPi3), but there's no solution or development to it:

    MergerFS missed a mount point. · Issue #484 · trapexit/mergerfs (github.com)


    I'm sorry, but this is going beyond my expertise so, hoping someone can come with some better thoughts.

    Zitat von Soma

    Well, this narrows down what is the root of the problems you're having, since it was working fine before that, ;)

    Is there an easy way to revert to what you had prior to the mergerFS? If you're willing to, of course.


    Found this on github (although RPi3), but there's no solution or development to it:

    MergerFS missed a mount point. · Issue #484 · trapexit/mergerfs (github.com)


    I'm sorry, but this is going beyond my expertise so, hoping someone can come with some better thoughts.

    Thank you very much for your try help :)


    What i found in radxa was that people wrote:


    Zitat

    The problem was that fstab was trying to mount the USB drives before they were available.

    Because the USB drives weren’t mounted, when fstab tried to mount the unionfs drive the system entered a state of emergency.

    My solution was to avoid fstab to mount the drives at boot.

    So, I added noauto to the /etc/fstab mount options and also to the /etc/openmediavault/config.xml just in case. This way I can still manually mount by clicking the mount button in OMV > File Systems if needed.

    Finally I added all the mount commands to /etc/rc.local.


    Zitat

    the main issue is that omv automatically adds the mount commands to fstab.

    this is only an issue with our hardware due to how it operates.

    if the rpi would initialize the hat at boot instead of needing a service it would not be an issue

    So people wrote that it is because of the lines in fstab and they move it to rc.local. But what i don't understand is that fstab is for boot operations and also mounts the disks and file systems, if in put them in rc.local then what? They don't mount even if i put the mount commands there or do i need to add something?

    I just copyed the exact lines that the original fstab provided me. But i don't know if i need to add stuff like


    mount -o


    or whatever.


    Zitat von Soma

    Is there an easy way to revert to what you had prior to the mergerFS? If you're willing to, of course.

    Yes sure it is but i think you also suggest me that a raid0 is not a good option right. So i wish to switch to snapraid if possible.

    Soma


    Do you know a command which i can remount my mergerfs drive?


    What i am trying is, that i have put my normal disk mount commands in /etc/fstab and leave them there (previously worked and the problem is mergerfs not my disks) and i put the mergerfs drive mount command in the etc/rc.local.

    Now i want to remount the mergerfs drive manually by a command from the rc.local.

    Is that possible?


    Or


    Is there a option that i can say that i don't allow OMV to mount the mergerfs drive and i later remount it by a manual command.

    If it could be possible, how would acommand like that look like? I don't really know a lot about how to mount drives with what kind of commands.


    My mergerfs drive mount command originally created by OMV looks like this

    Code
    /srv/dev-disk-by-uuid-1550fc8c-b8d9-4d39-ac72-71c067adee58:/srv/dev-disk-by-uuid-dc5621f9-bfff-4203-9cb5-c4461e428b0f:/srv/dev-disk-by-uuid-8812a396-4df5-45b9-85a5-8a1b057868ce                /srv/fad2fba6-4975-4f6a-a360-664e82967b98 fuse.mergerfs   defaults,allow_other,cache.files=off,use_ino,category.create=epmfs,minfreespace=4G,fsname=MeinNAS:fad2fba6-4975-4f6a-a360-664e82967b98,x-systemd.requires=/srv/dev-disk-by-uuid-1550fc8c-b8d9-4d39-ac72-71c067ade58,x-systemd.requires=/srv/dev-disk-by-uuid-dc5621f9-bfff-4203-9cb5-c4461e428b0f,x-systemd.requires=/srv/dev-disk-by-uuid-8812a396-4df5-45b9-85a5-8a1b057868ce        0 0

    But where i can adjust the mount process with

    mount -o

    or whatever people are saying

    If the drives themself don't have problems at boot time but only the mergerfs has, maybe you can set them to "noauto" and mount them at the end of the boot.


    This will require an expert input even though I have an idea of how to do it (but not that confident if it's the right way).


    The idea would be:

    Apply "noauto" to the "fuse.mergerfs" <mntent> options on the /etc/openmediavault/config.xml

    Redeploy the fstab to apply the changes sudo omv-salt deploy run fstab


    Run the command mount -a at the end of the boot (or even better, a script that detects if the drives involved are mounted/available and then, mount the mergerfs)


    Would like some more expert input on this one if it's doable this way or is there a better solution.

    I found a solution!!! Thanks to your tipp it worked!!


    I did not the exact thing as you said but it gave me a idea.


    What i did was:

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


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

    Code
    #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

    3. Then my System didn't went into emergancy mode. It now boots totally fine. Only the mergerfs drive is not mounted.

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

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




    Thanks again for Soma for giving me the idea :)

  • Copaxy

    Hat das Label gelöst hinzugefügt.

    All it matters is, it's working, ;)


    Glad to hear.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden