u/Sr_Renks

Fala, pessoal.

Estou procurando uma VPS no Nordeste, de preferência até uns R$80/mês. A ideia é usar basicamente como um ponto de roteamento: minha internet residencial não permite receber conexões de entrada direito, então quero colocar uma VPS com IP público na frente e fazer um túnel WireGuard até minha máquina, também pra servir de uso pro meu server de minecraft (na minha máquina).

Não preciso de uma máquina muito parruda. O que mais importa é:

- boa conectividade/latência dentro do Nordeste;
- IPv4 público ou IPv6 público;
- WireGuard/VPN permitido;
- poder encaminhar portas TCP/UDP pela VPS;
- tráfego sem uma franquia muito baixa;
- preço até ~R$80.

Pode ser Fortaleza, Teresina, Recife, Natal, João Pessoa, Salvador etc. Não faço questão de uma cidade específica, desde que a conectividade seja boa.

Já encontrei algumas opções, mas estou mais interessado em experiências reais. Alguém usa alguma VPS no Nordeste e recomenda?

Algum cliente? Queria saber apenas sobre a instabilidade, iria contratar 1gbps + IPv4 fixo (útil pro meu contexto) por 200 reais, o que tá dentro do orçamento.

Hello everyone,

I use Arch Linux on my ThinkPad E14 Gen 7 AMD and I am trying to understand if my firmware startup time is normal or if there is something wrong with the UEFI configuration.

Hardware:
- Lenovo ThinkPad E14 Gen 7 AMD
- CPU: AMD Ryzen 7 250 (Zen 4, 8C/16T, SMT enabled)
- GPU: Radeon 780M (RDNA3 integrated graphics)
- RAM: 16GB DDR5-5600 dual channel
- Storage: 512GB NVMe PCIe 4.0 (Micron)
- Display: 1920x1200 IPS 16:10
- TPM 2.0 (ST Micro)
- Secure Boot enabled with custom keys

Software:
- Arch Linux rolling release
- Linux kernel 7.1.x
- systemd 261.x
- Hyprland Wayland session
- Btrfs on LUKS2
- systemd-boot + UKI
- Secure Boot managed with sbctl
- Measured boot enabled
- TPM PCR policies with systemd-pcrlock

Boot layout:
- EFI partition mounted at /efi
- UKI located at /EFI/Linux/arch-linux.efi
- systemd-boot as bootloader
- Timeout disabled:
    - timeout 0
    - console-mode keep

Current boot time:
- Startup finished in 10.379s (firmware)
- 2.473s (loader)
- 1.456s (kernel)
- 3.277s (initrd)
- 6.697s (userspace)
= 24.284s total

The Linux side seems fine:
- Kernel starts in ~1.4s
- initrd in ~3.3s
- graphical.target reached after ~5.4s userspace

The main delay appears to be the UEFI firmware stage (~10 seconds). Some relevant details:

TPM initializes correctly: - tpm_tis STM0925:00: 2.0 TPM

Measured boot is working: - Secure Boot: enabled (user) - TPM2 Support: yes - Measured UKI: yes - Measured OS: yes No firmware updates are available through fwupd: - No updates available

Questions: 1. Is ~10 seconds of firmware time normal for this ThinkPad model?

2. Could the remaining UEFI boot entries (USB/PXE/NVMe fallback entries) cause this delay?

3. Are there any recommended Lenovo BIOS settings to reduce POST/UEFI initialization time?

4. Does Secure Boot + UKI + TPM measured boot normally add noticeable firmware delay on ThinkPads?

Olá pessoal,

Estou configurando um ThinkPad E14 Gen 7 (AMD Ryzen 7, TPM 2.0 ST Microelectronics) com Arch Linux e tentando montar uma cadeia de boot segura:

- Secure Boot com minhas próprias chaves (sbctl)

- Kernel UKI assinado

- Desbloqueio automático do LUKS2 via TPM2 usando systemd-cryptenroll

- systemd-pcrlock para vincular o desbloqueio ao estado esperado do boot

- Snapshots Btrfs com fluxo de recuperação

O problema é que só consigo fazer o TPM funcionar usando PCR 15.

Inicialmente eu queria usar algo como PCR 7 + 11 + 12 (ou outra combinação recomendada), pois pelo que entendi esses PCRs estão mais relacionados ao estado do Secure Boot, medições do kernel/initrd e cadeia de inicialização. Porém, sempre que tento usar esses PCRs, a política do TPM não corresponde após o reboot.

PCR 15 é o único que funciona de forma consistente.

Algumas observações:

- Secure Boot está habilitado e validado.

- O sistema inicializa através de um UKI assinado.

- O log de eventos do TPM existe e as medições parecem normais.

- O systemd-pcrlock funciona após o boot, mas tive problemas ao prever/travar alguns componentes.

- O comando "systemd-pcrlock predict" mostrou componentes ausentes como:

- "720-kernel-initrd"

- "750-os-separator"

- "770-nvpcr-separator"

- eventos de shutdown/finalização

No início eu gerei as políticas dentro do ISO do Arch/chroot, depois descobri que isso estava errado porque as medições do TPM eram do ambiente live e não da instalação real. Regenerei as políticas inicializando pelo sistema instalado.

Também testei diferentes combinações de PCR:

- Apenas PCR 7

- PCR 7 + 11

- PCR 7 + 11 + 12

- Outras combinações envolvendo medições do boot

A maioria das combinações falha no desbloqueio do TPM após o reboot, enquanto PCR 15 funciona.

Configuração atual:

- Arch Linux

- Btrfs sobre LUKS2

- systemd-boot/UKI

- Chaves próprias de Secure Boot

- Desbloqueio TPM2 usando systemd-cryptenroll

- Política usando PCR 15

Minhas dúvidas:

1. Estou entendendo errado o papel do PCR 15 nesse cenário? Usar PCR 15 sozinho é uma escolha razoável para desbloqueio automático do LUKS usando systemd-pcrlock?

2. PCR 7 + 11 + 12 ainda é considerada a abordagem recomendada para esse tipo de configuração? Se sim, o que poderia estar fazendo minha máquina falhar com esses PCRs?

3. Existe alguma limitação específica do firmware Lenovo/ThinkPad ou da plataforma AMD que possa explicar esse comportamento?

4. Existe a possibilidade de eu estar fazendo algo errado na geração do UKI, no bloqueio da linha de comando do kernel ou na ordem de geração da política do pcrlock?

Gostaria de entender o que posso estar fazendo errado antes de decidir permanecer definitivamente com PCR 15.

Hi everyone,

I am setting up a ThinkPad E14 Gen 7 (AMD Ryzen 7, ST Microelectronics TPM 2.0) with Arch Linux and trying to build a secure boot chain:

- UEFI Secure Boot with my own keys (sbctl)

- Signed UKI kernel

- systemd-cryptenroll TPM2 auto-unlock for LUKS2

- systemd-pcrlock to bind unlock to the expected boot state

- Btrfs snapshots with recovery workflow

The issue is that I can only get TPM enrollment working with PCR 15.

I originally wanted something like PCR 7 + 11 + 12 (or another recommended combination) because it seems more tied to Secure Boot state, kernel/initrd measurements, and the boot chain. However, whenever I try to use these PCRs, the TPM policy does not match after reboot.

PCR 15 is the only one that consistently works.

Some observations:

- Secure Boot is enabled and verified.

- The system boots through a signed UKI.

- The TPM event log exists and measurements appear normal.

- systemd-pcrlock works after boot, but I had issues predicting/locking some components.

- "systemd-pcrlock predict" showed missing components such as:

- "720-kernel-initrd"

- "750-os-separator"

- "770-nvpcr-separator"

- shutdown/finalization events

I initially generated policies from the Arch ISO/chroot environment, then discovered this was wrong because the TPM measurements were from the live environment and not the real installed boot chain. I regenerated the policy from the real system after boot.

I also tested different PCR combinations:

- PCR 7 only

- PCR 7 + 11

- PCR 7 + 11 + 12

- other combinations involving boot measurements

Most combinations failed TPM unlock after reboot, while PCR 15 worked.

My current setup:

- Arch Linux

- Btrfs on LUKS2

- systemd-boot/UKI

- custom Secure Boot keys

- TPM2 unlock using systemd-cryptenroll

- PCR 15 policy

Questions:

1. Am I misunderstanding the purpose of PCR 15 in this workflow? Is using PCR 15 alone a reasonable choice for LUKS auto-unlock with systemd-pcrlock?

2. Is PCR 7 + 11 + 12 still the recommended approach for this kind of setup, and if so, what could be causing my machine to fail with those PCRs?

3. Are there ThinkPad/AMD firmware limitations that can explain this behavior?

4. Could my UKI generation, kernel command line locking, or pcrlock policy generation order be wrong?

I would appreciate any suggestions about what I might be doing incorrectly before I settle with PCR 15 permanently.

Hi everyone,

I am setting up a ThinkPad E14 Gen 7 (AMD Ryzen 7, ST Microelectronics TPM 2.0) with Arch Linux and trying to build a secure boot chain:

- UEFI Secure Boot with my own keys (sbctl)

- Signed UKI kernel

- systemd-cryptenroll TPM2 auto-unlock for LUKS2

- systemd-pcrlock to bind unlock to the expected boot state

- Btrfs snapshots with recovery workflow

The issue is that I can only get TPM enrollment working with PCR 15.

I originally wanted something like PCR 7 + 11 + 12 (or another recommended combination) because it seems more tied to Secure Boot state, kernel/initrd measurements, and the boot chain. However, whenever I try to use these PCRs, the TPM policy does not match after reboot.

PCR 15 is the only one that consistently works.

Some observations:

- Secure Boot is enabled and verified.

- The system boots through a signed UKI.

- The TPM event log exists and measurements appear normal.

- systemd-pcrlock works after boot, but I had issues predicting/locking some components.

- "systemd-pcrlock predict" showed missing components such as:

- "720-kernel-initrd"

- "750-os-separator"

- "770-nvpcr-separator"

- shutdown/finalization events

I initially generated policies from the Arch ISO/chroot environment, then discovered this was wrong because the TPM measurements were from the live environment and not the real installed boot chain. I regenerated the policy from the real system after boot.

I also tested different PCR combinations:

- PCR 7 only

- PCR 7 + 11

- PCR 7 + 11 + 12

- other combinations involving boot measurements

Most combinations failed TPM unlock after reboot, while PCR 15 worked.

My current setup:

- Arch Linux

- Btrfs on LUKS2

- systemd-boot/UKI

- custom Secure Boot keys

- TPM2 unlock using systemd-cryptenroll

- PCR 15 policy

Questions:

1. Am I misunderstanding the purpose of PCR 15 in this workflow? Is using PCR 15 alone a reasonable choice for LUKS auto-unlock with systemd-pcrlock?

2. Is PCR 7 + 11 + 12 still the recommended approach for this kind of setup, and if so, what could be causing my machine to fail with those PCRs?

3. Are there ThinkPad/AMD firmware limitations that can explain this behavior?

4. Could my UKI generation, kernel command line locking, or pcrlock policy generation order be wrong?

I would appreciate any suggestions about what I might be doing incorrectly before I settle with PCR 15 permanently.

Hi everyone,

I'm running Arch Linux on a Lenovo ThinkPad E14 Gen 7 with an AMD Ryzen 7 250 (Zen 4), a Micron PCIe 4.0 NVMe SSD, and GRUB as my bootloader.

My systemd-analyze output is:

Startup finished in 11.628s (firmware) + 6.300s (loader) + 3.676s (kernel) + 4.971s (userspace) = 26.576s

From what I can tell:

• Firmware (UEFI): 11.6s
• GRUB: 6.3s
• Kernel: 3.7s
• Userspace: 5.0s

systemd-analyze blame and critical-chain don't show any major bottlenecks. The slowest service is tlp.service (~1s), but it isn't on the critical boot path.

My GRUB configuration currently has:

GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu

The BIOS is already up to date according to fwupdmgr, and there are no available firmware updates.

My questions are:

1. Is this boot time considered normal for this ThinkPad and CPU?
2. Is the 11.6-second firmware initialization typical for recent Lenovo ThinkPads?
3. Besides reducing the GRUB timeout (which would save about 5 seconds), are there any BIOS or Linux optimizations worth trying?
4. Would switching from GRUB to systemd-boot make a noticeable difference in boot time?

I'd appreciate hearing from anyone with a similar ThinkPad or Ryzen-based system.Hi everyone,I'm running Arch Linux on a Lenovo ThinkPad E14 Gen 7 with an AMD Ryzen 7 250 (Zen 4), a Micron PCIe 4.0 NVMe SSD, and GRUB as my bootloader. My systemd-analyze output is:

Startup finished in 11.628s (firmware) + 6.300s (loader) + 3.676s (kernel) + 4.971s (userspace) = 26.576s

From what I can tell:

• Firmware (UEFI): 11.6s
• GRUB: 6.3s
• Kernel: 3.7s
• Userspace: 5.0s

systemd-analyze blame and critical-chain don't show any major bottlenecks. The slowest service is tlp.service (~1s), but it isn't on the critical boot path.

My GRUB configuration currently has:

GRUB_TIMEOUT=5

GRUB_TIMEOUT_STYLE=menu

The BIOS is already up to date according to fwupdmgr, and there are no available firmware updates.

My questions are:

1. Is this boot time considered normal for this ThinkPad and CPU?
2. Is the 11.6-second firmware initialization typical for recent Lenovo ThinkPads?
3. Besides reducing the GRUB timeout (which would save about 5 seconds), are there any BIOS or Linux optimizations worth trying?
4. Would switching from GRUB to systemd-boot make a noticeable difference in boot time?

I'd appreciate hearing from anyone with a similar ThinkPad or Ryzen-based system.

For some time now I've been trying to control, or at least get information about the RPMs, but without success on Arch 7.1. Does anyone have any idea how this could be possible?

Me irritando com a minha atual, velocidade ficando nem perto de 90% do contratado, instabilidade e afins. Alguma recomendação boa para a região Turu e arredores? Arthur Carvalho.

Já não aguento mais as telas do Ilha sendo um sorteio de qual é a menos pior, todas com contraste imundo, como se estivesse assistindo a céu aberto ao meio-dia. Tô mapeando pessoalmente quais salas estão com esse sintoma; por outro lado, sigo com o Golden e o Slz como os melhores até então. Mais alguém notou isso?

​

Fora isso, raramente vejo algo no cinema hoje em dia: tanto por raramente ter algo realmente bom ou interessante pra assistir quanto porque simplesmente qualquer filme ligeiramente ligado a um nicho mais jovem enche de vagabundo que nunca tomou uma surra na rua por se comportar igual a um subumano. Esses dias dei um apavoro num grupo que estava falando alto numa sessão como se estivessem em casa. Sei que é um problema geral, mas eu pagaria o dobro pra ter o lanterninha devolta expulsando essa garotada lá fora.

Felizmente, Backrooms ignora quase todo o lixo de conteúdo criado pela fanbase e se mantém focado no universo do Kane Pixels. Ainda assim, achei o filme mediano, algo em torno de 6/10.

A direção é impressionante considerando a origem do projeto, mas, para mim, funciona mais como uma extensão dos curtas do que como um filme com uma narrativa realmente sólida. O foco está muito mais na atmosfera/estética e na expansão do universo do que na construção de uma história de fato.

Eu não esperava muito. Nem assisto trailers hoje em dia, então imaginei que o Kane manteria a essência dos curtas, adaptando-a ao cinema e usando o found footage de forma pontual e inteligente (como de fato acontece) enquanto aproveitava o maior orçamento e duração para expandir melhor a proposta.

Também esperava algo mais próximo de Cube e Cube 2: Hypercube, onde os personagens existem principalmente para nos inserir naquele mistério e explorar seu contexto. Em vez disso, o filme divide sua atenção entre a atmosfera e uma trama mais convencional.

Para mim, é justamente aí que ele se enfraquece. A parte atmosférica funciona muito bem, mas a tentativa de aprofundar personagens e conflitos nunca me envolveu. Eu já tinha aceitado vivenciar aquele mundo pela perspectiva do Clark, que funcionava melhor como um veículo para explorar aquele ambiente do que como protagonista de uma narrativa dramática. Não desenvolvi apego nem interesse por nenhum personagem, então boa parte de seus arcos serviu apenas para sustentar a tensão, às vezes de forma até arrastada.

Quando o filme pareceu retornar à proposta que mais me interessava, voltei a me animar. Mas o corte abrupto para o final acabou me deixando com a sensação de que faltou algo.

Felizmente, Backrooms ignora quase todo o lixo de conteúdo criado pela fanbase e se mantém focado no universo do Kane Pixels. Ainda assim, achei o filme mediano, algo em torno de 6/10.

A direção é impressionante considerando a origem do projeto, mas, para mim, funciona mais como uma extensão dos curtas do que como um filme com uma narrativa realmente sólida. O foco está muito mais na atmosfera/estética e na expansão do universo do que na construção de uma história de fato.