After an update of my TrueNAS I started getting some strange double beeps.
I thought it might be thermal warning, so I cleaned my NAS PC, put a monitor and keyboard on and booted it up.
I started to see some strange token series popping up, seemingly random: ^[[6~^ ^[[6~^.
I thought nothing of it.
Then more beeps, system froze. I checked the monitor. It was flooded with ^[[6~^ ^[[6~^.
I then rebooted my TrueNAS and went into the shell by pressing 9.
Now I see: ~~ and the same beeps occur when the characters appear. Roughly around every 8 seconds.
What is causing these? I tried unplugging all USB devices, I even tried to google.
I found things like kbdcontrol, jons, crontab. But with my very limited Linux knowledge I could not make anything work.
Hoping someone can help me with this.
Something went wrong with the patching process (I guess)
How I fixed it:
In the GUI I went to System -> Boot
I reverted to the previous patch.
Rebooted the system.
Issue still occurred.
Then I went to Dashboard -> check for updates.
It then went on and installed the update (as before).
Now the issue is resolved.
Related
If you install cygwin these days it runs "rebaseall" as part of its post installation process. This is apparently to realign dlls in some way so that you don't get errors in fork().
At this point in the process the install looks like it has hung for me, both with 32bit and 64bit cygwin. However, if I wait long enough (say 3 hours) the install will finish. At this point the computer runs like a dog - any new process takes forever to start and I have to reboot. If I do this then all is then fine until I try and install something else at which point the whole process kicks off again.
The install is doing something weird to my computer. I have tried closing all applications, removing software - all yield the same result. I have heard others complaining about this but seen no answers other than it must be some thirdy party software. To me this looks like a bug in cygwin.
Incidentally while the install hang is going on I can see dash processes starting and stopping in task manager - so something is happening but really slowly.
Any ideas?
I'll answer my own question. The issue was Trusteer Rapport. This piece of software beloved by banks, causes all sorts of bad side effects including this one.
This is not a programming question.
It is also borderline on http://superuser.com.
A normal update postinstall autorebase step take few minutes. Likely you have some software interfering like an antivirus.
Further reading:
https://cygwin.com/problems.html
https://cygwin.com/faq/faq.html#faq.using.bloda
and ask support on the cygwin mailing list
https://cygwin.com/lists.html
i'm running raspbian (2015-05-05-raspbian-wheezy.img) in qemu using compiled kernel (https://github.com/dhruvvyas90/qemu-rpi-kernel) on ubuntu 14.04. my final goal is to launch my python script within the emulation.
i'm following manual from http://www.unixmen.com/emulating-raspbian-using-qemu/, though many others suggest very similar sequence of actions.
things i'm trying and issues i'm experiencing:
first boot is more or less ok. i comment the line in /etc/ld.so.preload as suggested and reboot.
on second boot (after i remove init=/bin/bash) and all subsequent boots i get
ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/3.10.25/modules.dep.bin'
some googling suggested to run "sudo rpi-update". it didn't help, same message during boot.
on second boot (after i remove init=/bin/bash) and all subsequent boots i get
fsck died with exit status 6
looking into "/var/log/fsck/checkfs" as suggested tells that some location is not there, but it doesn't say which one
running "startx" produces error message from 1. it loads the UI eventually, but desktop only has "wastebasket" icon. there is also a thick white stripe on top of the screen blinking, like it keeps trying to load a tab but fails everytime. qemu window stops to respond to further interaction after this.
running "sudo apt-get upgrade" installs some packages, but after reboot i can't even get to UI - just blank screen with mouse cursor.
i'm not very experienced with how linux is configured at low level. i understand that i might be doing something completely stoopid.
so, my questions are:
how do i debug? i couldn't figure out the settings for qemu to write logs. i really don't want to fallback to gdb, as i'm not debugging qemu itself, just want to get notification on it's events.
ctrl key doesn't seem to work inside qemu window.
no copy-paste available. or i can't see how to turn it on.
am i missing something? from all the manuals i have seen it seems like this should go much much smoother. like it should "just work".
Since your post many things changed. The most important things is that now using Andrew Baumann GitHub repo you can build QEMU that boots recent Raspbian. I described my experience woth this code here. Instructions are straight forward. Implementation needs polishing but it best compilation of work so far.
To answer your questions:
QEMU have -s and -S options for GDB. First option setup gdb server hook and second freez CPU, so you can connect debugger. This is not for QEMU debugging this for guest system debugging. Default QEMU logging is to stderr, so if something valuable happen you will see it in terminal. You can raise QEMU verbosity by uncommenting various *DEBUG_ statements in source code. Also check help for -d and -D command line flags of QEMU.
Not sure I can help with this. Only thing that I can say is that my QEMU version 2.5.50 reacts to Ctrl+Alt which exits from GUI after capturing cursor, so it looks like QEMU understand Ctrl key. I assume that QEMU do not capture your special keys combination because your window manager do it before passing to QEMU.
This also not work for me, but I see some work was done in this area. Not sure how to enable and use that feature.
Emulating any hardware is very complex and requires a lot of work. All emulated targets are limited to some most important features. BCM2835/BCM2836 (Raspberry Pi/Raspberry Pi 2) SoC are still not accepted by mainline QEMU, so just work will not apply to those platforms.
I have a very strange problem with one of my systems. There are two components:
uClinux running on NIOS board.
Power PC running old CentOS.
There is an open socket between the two boards with constant text commands passing back and forth. I have several systems with this setup.
However, one of them have this strange error: the socket disconnects around midnight throwing broken pipe error. Does anyone knows what particular setting configures this behaviour? I doubt it is my software because it works just fine on several other systems.
So to summarize the results: I couldn't find what was causing the broken pipe error right at midnight. But I was able to mitigate its effects by ... ignoring the SIGPIPE signal as suggested by this post.
At first I thought my program had memory leaks. But I terminated all java processes and restarted Spring Tools Suite. I kept an eye on the task manager. In just a few minutes, javaw.exe had grown to 2,000,000 K Memory. The memory keeps going up, without issuing commands in STS. STS has literally ONLY been opened. I have no tabs open in it. The error log doesn't show any memory related errors. Upon closing STS javaw.exe DOES disappear from task manager and opening STS restarts the process over again around 150,000K, quickly jumping to 600,000K, then slowly growing and growing until it has consumed all my memory.
Any thoughts what might be causing this? I'm running a full system scan now just in case I've been compromised.
--edit--
This problem started around 10 AM Eastern and mysteriously went away at noon, when the security scan completed. No items were detected by the scan to lend an explanation to either the problem or its mysterious resolution. As of now javaw.exe is hovering at or around 700,000K. Very strange!
Sounds like a 2 hour bug! Be thankful it is gone but be sure to document it thoroughly if it occurs again. Sounds like a rough 2 hours you went through.
That is not completely unusual unfortunately. Because Eclipse is made up of a bunch of plug-ins some times a plug-in can go wild and start consuming memory and/or CPU. Using VisualVM (http://visualvm.java.net/) you can determine what is causing Eclipse to freak out. Depending on what it is, you might be able to disable that functionality. Because it could be so many different plug-ins it doesn’t surprise me you could not find any answers googling or looking here at StackOverflow.
I am writing my first OpenCL kernels on an Ubuntu machine with an NVIDIA card. Once in a while, the application totally freezes the whole computer. The mouse does not move, and the only way to reboot is by force-pressing the power button.
I've realized that the reason for the freezes is that I accidentally read past the last index of a global, read-only float array. While this is something I don't intend to do often, it might still happen in the future.
My question is - is there any way to prevent the computer from completely shutting down if this happens again? I know that, for example, Windows can shut down bad GLSL kernels and recover with a graphics driver restart. Is something similar possible here?
You may not be able to completely recover but you can recover better using SysRq (sometimes called System Request or Magic SysRq). By executing a specific key combination you can have Linux reboot in some what of a sane way (killing processes and unmounting filesystems). This key sequence is described in detail at http://en.wikipedia.org/wiki/Magic_SysRq_key so I won't repeat it here.
In some cases you might be able to still SSH to the device. If this is your case you might be in more luck. If you can SSH there are a number of other options you can try such as: unloading/reloading the crashed module, restarting the xserver, or at least rebooting the normal way.
Although I'm not an expert on "HURD" I believe it was designed to handle this type of condition better. The only other solution I can think of is using two graphics cards one for X and one for OpenCL. Dependidng on what you are doing you might have to passthrough the NVIDIA to a VM in order to completely isolate it off your host.