I’m surprised to keep seeing this ‘drive0’ all the time as it’s definitely no part of the config I created. That’s why I assumed that you must have put this into the config yourself, but since it now happened to a number of people, I’m obviously wrong there. Sorry @boob for blaming you in the first place.
Will see to rework the openHABian config but first I need to know if it would be sufficient to create the link or if I need to introduce that ‘drive0’ part into the config. So let’s try to get your setup working first.
(on my box it’s working without, so it’s difficult for me to simply reproduce the issue).
Note you needed to run ln -s . drive0 in /mnt/openhab-backup/slots directory (note the …/slots) or you use absolute pathes: ‘ln -s /mnt/openhab-backup/slots/mnt/openhab-backup/slots/drive0’.
Although in the wrong place, it’s also strange that you cannot create that link. Does there exist any file or directory called drive0 in the directory where you tried to create the link in ? Get me the ouput of a ‘ls -l’ in that dir, please.
You cannot create the dir first and make a link next.
Remove the dir (rmdir drive0) and ONLY create the link.
While you’re there, also do ln -s /mnt/openhab-backup/slots drive1 and insert a line taper-parallel-write 2 after the tpchanger line in amanda.conf
Possibly. Try a hard link (no -s).
As you’re the third to come up with this strangeness this week, why the heck do people keep using CIFS to mount a share from a UNIX server (your NAS) to a UNIX client (your Pi) ? Use NFS instead.
It’s shared from my windows-machine, so not much choice for me…
[18:54:11] openhabian@openHABianPi:/mnt/openhab-backup/slots$ ln /mnt/openhab-backup/slots drive0
ln: ‘/mnt/openhab-backup/slots’: hard link not allowed for directory
[18:56:05] openhabian@openHABianPi:/mnt/openhab-backup/slots$ sudo ln -d /mnt/openhab-backup/slots drive0
ln: failed to create hard link ‘drive0’ => ‘/mnt/openhab-backup/slots’: Operation not permitted
Does not make much sense as you won’t be running your Windoze 24x7, always ready to take nightly Amanda backups, will you ? Better put in a USB stick. Or try the AWS S3 variant.
After a bit of googling it seems cifs don’t mix very well with symlinks, and that’s probably what Amanda is trying to make as well, so this is a dead end.
@mstormi@pacive I sat up a NFS share, but had the same problem with the missing drive0 directory. Fortunately I could execute ln -s to create the symlink without any problem.
@mstormi No success. Starting amcheck openhab-dir leads to increasing load (up to 3) and nothing ever happened to slots. The same with amdump openhab-dir.
NFS connection shows up after reboot easily. No problem to access files from the one or the other side.
Are there any log files I can provide for examining?
Any other ideas?
First thing I’d try is to remove the raw SD device from the list of to be dumped filesystems (delete mmcblk0 line in /etc/amanda/openhab-dir/disklist). To dump or even just estimate dump size (which is the first step actually, and likely executed on first startup) of large SD cards takes very long. I’ve already removed that from future default configs.
There’s rather verbose logs by default in /var/log/amanda. Note there’s a client and a server component involved, so for each command, there’s at least 2 logfiles to inspect
Run ‘amcleanup openhab-dir’ as backup user and try to get amcheck to work next. Don’t go for amdump until amcheck works.
$ apt -y install screen vim nano mc vfu bash-completion htop curl wget multitail git bzip2 zip unzip xz-utils software-properties-common man-db whiptail acl usbutils
Reading package lists... Done
Building dependency tree
Reading state information... Done
acl is already the newest version.
bash-completion is already the newest version.
bzip2 is already the newest version.
curl is already the newest version.
git is already the newest version.
htop is already the newest version.
mc is already the newest version.
multitail is already the newest version.
nano is already the newest version.
screen is already the newest version.
software-properties-common is already the newest version.
unzip is already the newest version.
vfu is already the newest version.
vim is already the newest version.
wget is already the newest version.
whiptail is already the newest version.
whiptail set to manually installed.
xz-utils is already the newest version.
zip is already the newest version.
The following packages were automatically installed and are no longer required:
lua5.1 triggerhappy
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
libusb-1.0-0
Suggested packages:
groff www-browser
The following NEW packages will be installed:
libusb-1.0-0 usbutils
The following packages will be upgraded:
man-db
1 upgraded, 2 newly installed, 0 to remove and 43 not upgraded.
1 not fully installed or removed.
Need to get 1,217 kB of archives.
After this operation, 1,385 kB of additional disk space will be used.
Get:1 http://archive.raspberrypi.org/debian/ jessie/main man-db armhf 2.7.5-1~bpo8+1 [979 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian/ jessie/main libusb-1.0-0 armhf 2:1.0.19-1 [42.4 kB]
Get:3 http://mirrordirector.raspbian.org/raspbian/ jessie/main usbutils armhf 1:007-2 [196 kB]
Fetched 1,217 kB in 0s (1,904 kB/s)
Preconfiguring packages ...
(Reading database ... 39252 files and directories currently installed.)
Preparing to unpack .../man-db_2.7.5-1~bpo8+1_armhf.deb ...
Unpacking man-db (2.7.5-1~bpo8+1) over (2.7.0.2-5) ...
Selecting previously unselected package libusb-1.0-0:armhf.
Preparing to unpack .../libusb-1.0-0_2%3a1.0.19-1_armhf.deb ...
Unpacking libusb-1.0-0:armhf (2:1.0.19-1) ...
Selecting previously unselected package usbutils.
Preparing to unpack .../usbutils_1%3a007-2_armhf.deb ...
Unpacking usbutils (1:007-2) ...
Processing triggers for mime-support (3.58) ...
Setting up initramfs-tools (0.120+deb8u3) ...
update-initramfs: deferring update (trigger activated)
Setting up man-db (2.7.5-1~bpo8+1) ...
Installing new version of config file /etc/manpath.config ...
Updating database of manual pages ...
Setting up libusb-1.0-0:armhf (2:1.0.19-1) ...
Setting up usbutils (1:007-2) ...
Processing triggers for initramfs-tools (0.120+deb8u3) ...
ln: failed to create hard link ‘/boot/initrd.img-4.9.0-2-rpi2.dpkg-bak’ => ‘/boot/initrd.img-4.9.0-2-rpi2’: Operation not permitted
cp: error writing ‘/boot/initrd.img-4.9.0-2-rpi2.dpkg-bak’: No space left on device
cp: failed to extend ‘/boot/initrd.img-4.9.0-2-rpi2.dpkg-bak’: No space left on device
dpkg: error processing package initramfs-tools (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.19-18+deb8u9) ...
Errors were encountered while processing:
initramfs-tools
[master 1b6faf5] committing changes in /etc after apt run
Author: pi <pi@openHABianPi>
1 file changed, 1 insertion(+), 1 deletion(-)###############################################....................]
Updating FireMotD available updates count ...
E: Sub-process /usr/bin/dpkg returned an error code (1)
Hey guys,
i see that the errors says no space left on device…but i cannot understand why i got a 16GB sd card in the RPI2…So what could this be or how can i see how much space is left or something…
