Orange Pi 5B – DietPi – NVMe regression after kernel update
Technical report / Relatório técnico
Português + English
🇧🇷Portuguese Version
PORTUGUÊS
Título
Orange Pi 5B – NVMe deixou de funcionar após atualização para o kernel 6.18.45-current-rockchip64
Resumo
Estou usando DietPi em um Orange Pi 5B, com o sistema operacional em /dev/mmcblk1p1 e um SSD NVMe utilizado para armazenamento em /media/SSD.
Após uma atualização do kernel, o NVMe deixou de funcionar corretamente. O dispositivo continuava sendo detectado pelo hardware, porém a partição não podia ser acessada/montada normalmente.
O problema foi resolvido fazendo downgrade do kernel:
• Kernel com problema: 6.18.45-current-rockchip64
• Pacote: linux-image-current-rockchip64 26.08.0-trunk-dietpi3
• Kernel funcional: 6.18.37-current-rockchip64
• Pacote: linux-image-current-rockchip64 26.08.0-trunk-dietpi2
Após voltar para o dietpi2, o NVMe voltou a ser reconhecido e montado normalmente.
Hardware e configuração
• Orange Pi 5B
• DietPi
• Sistema em /dev/mmcblk1p1
• SSD NVMe de aproximadamente 500 GB
• Filesystem do NVMe: ext4
• Mount point: /media/SSD
Sintoma
Antes da correção, o comando:
df -h /media/SSD
retornava:
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk1p1 58G 56G 0 100% /
Isso revelou que /media/SSD não estava realmente montado no NVMe. O diretório estava dentro do filesystem raiz, fazendo com que os dados fossem gravados em /dev/mmcblk1p1 e o armazenamento principal chegasse a 100%.
DietPi Drive Manager
/dev/nvme0n1p1 : No filesystem / format required | Capacity: 474G
/dev/mmcblk1p1 : / | ext4 | Capacity: 57.9G | Used: 55.7G (96%)
O NVMe era detectado como dispositivo de aproximadamente 474 GB, mas sua partição não estava sendo utilizada/montada.
Teste do filesystem
Com o kernel novo, executei:
fsck -n -f /dev/nvme0n1p1
Resultado:
fsck.ext2: Input/output error while trying to open /dev/nvme0n1p1
Como o NVMe funcionava anteriormente e o problema começou depois da atualização do kernel, evitei formatar ou reparar o filesystem antes de investigar o kernel.
Kernel que apresentava o problema
O sistema estava usando:
linux-image-current-rockchip64 26.08.0-trunk-dietpi3
uname -r:
6.18.45-current-rockchip64
Downgrade
A versão anterior disponível era 26.08.0-trunk-dietpi2.
Comando utilizado:
apt download linux-image-current-rockchip64=26.08.0-trunk-dietpi2
Depois:
dpkg -i linux-image-current-rockchip64_26.08.0-trunk-dietpi2_arm64.deb
O pacote fez downgrade de 26.08.0-trunk-dietpi3 para 26.08.0-trunk-dietpi2 e instalou o kernel 6.18.37-current-rockchip64.
Resultado após reiniciar
Após o reboot:
uname -r
6.18.37-current-rockchip64
E:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
NAME SIZE FSTYPE MOUNTPOINTS
mmcblk1 58.9G
└─mmcblk1p1 58.9G ext4 /
nvme0n1 476.9G
└─nvme0n1p1 474G ext4 /media/SSD
O NVMe voltou a funcionar normalmente e foi montado em /media/SSD.
Conclusão
O downgrade permitiu isolar o problema. O mesmo hardware e SSD que apresentavam o problema com 6.18.45-current-rockchip64 voltaram a funcionar imediatamente com 6.18.37-current-rockchip64.
Isso fornece uma forte evidência de uma regressão no kernel 6.18.45-current-rockchip64 / pacote dietpi3 relacionada ao funcionamento do NVMe no Orange Pi 5B.
Não foi necessário formatar o SSD nem reparar o filesystem.
Bloqueio temporário do kernel
Para evitar que uma atualização automática reinstale o kernel problemático, apliquei:
apt-mark hold linux-image-current-rockchip64
Confirmação:
apt-mark showhold
linux-image-current-rockchip64
Também testei:
apt upgrade --dry-run
Resultado:
Not upgrading:
linux-image-current-rockchip64
Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 1
Por enquanto, o sistema permanece no kernel 6.18.37-current-rockchip64.
Pergunta para a comunidade
Alguém utilizando Orange Pi 5B + DietPi + NVMe conseguiu reproduzir esse problema com 6.18.45-current-rockchip64?
Existe algum bug ou regressão conhecida nessa versão do kernel relacionada ao driver/controlador NVMe do Orange Pi 5B?
Por enquanto, manterei o kernel 6.18.37-current-rockchip64 até existir uma versão corrigida.
ENGLISH
Title
Orange Pi 5B – NVMe stopped working after updating to kernel 6.18.45-current-rockchip64
Summary
I am running DietPi on an Orange Pi 5B, with the operating system on /dev/mmcblk1p1 and an NVMe SSD used for storage at /media/SSD.
After a kernel update, the NVMe stopped working correctly. The device was still detected by the hardware, but its partition could no longer be accessed/mounted normally.
The issue was resolved by downgrading the kernel:
• Problematic kernel: 6.18.45-current-rockchip64
• Package: linux-image-current-rockchip64 26.08.0-trunk-dietpi3
• Working kernel: 6.18.37-current-rockchip64
• Package: linux-image-current-rockchip64 26.08.0-trunk-dietpi2
After reverting to dietpi2, the NVMe was detected and mounted normally again.
Hardware and configuration
• Orange Pi 5B
• DietPi
• OS on /dev/mmcblk1p1
• Approximately 500 GB NVMe SSD
• NVMe filesystem: ext4
• Mount point: /media/SSD
Symptom
Before the fix, the following command:
df -h /media/SSD
returned:
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk1p1 58G 56G 0 100% /
This showed that /media/SSD was not actually mounted on the NVMe. It was simply a directory on the root filesystem. As a result, data was being written to /dev/mmcblk1p1 and the main storage reached 100% usage.
DietPi Drive Manager
/dev/nvme0n1p1 : No filesystem / format required | Capacity: 474G
/dev/mmcblk1p1 : / | ext4 | Capacity: 57.9G | Used: 55.7G (96%)
The NVMe device was detected as approximately 474 GB, but its partition was not being used/mounted.
Filesystem test
With the newer kernel, I ran:
fsck -n -f /dev/nvme0n1p1
Result:
fsck.ext2: Input/output error while trying to open /dev/nvme0n1p1
Since the NVMe had worked previously and the problem started after the kernel update, I avoided formatting or repairing the filesystem before investigating the kernel.
Problematic kernel
The system was running:
linux-image-current-rockchip64 26.08.0-trunk-dietpi3
uname -r:
6.18.45-current-rockchip64
Downgrade
The previous version available was 26.08.0-trunk-dietpi2.
I downloaded it with:
apt download linux-image-current-rockchip64=26.08.0-trunk-dietpi2
Then installed it with:
dpkg -i linux-image-current-rockchip64_26.08.0-trunk-dietpi2_arm64.deb
The package downgraded 26.08.0-trunk-dietpi3 to 26.08.0-trunk-dietpi2 and installed kernel 6.18.37-current-rockchip64.
Result after reboot
After rebooting:
uname -r
6.18.37-current-rockchip64
And:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
NAME SIZE FSTYPE MOUNTPOINTS
mmcblk1 58.9G
└─mmcblk1p1 58.9G ext4 /
nvme0n1 476.9G
└─nvme0n1p1 474G ext4 /media/SSD
The NVMe started working normally again and was mounted at /media/SSD.
Conclusion
The downgrade isolated the issue. The same hardware and SSD that exhibited the problem with 6.18.45-current-rockchip64 immediately worked again with 6.18.37-current-rockchip64.
This provides strong evidence of a regression in kernel 6.18.45-current-rockchip64 / the dietpi3 package related to NVMe operation on the Orange Pi 5B.
There was no need to format the SSD or repair the filesystem.
Temporary kernel hold
To prevent an automatic update from reinstalling the problematic kernel, I placed the kernel package on hold:
apt-mark hold linux-image-current-rockchip64
Confirmation:
apt-mark showhold
linux-image-current-rockchip64
I also tested:
apt upgrade --dry-run
Result:
Not upgrading:
linux-image-current-rockchip64
Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 1
For now, the system remains on kernel 6.18.37-current-rockchip64.
Question for the community
Has anyone running Orange Pi 5B + DietPi + NVMe been able to reproduce this issue with 6.18.45-current-rockchip64?
Is there a known bug or regression in this kernel version related to the NVMe driver/controller on the Orange Pi 5B?
For now, I will keep kernel 6.18.37-current-rockchip64 installed until a fixed version is available.