Find out what's hanging: ps -ef --forest
I am not sure I was able to glean much more from ps, but an installation log was generated.
I went with the un-mount and re-mount read-only option. Now for the past hour the process has been stuck at:
Configuration file '/etc/collectd/collectd.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
==> Keeping old config file as default.
Setting up tasksel-data (3.53) ...
Setting up tasksel (3.53) ...
Setting up libdevmapper1.02.1:amd64 (2:1.02.155-3) ...
Setting up libdevmapper-event1.02.1:amd64 (2:1.02.155-3) ...
Setting up dmsetup (2:1.02.155-3) ...
update-initramfs: deferring update (trigger activated)
Setting up lvm2 (2.03.02-3) ...
Installing new version of config file /etc/lvm/lvm.conf ...
When I hit the Enter key the cursor moves one line down but nothing else happens.
I am able to open another SSH session though.
I am upgrading from 4 to 5. I've disabled all services, but did not remove any plug-ins. I am not sure what the error is other than something possibly related to 'NoneType' and the py?
Let's split this into three parts:
USB boot devices: Are you using some kind of chainloading? Or what are the specifics here? Important IMHO is to update grub at the boot device too especially if it is chain-loading. In this case the system upgrade will only update the grub MBR of the device holding the operating system. I left some hints in this first post of this thread about a general issue with grub.
Encrypted disks: You shoud read the Buster release notes as suggest by the first post too and check if you are affected by any of the changes listed there. If you have just a common setup you probably won't have any issues to expect.
Plugins: The scripts will remove the plugins not compatible with OMV 5. So this step is not mandatory.
No, I am not chainloading. I have three OMV servers. All of them boot from one (1) USB key. All just plain old vanilla installations as per OMV documentation.
Thanks, I will check out the Buster release notes.
Ok, remove plugins but not purge correct?
Thank you, Sir.
dleidert This is awesome! I have three systems all running 4.x. Only one of them uses an encrypted storage device. The boot devices for all three are USB keys. Are there any special considerations to be given? You mentioned a caveat re: encrypted drives but I am not sure I caught the specifics. Presumably if my boot devices have enough free space available it shouldn't make any difference that they are USB keys.
ryecoaaron Advises to uninstall all plug-ins when upgrading from 4.x to 5.x. Should I do this and after the upgrade re-install them will my plug-in configuration settings be lost?
Thanks for the great work!
Hi, mi-hol: I may consider that, thanks. I don't believe that's the issue here though. The option to allow for USB devices to persist has been around since kernel version 3.(?). I just can't figure out why my USB device is not showing under /sys/bus/usb/devices. It should show there as 1e1d:1101 which would then allow me to try out the persist option.
Thank for your feedback.
My boot device is a 8GB USB key. I would like to suspend my system to RAM and I've been testing to accomplish this with rtcwake.
rtcwake -v -m mem -s 60 will suspend my system successfully but errors after wake
Message from watchdog:
The system will be rebooted because of error 19 = 'No such device'
I suspect this is because the USB key does not get re-mounted after suspend.
I believe there's a way to have USB devices persist through suspend with echo 1 >/sys/bus/usb/devices/[USB_ID]/power/persist. [USB_ID] being the device ID, which in my case should be 1e1d:1101
This is my device in question
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1e1d ProdID=1101 Rev=01.00
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
But there's no such device ID under /sys/bus/usb/devices
1-0:1.0 2-4 3-0:1.0 4-4 4-5 5-0:1.0 7-0:1.0 usb1 usb3 usb5 usb7
2-0:1.0 2-4:1.0 4-0:1.0 4-4:1.0 4-5:1.0 6-0:1.0 8-0:1.0 usb2 usb4 usb6 usb8
Any feed back would be appreciate.
Are there any circumstances or reasons why a OGG file wouldn't be recognized by the DLNA server?
I've done some Google searches, but I haven't found anything useful. Some of my OGG files show others don't. It's driving me nuts.
I have a single 3TB internal hard drive that I would like to encrypt. I've installed the plug-in, but when I try to select a device, no devices show. My internal HD is listed under Disks and File Systems shows it as unmounted EXT4. When I try to Create and Select a Device my internal HD doesn't show. Any idea what's going on? I am stumped.
Hard to say. I haven’t had an OMV 2.x system running a long time. Even if something needed to be changed, I would recommend a fresh install of 3.x or 4.x.
That's not an option for me at this time. Thanks for you help.
Try it. It still applies. OMV 2.x has barely changed since 2016.
Ok, this doesn't work for me... or maybe I missed something in the instructions?
I select OMV-Extras.org and disable Sync on the Repos tab (Save & Apply); then I select Update Manager and select Check; no updates. Although SyncThing v0.14.46 has been released.
If I reverse my steps and re-enable Sync on the Repos tab and check updates again, I am getting the same error as before. It appears joker_75 is having the same issue.
On what version of OMV? Did you follow my directions in the post you quoted?
Did not follow the directions, since the solution provided dated back to 2016.
I've been running SyncThing and successfully applying updates prior to 2016 up until now. So the solution didn't appear to apply?
It isn't the syncthing plugin causing it. It is the repo that omv-extras adds. Syncthing changed their repo from http to https. If you go to it in a browser it works because it redirects to http. But apt doesn't follow the redirect. I fixed omv-extras yesterday. So, disable btsync/sync repo and update omv-extras. This will fix it.
This post is back from 2016... I am experiencing the same error today.
Err http://apt.syncthing.net syncthing/release amd64 Packages 301 Moved Permanently
W: Failed to fetch http://apt.syncthing.net/dists…ase/binary-amd64/Packages 301 Moved Permanently
E: Some index files failed to download. They have been ignored, or old ones used instead.
I see the same thing. I think this only happens on systems that have no RAID configured, so it's harmless.
Do you have RAID disks or not?
Fair enough... but it delays boot time. No, I don't have any RAID disks. Just a single internal HD. Thanks man
This is a fresh install ov OMV 4.0.9 to USB flash drive. During the install I had internal HD removed. With the HD removed boot generated no errors. After installing the HD I get the following error during boot. It repeats the same error message about 30 - 40 times before finishing the boot:
mdadm: no arrays found in config file or automatically
As elsewhere suggested I modified /etc/mdadm/mdadm.conf to include:
# definitions of existing MD arrays
ARRAY <ignore> devices=/dev/sda
Then I did: omv-mkconf mdadm
This generated the follwing error:
mdadm /etc/mdadm/mdadm.conf defines no arrays
I rebooted and still get the same error message again. So I checked /etc/mdadm/mdadm.conf and noticed that the line I added was gone, so I added it again and rebooted; and I am still getting the same error message.
Any idea how get rid off this error at boot?
To quickly elaborate on that: that's what the filesystem knows. All flash media don't allow to directly overwrite data (they implement pages and 'erase blocks') so in reality if just a few bytes are written at a time the amount of data written at the flash layer can be magnitudes higher than what happened at the filesystem layer.
The problem is the so called 'write amplification' and that's what the flashmemory plugin is for as @cabrio_leo already mentioned. This should be used always when running off pendrives or SD cards (or even quality SSDs, wear out can be delayed easily by a factor of 20 or more)
What I've done is use gddrescue to recover the USB flash drive to a "new" (different) one of the exact same model type and capacity. The recovery was 100% successful. I don't understand why e2fsck is not able to fix either the source USB flash drive nor the file system on the recovered one. This doesn't make any sense to me.