Standard OMV update, reboot, now can't even access via SSH (possible bad MergerFS drive)

So I was running OMV, and using Yacht to manage some Docker containers. My Emby setup had started acting up just a bit. I decided to reboot the OMV server, then afterwards, I performed a standard update to OMV (now at v. 5.6.26-1). I rebooted again. This time though, I couldn't pull up the web GUI for OMV. I couldn't even SSH into the box. I hooked up a monitor and keyboard and checked the logs. Here's the error messages I found....

ERROR MESSAGES

- APEI: Can not request [mem 0xbf7aa760-0xbf7aa7b3] for APEI BERT registers

- openmediavault blkmapd[352]: open pipe file /run/roc_pipefs/nfs/blocklayout failed: No such file or directory

- openmediavault systemd[1]: Timed out waiting for device /dev/disk/by-uuid/ac008c9f-b214-43e4-bfbe-3cad670b2b9e.

I'm using MergerFS, and the device it's waiting for is 1 of my WD 8TB drives. It is spinning, but I'm not able to access it. If I'm remembering correctly, my setup is as follows: OMV is installed on the 500GB WD drive, then I have my Docker containers installed on the Crucial 1 TB SSD. All the rest of the drives are part single pool using Snapraid and MergerFS.

Any help would be much appreciated.

SD-ID	MAKE	MODEL	SERIAL NUMBER	TYPE	ADV-SIZE	LOCATION
(issue drive)	Western Digital	WD80EDAZ-11TA3A0	VGJ9ML8G	SATA HDD	8 TB	Front 1
sdb	Western Digital	WD80EDAZ-11TA3A0	VGJH8ZPG	SATA HDD	8 TB	Front 2
sdc	Western Digital	WD10EADS	WCAV53127560	SATA HDD	1 TB	Side 1
sdd	Western Digital	WD1001FALS	WMATV3847315	SATA HDD	1 TB	Side 2
sdf	Seagate	ST1000DM003	Z4Y94GBZ	SATA HDD	1 TB	Side 3
sdg	Seagate	ST8000DM004-2CX188	ZCT2DE18	SATA HDD	8 TB	Side 4
sde	Western Digital	WD5000AAKX-753CA1	WMAYUW449726	SATA HDD	500 GB	Side 5
sda	Crucial	CT1000MX500SSD1	1919E201E9E0	SATA SSD	1 TB	Side 6

I should also add that after rebooting, the server reports....

"You are in emergency mode. After logging in, type "jornalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode..... Give root password for maintenance.

SOLVED!

Zoki,

You were correct. Thank you!

nano /etc/fstab

Comment out all the drives, and I was able to log back into the gui, and ssh into the server. I was then able to see what drive was giving me the issue.

Also, a reminder to those using shucked drives. If you disconnect a shucked drive, be certain that when reconnecting that if it has tape on the 3rd pin for the 3.3V fix, that the tape is still there.