I think it is sad that we can't expect systemd to do things in order the disks are listed in fstab. I guess I can look at adding the x-systemd.requires lines.
I found a couple pages (such as this one) which indicate that with systemd, fstab order is not maintained. They're all just turned into .mount files and run in parallel, barring dependencies.
Are these disks usb disks?
Nope, they're internal sata drives. They even appear above the union mount in fstab like you'd expect. However when I looked at the journalctl it was doing the union, then immediately after the sharedfolders which referenced the union fs, then sometime later the underlying disks. I can post the fstab or something else if it helps figure out why it was doing that.
TBH, I have just ignored this problem, my /sharedfolders/ do eventually populate but I never reference them anywhere, even the latest @TechnoDadLife videos use /srv/ in Portainer
The solution is here not to use the default direct_io in options as this causes problems with docker and docker configs, I can't find the thread but another user highlighted this as it has something to do with mmap,
I much prefer the idea of referencing the /sharedfolders/ instead of the directly using the devices. It makes it easier to update things if anything changes. Like moving from bare drive to unionfs, just update the sharedfolders. It may be a holdover from being drilled into to use as little hardcoded values as possible. Though if it can't be made stable enough to rely upon then it's not the end of the world.
I already removed the direct_io option since the docs looked like it was suggested against, at least in the general case.
I experienced this issue after creating a union filesystem today. In my instance, it was mounting the fuse point before the underlying disks were mounted. It immediately after attempted to mount the sharedfolders, which failed because no data was there yet. Only sometime after the sharedfolders failed did it mount the disks.
I was able to solve this by adding x-systemd.requires to the options for the union filesystem from the plugin window. So for my union of two disks the options are
defaults,allow_other,use_ino,category.search=newest,x-systemd.requires=/srv/dev-disk-by-label-backup,x-systemd.requires=/srv/dev-disk-by-label-backup2
Now they seem to be loading fine.
So after further digging and testing on my own the past few weeks I'm pretty sure I found the problem and solution. Further testing showed that the errors displayed in the terminal when it hard locked up were not very consistent, so not just showing I/O errors for the Blu Ray like I had originally seen. And nothing would ever be saved to logs. Some things I tried were unplugging the Blu Ray drive, installing official nvidia drivers, removing the GT 710 graphics card, updating BIOS, and reinstalling OMV.
While chasing down an error reported during startup, I happened across others describing the same problems I have been experiencing. Turns out first gen Ryzen processors have issues with idling when running linux. When idling they have a habit of locking up the system. The solution was to go into the BIOS settings and change the 'Power Supply Idle Control' from 'auto' to 'Typical Current Idle'. It's been running stable for the past few days and the symptoms of others for whom this worked all match my own, so I'm hopeful that was indeed the solution.
Recently I rebuilt my server using new hardware. From an i5 2500k to ryzen 5 1600. I also added a blu ray drive. I moved over the hard drive and did a repair to fix the network. Ever since, it will stop working every few days. Plugging in a monitor shows it throws some errors before dying. A series of I/O errors from sr0, which is the blu ray player. I tried googling the error and most of the results are about problems booting from live cds. I'm not booting from a live CD, and most of the time the error comes up the disk drive is empty.
The errors look like a series of the following before it goes unresponsive.
print_req_error: I/O error, dev sr0, sector XXXXXXX
Buffer I/O error on dev sr0, logical block XXXXXXX
print_req_error: I/O error, dev sr0, sector XXXXXXX
Buffer I/O error on dev sr0, logical block XXXXXXX
print_req_error: I/O error, dev sr0, sector XXXXXXX
Buffer I/O error on dev sr0, logical block XXXXXXX
print_req_error: I/O error, dev sr0, sector XXXXXXX
Buffer I/O error on dev sr0, logical block XXXXXXXPhoto of the output https://i.imgur.com/WRT2Gvt.jpg
I've only seen the CPU stuck watchdog errors a couple of times, mostly it's just the I/O errors.
I'm having an annoying problem attempting to create a VM today with a new Ubuntu ISO. I had an older Ubuntu VM which was working fine but wanted to start fresh for a certain task. So I deleted the old one, downloaded an up-to-date ISO and went to set up the new VM. However, whenever I try to select the ISO I get an endless loading screen for "Choose a virtual optical disk file" dialog.
I tried looking for any logs but couldn't find where they might be. I also tried reinstalling the plugin, but the problem still persists.
Any thoughts on why the file picker isn't working?
The info box says it's downloading and installing clonezilla-live-2.6.0-37-i686-pae.iso (and that file's existing in the boot folder). dpkg -l clonezilla tells me, that actually version 3.32.22 is running.
2.6.0-37 is the latest stable release of the clonezilla live iso.
I was having some issues with cloning my main drive with the supplied iso for clonezilla in omv-extras, but found that the latest version (clonezilla-live-2.6.0-37-amd64.iso) did not have the same problem. Unfortunately the ssh didn't work out of the box for me like it did for jcd, so initially I could only access it by hooking up a monitor and keyboard (which I generally don't keep connected). With a bit of tinkering I was able to get a setup that works with the existing reboot button, and doesn't require renaming or editing the iso. Here's what I did:
#!/bin/sh
exec tail -n +3 $0
menuentry 'Clonezilla Live' {
set isofile="/boot/clonezilla-live-2.6.0-37-amd64.iso"
loopback loop $isofile
linux (loop)/live/vmlinuz boot=live config noswap edd=on nomodeset locales=en_US.UTF-8 keyboard-layouts=NONE ocs_prerun="dhclient -v enp12s0" ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch="no" ocs_daemonon="ssh" vga=788 nosplash toram findiso=$isofile
initrd (loop)/live/initrd.img
}Now Reboot to Clonezilla Once should boot the new iso instead of the old one, and bring up the ssh interface.
The only thing I'm not sure of is whether ryecoaaron's comment about updates wiping out changes applies to the grub config changes I made.