Can anyone please help me with this? I'm not able to access a Debian 8 GCP VM via SSH and also the serial console. That VM had an additional disk and after restart I'm not able to SSH. I even tried to connect to it via serial port and it showed me the below message.
You are in emerg
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details
You cannot recover the virtual machine - just the data.
Create a new instance. Detach the disk(s) and attach to the new instance. Copy your data to the new instance. Optionally delete the old instance and disks.
Related
My google cloud instance got a problem and it's preventing me to access the ssh. I would like to access the boot disk image from gcloud shell to download my files. How can I do that?
Thanks in advance
If you need to recover data from your existing boot disk of the problematic VM instance, you can detach the boot disk and then attach that disk as a secondary disk on a new instance so that you can have access to the data.
Detach the boot disk from the existing VM instance by running the following command.
gcloud compute instances detach-disk [INSTANCE_NAME] --disk=my-disk
Create a new VM and attach the old VM's boot disk as secondary disk by running the following command.
gcloud compute instances create [NEW_VM_NAME] --disk name=BOOT_DISK_NAME,boot=yes,auto-delete=no
Connect to your new VM using SSH:
gcloud compute ssh [NEW_VM_NAME]
Refer to the documentation that describes common errors that you may run into, when connecting to virtual machine (VM) instances using SSH, also ways to resolve errors for diagnosing failed SSH connections.
Create a new VM with a brand new disk. Add the problematic boot disk as additional disk. Start your new VM, log into it, and browse the additional disk to get your files.
I have a running EC2 instance on which one of the database having transactional records stored through the application running on the same instance. I've change the port due to some security reasons but after changing port I'm unable to SSH to the instance.
My security group and NACL both having old as well as new port configured in it.
I've tried to SSH several times but it gives error Network Error: Connection timeout.
I'm scared about to data lost if this instance gets stopped. Need help!
You can login to instance without losing data with the help of 'session manager' option under the "System Manager". You will need to complete certain per-requisites of the session manager as follows given in the Amazon docs for Systems Manager Prerequisites
After completing the per-requisites assign the IAM role to the EC2 instance created for SSM.
Into the AWS console, search for the session manager option under the System manager and your instance ID will get listed over there.
Select the instance and choose for the Start session, you will get the shell console of your instance.
Revert the changes made in /etc/ssh/sshd_config for the port and try to SSH again.
I have changed some rdp settings to the windows server. I can see the screenshot but I cannot able to connect to the instance. What are the other methods to connect to the instance? I dont have snapshots. How to fix this?
Create an AMI of your server before doing anything below.
You will not be able to connect to the instance using RDP if you have messed up RDP thru any other tool. You might be able to repair your settings by attaching the root EBS volume on another Windows instance and repairing.
This document will show you how to attach the Windows volume to another server. Just skip the stuff about resetting the password.
Resetting the Windows Administrator Password
If the changes to RDP were made in the registry, you can also attach the registry on the other Windows instance. Then undo / repair your changes.
Just make sure that you are using the same Windows versions for everything above.
Load or Unload Registry Hives
Edit another Windows install's registry
I have one instance of a Windows Server 12 R2 VM on google cloud that's working properly and I have connected to it successfully using RDP. I have tried to replicate it by creating a snapshot out of it and creating an instance from the snapshot. According to the platform the instance was created, but i can't seem to connect to it or to get a password. When I click "Get windows password" I get this:
forever. When i try to connect to it, I get
I have no idea what to do, any help would be appreciated.Thanks
The password creation tool from the console only works for images builted from the official image repo. In this case your source is a previous VM through a snapshot. In that case, and also in migrations all the previous credentials are kept in the new VM. You can download the GCP RDP agent here and access using the credential you used to have in your source VM.
Connecting to a Windows Instance
https://cloud.google.com/compute/docs/instances/windows/connecting-to-windows-instance
-----------Update----------------
In the case you can not get to enter the VM, it seems to be a firewall rules issue. By default the port tcp:3389(RDP access) is open to all VM at the default network, check your VM is in that network or check if the firewall rule has a tag to be applied.
If not, apply a tag to your new machine and create a firewall rule tobe applied to that tag.
Hope it help. Keep us posted!
I've made a mistake - disabled a NIC on a AWS EC2 instance. Currently I'm trying to get access to it. Google search gave me 3 possible solutions:
Create VPC and add a NIC for it - that didn't work for me. Actually I couldn't access to it even from another machine inside the VPC.
Detach the volume and attach to other instance. Load a registry hive and try to enable NIC via registry settings - that also didn't work for me. It seems there are about 100 keys that should be changed (created 2 registry snapshot and compare them) - it's not worth a try.
Detach the volume and attach to other instance. Load a registry hive and try to set AutoAdminLogon. And add a script
netsh interface set interface "Local Area Connection 2" enabled
to HKLM/.../RunOnce folder.
This third solution doesn't work for me because AutoLogon doesn't work for some reason. I'm sure AutoLogon doesn't work because in the other case the key from RunOnce folder will be removed. But it's still there!
I've create a new intance (let it be Instance0), go to register and set 3 keys: AutoAdminLogon, DefaultUserName and DefaultPassword.
Add a key with "netsh ..." to RunOnce folder. Disable NIC, restart the instance and ... it worked!
Then I disable NIC on this intance. Create a new intance - Instance1. Attach the volume from Instance0. Load "%Instance0-Windows%\System32\config\SOFTWARE" hive (It's HKLM/Software). Make the same operations as I did, attach the volume to Instace0, start it and ... it doesn't work!
My guess is that there are some differences between setting keys for your local machine and settings key using load hive for registry of not the local machine.
Can anyone help me in this problem? The question is not "Why does auto logon not work?" The question is "How to get access to the Instance0?" It seems for me that getting an access via autoLogon would be very easy if autoLogon works. If anyone knows a different method, that would be really appreciated.
it's easy, just allocate a new NIC in the same advisability zone on the ES2 instance, then attached the new NIC to the instance and allocate new Elastic IP and associate it to the new NIC, then use remote login to log into the EC2 instance using the new Elastic IP.
after login to the ES2 instance you have the choice to reconnect the old local area connection or stay on the new local area connection, best practice is to reconnect the old one because it increase the bandwidth available to your instance.
and have a nice day :)
Easy way is to make an AMI from that instance.
Then fire up the AMI with User Data Code (Powershell script) to enable the NIC
Amazon Elastic Compute Cloud -> User Data
Enabling and Disabling Network Adapters with PowerShell
If anyone else needs this in future this is how i resolved my issue.
Added a new network interface via the console.
attached an elastic IP to the new nic
connected via RDP to the new elastic IP
removed the new nic and reverted back to the original one.
disconnected via RDP
reconnected on the original and it worked.