The problems are that dual boot is no longer possible since grub does not exhibit the Windows boot option anymore and, as can be seen in recovery mode, SWAP is not activated. The old OMV 2014.2 (and before) did not have these problems. This computer has not secure boot activated. This was a fresh install via OMV LX 3.0 live mode button.
I’ve updated OMV 2014.2 to 3.0 at a computer with a SSD (120 GB) and a HDD(3TB) originally configured as
During installation, I’ve followed the recomendation to create a partition /boot/efi as to avoid initialization problems. I did it resizing the SWAP partition to 8GB and used the freed 2GB for the /boot/efi (marked as “esp”). I also formatted the SSD partition 2 as a f2fs file system.
You might even consider using a Lx 3.01 .iso as there will be much fewer packages updates after install. Lx 3.01 is just a Lx 3.0 respin with updated packages. 3.01 is Alpha still in testing but works just fine here.
The command grub2-mkconfig went OK but it has not changed anything. I think it would work if /etc/fstab had windows entries. For some reason it has nothing about windows partitions C and D, although both are mounted according to OMCC managing of disks.
The command swapon -a returns
swapon: /dev/sdb2: swapon failed: Invalid argument
I guess there is something wrong with systemd since other problems related to it are also present.
The command systemctl --failed returns just reference to the swap activation
UNIT LOAD ACTIVE SUB DESCRIPTION
● dev-disk-by\x2duuid-08d8342d\x2dce2f\x2d4e95\x2d97df\x2d2fd965885690.swap loaded failed failed /dev
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use ‘systemctl list-unit-files’.
$ swapon -s
File name Type size Used Priority
/dev/sdb2 partition 8388604 0 -1
However, it does not activate on boot. Now, boot takes about two or three minutes in a SSD device that used to boot in just few seconds. About 1:30 min are spent in a kind a verification of a device that I guess is the swap partition and then it fails to activate it.
It can be activated as it was done before with swapon -v /dev/sdb2. Still considering a reinstallation with the new iso.
To fix this I suggest to go back to your original post. Something you did while installing is likely the problem.
Is your system UEFI or Legacy BIOS? Is partition table GPT or MBR?
Is this the first time you created a /boot/efi partition? Did you have one for 2014?
/boot/efi is only needed for UEFI systems. /boot/efi partitions don’t carry much, the recommenced size is 512MB but they are often smaller I have one on a notebook that is 100MB that works just fine. But I’m thinking that you probably don’t need one at all. If you didn’t have it for 2014 then you don’t need it for Lx 3. I have no idea why your swap isn’t working. I almost never see swap used because of increases in RAM and settings in ‘/proc/sys/vm/swappiness’. You can open KSysGuard sometime and follow swap usage and you’ll see. That being said I have a 5GB swap partition myself.
So I would suggest a reinstall where you go back to what you have done previously that worked. Go back to what works unless and until there is a reason to change. I would suggest to use ext4 file system also until the other issues are resolved. I have an SSD and have tried f2fs and btrfs but did not see any advantage or improvement that I could notice.
As far a booting I don’t know this is over my head now. Not familiar with different drives on same machine having different partition table types. That seems wrong but I don’t really know. I’d want to know answer to that before filing a bug report. Otherwise it is probably bug report time.
The mkswap was a good one on your part. I learned something there.
There are commands to find out what is taking time on booting but since you have 1:30 I’d write down the whole message. It looks like its looking for a partition that isn’t there. Is the uuid in the error the uuid for the old swap? Do you have 2 swap entries in /etc/fstab?
I’ve reinstall OMV LX 3.0 and, after some corrections, everything seems fine now!
Thus, it follows a summary of what I did, what happened, and so on. It is a kind of a long report but I don’t want to skip some points.
My desktop has a SDD (MBR boot, MSDOS partitions) with Window 8 (ntfs) and OMV 3.0 (f2fs), and a HDD (no boot, GPT partitions) with Windows 8 (ntfs data), Linux Swap, and /home.
This disks configurations were probably chosen because it had Windows 7 which was not EFI boot compatible (??). I just kept this after updating to Windows 8.
I guess this is correct although unusual today.
In the first attempt to fresh install OMV 3.0, the installer “told me” that I should have a /boot/efi partition otherwise the computer could not boot. Thus I had created one resizing the swap partition. In this fresh reinstallation I just remove that /boot/efi partition and ignored the advice of non booting installation.
Step by Step:
1-In live mode, reinstalled OMV 3.0 with no /boot/efi and marking SWAP partition to format. This is probably necessary because I resized it back to 10 Gb. I had not formatted SWAP in the first installation and this was probably the cause for SWAP not being activated. [quote=“ben79, post:14, topic:850”]
The mkswap was a good one on your part
Mkswap probably did what formatting woud have done at first place.
Upon rebooting, as expected, the computer did not boot.
2 - MBR repair using the Window 8 installation disk. Details of this step are, I guess, out of the scope of this forum. It is really simple to do it as can be seen at,
3 - GRUB2 installation at MBR - This was tricky since I don’t know much of everything after all. For references on this see,
Question: When I install I boot from flash drive (usb stick) and in my BIOS am offered two options to boot in to the .iso. One is labeled UEFI and the other isn’t. I know that if you have a UEFI system you must boot the UEFI entry in BIOS or it will not work. I’m wonder if the reverse is true for Legacy/MBR systems. Which way did you boot?
Not sure what is the proper answer. I don’t think I really understand the question. Let me try to answer,
I’m talking about my desktop, where I had the problems that motivated these posts.
The first thing we see when pressing F2(to Bios) is that the boot option is UEFI (or EFI? I’ll check later). I use a DVD to install the system. The partitions with Linux and Windows system files are of MSDOS type located at a SDD with MBR boot.
I can look for more information to properly answer later on today. Please, let me know if and what to look for.