Você está em modo de emergência

Como telcoM disse nos comentários, as mensagens BPF provavelmente não são relevantes e provavelmente fizeram com que o erro real saísse da tela.

Nenhuma das ações (pressionar ctrl-d ou enter) provavelmente causará danos, mas provavelmente também não resolverá o problema imediatamente. Se você estiver pronto para tentar consertar o sistema, não custa nada tentar isso.

Se você pressionar Enter, poderá explorar o sistema e tentar determinar o erro e possivelmente corrigi-lo (parcialmente).

Os comandos journalctl sugeridos no erro devem ajudar a revisar o log de inicialização completo que foi exibido, podendo expor o erro real, provavelmente algo sobre não encontrar um disco ou não encontrar o disco raiz.

Comparar os dispositivos lsblk disponíveis com os discos esperados do fstab e dfverificar os discos realmente montados pode ajudar a determinar qual deles falhou (se você ainda não encontrou isso nos logs).

Se o disco com falha não for importante, você pode editar o fstab (talvez tenha que remontar o read write primeiro) para comentar o disco com falha. Uma vez feito isso, você pode sair do modo de recuperação e tentar uma inicialização normal e então talvez explorar o disco ausente mais tarde.

Se o disco com falha for importante (como o disco raiz), talvez seja necessário fazer algo mais difícil para consertá-lo, dependendo do motivo da falha na montagem.

Você precisará fazer login com credenciais de root. Tente o sugerido "journalctl -xb", pois pode ajudar.

As mensagens BPF são parte do log do kernel, em vez do log de inicialização, e parece que seu sistema falhou bem cedo. Parece provável que seu modo de emergência esteja vindo do initrd (initramdisk) e que a raiz regular ainda não foi montada. O comando 'mount' mostrará a você.

SE for esse o caso, você pode querer inicializar uma mídia live para sua distribuição, ou então um kernel de "resgate", se presente.

Análise

A captura de tela do imgur indica que o sistema de arquivos raiz e o swap criptografado foram ativados com sucesso, então o problema provavelmente é um ou mais dos sistemas de arquivos restantes listados em /etc/fstab.

Os erros que você encontrou no diário têm várias causas:

BIOS Error (bug): Could not resolve symbol

Provavelmente isso é algo que somente uma atualização do BIOS poderia consertar... e provavelmente sempre esteve lá, você só não percebeu.

[drm] *ERROR* Port F/TC#3: timeout waiting for PHY ready

Algo sobre um adaptador de vídeo, provavelmente procurando por uma porta que não está conectada à placa-mãe.

Failed to insert module 'autofs4': Invalid argument
Same error with modules 'lp', 'ppdev', 'parport_pc', 'msr', 'kyber_iosched'.
Failed to start Load Kernel Modules.

Isso é interessante... você instalou alguma atualização recentemente? Um pacote de kernel atualizado, talvez? Alguns módulos do kernel parecem estar falhando, mas nenhum deles deve ser absolutamente crítico. Metade deles está relacionada a uma porta paralela legada (porta de impressora) que praticamente nenhum sistema moderno tem mais.

nvme0n1: /usr/lib/udev/rules.d/60-block-pop.rules:6 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:0e.0/pci10000:e0/10000:e0:1d.0/10000:e1:00.0/nvme/nvme0/nvme0n1/queue/scheduler}, ignoring: invalid argument
loop4: /usr/lib/udev/rules.d/60-block-pop.rules:2 Failed to write ATTR{/sys/devices/virtual/block/loop4/queue/scheduler}, ignoring: Invalid argument
Same with loop 0-7

Uma regra do udev /usr/lib/udev/rules.d/60-block-pop.rulesestá tentando alternar o agendador de E/S usado para vários sistemas de arquivos... e talvez fazendo isso de uma forma "barulhenta": parece estar iterando em todos os dispositivos semelhantes a disco e não se importando se a configuração não está disponível para um dispositivo específico.

FAT-fs (nvme0n1p2): IO charset iso8859-1 not found
Failed to mount /recovery
Failed to mount /boot/efi.

Este pode ser o motivo mais imediato pelo qual seu sistema não está inicializando: ele está tentando montar /recoverye /boot/efi, que aparentemente são ambos sistemas de arquivos da família FAT (provavelmente especificamente FAT32).

Mas como /etc/fstabnão define uma iocharset=opção de montagem para eles, o sistema está tentando montá-lo usando o conjunto de caracteres de E/S padrão integrado para sistemas de arquivos da família FAT: iso8859-1. Mas aparentemente o suporte para ele não está disponível para o kernel: talvez ele tenha sido configurado como um módulo carregável, mas o nls_iso8859-1.komódulo não está disponível ou foi corrompido de alguma forma. Ou talvez todo o suporte de caracteres ISO8859-1 para sistemas de arquivos tenha sido completamente deixado de fora da configuração do kernel mais novo, porque alguém assumiu que todo sistema de arquivos moderno usaria UTF-8. (Isso seria um erro.)

Tudo isso me faz pensar que algo pode ter dado errado com a atualização mais recente do kernel que seu sistema recebeu. Talvez o processo de criação do initramfs tenha ficado sem espaço em disco, e o sistema agora está inicializando com um initramfs incompleto, ou algo assim?

Para verificar isso, execute dpkg --list 'linux-image*' to list the currently-installed kernel packages in your system. If there's more than one, find the highest-version one that does not say (meta-pacote) in theDescription field, and note down in full what itsName` no campo diz. Então procure por esse nome nos logs de gerenciamento de pacotes:

grep <kernel package name> /var/log/dpkg.log

substituindo <kernel package name>pelo nome completo do pacote que você encontrou. Isso deve lhe dar as entradas de log indicando quando o pacote do kernel foi instalado. Se a data de instalação for logo antes do início desse problema, você provavelmente encontrou a causa.

Solução alternativa

Se houver mais de um kernel instalado, a solução mais fácil é tentar inicializar o sistema com a segunda versão mais recente do kernel em vez da mais nova. Eu pessoalmente não uso o Pop_OS, então este conselho será baseado no Google. O Pop_OS não usa o bootloader mais comum do Linux, GRUB, mas em vez disso parece usar systemd-boot. Então os procedimentos usuais envolvendo o GRUB não se aplicarão .

No início do processo de inicialização, deve haver um menu simples baseado em texto com cerca de quatro itens e um tempo limite de 10 segundos ou mais. Pode parecer com isso:

Pop!_OS (pop_os-current.conf)
Pop!_OS (pop_os-oldkern.conf)
Pop!_OS recovery
Reboot Into Firmware Interface

Se você normalmente não vê esse menu, tente tocar na tecla SPACE assim que ligar o sistema. Continue tocando até ver algo que não seja mensagens do BIOS ou o logotipo do fabricante, e você deverá obter o menu descrito acima.

Se apenas o pacote do kernel mais novo tiver o problema, selecionar a opção de menu "kernel antigo" ( Pop!_OS (pop_os-oldkern.conf)ou similar) deve permitir que o sistema inicialize mais ou menos normalmente... por enquanto. Mas você não deve deixar o sistema instalar mais nenhuma atualização até descobrir o que deu errado e, idealmente, consertar.

Se o sistema inicializar em um estado normal com o kernel antigo, abra uma janela de terminal e execute df -hpara ver se algum sistema de arquivos está 100% cheio ou próximo disso. Em particular, se o /boot/efisistema de arquivos estiver muito cheio, pode ser a causa raiz dessa falha. O tamanho da sua /dev/nvme0n1p1partição (que provavelmente é sua partição de sistema EFI e, portanto, /boot/efi) é de apenas 498M, o que pode facilmente ser muito pequeno para várias versões de kernel instaladas + seus arquivos initramfs.

Se inicializar com um kernel mais antigo não ajudar, a Pop!_OS recoveryopção boot também pode valer a pena tentar. No entanto, não tenho experiência com isso, então você deve ler a documentação do System76 sobre isso primeiro.