I have been using Qt Creator for some time now without a problem. Now i try to start it and it just doesn't. It looks like it's loading and then it crashes.
I have tried to fix it by reinstalling it several times, i deleted all the config files, just in case, nothing.
I'm on Arch Linux and here is the error it throws when i launch it from the terminal:
/usr/bin/qtcreator: line 2: 4379 Bus error (core dumped) QT_LOGGING_TO_CONSOLE=1 qtcreator-bin $#
Try to run qtcreator in gdb to find out where (in which library) it crashes. Try to reinstall that library.
Or: I assume you installed qtcreator via your distribution packages. QT offers binary packages for qtcreator, which you can try.
Got similar. Debugging into showed that systemd service cannot open journal files properly (memory mapped it is, thats why SIGBUS).
You can test with issuing command and seeing output like below:
journalctl --disk-usage
An error was encountered while opening journal file or directory /var/log/journal/606980f452a14d4bb7327a74a7ff41ee/system#00057ba473706a85-48f3052664924467.journal~,
ignoring file: Input/output error Archived and active journals take up
171.0M in the file system.
To fix that you must do full disk check (on start, press E in grab and add kernel parameter fsck.mode=force).
Then delete all journals and restart service (well, you will lose some old messages, add path where you journals are according to prev ouput):
sudo rm -rf /var/log/journal
sudo systemctl kill --kill-who=main --signal=SIGUSR2 systemd journald.service
Problem will go away itself in couple days maybe, if systemd will do rotation and delete old journals. Any way, in my case it was caused by power loss.
Related
Since I installed according to the guide here on wsl2 ubuntu 20.04, I've been having errors related to libstc++.so.6, specifically GLIBCXX_3.4.26 not found (required by ...) where ... refers to different files within /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/ ending in .so, .so.1, .so.6 and so on (for instance, when running paraFoam the error would appear with respect to about 20 such files). I am able to successfully visualize the cavity tutorial (in paraview installation on windows).
I could get the errors to go away by doing what the user laborg suggested on Jan 4 for a similar problem with julia (see here), specifically copy libstdc++.so.6 from /usr/lib/x86_64-linux-gnu to /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/.
The questions is whether this copy-paste solution is recommended; will it come back and haunt me later? Is the libstdc++.so.6 from system installation going to be an issue if used in the lib64 folder of openfoam?
An additional info concerning openfoam installation, foamInstallationTest shows *not installed* errors against flex, wmake, gcc, g++, icoFoam and *critical error* for gcc, g++, icoFoam; but I as given here, foamInstallationTest is not meant for installation from the tar file. Openfoam installation seems to be alright based on the running of the cavity tutorial.
ok, please don't do copy past operation to solve this problem. The error means that you haven't installed the pre request libraries in your ubuntu. It seems that you have missed the first step in the tutorial.
It is not recommended but it will not hurt as long as the GLIBC versions returned from this command
strings /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 | grep GLIBC
are a subset of the GLIBC versions from this command.
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC
which was no doubt the case for your Ubuntu setup.
A less risky route would be to redirect the soft link /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 to point to your other libstdc++.so.6 (that way you retain both versions)
ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6
Then, if you hit an issue, you can always reset the link back to its original target. Of course /usr/lib/x86_64-linux-gnu/libstdc++.so.6 is itself a soft link, but you can point to it all the same or you can point to its target.
I believe the issue you are hitting is a derivative of the one mentioned here https://www.cfd-online.com/Forums/main/229027-persistence-glibcxx_3-4-26-not-found.html, which would point towards the fact that it is not an installation error on your part but an issue related to the packaging of the OpenFoam binaries. I agree it would screw up the wsl2 setup owing to the way OpenFoam prepends everything to paths. Of course the safest route is to compile from source using the Ubuntu system's gcc and thereby bypass the ThirdParty.
Seeing as you are using Ubuntu in the WSL instance, could also just install the Ubuntu package directly:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
This problem comes from this line in the tutorial:
echo "source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc" >> ~/.bashrc
This will point to OpenFOAM's libstdc++ everytime you open a terminal (or start a WSL2 session). If your workflow is not related to OpenFOAM, that can be an issue. If you remove or comment that line in your ~/.bashrc things should get back to normal. You can use nano in WSL2.
nano ~/.bashrc
Then comment:
#source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
However, as OpenFOAM uses that bashrc, you will need to source the OpenFOAM bashrc in each terminal before using openFOAM.
source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
My personal choice is to keep that line commented and, if I have a long work session using OpenFOAM, I just use nano to uncomment it, so every shell that I open works without sourcing again.
There are more elegant or complex approaches, but I prefer this one.
This answer should be valid with the 2006 version too, the link you shared points to 2012, so I guess they just updated the tutorial. If you installed 2006, just make sure when you source comment/uncomment to use the correct name.
In the same manner, if you followed another tutorial with another tool and sourced another library, you may experience issues.
Just start by taking a look at your bashrc and cleaning it.
I'm trying to install a linux-Kernel version 4.9.228 in my ubuntu 20.04.
The kernel compiled successfully, without any errors. I also executed the command:
sudo make modules_install install
When I rebooted my system, to check whether it made correct entry, I checked the files under the /boot/ directory:
System.map-4.9.228
vmlinuz-4.9.228
initrd.img-4.9.228
config-4.9.228
I don't know why but when I ran uname -r. It hasn't updated my version. It still says 5.4.0-37-generic.
Please guide me if I am missing something.
Note: The sole purpose of doing all this, is to learn how to add a system call and how to compile a kernel. I'm open to suggestions, if you got any. Thanks.
You might have successfully installed a different kernel version, but in order to boot into it, you need to tell the bootloader to do so.
I'm going to assume that you are using GRUB2 as bootloader, since it's standard on most distributions including Ubuntu. In order to boot the new kernel, you have multiple options.
Option 1
This is the safest and recommended option.
Edit the GRUB configuration file /etc/default/grub (you need to be root, so use something like sudo vi or sudo nano) and make sure that you have GRUB_TIMEOUT=N where N is a number of seconds. If you don't, then just add it in a new line. You want N to be at least 5 or 10 so that you have time to select the correct kernel version when GRUB starts.
Additionally, make sure that you do not have any of the following lines (you shouldn't have them, but if you do, remove or comment them):
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_SUBMENU=y
GRUB_HIDDEN_TIMEOUT=N
GRUB_TIMEOUT_STYLE=hidden
Save the changes to /etc/default/grub and run sudo update-grub. This will detect currently installed kernels and add them to the bootable list when you start the computer and enter GRUB.
Reboot your PC, when GRUB starts you will see a list of options. If you don't do anything, your default kernel will boot, otherwise you can use the arrow keys and the ENTER key to navigate to "Advanced options for Ubuntu", where you will find the list of available kernels and you will be able to select the one you prefer.
It should look something like this:
Option 2
Use only as fallback if option 1 does not work (it should, but you never know). This is not as clean as option 1 because it changes the default kernel, and changes are also probably going to be overridden by an upgrade of your current kernel (which technically does exactly this to update the default version).
Make the kernel you want the default one by changing the two symlinks /initrd.img and /vmilunuz to point to the right versions of the kernel and initrd image. This can be done either manually or through the linux-update-symlinks command.
$ linux-version list --paths
... grab the correct VERSION and PATH ...
$ sudo linux-update-symlinks install VERSION PATH
Run sudo update-grub to let GRUB detect the changes.
Reboot your PC.
Option 3
Manually boot into the kernel you want from the GRUB command line. This is an advanced option and I'm listing it only as a last resort, you should never need to do this unless you have completely broken your system configuration.
Reboot the PC into GRUB, and as soon as you see it, press C to enter the GRUB command line.
Follow this answer from now on.
In any case, remember that playing around with kernel development on your own machine is not a good idea if you are not sure what you are doing. I recommend you use a virtual machine to experiment with the kernel, that way if anything goes wrong you can just throw it away and create a new one.
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
I'm beginning with Spark so not really sure where my problem is and looking for a helpful hint here. I'm trying to run Spark (pyspark) on a windows 7 machine as an admin but it does not seem to be working (I still get the WindowsError 5). See image below:
I've downloaded the file (release 1.2.0 with pre-built for Hadoop 2.4 or later), unzipped it using tar via command line and set IPYTHON=1 before calling bin\pyspark. When I call it, pyspark runs but I get the error below as per image.
When I try calling certain SparkContext objects, I get name 'sc' is not defined.
I've got python 2.7.8 installed, Spyder IDE and am in a corporate network environment.
Does any one have a clue what could be going on here? I've looked up a few questions such as Why am i getting WindowsError: [Error 5] Access is denied? but could not find a clue.
Briefly:
I had what should be the same problem. For me, it was that the *.cmd files in the $spark/bin directory weren't marked as executable; please try to confirm by:
right clicking on pyspark2.cmd and:
properties / security tab then examine 'Read & execute'
I found the workaround on another site, that recommended downloading hadoop-winutils-2.6.0.zip (sorry don't have a link). Here is an example of the cmd to use (after moving to proper directory):
t:\hadoop-winutils-2.6.0\bin\winutils.exe chmod 777 *
I did need to run the chmod 777 cmd to make the /tmp/hive writeable too.
good luck!
(... new here - sorry for the poor formatting)
(update: Matt thanks for fixing formatting issues!)
root cause: the tar program i used on windows via tar -zxf <file.tgz> did not apply
the proper attributes to the extracted files. in this case the 'executable' files
weren't properly set. yeah, maybe i should update my version of cygwin.
I'm using minix3 on VMware Player and i'm having trouble compiling a system call.
I actually tried to see if i can add a simple command in a system call just to see that working and i put a simple printf("my message"); in protect.c file which it is on usr/src/servers/vfs.
I saved it, and tried to compile it with make command while i am on vfs directory.
It says that protect.c is up to date.
I try change a file's owner (protect.c has the chown mode code in it) and i'm waiting as a result my message. Instead it's just run the command correctly without printing my message.
I assume that i did something wrong with compiling and i'm searching for hours over the internet trying to fix it. But the only command that cames repeatedly is make hdboot. I know that this command it's not gonna work because i'm using minix3 as a virtual OS, but i tried it just to confirmed it and as i said didn't work.
Is anyone know anything about compiling in minix3?
IF your problem is indeed with compilation and you've implemented your system call correctly then after making any edits in /usr/src you should call "make install" from /usr/src/releasetools and then call "reboot" to restart minix