- 最新
- 最多得票
- 最多評論
Hi there,
In most cases, 1/2 status check means there's either a boot issue, or a networking issue. In both cases, having a look at the system logs [1] and instance screenshot [2], is the best way to find the potential culprit. I see you've stated there's no particular information in the system logs, so the screenshot will be your next best bet.
Should the screenshot show the login prompt, this would confirm that there's no boot issue, however, there is a network issue. Reason being it can only get to the login prompt if boot is successful. Further, not being able to connect to the instance when the login prompt is there, confirms network issues.
The opposite is also true, if there's no login prompt on the screenshot, then it's most likely a boot/OS issue.
You can use this information to further troubleshoot with the help of the following document: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html
References: [1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html#instance-console-console-output [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html#instance-console-screenshot
Again, thanks for the information.
You can look at "/etc/netplan/50-cloud-init.yaml"
How to reach these files on the failed system?
It's a pleasure.
Best would be to stop the instance. Detach it's volume and attach it to a working instance. Whereby you can mount the newly attached volume and review the files:
- Once attached to a working instance connect via SSH
- Run "lsblk" to see the disk name. Usually something like xvdf1 or nvme1n1p1.
- You can mount it to /mnt with "sudo mount /dev/<partitionname> /mnt Example: sudo mount /dev/xvdf1 /mnt
Once mounted you will find the file in the mounted path like "/mnt/etc/netplan/50-cloud-init.yaml"
-
Once you've checked what you need to, you can do the following: a) cd / b) umount /mnt
-
You can then detach the volume and attach it to the original instance as "/dev/sda1" or "/dev/xvda" depending on what is used.
Thanks, the problem was due lack of cloud-init on the system. For some reason, it was removed!
Thank you so much!
My solution was with fixing the macaddress in /etc/netplan/50-cloud-init.yaml.
Had to login via serial connection to update it, as it failed network connection. Bummer this is default when creating an Ubuntu 22.04 image. :\
相關內容
- 已提問 6 個月前
- 已提問 6 個月前
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 3 年前
Thanks so much for the response. I have confirmed the login prompt, and will now focus on the network issue. If there are any further hint on the network side, please.
Anytime at all.
Now that we know it's a network issue, you can have a look at the following files:
Ubuntu 18 makes use of "netplan", therefore to edit the Networking configuration for an Ubuntu 18 instance you need to ensure the netplan yaml file is populated with correct information:
You can look at "/etc/netplan/50-cloud-init.yaml". When looking at this file, ensure the populated "macaddress" matches that of your instance ENI. You can find the ENI within the "Network" tab of your instance information. You can then open that ENI and find the MAC address. Should the information not match, this will most likely be the cause of the network issue.
Next, you can look at "/etc/udev/rules.d/ *". Check for the Persistent rules file (something like 70-persistent-net.rules). You are looking to see if there are no default rules created. If you see some rule file named like that, just rename this file and keep it in the same directory. If you cat that file, you will most likely see it has the same incorrect MAC address "ATTR{address}" as in the 50-clout-init.yaml file. Once you've renamed or deleted this "persistent" file, you can try rebooting.
This is about as much as I can do without seeing the OS myself. Hope it helps!
Note - It's always useful to spin up a working instance (Same instance type and OS flavor/version) and compare the network files.