My computer's clock has been restarted, after this restarting I turn on my computer and waited for my CentOS to boot. but I face a black page which contains :
****An error ocurred during the file system check.
**** Dropping you to a shell; the system will reboot
****when you leave the shell.
****Warning -- SELinux is active
****Disabling security enforment for system recovery.
**** Run 'setenforce 1' to reenable. Give root password for maintenance (or type Control-D to continue):
I typed my password and I face #root line in the very black page.
I really need my CentOs work in GUI . Please help me.
If you have access to a root shell, try this command: "fsck -a" It will try to automatically fix error on your filesystem.
Related
I have Cywgin running on a windows VM and I'm having problems keeping a stable SSHD service running.
The issue is that file permissions on the /etc/ssh_host_ecdsa_key, /$home/.ssh etc directories are being randomly reset so SSH connections are refused because I am using strict mode. When I stop the SSHD service, reset all the file and folder permissions to 700, restart SSHD, SSH connections work fine until they apparently randomly stop and sure enough all the relevant sshd directory and file permissions are reset.
Has anyone encountered this problem before and know a possible solution?
In case somebody is researching a similar issue, the problem was due to instability on the VMs C drive after hibernating, logging off etc.
The solution was instead of installing Cywgin directly on the VM, install Cywgin a separate networked drive mounted on the VM. Works perfectly and no more instability issues.
I am having a problem keeping SSH running on the Windows Subsystem for Linux. It seems that if a shell is not open and running bash, all processes in the subsystem are killed. Is there a way to stop this?
I have tried to create a service using nssm but have not be able to get it working. Now I am attempting to start a shell and then just send it to the background but I haven't quite figured out how.
You have to keep at least one bash console open in order for background tasks to keep running: As soon as you close your last open bash console, WSL tears-down all running processes.
And, yes, we're working on improving this scenario in the future ;)
Update 2018-02-06
In recent Windows 10 Insider builds, we added the ability to keep daemons and services running in the background, even if you close all your Linux consoles!
One remaining limitation with this scenario is that you do have to manually start your services (e.g. $ sudo service ssh start in Ubuntu), though we are investigating how we might be able to allow you to configure which daemons/services auto-start when you login to your machine. Updates to follow.
To maintain WSL processes, I place this file in C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\wsl.vbs
set ws=wscript.createobject("wscript.shell")
ws.run "C:\Windows\System32\bash.exe -c 'sudo /etc/rc.local'",0
In /etc/rc.local I kick off some services and finally "sleep" to keep the whole thing running:
/usr/sbin/sshd
/usr/sbin/cron
#block on this line to keep WSL running
sleep 365d
In /etc/sudoers.d I added a 'rc-local' file to allow the above commands without a sudo password prompt:
username * = (root) NOPASSWD: /etc/rc.local
username * = (root) NOPASSWD: /usr/sbin/cron
username * = (root) NOPASSWD: /usr/sbin/sshd
This worked well on 1607 but after the update to 1704 I can no longer connect to wsl via ssh.
Once you have cron running you can use 'sudo crontab -e -u username' to define cron jobs with #reboot to launch at login.
Just read through this thread earlier today and used it to get sshd running without having a wsl console open.
I am on Windows 10 Version 1803 and using Ubuntu 16.04.5 LTS in WSL.
I needed to make a few changes to get it working. Many thanks to google search and communities like this.
I modified /etc/rc.local as such:
mkdir /var/run/sshd
/usr/sbin/sshd
#/usr/sbin/cron
I needed to add the directory for sshd or I would get an error "Missing privilege separation directory /var/run/sshd
I commented out cron because I was getting similar errors and haven't had the time or need yet to fix it.
I also changed the sudoers entries a little bit in order to get them to work:
username ALL = ....
Hope this is useful to someone.
John Butler
Problem
I was working with bento/centos7.2 box. I did a vagrant up and while it was booting up, I noticed the box has an update and I instinctively cancelled the operation (which I suggest not to do, ever!). So I went ahead and did vagrant destroy, rm -rf .vagrantjust to be sure (Again, I suggest not to do, ever!). I removed my box by vagrant box remove bento/centos7.2 and did vagrant up and ended up with this:
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
Environment
Ubuntu 16.04
Vagrant 1.81
Centos 7.2 Box
Things I tried
Following are the threads I have tried:
vagrant + virtualbox Timed out while waiting for the machine to boot
Timed out while waiting for the machine to boot when vagrant up
Vagrant "Timed out while waiting for the machine to boot."
When I enabled the GUI, I realized the box is booting up properly; it's just stuck at login screen(bug in box with ssh?). Screenshot:
Any help is much appreciated.
There are multiple possibilities that cause this issue:
Try running:
vagrant reload
This re-installs the guest-additions on the box.
Try opening Virtualbox (GUI interface) and the open the virtualbox (console). The box might for example be
i) waiting for fsck (filesystem check) if it was shutdown uncleanly
ii) login to the box over Virtualbox GUI by using the default username/password (typically vagrant/vagrant) and figure out is the ssh server running on the box or not.
Run
vagrant ssh-config
and see to what port and by which ssh key it is trying to use. Use them manually e.g.:
ssh -i <identity_key_location> vagrant#localhost -p 2222
I don't know if this was an effect of the shellshock attack which my server was victim to (or another attack that worked) but it basically enabled the hacker to overwrite my SSH config file when the server rebooted.
This new file used wget to load in a file from a website, then another library of hack functions which I guessed he then used to run hacks/DOS from my server. I caught it pretty fast and ideally want to upgrade but because I have cancer and just had a big operation it is too much effort at the moment.
Therefore I did a lot of house keeping, changing passwords, removing shell access, reverting back to DASH, replacing the default shell for root and any other users to another folder with symbolic links, restoring the config file for SSH, removing CGI functionality from config files e.g
ScriptAlias /cgi-bin/ /home/searchmysite/cgi-bin/
#
allow from all
#
Removed AW stats and Webalizer for all virtual min sites.
I already had DenyHosts and Fail2Ban installed.
I also blocked in/outbound traffic to the IPs of the sites he was getting the files from.
However it seems since this change I have lost the visual cron manager from webmin.
When I go to the menu item "Scheduled Cron Jobs", it says, "The command crontab for managing user Cron configurations was not found. Maybe Cron is not installed on this system?"
However I can see in the file system it exists.
When I run crontab -l or crontab -e I get "Permission Denied"
whoami shows "root"
I did think at the time of the hack this was all related and he had used SSH and a Cron job to get his hack running.
What I want to know is how I can get the CronTab manager back.
All the cron jobs are still running such as importing feeds into my websites, running scheduled emails and so on, what I don't know is how to resolve this without a full rebuild.
If I had the time and energy I would do that but I am totally drained and before this hack everything was just running smoothly and my websites which bring me in money were working fine.
They currently are still working fine and I regularly check my logs for IPs that look odd, have strong htacess rules for xss/sql/path travesal/file hacks and ban whole countries from Cloudflare which the site sits behind. So I don't "think" the machine is compromised at the moment even if it is old - could be wrong though!
details of box
Operating system Debian Linux 5.0 Virtualmin version 3.98.gpl GPL WebMin Version: 1.610 Kernel and CPU Linux 2.6.32.9-rscloud on x86_64
So if anyone can help me get my crontab manager back that would be great.
Thanks
1) check if chattr exists, if not, download a new one.
2) type whereis crontab, then chattr -isa /path/to/crontab.(usually /usr/bin/cron) then chmod crontab back to it original settings.
3) navigate to /var/spool/ and
chattr -isa cron
cd cron
chattr -isa crontabs
4) remove cron entry in /etc/cron.weekly
Look in /etc/cron.weekly for any new
I am new to Linux , and I am trying to install AlteraQuartus 2 WEb Edition and NIOS2 EDS to play with Nios2 Processor.
However , after installing Quartus and when I am trying to execute jtagconfig.
I do not see something like below , even after running /altera/nios2eds/nios2_command_shell.sh
1.)[Nios2 EDS] $
2.) Unable to lock chain (Insufficient port permissions)
Please Help,
To check if this is indeed a port permission problem, start the trouble-shooting by running jtagd (the deamon between the Altera tool and the driver) as root. At first, you must make sure that jtagd is not running, since if it is already running as a user, trying to start it as root will have no effect.
$ sudo killall -9 jtagd # Kill jtagd, ...
$ sudo killall -9 jtagd # ...and verify jtagd is indeed not running.
jtagd: no process found # Good, verified.
$ sudo jtagconfig # Will also start jtagd as root
1) CV SoCKit [2-1]
02D020DD 5CSEBA6(.|ES)/5CSEMA6/..
4BA00477 SOCVHPS
If the above is successful, this is indeed a port permission problem. To fix it permanently, try with udev rules, as suggested by #eepp.
(On a side note, jtagd will be started by jtagconfig if not already running, as the same user that started jtagd. Hence #eepps command will work as well, but jtagd should be killed first.)
For further trouble-shooting, running jtagd with some debug command-line options can give useful information:
$ jtagd --foreground --debug
JTAG daemon started
Using config file /etc/jtagd/jtagd.conf
Remote JTAG permitted when password set
Cant bind to TCP port 1309 - exiting
(The above error message is typical if jtagd is already running.)
(Above is taken från http://www.fpga-dev.com/altera-usb-blaster-with-ubuntu/. See that page for more details.)
"Insufficient permissions" or "permission denied" or whatever relating to not having permissions on *nix usually means you must run the command as user root (or as another user who has the permissions, but root has all of them).
So run jtagconfig as root:
$ sudo jtagconfig
Alternatively, as root, put this in a new file /etc/udev/rules.d/51-altera-usb-blaster.rules:
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6002", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6003", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6010", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6810", MODE="0666"
and then, run:
$ sudo udevadm control --reload
This should change the permission of your USB-Blaster Download Cable device so that any user may access it (if this is what you want), so you should be able to issue jtagconfig without sudo. Those five idProducts are all the known USB-Blaster Download Cable USB product IDs (for the Altera vendor ID, 0x09fb).
I wrote a fairly complete Arch Linux wiki page about Altera softwares on Linux if you want more details.
It may be obvious but make sure you're not going through a USB hub. That was my problem for Altera DE2-115 with Quartus Prime Lite 20.1.1 on Ubuntu 20.04.
The above answers fixed my permissions issue (Specifically adding ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666" to the new file /etc/udev/rules.d/51-altera-usb-blaster.rules).
But I was still getting.
1) USB-Blaster [1-2.1]
unable to lock chain - Chain in use - check
Going straight to my PC solved it.