I compiled a (lm75) driver as a module to insert at run-time and and when tried to perform below
#insmod ./lm75.ko
I got the output as
Error: Driver 'lm75' is already registered aborting...
insmod: can't insert './lm75.ko': Device or resource busy
So, tried removing the same from kernel as below
#rmmod lm75.ko
which outputted
rmmod: can't unload module 'lm75': No such file or directory
let me know if I'm missing something else?
I'm using a script to run commands in u-boot which in turn is loading images (uImage, rootfs, dtb) from predefined locations in the MMC where as the recent version uImage is in wrong location (my fault). Hence, the uImage and rootfs loaded are different, whereas uImage has LM75.KO inserted (as it is a old image where LM75 is compiled as an built-in driver) and rootfs has no info about the LM75 (as it is latest one, in which LM75 is compiled as an kernel module). When, replaced with correct images the insmod and rmmod worked as expected. Hope this helps people like me :)
Related
I have a PC that usually used for Yocto image building. Now I need to add ROS2 packages to the same image. After all it's turned out the disk is full so I've connected a SSD external disk to build the image on it. I did the same steps as before, run the same command etc. but after the build starts if crashed at the first package. I've reinstalled all the sources from zero, I've deleted tmp and ssstate-cache but nothing help. I don't understand what this error says.
This is error trace log
As I see Yocto fail to write something into ssstate-cache/61, I don't really know what that is. A user has read/write permissions.
The build system: Ubuntu 20.04
Yocto version: zeus
In the linked error log, the relevant part is:
SignatureGeneratorOEBasicHash.dump_sigtask(fn='/media/sw/Samsung/yocto/sources/poky/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy-native.bb', task='do_fetch', stampbase='/media/sw/Samsung/yocto/build-xwayland/sstate-cache/61/sstate:texinfo-dummy-native::1.0:r0::3:610ed4b8e8bf78bbcd4a667b6645a0276f5c8bfce5de4822923850d44d032bbe_fetch.tgz.siginfo', runtime='customfile:/media/sw/Samsung/yocto/build-xwayland/tmp/stamps/x86_64-linux/texinfo-dummy-native/1.0-r0'):
os.chmod(tmpfile, 0o664)
> os.rename(tmpfile, sigfile)
except (OSError, IOError) as err:
OSError: [Errno 22] Invalid argument: '/media/sw/Samsung/yocto/build-xwayland/sstate-cache/61/sigtask.twkjztl9' -> '/media/sw/Samsung/yocto/build-xwayland/sstate-cache/61/sstate:texinfo-dummy-native::1.0:r0::3:610ed4b8e8bf78bbcd4a667b6645a0276f5c8bfce5de4822923850d44d032bbe_fetch.tgz.siginfo'
It is likely that the new name is not valid for the target disk filesystem. Typically the : character is invalid on FAT/NTFS filesystems. Native Linux filesystems like Ext4, XFS and Btrfs will not have this limitation.
In conf we added the following line:
shared_preload_libraries = 'passwordcheck'
After restart postgres, password check is supposed to take effect, and I can test by creating a simple password for the new role. My question is:
Is there any way to list preloaded (enabled) libraries, or show this lib has been successfully loaded?
You can examine the current setting of shared_preload_libraries to see which libraries were loaded at server start time. You can be certain that these libraries are loaded, because otherwise the server would have refused to start and stopped with an error message.
But there are many other ways to load an extension shared library into PostgreSQL, for example by calling C functions or using the LOAD statement. There is no way in PostgreSQL to determine all libraries that are currently loaded into your database backend process.
I have ubuntu version 18.04.3 running on virtual box.
I have been trying to install pintos on qemu, but when I run ./pintos run alarm-multiple my qemu is stuck on loading.
I am getting the following output:
**WARNING: Image format was not specified for '/tmp/5XpQ2ee16J.dsk' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write
operations on block 0 will be restricted.Specify the 'raw' format
explicitly to remove the restrictions.
qemu-system-x86_64: warning: TCG doesn't support requested feature:
CPUID.01H:ECX.vmx [bit 5]
PiLo hda1
Loading............
Kernel command line: run alarm-multiple
Pintos booting with**
Nothing is coming after pintos booting with
You are using an old version of pintos.
Use the latest version available here.
git://pintos-os.org/pintos-anon
i have a tomcat6 server running on a CentOS 6 machine and so far so good.
in one of my webapps i need to use a context param to access an external folder located in the filesystem, i configured my server.xml like this (relevant portion of <Host> tag only) :
<Context path="/userimages" docBase="/home/someuser/faces/32x32" debug="0" reloadable="true" crossContext="true"/>
when i start the server i get this error :
java.lang.IllegalArgumentException: Document base /home/someuser/faces/32x32 does not exist or is not a readable directory
i read something about folder permission so i set both "32x32" and "webapps" folder to 777, but it's still not working...any idea of how to fix this ?
P.S. on windows OS it works perfectly
My suggestion is to put your data into /usr/share/tomcat6/conf/context.xml which is a symlink to /etc/tomcat6/context.xml on CentOS 6. At least tomcat6 does read the contents of that file when it restarts, and I had some luck getting resource data loaded from there. It would seem that this file is new in tomcat6.
I used strace to check which files it was visiting and it does run stat() on the various files like /var/lib/tomcat6/webapps/*/META-INF/context.xml but nowhere does it actually open() those files, so I'm pretty sure it does not read the contents. Maybe some bug? Maybe imaginary future feature?
I managed to get Plandora (uses context to supply MySQL database connection details) running on CentOS 6 with these packages (from yum):
apache-tomcat-apis-0.1-1.el6.noarch
java-1.6.0-openjdk-1.6.0.0-1.61.1.11.11.el6_4.i686
mysql-connector-java-5.1.17-6.el6.noarch
tomcat6-6.0.24-52.el6_4.noarch
tomcat6-servlet-2.5-api-6.0.24-52.el6_4.noarch
tomcat6-el-2.1-api-6.0.24-52.el6_4.noarch
tomcat6-admin-webapps-6.0.24-52.el6_4.noarch
tomcat6-jsp-2.1-api-6.0.24-52.el6_4.noarch
tomcat6-lib-6.0.24-52.el6_4.noarch
tomcat6-webapps-6.0.24-52.el6_4.noarch
Just in case anyone else is trying to get Plandora to work on CentOS 6, you also need to make sure you symlink:
ln -s /usr/share/java/mysql-connector-java.jar /usr/share/tomcat6/lib/
I get this exception in PostgreSQL:
org.postgresql.util.PSQLException: ERROR: could not access file "$libdir/plpgsql": No such file or directory
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1721)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1489)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:193)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:236)
at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:205)
I searched a lot and most solution points to a wrong installation. But this is my test db which has been running without issues for a long time. Also inserts are working. Issue occurs only on select queries.
Apparently, you moved your PostgreSQL lib directory out of place. To confirm this, try the following in psql:
> SET client_encoding TO iso88591;
ERROR: could not access file "$libdir/utf8_and_iso8859_1": No such file or directory
If you get an error message like this, then my theory is correct. You'll need to find out where those files ended up, or you can reinstall PostgreSQL to restore them.
To find out what $libdir is referring to, run the following command:
pg_config --pkglibdir
For me, this produces:
/usr/lib/postgresql
I have the same problem: the other postgres server instance (8.4) was interfering with the 9.1 one; when the 8.4 instance is removed it works.
the other instance can sometimes be removed from the system while still running (e.g. you do a gentoo update and a depclean without stopping and migrating your data). so the error seems particularly mysterious.
the solution is usually going to be doing a slot install/eselect of the old version (in gentoo terms, or simply downgrading on other distros), running its pg_dumpall, and then uninstalling/reinstalling the new version and importing the data.
this worked pretty painlessly for me