Hi i want to install MinorFS 0.3.5 to my computer. My Ubuntu version is 14.04 LTS. But i had some problems while installing the program.
Firstly i installed all fuse modules and gcc and run the script install.pl.
The program is designed for Ubuntu 8. As a result it wants to install fuse module to start the script install.pl.
But there is not a loadable fuse module for Ubuntu 14.04 LTS. I research about it and i see that, for the latest version of Ubuntu, the kernel is configured to include FUSE instead of compiling it as a module. So, i modified the perl code in install.pl and
install the script.(I install fuseiso with command apt-get install fuseiso just in case.)
Everyting is great for the moment. But for the next step, i run the command on terminal "/etc/init.d/minorfs start ".
And i get this error : " The path specified in /var/minorfs/viewfs.startcap is not a valid base dir for minorviewfs
"
This command runs the minorcapfs and minorviewfs i guess.Minorcapfs run succesfully but for minorviewfs i got this error.
The code which gives the Error writen below:(in minorviewfs file)
unless (-d $basepath) {
print STDERR "The path specified in $VARDIR/viewfs.startcap is not a valid base dir for minorviewfs\n";
exit 1;
}
Then for test, i print my " $basepath " and it's : /mnt/minorfs/cap/61ce0488ac06eba530e178a0d1716ec576b47f71
I couldn't solve this error.
Please help me to get rid of this problem.
Thank you!
I solved the problem with manually making a directory with the mkdir command. Now the script work. But now I have a different problem. The output is ;
Starting MinorFs filesystems minorcapfs going into background, consult syslog for information minorviewfs going into background, consult syslog for information.
Then when i run the command ls -la /mnt/minorfs/priv
i should get a links to the folders. But I have nothing.
dr-xr-xr-x 1 root root 0 Jan 1 1970 .
lrwxrwxrwx 1 root root 0 Jan 1 1970 home ->
lrwxrwxrwx 1 root root 0 Jan 1 1970 tmp ->
So i looked the system log file with gedit /var/log/syslog and i see that Error;
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: Problem in Fuse::main at /usr/local/bin/minorcapfs line 340
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: user: 0 1001 ; group 104 104 104 104 at /usr/local/bin/minorcapfs line 341
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: Probably a problem accesing /dev/fuse at /usr/local/bin/minorcapfs line 342
Sep 1 13:52:01 burak-UX31A minorviewfs[3584]: Use of uninitialized value in subroutine entry at /usr/lib/perl5/Fuse.pm line 147, line 26.
And this the MinorCapfs code ; http://codepad.org/nUUJ3b5m
How to get rid of this problems? Thank you.
Related
Downloaded from here
Untarred, mkdir build, mkdir PC, executed...
../../gdb/configure --target=arm-linux-gnueabihf
returned...
../../gdb/gdbsupport/common-defs.h:33:10: fatal error: ../../gnulib/config.h: No such file or directory
#include "../../gnulib/config.h"
There was a 'gnulib' package I could install, installed it and it made no difference
Edited ../../gdb/gdbsupport/common-defs.h and found one header include based on gdbserver/gdb.
#ifdef GDBSERVER
#include "build-gnulib-gdbserver/config.h"
#else
#include "../../gnulib/config.h"
#endif
Go back two levels and there is a gnulib directory but no config.h, ll shows
-rw-rw-r-- 1 user user 51507 May 23 15:10 aclocal.m4
-rw-rw-r-- 1 user user 2417 May 23 15:10 ChangeLog
-rw-rw-r-- 1 user user 69989 May 23 15:10 config.in
-rw-rw-r-- 1 user user 743485 May 23 15:10 configure
-rw-rw-r-- 1 user user 1625 Feb 8 05:49 configure.ac
drwxrwxr-x 5 user user 4096 Jun 2 14:53 import/
-rw-rw-r-- 1 user user 739 May 23 15:10 Makefile.am
-rw-rw-r-- 1 user user 58332 May 23 15:10 Makefile.in
drwxrwxr-x 2 user user 4096 Jun 2 14:53 patches/
-rw-rw-r-- 1 user user 249 Sep 20 2019 README
-rwxrwxr-x 1 user user 5641 May 23 15:10 update-gnulib.sh
So in the process of writing out the end of my question I put two and two together and am just answering so no one else has to go through this.
As you'll notice configure in gnulib is not executable, so first I ran 'chmod +x configure' Before running it I figured I would go back into my build/PC directory to run configure from there to see if that would recursively configure gnulib, but that did not seem to be the case. You will need to execute ./configure inside of the gnulib directory to generate the config.h. I think regardless of you cross compiling or not you want gnulib to NOT have an explicit target, looks like it'll be used solely for the purpose of building GDB.
After running ./configure you'll now notice you have a config.h, yeahhhhhhh! Now go back to your build/PC directory and run make. Guess what? It will now complain about having already configured the gnulib directory and you need to clean up for make to work. "But Joe!", you say, "Won't that remove the config.h we so desperately needed?" "Yes! Yes it will!" So you need to move your config.h elsewhere, execute 'make distclean' inside of the gnulib directory, go back to your build directory, just wipe it out completely because you'll have issues due to the mixed configurations, re-configure yet again, DON'T FORGET TO COPY CONFIG.H BACK INTO GNULIB/, then run make.
All in a days work.
I have installed clamav in Ubuntu 18.04 using
'''sudo apt-get install clamav'''
and tried clamscan but showing the error as follows:
LibClamAV Error: cli_loaddbdir(): No supported database files found in /var/lib/clamav
ERROR: Can't open file or directory
----------- SCAN SUMMARY -----------
Known viruses: 0
Engine version: 0.102.1
Scanned directories: 0
Scanned files: 0
Infected files: 0
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.004 sec (0 m 0 s)
***
After googling I removed entire clamav, installed again and tried sudo freshclam command, but showing the following error all times when clamav is updating:
Mon Jan 27 21:51:53 2020 -> ^Download failed (28) Mon Jan 27 21:51:53 2020 -> ^ Message: Timeout was reached
Mon Jan 27 21:51:53 2020 -> ^getcvd: Can't download daily.cvd from https://database.clamav.net/daily.cvd
Mon Jan 27 21:51:53 2020 -> Trying again in 5 secs...
^CMon Jan 27 21:51:57 2020 -> Update process terminated
It consumed my entire data and at final I terminated the process. I tried it more that 5 times, same result persist. Anybody please help me to figure out this issue.
Also I need to know which AV is better for Ubuntu Clamav or Comodo?
Thanks
It seems to be timing out getting the virus definition database. Are you able to connect directly to https://database.clamav.net/daily.cvd
It's a fairly large file (~58 MB) so it might not work if you're on a limited connection.
I try to get the name of the folder / file pointed by the symbolic link.
For example, when you do ls -l
You can get this result
-rw-r--r-- 1 macos staff 0 Feb 22 12:05 test
lrwxr-xr-x 1 macos staff 7 Feb 19 11:05 sl -> test
How could I do, if I know the path of sl to get the file/folder here it pointed to ?
I want to do it using stat if possible.
Any suggestion ?
So to summarize :
It's impossible to get the name of the file/folder pointed by a symbolic link, using lstat or stat.
The function readlink can do the job => Man : http://man7.org/linux/man-pages/man2/readlink.2.html. You will get example in the man
Thank you for helping me solve my problem
I have configured a private APT repository (using resources on internet like http://inodes.org/2009/09/14/building-a-private-ppa-on-ubuntu/) and I'm uploading for the first time my package containing the sources of my C++ application.
So reprepro repository is empty.
I use the following command in order to start the build:
sudo reprepro -V -b /srv/reprepro processincoming incoming
Then the build start, a lot of output is genearated and I can see that pbuilder is compiling the project source code and everything is fine. I can even find in the result/ folder debian packages etc...
But the build failed with a POST_BUILD_FAILED because it seems that pbuilder has changed the douane-testing_0.8.1-apt1.debian.tar.gz file and the md5 sum is now different as shown here:
File "pool/main/d/douane-testing/douane-testing_0.8.1-apt1.debian.tar.gz" is already registered with different checksums!
md5 expected: 97257ae2c5790b84ed7bb1b412f1d518, got: df78f88b97cadc10bc0a73bf86442838
sha1 expected: ae93c44593e821696f72bee4d91ce4b6f261e529, got: d6f910ca5707ec92cb71601a4f4c72db0e5f18d9
sha256 expected: c3fac5ed112f89a8ed8d4137b34f173990d8a4b82b6212d1e0ada1cddc869b0e, got: ebdcc9ead44ea0dd99f2dc87decffcc5e3efaee64a8f62f54aec556ac19d579c
size expected: 2334, got: 2344
There have been errors!
I don't understand why it is failing as when I compare the 2 packages (having those md5 sums) the content is strictly the same (I used a diff tool but no differences and no new or removed files).
The only thing I can see is that the archive from pbuild is bigger of 10 Bytes than the orginal one I have uploaded:
On my development machine, the file with the md5 97257ae2c5790b84ed7bb1b412f1d518 :
-rw-r--r-- 1 zedtux zedtux 2334 Feb 3 23:38 douane-testing_0.8.1-apt1.debian.tar.gz
On my server, the file with the md5 df78f88b97cadc10bc0a73bf86442838 :
-rw-r--r-- 1 root root 2344 Feb 5 00:58 douane-testing_0.8.1-apt1.debian.tar.gz
I have pbuild version 0.213 on my server.
What could be the reason of this behavior and how can I fix it ?
Edit
I'm suspecting an issue with the GPG key which looks missing and then files aren't signed so md5sum is different.
During the build process I have the following lines:
I: Extracting source
gpgv: Signature made Wed Feb 5 22:04:37 2014 UTC using RSA key ID 9474CF36
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./douane-testing_0.8.1-apt1.dsc
Edit 2
I have tried to find the command to create manually the .debian.tar.gz file.
The best I've found is the following:
tar cv debian | gzip --no-name --rsyncable -9 > douane-testing_0.8.1-apt1.debian.tar.gz
I don't get the same result than dpkg-source but I tried the same command on my server (I should at least have the same size) but it's not matching...
Could it be that Debian and Ubuntu aren't compressing the same way ?
Finally after some evenings of research I found the solution on launchpad.net !
Found the solution. By default pbuilder calls dpkg-buildpackage like so:
DEBBUILDOPTS="$DEBBUILDOPTS -rfakeroot"
dpkg-buildpackage -us -uc $DEBBUILDOPTS
That causes dpkg-buildpackage to rebuild the diff.gz and .dsc files. Add a -b in there, and it won't. It also means the resulting .changes file will only reference the .deb file. Which is what you want, I think.
The easy solution is to add a line to your .pbuilderrc:
DEBBUILDOPTS="-b"
My previous answer is alright but is not complete.
Then I had the issue that reprepro complains about the source tarball (.orig.tar.xz).
But it was normal as I wasn't doing the packages correctly.
I have written a bash script which I'm executing in VM for each Ubuntu series.
This script was always doing everything from scratch, and was using dh_make --createorig argument and here is the issue.
The correct way is to generate once (for example on Ubuntu precise) and then re-use the .orig.tar.xz file and no more use the --createorig argument of dh_make.
I hope this could help someone :-)
I'm trying to use a somewhat old DAQ, and had to jump through a few hoops to get an old (circa 2004) device driver for it to compile (DTI-DT340 Linux-DAQ-PCI).
I've gotten to the point where it compiles, I can load the kernel module, it finds the card, and I can create the character devices using mknod.
But I can't seem to open these devices and keep getting errno 19 (ENODEV) 'No such device' when I try to
open("/dev/dt340/0",O_RDWR);
but mknod had no complaints about making it, and it's there:
# ls -l /dev/dt340/
total 0
crw-rw-r-- 1 root staff 250, 0 2009-04-23 11:02 0
crw-rw-r-- 1 root staff 250, 1 2009-04-23 11:02 1
crw-rw-r-- 1 root staff 250, 2 2009-04-23 11:02 2
crw-rw-r-- 1 root staff 250, 3 2009-04-23 11:02 3
Is there something I'm neglecting to do? What might be a reason open fails?
Here's the script I use to load the driver and make the devices.
#!/bin/bash
module="dt340"
device="dt340"
mode="664"
# invoke modprobe with all arguments we were passed
#/sbin/modprobe -t misc -lroot -f -s $module.o $* || exit 1
insmod $module.ko
# remove stale nodes
rm -f /dev/${device}/[0-3]
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
mkdir -p /dev/${device}
mknod /dev/${device}/0 c $major 0
mknod /dev/${device}/1 c $major 1
mknod /dev/${device}/2 c $major 2
mknod /dev/${device}/3 c $major 3
# give appropriate group/permissions, and change the group
# not all distributions have staff; some have "users" instead
group="staff"
grep '^staff:' /etc/group > /dev/null || group="users"
chgrp $group /dev/${device}/[0-3]
chmod $mode /dev/${device}/[0-3]
Some additional info:
#grep dt340 /proc/devices
250 dt340
# lsmod | grep dt340
dt340 21516 0
# tail /var/log/messages
Apr 23 11:59:26 ve kernel: [ 412.862139] dt340 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Apr 23 11:59:26 ve kernel: [ 412.862362] dt340: In function dt340_init_one:
Apr 23 11:59:26 ve kernel: [ 412.862363] Device DT340 Rev 0x0 detected at address 0xfebf0000
#lspci | grep 340
03:01.0 Multimedia controller: Data Translation DT340
ANSWER: A printk confirmed that the -ENODEV was thrown from inside open(). Following an oldstyle
while ((pdev = pci_find_device(PCI_VENDOR_ID_DTI, PCI_ANY_ID, pdev)))
(which is deprecated), if(!pdev) ends up true, and returns the -ENODEV.
I'm inching closer - I guess I have to work through and update the pci code to use more modern mechanisms...
If the device shows up in /proc/devices, and you're sure you've got the number right in mknod, then the driver itself is refusing the open. The driver can return any error code from open() - including "no such device", which it might if it discovered a problem initialising the hardware.
I'd guess it is a problem in the driver, check the open function.
It shows up in /proc/devices, so all the generic device stuff seems to be ok.
mknod doesn't care if there is an device corresponding to the given major/minor numbers. Are you sure insmod is installing your module? What does lsmod tell you?
I'm unfamiliar with having to add the ".ko" extension. Is that something specific to your device driver?
Check through lspci and make sure hardware is properly initialized. If your system supports hotplug, pci_find_device won't work. The problem with this is a refcnt. The best way to deal and learn is to dissect the API. BOL !!