Recovering Journal after reboot (ViewPower init.d conflict)

  • Hi,

    I installed a new OMV5 on my system, but I have a strange behaviour after a reboot: during boot appear a "recovering journal" message.

    If I shutdown the system and then startup again, that message doesn't appear. Any ideas to solve?

  • No, it isn't apparently causing errors... but my previous OMV4 installation didn't have this behavior. In OMV4, I disabled journaling too, but after this error I didn't do the same in OMV5.

    I don't think it's an expected behaviour: after the fresh install of OVM5, system didn't show this error.

    It's appared after some installation. Initially I installed Nextcloud without docker and this error wasn't there. It was necessary a reboot for php recongnition.

    After I added docker with some containers and Viewpower to control my UPS and the flash plugin to reduce write on the disk. I installed in a USB Flash drive.

    I saw some post in other forum that said the problem could be with ACPI feature, but solutions posted there, didn't worked for me: I tried to disable ACPI.

    Instead I had odd behavior with that, that error disappeared but I can't shutdown normally the system. It hangs and I have to shutdown with the power button.

  • I can't shutdown normally the system. It hangs and I have to shutdown with the power button.

    Using the power button to shut down is not a proper clean shutdown and can cause filesystems to be checked and recovered via the journal on the next boot. Is this what is happening?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Using the power button to shut down is not a proper clean shutdown and can cause filesystems to be checked and recovered via the journal on the next boot. Is this what is happening?

    No, it isn't the problem. If I reboot the problem appear, if I shutdown doesn't appear.

    As solution (read in some post from other forums), I tried to disable ACPI setting on the kernel boot with acpi=off. With this "solution" I had the problem during shutdown, so I came back to use ACPI and the behaviour is in the first statement.

    It seems that during reboot, I can't have a proper clean shutdown but I can't understand why.

  • I've seen this behavior on motherboards with defective ACPI configurations set by BIOS.


    Is a BIOS update available for your board?

    Could you share hardware details?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • Yes, of course. My system is based on AsRock J4105-ITX. I had the last BIOS update already installed. It' the first thing I tried.

    Openmediavault is installed on a 32Gb USB Stick. I use a Sata PCI-E card to expand Sata Ports: Syba SI-PEX40064 based on Marvell 88SE9215 chipset. I have populated both RAM slots with 2 Crucial CT4G4SFS824A 4GB DDR4 2400 MHz CL17.


    I checked with dmseg | grep failed and i get this:

    Code
    [    0.597031] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM
    [   11.297652] i915 0000:00:02.0: [drm] failed to retrieve link info, disabling eDP
  • I seem to remember a number of issues reported by owners of this motherboard.

    I'd recommend to ask for vendor support.


    issues reported in OMV forum for this board can be found via a site-specific internet search

    Example:

    https://duckduckgo.com/?q=site…rg+AsRock+%2BJ4105&ia=web

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • as OMV is just an application running on Debian OS, maybe Debian 11 (with OMV6) would improve the situation.

    I'd try Debian11 first from a CD or USB Live distribution (without upgrading your system)

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • I did another kind of test. You gave me the idea.

    I installed a clean minimal Debian 10 with SSH server and standard system utility.

    The problem has gone. So there is something else that cause this behaviour.

    I must investigate to understand what are causing the problem.


    I already notice some difference: kernel is not the same (4.19 vs 5.10bpo), some firmware are missing in the new installation, I removed all hard drives from the system during test and obviously nothing is installed (OMV, Docker, Nextcloud, etc.).


    I have a doubt about folder2ram too.


    I saw a different message during shutdown for reboot: in my actual system appears "watchdog can't stop" that remain many seconds before restart, in the clean installation it's so fast that I can't read what happens.


    Some suggestion on how to investigate, better than reinstall all thing with "reboot check"?

  • fixing a broken OS installation with unclear root cause is usually much more difficult & effort than performing a new installation.

    I've tried it several times and never succeeded to fix a broken OS.

    Maybe the OMV ISO image doesn't handle all specific aspects of this platform correctly. I'd assume HW support could be (partially) cut down due to size restrictions of ISO media.


    With your result I'd recommend to use:

    1) "Installation on Debian"

    2) 2 high-quality USB sticks or small SSDs for the new installation in an Active/ instant Backup device after each setup step.

    See https://openmediavault.readthe…/installation/on_usb.html and the related chapters "Installation on Debian"

    for details


    Does this make sense?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    2 Mal editiert, zuletzt von mi-hol ()

  • I'm agree with you. I don't think there is another way.

    I already installed OMV4 over debian because this motherboard doesn't support legacy mode. So no problem with that for OMV5.

    I didn't understand what do you mean "an Active/ instant Backup device after each setup step"? How can i get that?

  • Active/ instant Backup device after each setup step"? How can i get that?

    manually using dd to "clone" one device completely to another.

    Does that help? A Linux tutorial for dd might be a good reference

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • I finally found the problem: It's ViewPower that are causing this problem. After I installed it, I get again "recovery journaling" after reboot. But now I have to understand how I can fix it, because I need it to control my UPS.


    I think the problem could be the method used to start the service. I used a init.d script. Any ideas?



    EDIT:

    I confirm the problem is the init.d script. I disable it and the problem is gone, but how can I start Viewpower?


    EDIT2:

    I finally found a solution! Installation tries to install the correct method depending on Linux distribution.

    So I found in the installation folder a systemd service. I used that. That's a little bug inside, but easy to correct.

  • good to hear, please set status of this post to "resolved" and please change the title to indicate the root cause

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • alewaste

    Hat das Label gelöst hinzugefügt.
  • alewaste

    Hat das Label OMV 5.x hinzugefügt.
  • alewaste

    Hat den Titel des Themas von „Recovering Journal after reboot“ zu „Recovering Journal after reboot (ViewPower init.d conflict)“ geändert.

Jetzt mitmachen!

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