My first thought is that your keyboard is broken. Liquid damage maybe or similar? keys getting pressed by itself. Even if you connect external one the laptop one still outputs garbage.
Clean it up maybe? test on live usb to see what the keys are doing.

It does kind of sound like a stuck key. Here's something similar with a problematic volume key:

Odd that UEFI works fine, but maybe it simply ignores some special keys?

Edit: At least on my system ^[[26~ is volume down. Not sure if that helps?

Last edited by whizse on 24 October 2024 at 11:43 am UTC

This is a keyboard issue in some way, but it could be both physical or software. My suggestion would be to try the previous kernel first.

The ^[[(code)~ is always indication of keyboard input. To see it intentionally you can type "read" as a command and start pressing keys like F1, F2, F12, etc. (ctrl + c to exit)

Sorry, maybe I wasn't clear.

This is after my manufacturer logo and before I would normally input my disk encryption passphrase, prior to the operating system loading.

Instead of seeing the (semi) graphical screen to enter my disk encryption password, I get a Terminal-like screen showing the giberish mentioned above automatically repeating on-screen (not through my input, it just appears on-screen itself for a few seconds), followed by that error message asking for my passphrase, which never works.

There is no possibility of liquid damage on this laptop, and this laptop - which is still only about two months old - has never been subject to any sort of damage; it was also in a protective case all day, sitting in on the back seat of a car with nothing on top of it, so it's unlikely to have been subject to some sort of unknown damage.

I think this relates to LUKS, the disc encryption... But I have no idea why it has randomly done this, when I haven't updated or done anything else that might cause such an issue.

Edit: Actually, I just remembered that I did one thing prior to shut down this morning, which was "purge" Geary from Pop!_OS using:
sudo apt purge geary

I foolishly didn't read what Terminal gave me (e.g. additional packages being removed) and just hit "Y" (I figured that nothing critical would be removed), so maybe I broke something doing this?

Also, for s#!ts and giggles, I launched a "live" session, to test the keyboard using LibreOfice... I checked all of the keys, nothing appears to be "stuck" or otherwise malfunctioning, and keys that offer on-screen input (e.g. letters, numbers, etc...) all appear to be working perfectly.

Last edited by Cyba.Cowboy on 24 October 2024 at 1:04 pm UTC

If a key is held down during boot, the boot splash screen (plymouth on Pop_OS I think?) might exit and you get a terminal like interface.

Likewise, if you get random key-presses when entering a password (even if they are not echoed to the screen) you are not going to produce the right passphrase.

Not saying 100% this is the issue but it does seem the most likely.

If a key is held down during boot, the boot splash screen (plymouth on Pop_OS I think?) might exit and you get a terminal like interface.

The only splash screen I see if the manufacturer logo (in my case, ASUS), then it briefly shows that gibberish automatically appearing on-screen, before the error message.

Are you saying I should hold down a particular key when I see the ASUS logo? Any idea what key?

Likewise, if you get random key-presses when entering a password (even if they are not echoed to the screen) you are not going to produce the right passphrase.

So you're saying that even if I am entering the correct passphrase (which I am), it's likely misinterpreting the input and thus, even though I'm physically pushing the correct keys, the wrong input is being registered by the computer?

What on Earth would even cause this prior to the operating system being booted?

Last edited by Cyba.Cowboy on 24 October 2024 at 1:09 pm UTC

As mentioned previously, a stuck key seemed the most likely culprit.

But it seems less likely if you don't have any problems with a live session.

The error message is definitely from plymouth:

"src/client/plymouth.c: ply_error ("error: unexpectedly disconnected from boot status daemon");"

This is the boot "splash" application that provides a niceish GUI when you enter the passphrase for LUKS. If that exits you are left with the terminal/DOS like text interface.

if you can easily unplug the laptop keyboard or maybe disable it from UEFI/BIOS that would be a good test to see if it still posts this keypress.

It still looks like its just spamming some key..but if its all right on liveUSB then it might have some strange software bug ofc on your current install.

Another hypothesis is that "^[[26~" is red herring. It might always have been there but hidden by the plymouth splash.

A broken boot sequence (the "unexpectedly disconnected from boot status demon" error) and not being able to unlock an encrypted partition might be signs of a drive failure... just guessing here of course.

It would be interesting to run some SMART checks on the drive and see if you can unlock and mount it from a live USB. Not really sure what tools would be best for that on Pop_OS?

Sorry, maybe I wasn't clear.

This is after my manufacturer logo and before I would normally input my disk encryption passphrase, prior to the operating system loading.

At this point, your kernel is already booting. Try an older kernel, new kernels can do strange things sometimes, so it is still a valid check assuming it's not hardware. Otherwise, the other posters options may help

error: unexpectedly disconnected from boot status demon

Not sure that I can contribute anything useful to resolving the original problem. I have generally avoided drive encryption exactly because of the potential for problems like this.

It would be interesting to run some SMART checks on the drive and see if you can unlock and mount it from a live USB. Not really sure what tools would be best for that on Pop_OS?

When I had boot issues with my Pop!_OS installation, I was able to use my MintStick (Linux Mint live USB) to troubleshoot and fix the problem. The Mint Team always includes a number of very useful tools for troubleshooting problems on their live USB. In this case, perhaps Disks or GParted might help where SMART data is concerned?

Sorry for taking so long to get back to you all - I've been pretty sick and I'm in the midst of changing jobs.

I have generally avoided drive encryption exactly because of the potential for problems like this.

I'm considering doing this in the future, because it just causes too many headaches when something goes pear-shaped... My understanding is that for most "mainstream" distros, the default encryption used isn't all that strong, anyway.


Well, I've had a partial win - using this solution, I was able to decrypt my storage drive from a "live" session... But I can't seem to mount the storage drive using this command (as per the 'Ask Ubuntu' answer ):
udisksctl mount -b /dev/mapper/ubuntu--vg-root

If I had to take a guess, I'd say it's because I'm running Pop!_OS and not Ubuntu; but even when I tried "pop" and "popos", I was given the following errors:
Error looking up object for device /dev/mapper/pop--vg-root
Error looking up object for device /dev/mapper/popos--vg-root

Any ideas what I should use instead of "ubuntu"?

I think that if I can mount the drive from within the "live" session, manually backup the data and then do a "clean" install, I can work around this problem... It's not the perfect solution by any stretch of the imagination, but one which keeps my data safe.

If I had to take a guess, I'd say it's because I'm running Pop!_OS and not Ubuntu; but even when I tried "pop" and "popos", I was given the following errors:

Any ideas what I should use instead of "ubuntu"?

I don't use it myself, but just a quick thought: Since Pop!_OS has an underscore in its name, have you tried using "pop_os"?

Last edited by Pengling on 27 October 2024 at 11:31 pm UTC

Um, why mess around with udisksctl in this case?

Optionally switch to root:
$ sudo su -

If you skip above, just append sudo to the following.

Start by listing your partitions:

Note: This will work fine on bash, but zsh may throw a no matches found if one of those are missing, in that case just remove the missing one. For example: $ fdisk -l /dev/sd*

$ fdisk -l /dev/{hd*,sd*,nvm*}

This will show partitions from all regular drives, now read through it until you find your drive (See disk model). Under that you'll see a list of partitions, for example it might read "/dev/sda3"

There will probably be multiple partitions on your boot drive, some listed as "EFI System" and such. Try the largest partition first that says "Linux filesystem" or "unknown" (Unknown can occur in some LUKS setups, and does not indicate a problem in that case).

The largest one may be /dev/sda3 for example. Let's try to unlock it:

$ cryptsetup luksOpen /dev/sda3 data3

Let's mount it:
$ mkdir /mnt/data3
$ mount -t auto /dev/mapper/data3 /mnt/data3

If successful you should now see your data in /mnt/data:

$ ls /mnt/data3

On most configurations the largest partition is probably your home directory. Repeat the process for other smaller partitions if they exist, replacing "3" with the partition number, for example to mount an encrypted /dev/sda2:

$ cryptsetup luksOpen /dev/sda2 data2
$ mkdir /mnt/data2
$ mount -t auto /dev/mapper/data2 /mnt/data2

This will likely be your filesystem root ( / ) directory. You can swap and change then numbers or devices as needed, the process is the same.

When done, for each one just do:
$ umount /mnt/data2
$ cryptsetup luksClose data2

While swapping numbers as needed. :-)

Also, just to be clear, you can run a SMART health check on the drive without unlocking or mounting it.

Something like GNOME Disks, as suggested previously by Caldathras, works for for a traditional drive (mechanical or SSD). For NVMe you probably need a cli tool like "nvme" or "smartctl".

Start by listing your partitions:

Note: This will work fine on bash, but zsh may throw a no matches found if one of those are missing, in that case just remove the missing one. For example: $ fdisk -l /dev/sd*

$ fdisk -l /dev/{hd*,sd*,nvm*}

This will show partitions from all regular drives, now read through it until you find your drive (See disk model). Under that you'll see a list of partitions, for example it might read "/dev/sda3"

There will probably be multiple partitions on your boot drive, some listed as "EFI System" and such. Try the largest partition first that says "Linux filesystem" or "unknown" (Unknown can occur in some LUKS setups, and does not indicate a problem in that case).

The largest one may be /dev/sda3 for example. Let's try to unlock it:

$ cryptsetup luksOpen /dev/sda3 data3

Let's mount it:
$ mkdir /mnt/data3
$ mount -t auto /dev/mapper/data3 /mnt/data3

It worked all the way up until this point...

When I entered:
mount -t auto /dev/mapper/data3 /mnt/data3

I was told:
mount: /mnt/data3: unknown filesystem type 'LVM2_member'.

Oh, LVM, how exotic!

Joking aside. That's actually really good news! It means your LUKS encryption header is intact and the data can be decrypted.

Follow the instructions I gave above up to the point of mount. We just need to mount it slightly differently. The logical volumes *should* be automatically picked up. So I'll explain that way first.

This time after creating /mnt/data3, do this:

$ lvdisplay

This should output the logical volume(s), each one with its own LV Path, something like "/dev/data/root" for example.

To mount, simply use the path shown next to "LV Path". For example if it is "/dev/data/root":
$ mount /dev/data/root /mnt/data3

This should mount. Now check it:
$ ls /mnt/data3

Hopefully this gets you to your files. This should be all that is needed on a healthy setup.

Last edited by BlackBloodRum on 31 October 2024 at 7:12 pm UTC

It tells me the mount point does not exist:
root@pop-os:/home/pop-os# lvdisplay
  --- Logical volume ---
  LV Path                /dev/data/root
  LV Name                root
  VG Name                data
  LV UUID                PFMI6C-AhIh-lSgl-4CUa-2nbc-0Qok-9mFwYL
  LV Write Access        read/write
  LV Creation host, time pop-os, 2024-08-16 09:22:16 +0000
  LV Status              available
  # open                 0
  LV Size                <944.85 GiB
  Current LE             241881
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1
  
root@pop-os:/home/pop-os# mount /dev/data/root /mnt/data3
mount: /mnt/data3: mount point does not exist.
root@pop-os:/home/pop-os# mount /dev/data/root /mnt/data
mount: /mnt/data: mount point does not exist.

Did you create the directory /mnt/data3?

$ mkdir /mnt/data
$ mount /dev/data/root /mnt/data

This should get that mounted.