My desktop froze out of nowhere. Now I can't get past emergency mode after rebooting

Ubuntu Version:
Ubuntu Studio 24.10

Desktop Environment (if applicable):
KDE Plasma 6.1

Problem Description:
I’m thrown into emergency mode and don’t know how to get back to doing normal stuff on my computer.

I was browsing the web and managing files. Out of nowhere, my desktop froze up and I could no longer get anything to happen. Even my cursor stopped moving.

I had to press the power button for five seconds to force a shutdown. When I turned it back on, it stayed on the Ubuntu Studio loading screen for much longer (about 20+ seconds), and then it says I’m in emergency mode. What I expect to happen, and what has happened up until now, is that I only face the loading screen for about 4 seconds and get to my login screen (SDDM I think) where I type my password and then get to my desktop. I’m not new to Linux; I’ve never had this happen before after forcing a shutdown, and this is across various Debian and Ubuntu distros.

If I do CTRL+D (as instructed) to continue booting up as normal, I eventually get to my login screen, and it recognizes my password. After entering my password, I get a blank screen for what feels like more than a whole minute, and then I’m returned to the login screen. (If I type my password incorrectly on purpose, it rejects my login attempt normally as expected and I can still enter my password again or shut down, restart, etc. using my mouse.)

I don’t think I’m able to reproduce what I did to get to this point, nor could I accurately retrace what I was doing. The last things I remember doing were finishing a Twitch stream on the Firefox snap and syncing files from other devices with Syncthing.

Relevant System Information:

  • GMKtec G3 Plus
  • Intel N150
  • 16 GB RAM
  • 512 GB NVMe

I just got this computer a few days ago. The day I am posting this would be Day 4 of having and using this hardware.

Not sure if it matters, but the NVMe came with Windows 11 installed, and I didn’t even give it a chance to boot; right away I threw my USB into the computer, booted a live session of Ubuntu Studio, and installed it, erasing the entire disk. Everything was fine for a couple days until the above happened.

I am not dual-booting. I only have one piece of storage (the NVMe), and the only OS on it is Ubuntu Studio.

I also ticked “use LVM and encryption” during install (might not be the exact words, but “LVM” and “encryption” were definitely in there). If encryption is part of the problem, then maybe this is relevant.

Screenshots or Error Messages:

I’m not sure how to copy this text and transfer it to the device I’m using to post this (a smartphone) or take a direct screenshot and send it in this state. Normally I’d use Spectacle or KDE Connect or Syncthing or even one of my note-taking apps.

What I’ve Tried:

Two posts on askubuntu.com suggested that it is a filesystem issue, but the instructions are honestly over my head and I’m not sure whether to go forward with any of those instructions out of fear of breaking my system.

One of those posts suggested I do mount -a to find all unmounted mount points, and then to comment those out in /etc/fstab using vi, which I don’t know how to use.

Here’s what I got after doing mount -a:

The other post mentioned using a fsck command, with no explanation about what that does.


1 Like

Welcome to Ubuntu Discourse :slight_smile:

More than likely, you are being dropped into emergency mode either because of filesystem corruption or an invalid fstab or both.

Let’s break this down:

At what point do you enter the password for encryption, before it drops to emergency mode?

My suggestion would be to do the following to try and fix this:

  • enter maintenance mode and find your volumes with lvscan
  • you want the one that says root, something like this
    ACTIVE '/dev/ubuntu-vg/root' [XXX GiB] ...
  • run lsblk -f to confirm the partition we want to check. It should be something like this /dev/mapper/ubuntu--vg-root
  • now run a filesystem check on the root partition fsck /dev/mapper/ubuntu--vg-root
  • If prompted to fix errors, type y in the console
  • once the check is done, fingers crossed that it says either no issues found or it repaired the problems
  • check the fstab file for errors like missing or incorrect UUIDs, a drive or partition that no longer exists.
    nano /etc/fstab
    Make any relevant changes and then Ctrl+O to write, Enter, Ctrl+X to exit
  • type reboot at the prompt

Report back if the issue was resolved, any other issues, any questions before running commands.

1 Like

Once you login just check lsblk to see what successfully mounted at this point. That will narrow it down big time.

1 Like

Thanks for the welcome!

I’m never asked for my password unless I make it to the login screen. Might this be because I chose to have a root partition and a home partition?

It told me that lvscan could not be found, but can be installed with apt install lvm2. I don’t have an Ethernet cable.

So I did lsblk -f instead, and here’s my output. (I did the command twice so I can see the last lines of output, because it doesn’t scroll all the way down for some reason. Most of the entire list seems to be just snaps, so I’m focusing on the NVMe, which again is the very bottom of the output. That’s the only storage drive I have.)

I believe nvme0n1p3 should be where /home is. Should I run fsck nvme0n1p3 next?

Thanks for your friendly and easy-to-read responses.

You should have been asked to create a password, did this not happen?

I am concerned that no filesystem type is shown or /home which I would have expected to see.

Caveat: I do not use LVM or encryption so my knowledge in this area is somewhat limited.

In any event, you would run fsck on the root partition and not the home partition.

In this case,
e2fsck -f /dev/nvme0n1p2

Report back if there are errors or other issues.

I was asked to create a password during the install process, same as with any usual Linux install. This was my first time selecting the encryption option.

I ran e2fsck -f /dev/nvme0n1p2, and it told me that it is mounted, but then it says:

e2fsck: Cannot continue, aborting.

My mistake, sorry.

You need to boot with a live USB so the filesystems are unmounted and then run that command from the live try mode.

Actually, once you are in the live environment please let us see the output of lsblk -f again before you start the fsck.

Can do. Here is the output of lsblk -f:

I am still concerned that nothing is showing for the nvme0n1p3

Regardless, try running the check now:
sudo e2fsck -f /dev/nvme0n1p2

When it completes, reboot without the USB and hopefully we will see some progress.

Unsuccessful.

I ran the above command and rebooted. It still took much longer to boot to the login screen (and this time it skipped emergency mode). When I entered my password, it spent nearly three minutes at a black screen before returning me back to the login screen.

Below is the output of that command. It finished instantly, which I feel like isn’t supposed to happen?

e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/nvme0n1p2: 536320/7815168 files (0.2% non-contiguous), 7068289/31250176 blocks

@samuelitooooo
Ok one of the screen shots the system complained it could not find a block device.
specifically

/dev/disk/by-path/pci-0000:02:00.0-nvme-1-part/by-uuid/7c6558d5-a601-4aea-a81a-dbefd76f587e

Which has my curiosity up, on two files

  1. the fstab file contents. (I don’t suspect this to be a issue but could be)
    cat /etc/fstab
    will display the contents of the file which you can then copy the screen out put (via highlight and ctrl-c keystroke or right clicking the mouse button, or the previous usage of a phone camera)

sudo nano /etc/fstab (will put you into a editor named nano for the file, the symbol # is to create a comment that prevents the file line item from attempting to load. one places the # symbol in the starting line to stop the file from loading that line.)
example from one of my servers

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p2 during curtin installation
/dev/disk/by-uuid/fa5e9974-c638-4552-aa25-f0aa2761abb0 / ext4 defaults 0 1
# /boot/efi was on /dev/nvme0n1p1 during curtin installation
/dev/disk/by-uuid/97A4-7C5F /boot/efi vfat defaults 0 1
/swap.img       none    swap    sw      0       0

Every line that has the # in the start of a line is skipped

  1. The grub file. <<<<<<<<<<<<<<(here is where I Think the actual issue “MIGHT Reside”)
    to display the contents
    cat /etc/default/grub

please copy & post the output on the grub file first

I’m suspecting believe it or not a video driver when attempting to load, It may not be the case .

I just want to see if you have a line within the file similar to:

GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”

I suspect a fix maybe to comment that line and the paste below it this

# GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash nomodeset”

save the file with the editor then run

sudo update-grub2
or 
sudo update-grub

Reboot
the major issue (log-in) may resolve itself if so great
if it doesn’t easily reversed back to the original status

and if the block device still complains then a simple comment in front of the line in fstab “might” correct it
example

# /dev/disk/by-path/pci-0000:02:00.0-nvme-1-part/by-uuid/7c6558d5-a601-4aea-a81a-dbefd76f587e

that is provided that /dev/disk/by-path/pci-0000:02:00.0-nvme-1-part/by-uuid/7c6558d5-a601-4aea-a81a-dbefd76f587e is present in the fstab file

It skipped emergency mode for me again, so I entered into tty to get the contents below for you. (I guess whether it automatically brings up emergency mode is sporadic after booting another live distro.)

Here are the contents of `/etc/default/grub`

and here are the contents of `/etc/fstab`

I’ll make another reply after attempting the above suggestions.

Just some background until you post after attempting to get a clean boot.
which I think the line

GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash nomodeset”

in the /etc/default/grub

and then sudo update-grub or sudo update-grub2 (system /OS dependent I don’t recall your grub version) will get a boot.

fast forward to the what I suspect is the minor part
in the etc/fstab
/dev/disk/by-path/pci-0000:02:00.0-nvme-1-part/by-uuid/7c6558d5-a601-4aea-a81a-dbefd76f587e

is attempting to mount in the /home directory (look at the 11th line)

 /dev/disk/by-path/pci-0000:02:00.0-nvme-1-part/by-uuid/7c6558d5-a601-4aea-a81a-dbefd76f587e  /home ext4 defaults 0 1

and is failing to mount properly. Probably because /home has directories and files prior to fstab mounting the drive (partition).
the command

ls /home  

will verify that as that drive is not mounted if there is files then it would error when attempting to mount

one could just comment that line temporally to resolve the boot error process
just remember that you have to issue the grub-update after editing the grub file.

Then revisit this ( etc/fstab) after being able to cleanly boot.

ls -l /dev/disk/by-path/

will display if the /dev/disk/by-path is actually valid below is a sample

mike@media1:~$ ls -l /dev/disk/by-path/
total 0
lrwxrwxrwx 1 root root  9 Apr 17 15:01 pci-0000:00:1f.2-ata-2 -> ../../sda
lrwxrwxrwx 1 root root  9 Apr 17 15:01 pci-0000:00:1f.2-ata-2.0 -> ../../sda
lrwxrwxrwx 1 root root 10 Apr 19 21:56 pci-0000:00:1f.2-ata-2.0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 19 21:56 pci-0000:00:1f.2-ata-2-part1 -> ../../sda1
lrwxrwxrwx 1 root root 13 Apr 17 15:01 pci-0000:01:00.0-nvme-1 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Apr 17 15:01 pci-0000:01:00.0-nvme-1-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 Apr 17 15:01 pci-0000:01:00.0-nvme-1-part2 -> ../../nvme0n1p2

or for a more streamline approach

ls -l /dev/disk/by-path/ | grep pci-0000:02:00.0-nvme-1-part

which will look for just that partition on the drive by path

I did this, and nothing changed other than the resolution of my login screen; it’s zoomed out now.

However this does help me see the entire command line in TTY and emergency mode, so I’ll keep it for now; thanks. I had to look up how to use nano without being able to see the shortcut guide towards the bottom; now I have no problem with it, and I can see the command I’m actually typing without having to clear the screen. I understand how to revert it back to how I had it.


Sorry but I don’t understand your instructions for /etc/fstab. I’ll try to make sense of this and try tomorrow.

so at this point can you pretty much use the system ?
log in and access some items.

except for the drive mounting error on /home ?

try this

lsblk -o NAME,UUID,SIZE,FSTYPE,TYPE,MOUNTPOINT 

then let’s see if /home is on the system

ls /

and post the output of the commands please

2 Likes

After you completed the above post type this and post output as well please

ls /home && ls /home/$USER

No, I cannot. As I said, nothing changed other than the resolution of the login screen and the terminal.

So I commented out the /dev/disk/by-path/pc1-… line in /etc/fstab and did sudo update-grub. It boots way faster now so I get to the login manager (SDDM) in the same amount of time as I used to when things were working fine (and it skips emergency mode), but when I type my password and log in, it still spits me back out to the login manager—also way faster now, almost instantly.

Updating the grub worked, but it scrolled through so much output for a couple minutes before finalizing. I show one screenshot of that below—I’m not sure if the Discourse platform allows video files.

One line may be of concern:

error: cannot read `/dev/nvme0m1': Input/output error.

Okay, you asked me for the output of multiple commands. Here they are (I went into TTY to get these):

encrypted LVM give me a fit …
However there seems to be a bug report related to LVM encrypted volumes.
In that bug report one method was to run

sudo apt-get -y install systemd-cryptsetup

then to update the system with

update-initramfs -u -k all

after editing /etc/crypttab file if needed

there was quite a bit more that I found, but most reported success with the above.

If that doesn’t work this will probably turn into a marathon post …
I’m wondering if honestly the quickest method would not be a clean fresh re-install. Of course that is highly dependent on what files you have. And if backed up your desire to just fix what you have instead of starting over.

With that being said if you desire to keep plugging away at this I’ll help what I can
here is the bug with the cryptsetup fix

here is another post on stack exchange which resembles your issue
Stack exchange

2 Likes

Alright, I’ll go for a full reinstall. Fortunately I did have my documents backed up.

Here’s the output for update-initramfs -u -k all:


Would you say this is an issue with LVM? If so, should I avoid LVM for future installs [at least until said bug addressed]? I honestly only opted for encryption under extreme precaution in case my mini-PC is stolen. That’s it. :stuck_out_tongue: I’m willing to do without it; I just want to use my computer.

Also, I’m new to Discourse, but should I mark your last response as the solution, even though not everyone may consider [wiping everything and] reinstalling a solution? haha

I appreciate your time and effort (as well as rubi1200’s).

1 Like

Most of my systems don’t do GUI, I use mostly CLI is it superior ? No, I just prefer the CLI

I use LVM on my servers with no issue. As well as ZFS together.

I don’t use LVM (nor do I use ZFS on boot drives, which is honestly my preferred method to join drives together) on my boot drives.

Is the encryption methods used with LVM flawed, NO. Only if the user does not understood what the system needs to access to decrypt.

I don’t encrypt LVM… With that said I honestly know many whom do and don’t have issues.

What I do suspect is basically is errors in your fstab file in that your nvme drive is not decrypting properly thus not mount the /home.

Do I think you had a bad setup? Not really just a series of unfortunate events leading to this.

Hmmm file security big fan, but that is something that you as a user have to determine the actual sensitivity of as well and the need for or against. That I cannot answer for you.
I hope my answers help … I do know at anytime one can setup a LVM encryption on a drive containing sensitive data even after a clean installation.

2 Likes