I accidentally set the default systemctl target to basic target while trying to switch from multi-user to graphical target on my raspberry Pi 3B which runs the Raspbian OS. Since then when I boot my RPi it does not start and only displays a welcoming screen. I tried to edit the config and cmdline files while in recovery mode to try to access the command line but I could not. Can someone explain to me what the basic target even is because I have been searching online for hours and cannot find a proper explanation? Do I need to format my RPi now or can I access my command line by some way to switch to multi-user target?
Thanks in advance.
The documentation for all systemd so-called special units is available under systemd.special(7) man page (or in the respective online version).
basic.target is an early-boot synchronization point, ordered even before initrd, so the service for login prompts is simply not started, thus there's no command line to work with. This is nicely described and visualized in the bootup(7) man page.
You can temporarily override the default target from the kernel command line using the systemd.unit= argument (systemd(1), section Kernel Command Line).
In your case, adding systemd.unit=multi-user.target to your kernel command line should be enough to allow you to boot back into your rPi and then make the target change permanent by calling systemctl set-default multi-user.target (or graphical.target, as that seems to be the original way you were trying to follow).
Related
I am evaluating a self-hosted artifactory installation on a trial license. I followed the official installation instructions for the docker container and the linux archive file. Neither of these installation options are working. The artifactory service fails to start.
I have opened an issue to track the problem: https://www.jfrog.com/jira/browse/RTFACT-27182
TL;DR; A component fails, a nasty stack trace appears in the logs, and eventually the services stop.
It would seem that there is a bug in artifactory. I have traced this back to multiple versions and this issue spans multiple years.
The problem appears to be that artifactory cannot get past the bootstrapping/initialization phase when started with artifactoryctl. At a certain point (around 2-5 minutes in) all the services stop and a pid file is left over, which is bad.
The workaround I have found is that the service can pass this initialization phase only after multiple start/stops (3 to be exact). In other words, we call artifactoryctl start, wait for all failures, then artifactoryctl stop and repeat two more times. On the fourth and final start, we will see the service come online (in about 150 - 190s). From then on, the service will start correctly with one call to artifactoryctl start.
I have not yet looked at the systemd unit file. My guess would be that it has/or could be made to have a number of retries to work around this issue and perhapse this issue does not exist when using the service wrapper.
I have also not yet looked again at the docker container which appears to be failing for the same reason. A workaround off the top of my head would be to modify the entrypoint script. If you were to dockerk exec into the container and try the workaround above it would likely terminate the root process and kill the container.
I have a simple application using
QT += core gui network webkitwidgets
I've used windeployqt.exe to generate the 32 bits release on my win-10 64 bit computer. When I put the folder on a win-7 64 Bit desktop and double-click the app.exe, it never starts.
I can see it in the task manager, but I can't kill it, and if I try I cannot close the explorer folder in which I double clicked anymore.
I've checked the usual platform, ICU, qwindows.dll, and so on.
http://doc.qt.io/qt-5/windows-deployment.html
EDIT Precisions:
I've compiled with default 32 Bit kit: "build-Test-Desktop_Qt_5_5_1_MinGW_32bit-Release" with "mingw492_32"
I have a package "release" generated by windeployqt.exe using the --webkit switch. I start a command prompt:
> set path=
> set mingw=
Then I make sure that no Qt/Mingw things exists anymore in my environment variables.
I also rename "c:\Qt" into "c:\ __Qt".
I move my release folder on my desktop.
I start release\test.exe ( from the clean path shell )
Everything runs fine! So The release/test.exe has everything it needs without the path/mingw variable.
But as soon as I put the folder on another windows machine ( 7 instead of 10 ) it never starts.
I tried dependency walker. It shows a lot of "API-MS-WIN*.dll" missing...
It even shows much more missing dlls on the "good" machine than on the bad one !!!
Every single "missing dll" on the "bad" target machine is actually in system32 on this machine.
Thanks for advice, every advice is welcome, I'm a bit desperate... :)
Edit
It seems to be related to the machine itself. I have successfully deployed this (very small) app to 2 non developer machine on win7 and win8 respectively. But the above "bad machine" still resits running it...
Edit
The problem seems not to be general but related to this one particular machine. Hence, feel free to close or move to the appropriate forum as it is not related to Qt/windeplyqt. If I figure out a solution, and question is closed, I'll simply add a last edit. Safe Boot and malwarebyte are my next actions.
After a long investigation.
Do not believe dependency walker, it used to be a top notch tool but it is now outdated.
If there is a missing dll, the system will prompt you with "cannot load dll xxx.dll" anyway.
Your best shot in case a soft runs on machine X but not on Machine Y is:
start in safe mode ( run: msconfig --> diagnostic startup )
turn off any antivirus or non microsoft/driver software,
"run as administrator".
If you can run with step 3. Then proceed by elimination:
run without admin rights,
Start anti spyware, etc...
Add appropriate exception to your antivirus if it is the root cause.
If the antivirus is not the root cause, run process monitor on both machines. Then compare, what Failed on one machine and not the other ? Read the windows event log and compare any error messages on both machines.
run sfc /scannow to check disk
run a complete anti spyware scan/ pc-repair tool ( malwarebytes, combofix, ... )
Make sure you really have the very same package on both machines, make sure you are not trying to run an exe on mac OS, make sure your computer is on.
Call the oracle, you are in the matrix...
In my case the problem was Avast and it was solved by adding appropriate exception.
I am running Grizzly on a two node configuration. If I use the standard images, I.e. cirros-0.3.0-x86_64-disk.img or any of the ubuntu-server-cloudimg-amd64-disk1.img I have no problems, console log is there. But if I create an image using KVM and any of the ubuntu ISO standard files, then I don't get a console log. Instances always run OK and I can access them via the dashboard login screen, and there are no error messages about the console; console.log is always 0 bytes on these cases. Is there any difference on those cloud images that I need to add to my image creation process? I have already tried and added libvirt unsuccessfully.
Thanks for the help
Short answer
Inside of your virtual machine, edit /etc/default/grub so it has the line:
GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"
Do
sudo update-grub
Longer answer
Grub needs to be configured to write the boot messages to the serial device (ttyS0). In particular, on Ubuntu, in your /boot/grub/grub.cfg, there should be a line that has console=ttyS0, like this:
linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=ttyS0
However, you shouldn't edit this file directly. Instead, you should edit /etc/default/grub to specify the additional parameters to be passed to the kernel and then run update-grub, which will update the files in /boot/grub for you. Specify the console=ttyS0 argument by editing the GRUB_CMDLINE_LINUX_DEFAULT variable defined in /etc/default/grub.
I have compiled my freebsd libc source with -g option, so that now I can step in into libc functions.
But I am having trouble stepping into system calls code. I have compiled the freebsd kernel source code with -g. On setting the breakpoint, gdb informs about breakpoint on .S files. On hitting the breakpoint, gdb is unable to step into the syscall source code.
Also, I have tried: gdb$catch syscall open
but this is also not working.
Can you please suggest something?
Thanks.
You appear to have fundamental lack of understanding of how UNIX systems work.
Think about it. Suppose you were able to step into the kernel function that implements a system call, say sys_open. So now you are looking at the kernel source for sys_open in the debugger. The question is: is the kernel running at that point, or is it stopped. Since you will want to do something like next in the debugger, let's assume the kernel is stopped.
So now you press the n key, and what happens?
Normally, the kernel will react to an interrupt raised by the keyboard, figure out which key was pressed, and send that key to the right process (the one that is blocked in read(2) from the terminal that has control of the keyboard).
But your kernel is stopped, so no key press for you.
Conclusion: debugging the kernel via debugger that is running on that same machine is impossible.
In fact, when people debug the kernel, they usually do it by running debugger on another machine (this is called remote debugging).
If you really want to step into kernel, the easiest way to do that is with UML.
After you've played with UML and understand how the userspace/kernel interface works and interacts, you can try kgdb, though the setup is usually a bit more complicated. You don't actually have to have a separate machine for this, you could use VMWare or VirtualPC, or VirtualBox.
As Employed Russian already stated, gdb being in userland cannot inspect anything running in the kernel.
However, nothing prevents to implement a debugger in the kernel itself. In such case, it is possible to set breakpoints and run kernel code step by step from a local debugging session (console). With FreeBSD, such a debugger is available as ddb.
Some limitations would be the lack of connection between your gdb and ddb sessions and I'm unsure source level debugging (-g) is available for kernel code under FreeBSD/ddb.
An alternate and much less intrusive way to 'debug' the kernel from userland would be to use dtrace.
I've developed a Qt application which contains a TCP server and such. I'm now trying to make Ubuntu packages and let the application automatically start on startup.
The application needs to be running even if nobody is logged in, which means a daemon started via a script in /etc/init.d/
I tried simply running the application on start and sending a kill-signal on stop in the init.d script but that means the application runs in the foreground and blocks the init-script.
Forking like in an other question almost seems to work, I get 'unknown error' after trying to start a TCP server. Nevertheless, there should be an easy to way to write a init-script that runs my application in the background on startup on the various Linux distributions.
Could anyone point me in the right direction?
Using Ubuntu 9.10 with Qt 4.5
The best way is probably to use QtService where the work of forking is taken care of for you.
However, if you want to continue to build your own, you should either background the application or run it via start-stop-daemon that comes with OpenRC or a similar utility for your distribution.
Also, make sure that you only link to the QtCore shared library. Although the application might be command line and never pull up the GUI, that doesn't mean that X isn't required in order for the application to run. For example, a set of unit tests:
$ ldd runTests | grep Qt
libQtTest.so.4 => /usr/lib/qt4/libQtTest.so.4 (0x00007fd424de9000)
libQtXml.so.4 => /usr/lib/qt4/libQtXml.so.4 (0x00007fd424baa000)
libQtGui.so.4 => /usr/lib/qt4/libQtGui.so.4 (0x00007fd4240db000)
libQtCore.so.4 => /usr/lib/qt4/libQtCore.so.4 (0x00007fd422644000)
Because QtGui is present, all the X libraries are also brought in, although filtered from the above output.
Is your program a GUI application or does it work without GUI?
Why don't you just background it within the init script using &?
You need to add a symbolic link into any of the rc?.d directories under /etc depending on the default runlevel. Or use the update-rc.d script: first you need to create a script into /etc/init.d that executes the application; second, use the update-rc.d script to add the needed files to start.
You can find information about how to do it by reading update-rc.d manual page:
$man update-rc.d
I think the simplest way is to not have any daemonize logic in your application itself, instead use a helper program to start the app in the background and manage a pid for it.
For example, startproc.
You can take a look at the many scripts already in your /etc/init.d for inspiration. From what I see there, most of standard linux daemons depend on startproc for start, and killproc for stopping.