Unable to change file systems

Beddhist · 20. März 2021

Hi, I'm a noob with OMV, but have played with Linux for 30 years. I have just set up a new server with OMV 5.

The install went smoothly and all connected disks were recognised. I wiped one HD and created a new ext4 FS and backed up my system to that. Then I installed the flash media plugin and followed its instructions on how to remove the swap partition. I also connected another drive, wiped it and created a new ext4 FS.

Shortly after that I noticed a phantom partition /dev/sda2, supposedly mounted on / and shown as missing. Any attempt to either delete this from the GUI or to create another FS resulted in the GUI throwing errors every few minutes.

After reboot I got the message that my config had changed and did I want to save it. Clicking Save sent the GUI back into the tailspin of continuous errors. After another reboot I answered the Save? question by clicking Revert and I was back where I started.

After reading some other similar topics I edited /etc/openmediavault/config.xml. There I found and deleted the entry for this phantom FS and it disappeared. I can now create another FS, but all its sizes show as "n/a" and attempting to mount it results in these errors:

Removing the directory '/' has been aborted, the resource is busy.

Followed every 10 secs by

An error has occurred.

Details:

HTML

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->

Alles anzeigen

Shortly after I Ok the 1st error OMV rebooted without further messages. Upon logging in again I'm asked to save the changes, which I chose to revert. I'm now back to square one with an FS that OMV doesn't want to mount.

Somehow, the OMV internal config regarding partitions seems to have been damaged. How can I reset this?

Hardware

Thanks,

Peter.

Beddhist · 23. März 2021

Update: I don't know what else to try, so I manually mounted the partition. Worked and shows in OMV. OMV can unmount it, but trying to mount it again results in the message:

Error #0: OMV\Exception: Removing the directory '/' has been aborted, the resource is busy. in /usr/share/openmediavault/engined/module/fstab.inc:65 Stack trace: #0 [internal function]: Engined\Module\FSTab->deleteEntry(Array) #1 /usr/share/php/openmediavault/engine/module/moduleabstract.inc(157): call_user_func_array(Array, Array) #2 /usr/share/openmediavault/engined/module/fstab.inc(31): OMV\Engine\Module\ModuleAbstract->execTasks('delete') #3 /usr/share/openmediavault/engined/rpc/config.inc(164): Engined\Module\FSTab->preDeploy() #4 [internal function]: Engined\Rpc\Config->applyChanges(Array, Array) #5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array) #6 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array) #7 /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc(909): OMV\Rpc\Rpc::call('Config', 'applyChanges', Array, Array) #8 [internal function]: Engined\Rpc\OMVRpcServiceFileSystemMgmt->mount(Array, Array) #9 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array) #10 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('mount', Array, Array) #11 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('FileSystemMgmt', 'mount', Array, Array, 1) #12 {main}

OK Hide details

Followed by several more generic ones, detail "Bad Gateway". After clicking away serveral of these, so I can copy the above text there was a beep and it rebooted. What follows I only know too well: login, question Apply/Revert. Before I revert the disk is shown as unmounted, as it is after the revert.

Time for a system restore?

crashtest · 23. März 2021

Zitat von Beddhist

Time for a system restore?

I would. I know that you attempted to relay what you did in the first post but guessing at what might have happened , to correct an issue, is hard to do.

Since data is not involved, it's best to start clean.

cabrio_leo · 23. März 2021

Zitat von Beddhist

Then I installed the flash media plugin and followed its instructions on how to remove the swap partition.

Normally it is not necessary to edit /etc/fstab in order to remove the swap partition for the flash media plugin. This step is noticed as "optional". You should undo the change of the fstab file and restore config.xml from the backup copy you hopefully have created before modifying the main openmediavault configuration database.

Beddhist · 23. März 2021

Thanks for your replies, folks. The restore made it worse: the phantom partition returned. I just disconnected all drives and re-installed.

During the install there were more problems:

First round, a bunch of console errors and the HD inaccessible.

Reboot and all that was good, now DHCP refused to work. Ended up skipping it and looking at a long Debian install menu, from where I chose 'detect NIC hardware' (no message, quickly back at the menu), then DHCP again and this time it worked. Plain sailing from here on.

I made one small, but significant change: set a root password. Previously I didn't and it disabled grub recovery boot and the system rescue CD. (Nasty trap for noobs!)

I'm now going to add the drives one by one and see how we go.

cabrio_leo · 23. März 2021

You should be extremely careful if you do manual changes in the config.xml file. Normally this is not necessary and not recommended also.

But if you intend to do it you should always be able to restore the original version.

Beddhist · 23. März 2021

It looks like I have run into a bug in OMV:

Shut down.

Connect 2nd HD. This is on a plug-in card, the system disk is connected to the main board.

System disk sda has now become sdb.

2nd HD is sda.

OMV doesn't like it and the phantom partition has re-appeared:

Now what do I do? I'm afraid the next step will be to install Mint. I know it works.

crashtest · 23. März 2021

Zitat von Beddhist

I just disconnected all drives and re-installed.

That's was what I meant. Restore to me = A rebuild or (if you have it) restoring a full backup of the OS.

Using external thumbdrives to boot makes OS backup easy. First, clone the thumbdrive. Then, if there's a problem with a configuration change or an update, swap the boot drive out and use the backup.

Beddhist · 23. März 2021

I did have a full backup, made with the omv-backup plugin using rsync. Turns out the problem already existed, probably did from the moment I plugged in more than one drive right at the start. That's how it happened this time round, too.

At least I can say now that the error is reproducable. Looks to me as if I can't use OMV with my hardware, at least until the bug is fixed.

Beddhist · 24. März 2021

I found a temporary workaround: rebooted with only the system drive connected. As I expected, the phantom partition is gone, or back to being the system partition, depending on how you look at it. Everything is good.

Now I hot-plugged the remaining 4 drives and they all show up with their file systems, without having to do anything. All can be mounted and unmounted ok.

Contrary to what I expected, even after a reboot all is still well. sda is still the system drive. So I tried a cold boot and it's still good.

Now my problem is that I don't trust this any more. Once I migrate my applications to this it has to be available 24/7. I'm afraid that any time a reboot may shuffle the device files around again and disable adding/removing drives.

I wonder what can make the device files change and why OMV seems to have a problem with it. I'm not the only one, there is at least one other topic in this forum discussing the same problem.

Where to from here...?

Beddhist · 24. März 2021

Zitat von cabrio_leo

Normally it is not necessary to edit /etc/fstab in order to remove the swap partition for the flash media plugin. This step is noticed as "optional".

Even WITH all the changes I made at reboot there was an error message saying it couldn't find the swap partition and turning on swap had failed. I'm confused: if I don't remove the swap partition, at the next boot swap will be back on. With 32GB RAM I reckon I will not need any swap.

What exactly should I do to turn it off?

Thanks,

Peter.

crashtest · 24. März 2021

Zitat von Beddhist

What exactly should I do to turn it off?

There's a difference between editing /etc/fstab and removing the swap partition.

You don't need to wipe the swap partition. This is optional. That instruction was added for mdadm RAID (throws an inconsequential error message) and GPT disk users (the swap partition may come back if not physically erased). (If they're larger than 2TB, your disks should be formatted GPT.)

In fact, while it's recommended, you don't need to edit out the swap partition in /etc/fstab. The plugin will work without the /etc/fstab edits.
________________________

Zitat von Beddhist

It looks like I have run into a bug in OMV:

What you're observing is not a bug. It's the behavior of your mother board.

Back in the day, Linux mapped device names based on the sequence as presented to the Linux OS by the mother board. SATA ports. /dev/sda was assigned to SATA port 0, /dev/sdb was assigned to SATA port 1, and so on. Then MB OEM's decided to "help" users that didn't pay attention to details, such as SATA port numbers. If a user had "one" drive plugged in, that SATA PORT became PORT 0 (the first port presented by the MB) which the LINUX OS assigned /dev/sda. Unfortunately, when another drive is plugged into a lower port number, that port was usually presented by the MB as the first port. Depending the MB and it's BIOS / UEFI, this resulted in boot issues.

To get around that issue, grub (the boot loader) will set UUID's on the partitions of the boot drive and ignore the device name(s). An example follows:

Spoiler anzeigen

The above UUID assignment should be happening automatically. However, different MB's handle devices differently so, to be sure, once you have everything working correctly, SSH into the server as root and run the command update-grub. UUID's will be assigned to the boot drive and grub's config will be updated.

Beddhist · 24. März 2021

Thanks for the explanations. Just a couple of observations:

During boot the system tries to mount the commented swap partition anyway. I don't know whether this is a GPT partion, but the drive is only 240GB. I haven't touched it after the reinstall and I'm now not going to any more.

I understand what all the uuid stuff is for, but I don't see where grub comes in now. I don't have a problem with booting. Fact is, I added a disk to the system and that changed the system drive to not be sda any more. Linux has no problem with that, but OMV does. Reproducable. Why is that not a bug?

When I started building this I consciously connected the system drive to the first port on the mobo. I don't know why the sequence changed and why, after hot-plugging all the drives it changes no more through reboots. There seems to be some randomness in it.

crashtest · 24. März 2021

Zitat von Beddhist

Why is that not a bug?

Because the function of device names is handled by Mobo hardware and the OS, "Debian". Debian is the OS - OMV is an application. Debian is one of the oldest and most stable of the Linux distro's.

Zitat von Beddhist

I don't have a problem with booting.

Good.

Zitat von Beddhist

I added a disk to the system and that changed the system drive to not be sda any more.

If the system boots, the system drive's device name doesn't matter. The reason(s) why were mentioned above. That's BIOS or UEFI rearranging the device name versus port order according to who-knows-what. If the system boots, grub's config and UUID's are working as they should.

_____________________________________________________________

You have an "8 port SATA card" that could, easily, be part of whatever is going on with these path/device name changes. This card is, without doubt, interacting with your Mobo and that can affect port assignments and other hardware resources. Perhaps, this is pure speculation, this card is idle until drives are plugged into it - then it begins to interact with your motherboard. Perhaps the card is seizing dev/sda through "?", prioritizing ports for the drives that are plugged into it.

Have you looked at the card's setup BIOS? Who makes "the card"?

Your mobo has 4 SATA ports. Maybe you should use those ports, as a test, to see if this issue clears up.

Beddhist · 25. März 2021

Yes, but the issue remains: I reboot, the device names change, Linux is fine with that, but OMV falls over. The device names do not change while the system is running, if that's what you were thinking.

crashtest · 25. März 2021

First, noting that I'm not a Developer, I don't know how many times I've seen a Linux user claim they found a bug that wasn't a bug.

After rereading all your posts, a couple of suggests have been given to you where you haven't indicated whether or not you've tried them. Realize that you're coming to the forum asking for advice but it appears you're not taking it. If you're looking for an answer you'll like, that's not the best place to start.

The list - test each item:

1. You haven't indicated whether you're booting from flash media or not. If you're booting from a hard drive, the plugin is not needed.
2. If you are booting on a thumbdrive, you don't need to do the /etc/fstab edits or to purge the swap partition. They're merely enhancements, previously explained. The Flashmemory plugin will work fine without them. Try it.
3. See if you get the same issues with the no name Chinese SATA card REMOVED. With or without their own BIOS, they do weird things. There's a reason why they're cheap and most of them have zero support.
4. If you have a work around, go with it. There's no point in forcing an error that can be avoided. There are numerous "unique" installations with odd hardware combinations and BIOS / UEFI versions, that can't be taken into account when developing a package.
5. Write up an issue -> here but realize that your ability to reproduce an issue is not enough. The Developer will have to be able to reproduce the issue as well. If he can't, that would be it. I can tell you, on one of my platforms (OMV5 Booting on a USB thumb drive, Intel Mobo and Xeon CPU's, 32GB, with a Dell Perc HBA card - 8 ports, with 4 drives attached) I can't reproduce it and I've done the /etc/fstab edit and the swap partition purge.

6. If none of the above works, perhaps OMV is not for you. Ask for a refund and install Mint.

That's the best I can do. Perhaps someone else can chime in with other ideas.

Beddhist · 25. März 2021

Thank you for your time and trouble. I have wasted enough of that now.

Your approach is to avoid the device files changing. Mine is that it's a fact of life, Linux handles it elegantly and OMV doesn't.

I have also come to the realisation that OMV is like a black box: only very few people know what goes on inside. So, I have gone to #6.

I still think that OMV is a brilliant piece of software for certain users and their machines.

Thanks again and have a nice day.

Jetzt mitmachen!