I am having the same issue with Sabrent USB-SATA adapters giving the same Serial Numbers. Noting the UDEV database work a few years ago, is there a "fix for Dummies" I can apply?
My common SNs are WY22VE1Y & WD-WXK1A10X4320.
I do use /dev/disk/by-UUID, however, it would make life easier to be able to trust the SNs.
I have been forced to reinstall OMV on my Rock64 and I am struggling with the armhf ayufan version. I need perl 2.060 or later and the system tells me I have the latest version at 2.044.
I am happy to try the armbian OMV version in the hope this might fix my issue. Can someone point me to the image - I can't find it anywhere? (... and will it resolve the perl version issue?)
Further to the message above, my NAS' internal back-up was unmounted as the back-up cron job started. Has anyone any thoughts on why this might be happening (syslog attached for 02:30, the time of the cron job).
For the past three years I have had occasional spontaneous unmounts of the second, back-up drive on my NAS. The unmounts seem to occur when my rsync job backs-up the master drive (Boss) to the back-up (Slave). NB, to re-mount the disc I just click on Mount, I do not have to then click on Apply and Agree.
When I ran a test of rsync today both the master and the back-up unmounted.
The ROCK 64 and the two discs get power from a regulated Power Supply, where each drive is powered using a ROCK64 USB 3.0 to SATA III hard drive adapter cable/converter with UASP. The power supply delivers more than enough power for the set-up, and for additional devices, e.g. additional back-up discs - none was attached at the time of the unmount.
Are you able to suggest a reason for the unmount and whether there might be a fix? In case it helps I have attached an edited syslog from the time of the unmount.
My var/log has filled completely.
ness1602, does this command purge var/log periodically? Can I presume that I just enter this in to Scheduled Jobs after setting the time?:
find /var/log/ -type f -mtime 90 -exec rm -rf {} \';
DHGE, when would I run these commands?
Thanks.
Thanks for the replies. I have fixed the issue but I don't know how I did it.
I had previously tried setting the Europe/London option but:
1. it made no difference to the Current Time, it remained incorrect and lagged the Manual Time by 1 hour
2. if I clicked "Update Now" the system automatically switched the time to UTC and the Current Time remained 1 hour behind the greyed-out Manual Time
After macom's comment I tried setting the system to Europe/Berlin but the time stayed as before, Manual Time was correct for the UK (i.e. CEST -1h) and Current Time was 1 hour behind (i.e. CEST -2h). Clicking on "Update Now" forced the system back to UTC and the Current Time 1 hour behind the true UK time.
I then changed the manual time to something ridiculous, say two hours and ten minutes ahead of now. I clicked "Upgrade Now" and was kicked out of the system. When I logged back in the Current Time was correct and the Manual Time was greyed-out and 1 hour in advance (i.e. CEST).
So, I don't know how it happened but it is now correct.
Thanks for your help.
Since the change in the clocks in the UK my system has remained on GMT and has not adjusted to British Summer Time (BST = GMT+1).
In Settings/Date & Time I have time set to UTC which shows the Current Time as 1 hour behind UK time. The correct time is shown in the Manual section (and is greyed out).
Running TZselect shows:
- Local time is now:Sat Apr 27 10:40:48 BST 2019.
- Universal Time is now:Sat Apr 27 09:40:48 UTC 2019.
Can someone tell me how to have the system operate under BST?At the moment my Cron back-up runs an hour late and my music server displays GMT not BST.
Is there a (simple) way of getting faad running on my Rock64? I need it to make my Logitech Media Server (Squeezebox Server) work fully.
The Server worked fine under OMV_3_Rock64 but it isn't transcoding AAV under OMV_4_Rock64.img.xz.
Thank you.
I tried apt-get -f install but got this:
Errors were encountered while processing:
lvm2
openmediavault
openmediavault-flashmemory
I think a fresh install is needed.
Thanks for the reply.
I hadn't looked at the log as this is alien territory to me. I have now looked and the log starts at 07:35:23 today so it is too late to be useful.
Quite separately I followed the suggestion to move up to OMV4 by entering omv-release-upgrade in PuTTY. Now I can only see the system on PuTTY, I can't see it in my browser, http://192.168.1.180/ just times out. I've tried rebooting and it makes no difference.
This is now veering off topic but is there a ready fix for this? The end of the upgrade had the following text:
dpkg: man-db: dependency problems, but processing triggers anyway as you requested:
man-db depends on bsdmainutils; however:
Package bsdmainutils is not configured yet.
man-db depends on libgdbm3 (>= 1.8.3); however:
Package libgdbm3:armhf is not configured yet.
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
openmediavault-flashmemory
folder2ram
My Rock64 has two discs attached to it, the first (Boss) holds all of my data and back ups, the second (Slave) is a scheduled rsync copy of Boss that runs at 02:30 daily.
Last night both discs spontaneously unmounted at around 02:39 (the time of a system email). Any idea why this might happen?
This scheduled job has run largely unchanged for the past 6 months. The only modification is I upgraded Slave two days ago and enabled write cache. I left it copying Boss during the day yesterday.
I got a "sending incremental file list" message at 02:30 which indicated that Slave was an exact copy of Boss.
For the record I am getting several daily CRON-APT messages about "Failed to fetch http://security.debian.org/dists/jessie/updates/InRelease Unable to find expected entry 'main/binary-arm64/Packages' in Release file".
OK, and thanks for the confirmation that I need not worry. The comments on checking the card are interesting.
All previous installations have used Win32DiskImager. When I have time after Christmas I'll look at rebuilding.
Thanks for the reply. Interestingly the SD card is only about 3 months old so I'd be surprised if it were wearing out already.
I ran dpkg --verify. I don't know how to interpret the results (given below) - I'm guessing that since it didn't post any errors that things are ok?
# dpkg --verify
??5?????? c /etc/netatalk/afp.conf
??5?????? c /etc/cron-apt/action.d/3-download
??5?????? c /etc/cron-apt/config
??5?????? /usr/share/doc/python3.4-minimal/changelog.Debian.gz
??5?????? /usr/share/doc/python3.4-minimal/copyright
??5?????? /usr/share/doc/quotatool/README
??5?????? /sbin/mkfs.xfs
??5?????? /usr/share/unicode/extracted/DerivedCombiningClass.txt
??5?????? /usr/share/doc/python3/copyright
??5?????? c /etc/watchdog.conf
??5?????? /usr/lib/arm-linux-gnueabihf/libdbus-glib-1.so.2.2.2
??5?????? /usr/share/doc/socat/README.gz
??5?????? /usr/share/doc/socat/socat-openssltunnel.html
??5?????? c /etc/default/monit
??5?????? c /etc/monit/monitrc
??5?????? c /etc/ntp.conf
??5?????? c /etc/collectd/collectd.conf
??5?????? c /etc/updatedb.conf
??5?????? c /etc/hdparm.conf
??5?????? /usr/share/doc/python3-gi/changelog.gz
??5?????? c /etc/default/smartmontools
??5?????? c /etc/smartd.conf
??5?????? /var/lib/smartmontools/drivedb/drivedb.h
??5?????? /usr/share/doc/tar/changelog.gz
??5?????? c /etc/cron.daily/mdadm
??5?????? /sbin/mdmon
??5?????? /usr/share/doc/rsync/changelog.gz
??5?????? c /etc/sysctl.conf
??5?????? c /etc/default/avahi-daemon
??5?????? c /etc/avahi/avahi-daemon.conf
??5?????? c /etc/issue
??5?????? c /etc/default/acpid
??5?????? c /etc/default/collectd
??5?????? /usr/share/doc/python3-software-properties/changelog.gz
??5?????? c /etc/default/rrdcached
??5?????? c /etc/init.d/rrdcached
??5?????? /usr/bin/armbianmonitor
??5?????? /etc/init.d/armhwinfo
??5?????? /etc/cron.daily/log2ram
??5?????? /etc/armbian-release
??5?????? /etc/default/cpufrequtils
??5?????? /etc/update-motd.d/41-armbian-config
??5?????? /etc/update-motd.d/99-point-to-faq
??5?????? /etc/update-motd.d/10-header
??5?????? /usr/lib/python2.7/collections.py
??5?????? c /etc/default/openmediavault
??5?????? /usr/lib/python2.7/argparse.py
??5?????? /usr/share/doc/software-properties-common/changelog.gz
#
Logging in to PuTTY there was a remark to run apt-get update. This gave the error below. Do I need to worry?
Errors were encountered while processing:
/var/cache/apt/archives/python-samba_2%3a4.2.14+dfsg-0+deb8u9_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)I tried a few Google suggestions (below) but none removed the error:
apt-get clean
apt-get update && apt-get upgrade
dpkg --configure -a
apt-get -f install
mount -t proc proc /procThe full text of the response to apt-get update && apt-get upgrade is:
Traceback (most recent call last):
File "/usr/bin/pyclean", line 32, in <module>
from debpython.namespace import add_namespace_files
File "/usr/share/python/debpython/namespace.py", line 28, in <module>
from debpython.pydist import PUBLIC_DIR_RE
File "/usr/share/python/debpython/pydist.py", line 29, in <module>
from debpython.version import vrepr, getver, get_requested_versions
File "/usr/share/python/debpython/version.py", line 24, in <module>
from ConfigParser import SafeConfigParser
ValueError: bad marshal data (unknown type code)
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
Traceback (most recent call last):
File "/usr/bin/pyclean", line 32, in <module>
from debpython.namespace import add_namespace_files
File "/usr/share/python/debpython/namespace.py", line 28, in <module>
from debpython.pydist import PUBLIC_DIR_RE
File "/usr/share/python/debpython/pydist.py", line 29, in <module>
from debpython.version import vrepr, getver, get_requested_versions
File "/usr/share/python/debpython/version.py", line 24, in <module>
from ConfigParser import SafeConfigParser
ValueError: bad marshal data (unknown type code)
dpkg: error processing archive /var/cache/apt/archives/python-samba_2%3a4.2.14+dfsg-0+deb8u9_armhf.deb (--unpack):
subprocess new pre-removal script returned error exit status 1
Traceback (most recent call last):
File "/usr/bin/pycompile", line 35, in <module>
from debpython.version import SUPPORTED, debsorted, vrepr, \
File "/usr/share/python/debpython/version.py", line 24, in <module>
from ConfigParser import SafeConfigParser
ValueError: bad marshal data (unknown type code)
dpkg: error while cleaning up:
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/python-samba_2%3a4.2.14+dfsg-0+deb8u9_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)Thanks.
Fixed, thank you.
OMV didn't like the spaces. I had previously tried <Back\ Up\ I> but this didn't work, either. So it is now <BackUp1> and all is well.
Thank you.
I did that but there is nothing under:
/media/dev-disk-by-label-Back Up I It's an empty folder.
It is still all under:
/media/dev-disk-by-id-usb-HitachiG_ST_21001205140000007959-0-0-part1
Very puzzled.
I have not managed to get my USB discs to be visible by label in WinSCP. By editing config.xmland running omv-mkconf fstab I unwittingly generated a new entry in WinSCP:
Original entry:
/media/dev-disk-by-id-usb-HitachiG_ST_21001205140000007959-0-0-part1
New additional entry:
/media/dev-disk-by-label-Back Up I
The new entry has no sub-folders. I couldn’t work out how to unregister the disc and tried:
echo 1 > /sys/block/sda/device/deleteThis only lost the disc in the OMV GUI.
Can you say what entries/edits I need to do make to achieve the desired result, please?
I am worried but I don't know what to do. I gave the output of hdparm because it shows clearly that the actual disc serial number is different from that under the OMV GUI. Can you advise what dmesg is and what I look for in /var/log/syslog?
I originally thought that the disc was at fault because it became unallocated, it lost all formatting and was unreadable. Could the OS cause this? I presumed it was a disc failure, even though the disc is new.
I'm not sure about the old image of RPi - I'm using OMV 3.0.59.
OK, thanks. Somehow it has worked for the last year, referencing the UUIDs, so the Serial Numbers were ignored.
My biggest worry is how a disc could just go "unallocated". This is more disturbing as this disc is going to be my master back-up. I don't want it to become unallocated at some future date.
Your comment on USB-SATA cables is interesting. I don't recall whether the serial numbers were identical before I changed one of the discs - they had run happily together for more than a year. My concern is to ensure that it is not the identical serial numbers which are causing my disc to disappear and become unallocated.
Entering your proposed command I get:
-bash: armbianmonitor: command not foundMeanwhile I get this with hdparm:
hdparm -I /dev/sd? | grep 'Serial\ Number'
Serial Number: WD-WXK1A10X4320
Serial Number: WCC2RCP3So the system sees the real serial numbers whilst the OMV GUI gives different serial numbers, identical for both discs (even when using different USB-SATA cables). That serial number is 116AC2101219.
As I say, my concern is to avoid a repetition of the vanishing disc. If identical GUI serial numbers are a non-issue, I'll try again with moving all of my data on to the new disc.
Incidentally, it shouldn't be a power supply problem as I run everything from a powered hub and have had previously had three cohabiting discs - I only had two discs when the new one became unallocated.