If a Linux system has trouble booting it may enter a state known as 'emergency mode'. This is a special mode wher the system is unable to correct itself from, throw's it's metaphorical hands up and says "I give up, human intervention required". It will ask you for the superuser password if your on an insecure terminal, otherwise it might drop you immediately to a root prompt.
Terminals and what programs run on them are usually defined wherever 'getty' is. That place is OS specific so you'll have to look at your POSIX vendor's manual for that, but it is usually some place under /etc. The getty is responsible for spawning the programs on your terminals. Usually this is the /sbin/login program on TTYs 1-6 and an X11 Display Manager on TTY7. The login program does exactly what it's name is and asks you for a user/password and logins you in then starts your shell. The XDM does that same thing, except graphically with a X11 display server. The X11 display server is the userspace software the provides raster graphics capabilities to UNIX like operating systems.
Secure terminals as defined by the getty configuration are simply terminals that are considered to be in a physically secure location, and won't ask you for the root password upon login. Insecure terminals require passwords for logging in.
First thing to do ounce logged in is to check the log files to figure out why things broke. Pagers and text editors like Less, More, and Vim are great for this. Search likely candidates in /var/log/. If you are using systemd you may not have log files. You will have to use the systemd journal with the journalctl command. Ounce you've found the mountpoint that failed you can find out why in the kernel log buffer. Simply type dmesg to view that. On older systems dmesg may not contain a Human mode so you can pipe dmesg into a pager like so: dmesg | less.
A failure and cause of emergency modes are typos in the system's filesystem tab. It's located in /etc/fstab and called fstab because it's a text file of the system's mountable filesystems and their properties in TSV tabular format. (tab separated values). The definitive format for fstab can be found in fstab(5) man 5 fstab but a gist of it is like this:
The device/partition field is the physical device or volume if using LVM, the filesystem resides on. You can use lsblk to list out these and lsblk -f to read basic filesystem information from block devices. A block device is an abstract storage device that reads/writes data in blocks. Typically 512k at a time for legacy IDE hard drives, 4096k for modern hard drives, 2336/2048 bytes for CD-ROMS in mode1/mode2 respectively. This is why we use filesystems on top of block devices unlike the 1960s where people used blocks directly. The filesystem abstracts blocks for us so all we normally have to care about is the name of the file and where the file is in a folder hierarchy.
Block devices are often 'partitioned' into several different abstract block devices with something called a 'partition table'. There are multiple types of partition tables but the two most common ones are MSDOS and GPT. MSDOS is readably by legacy BIOS based computers and GPT is readable by modern modern machines. GPT also allows labeling of partitions and does not have as severe of limits on the number of partitions that can be created so no workaround hacks like 'primary' and 'extended' partitions need to be done to have a large amount of partitions. On GNU there is a tool called 'parted' than can be used to created and manage partition tables. Older tools like fdisk and cfdisk can also be used. See my article on Bootstrapping Linux On The X86 Platform for details on using that.
Mountpoint is simply where in the VFS (Virtual FileSystem) you want to `mount` your filesystem. In UNIX-like operating systems, everything is a folder/folder. And the VFS fake filesystem in which all real and pseudo-filesystems are mounted into. At the very least a UNIX-like system needs a root filesystem in order to start it's tree from. Otherwise the system will not be able to boot. It should be noted however, that if your system is running systemd made by Poettering and Redhat that they do not respect the UNIX philosphy very much, and your system may fail to come up if ANY filesystems fail to mount, not just the root one. Normally when running System V, OpenRC, Sinit, Rc6, or others if the root filesystem comes up but for example /home doesn't come up services that do not rely on home can still come up like networking so an administrator can remote in and fix things without being physically on the machine.
Popular filesystem types on Linux are ext4 and XFS. If you want to quickly check for which type of filesystem you have it's pretty easy to do by hand. As the superuser just hexdump the beginning of the partition to screen. Be sure to use a pager as the storage device is almost always much larger than the amount of characters that can fit onscreen. hexdump -C /dev/sda1 | less. Ext4 is easy to tell because the first 400 bytes on disk will be 00s.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 00 c0 c9 01 00 d0 26 07 66 8a 5b 00 3e 63 99 00 |......&.f.[.>c..|
XFS is even easier because the first 3 bytes of an XFS filesystem are always XFS
in ASCII coding (58 46 53).
00000000 58 46 53 42 00 00 10 00 00 00 00 00 00 08 00 00 |XFSB............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 99 a1 09 53 46 4e 4c 61 87 ba 4a 32 2b df ac 36 |...SFNLa..J2+..6| 00000030 00 00 00 00 00 04 00 05 00 00 00 00 00 00 00 80 |................| 00000040 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 |................|
Alternatively if your are not as familiar with filesystem signatures you may try to have the kernel auto-detect what filesystem it is. Try mounting it somewhere with the verbose flag and seeing what it detected the filesystem to be. mount -v /dev/sda1 /mnt && mount | grep "sda1"
Mount parameters define how the kernel will treat the filesystem and represent it to the VFS. 'defaults' are fine for most use cases, but you may also want to specify "noatime", "relatime", and/or "trim" if your filesystem supports trim. Noatime is good for improving performance reducing wear on your physical media. In the VFS files have some attributes on them such as create time, modify time, and access time. If knowing the access time does not matter for your application you can turn off that field with the noatime parameter. If your using an application that is hard-coded to require a atime field and will not function properly without it but does not need accurate data from that field the compatibility option "relatime" can be used. It means relative access time and just treats the access time field the same as the modify time field. You would want to turn this off if you don't need it otherwise every single file/folder read will cause a disk write. That can a performance hit and due to entropy, physical media can wear down with usage. Physical media has a limited number of writes it can handle before it starts failing. The trim parameter is useful for solid state storage media and storage area network devices. It allows the kernel to signal to the underlying media when a block is no longer in use and the drive's built in management may run garbage collection and wear leveling on those sectors. This improves the speed and longevity of solid state media and allows for a feature called "thinly provisioned storage" on big Storage Area Networks. This allows you to over-provision virtual block devices for virtual machines but the storage server does not actually use space until the virtual machine writes data to those sectors.
The dump bit is legacy cruft and be be set to zero if your not using the dump(8) tool for backups.
The check bit determines which filesystems get checked and in what order. System critical filesystems should be set to "1" and user data should be set to "2". Filesystems that do not need checking or you don't care about can be set to "0". On most UNIX-like systems filesystems with the check bit set to 2 can be checked in parallel offering a throughput improvement
Each column in the fstab file can be deliminated with either spaces or tabs, but tabs is preferred due to the positions of each column being able to retain their alignment with others thus improving legibility. It does not matter how many delimiters are between each column. The "#" symbol can be used to comment out or 'deactivate' any text after it until the carriage return. This is useful for quickly disabling lines for debugging or adding comments to lines.
On Linux UUIDs (Universal Unique IDentifiers) can be used in place of the block device field. This is very useful in computers with more than one drive because sometimes drive controllers can be initialized out of order, such that the alphabetic descending identifier may not be the same across a reboot or a hot-swap. You can determine the UUID of a device or partition with the blkid(8) tool. Simply run blkid as the superuser it will return all the block devices and partitions it find. It may also return the filesystem type and partition label detected in newer implementations.
Simply copy-and-paste it into place of the block device column in fstab to use them like so:
UUID="12345678-aaaa-bbbb-cccc-123456789012"
When you have finished correcting fstab you may continue to boot procedure by pressing control-D on your keyboard or typing the exit command