How to avoid "Welcome to emergency mode!"
Solution 1
Type journalctl -xb
to view logs. Then look for the red ones by scrolling down. It will show some error regarding fsck and the disk partition related to it, at least in my case.
If you have the same issue then,
enter the following commands as root user
umount /dev/sda/<error partition number>
fsck /dev/sda/<error partition number> -y
mount /dev/sda/<error partition number>
reboot
Solution 2
We ran into this problem, and I spent 3+ hours trying to fix it. Turns out, one of the EBS wasn't reattached after instance reboot, and since the mount was hardcoded in /etc/fstab, it failed during startup. Once we attached the EBS back to the instance, everything came back up.
Another thing to note: if you reattached the EBS without specifying which /dev/ it's mounted, the EBS will have a different /dev/ point; however, this won't cause an error, as fstab uses device ID and not device location.
Related videos on Youtube
KcFnMi
Updated on September 18, 2022Comments
-
KcFnMi over 1 year
Just after power on I got to :
[[0;32m OK [0m] Started Login to default iSCSI targets. [[0;32m OK [0m] Reached target Remote File Systems (Pre). [[0;32m OK [0m] Reached target Remote File Systems. Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to try again to boot into default mode. Give root password for maintenance (or press Control-D to continue):
How to avoid this?
Who is getting in the way and showing this
Welcome to emergency mode!
?May I disable any service so that in the next reboot it didn't happen?
This question is part of another one: Amazon AWS EC2 Volume issue prevents instance access via SSH