Rpi4 SSD boot (PiOS e Hassio)

Motivação
Com as informações de que os SD card´s podem avariar de um momento para o outro, resolvi testar o boot do Rpi4 por SSD (valido só para rpi4).

Depois de ler algumas coisas, deixo aqui um resumo da minha experiencia, ainda incompleta, pois não consegui tirar conclusões da falha de alguns boot´s (ver mais à frente).

1º Verificar se rpi está pronto para USB/SSD boot

  • flashar o PiOS 32bits num SD com programa Raspberry Pi Imager e arrancar o Rpi
  • Verificar a versão de booloader com cli (linha comandos), introduzindo
sudo rpi-eeprom-update 

ou

vcgencmd bootloader_version
  • Se o resultado for “CURRENT: … 03 Set 2020 …” , (ou data mais recente) o Rpi está pronto para SSD boot(testado).
  • Se for este " CURRENT: … xx Jun 2020 …" , o Rpi tb deve estar pronto para SSD boot (por algumas experiencias de utilizadores que li).
    image

    Todas as versoes de datas anteriores, julgo que não estejam preparadas para SSD boot

Se não estiver preparado ou quiserem actualizar o firmware, passar ao 2º passo

2º Actualizar o firmwar do rpi4

  • Na net encontramos varios comandos possiveis, usei esta sequencia e funcionou
sudo apt update
sudo apt full-upgrade
reboot
  • Verificar novamente a versão do bootloader, pois desconfio que apos os comandos anteriores já terá ficado actualizado, se confirmarem que está , o rpi está pronto para SSD boot.
sudo rpi-eeprom-update

Se não estiver , continuar …

  • Confirmar se o ficheio “rpi-eeprom-update” contem a opção "FIRMWARE_RELEASE_STATUS= “stable” " com o comando.
sudo nano /etc/default/rpi-eeprom-update
  • Caso não esteja “stable” editar o ficheiro e sair com ‘^X’ , confirmando depois que querem gravar ‘Y’ e ‘Enter’
  • A seguir, instalar o update
sudo rpi-eeprom-update -d -a
reboot
  • Apos arranque do rpi verificar novamente a versão do bootloader
vcgencmd bootloader_version
  • Verificar a configuração do bootloader
vcgencmd bootloader_config

Procurar por BOOT_ORDER=0xf41, se aparecer assim indica que a ordem de boot será:
1ºUSB/SSD (4)
2ºSD (1)
O “f” tem a haver com qualquer coisas de loop boot
image

Já temos o Rpi4 pronto para boot pelo SSD.

3º Testes:

A- PiOs 32 bit Boot pelo USB com Pen Sandisk Extreme USB3.0 16Gb

  • flashar o PiOS 32bits na pen com programa Raspberry Pi Imager e arrancar o Rpi ( não esquecer tirar o SD)
    Resultado, exito no arranque quer na porta USB2.0 quer na USB3.0

B-PiOs 32 bit Boot pelo USB com SSD Kingston A400 120Gb caixa com chip Jmicron567

  • flashar o PiOS 32bits no SSD com programa Raspberry Pi Imager e arrancar o Rpi ( não esquecer tirar o SD)
    Resultado exito no arranque na porta USB2.0, na USB3.0 não arranca ou fica desmasiado tempo para arrancar
    Há alguns relatos de que pode ter a haver com o chip do adaptador da caixa SSD/USB, para verifiar o tipo de chip, podem usar o comando
lsusb

C-Hassos 4.13, 4.13 64bit, 5.2
testes flashando com Raspberry Pi Imager e tb com balenaEtcher, na PEN SanDisk e no SSD não consegui arrranque
O processo de flashar e arrancar leva muto tempo , com o SSD nem vou testar :slight_smile:

#############################################################################
actualização testes
#############################################################################
**D-Hassos 5.2 64bits , na PEN SanDisk **
Arrancou na porta USB2.0 e ainda não testei mais nada
PS: Acabei de arrancar na porta 3.0, tb arrancou . Tb não sei se tenho mais paciencia para testar com o SSD. Provavlmente com outra caixa e outro chip daria …

D-Hassos 5.2 64bits , no SSD (já funciona na porta 3.0)

  • Arrancou na porta 2.0 , falhou na 3.0 , definitivamente problemas com o chip do adaptador
  • Solução aplicar “quirks” , depois de aplicar , já arrnaca na porta 3.0

#####################
Aplicação de quirks:
#####################
Arrancar o rpi com SD card com PiOS, ligar o SSD na porta 2.0, na cli executar o comando para obter ID do adaptador

lsusb

Aparece algo do genero , procurar e apontar o ID do adaptador


Ligar o SSD num PC , editar o ficheiro ‘cmdline.txt’ que está na raiz do SSD.
O ficheiro já tem conteudo por ex" dwc_otg.lpm_enavle=0 console=tty" vamos adicionar logo no incio "usb-storage.quirks=XXXX:XXXX:u " onde XXXX:XXXX é o ID do adapatador
ficando assim tudo na mesma linha
“usb-storage.quirks=XXXX:XXXX:u dwc_otg.lpm_enavle=0 console=tty”.

Ligar o SSD ao rpi sem SD e temos o HassSO a arrancar pelo USB3.0/SSD no rpi4.
A performance com quirks não será a mesma , mas ao menos funciona.

#############################################################################
actualização 2020/11/08 testes
#############################################################################
Comprei um adaptador iitrust USB 3.0
https://www.amazon.es/gp/product/B073QG493V/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

Com este adaptador consegui arranque na porta USB3.0 sem necessidade dos “quirks” de:

  • PiOS 32
  • Hassio 5.4 64bit

#############################################################################
Fontes usadas , para registo / consulta :
#############################################################################

https://www.jeffgeerling.com/blog/2020/im-booting-my-raspberry-pi-4-usb-ssd

EDITED: 2020-10-17 Fontes:
(fala da questão do boot por USB3.0)

(ultimas releases à data (2021/01) temos hassos_rpi4-64-5.10.img.gz)

3 Likes

Tenho o meu HA a bombar apartir de um SSD Scandisk 240 Plus, mas também consegui num GoodRam CX300 de 120. Fiz através da atualização do bootloader de 3Set, o mesmo do post e depois com o Raspberry OS instalado no SD card e a correr num PI4, fiz copia para o SSD. Alterei a prioridade do boot para USB e voilá.
No meu caso achei que o booting time era substancialmente superior quando comparado com o SD card, por isso tentei noutro SSD. O resultado foi o mesmo. Como isso não afeta o reboot do server do HA, não chateia, só se houver alguma quebra de energia. Agora o acesso aos ficheiros é brilhante e nota-se quando tens que fazer o reboot ao HA para assumir alguma alteração. Aconselho vivamente para quem tem o HA a rolar no PI.

@Jcorreia
Tive problemas em alguns testes de boot, mas nunca copiei o hassio do cartão para SSD, instalei sempre a partir de imagem original com balenaEtcher ou Raspberry Pi Imager.
Estas a arrancar na porta USB3.0 ?
Que versão de Hassio estas a usar 4.13, 5.2, 32bit, 64bit ?
Que chip e que caixa para o SSD usas?

Como instalei o SO completo no PI em vês do Lite, ele tem um aplicativo de copia integral. Numa fase inicial, também tentei copiar o sd card através do balena, mas nunca consegui fazer arrancar da USB.
Sim coloquei na porta USB3.0.
Eu instalei a versão supervisor em cima do raspberry SO 32bits. Tive de instalar os pacotes do docker e depois o supervisor. Tenho outra instalação do hassio em VM no meu laptop que serviu de teste na primeira abordagem ao HA. Agora já está em produção no PI4 4GB. Vou juntando dispositivos conforme vou evoluindo. Estou nisto à cerca de 3 meses e ainda me falta muito para dominar ou sentir-me confortável com a ferramenta, mas estou a adorar o potencial disto.

@Jcorreia
Então com o balena, nunca instalaste o hassio directamente no SSD a partir da imagem que é disponibilizada para rpi4 em:


Pegaste na imagem do SO 32bit disponibilizada no site da raspeberry e com o balena enviaste para SSD? desta forma arrancou no USB3.0?

Há muitos relatos de malta a queixar-se de problemas de boot e velocidade do hassio no USB3.0, indicam o adaptador USB/SSD como possivel causa.
No meu caso só consegui arrancar no USB3 com Hassos 5.2 64bits e após aplicação de “quirks”.
Para já e até arranjar outro adptador para testar, mantenho o HA no SD.

Claro que tentei, mas não resultou. Ainda deixei o SSD a “partir pedra” toda a noite a pensar que seria questões do arranque inicial do HASSIO, mas nada. A unica forma foi mesmo como disse, montar o OS no SD card e depois copiar para o SSD. Depois de arrancar do SSD, instalei o HA supervisor em cima. Também vi muitos posts a relatar problemas com o cabo e não me custa a admitir que venha dai o problema. O meu em particular identificava o cabo e não a drive ScanDisk quando fiz a cópia. Como tem funcionado na perfeição não tenho tocado, talvez um dia destes tente com outro cabo, agora o meu interesse é integrar tudo primeiro.
Por acaso ontem tive um blackout durante a noite, talvez por causa do temporal e a máquina arrancou na perfeição quando a energia voltou.

Há novidades relativamente ao boot do Hass.io em SSD num Pi 4? Hoje experimentei fazer a cópia pelo balenaEtcher do microSD para o SSD e ele até arrancou e tinha acesso ao HA, mas dava-me erros nas bases de dados, nomeadamente dos Shelly. Presumo que por diferenças nos tamanhos das partições?

Depois experimentei instalar diretamente a última imagem “hassos_rpi4-4.15.img” no SSD mas não faz boot, bloqueia no arranque com ecrã preto.

Eu tenho o meu pi4 a correr hassos 5.2 numa pen usb faz algumas semanas, e sem problemas até a data. Próximo passo vai ser migrar para um ssd.

Tenho novidades! Há sempre males que veem por bem! Lá diz o velho ditado! Tive um crash no fim de semana com o PI4 + SSD. Não sei o que se passou mas não conseguia aceder ao HA e claro que automatizações, nickles. Andei às voltas e decidi fazer uma instalação limpa, como tinha os snapshots na nuvem não haveria problema.
Depois de muita luta e concretamente para o que nos interessa aqui no tópico, deixei de ter problema no arranque com SSD de demorar uma eternidade até vir acima. O que fiz? Li nos fóruns em inglês do HA comunity, que as novas imagens do SO já estariam adaptadas ao arranque por USB. O bootloader já era o mais atual, portanto não mexi nada. Copiei a imagem mais atual 31/10 (buster-lite armhf-nightly) para o SSD com o Balena. Depois dei arranque no PI e ele começou quase imediatamente a instalar. Fiz update e upgrade e voilá. Arranque super rápido quando comparado com o que tinha no SSD anteriormente ao crash. Depois foi só instalar o HA à la mano (Supervisor). No arranque inicial fiz o restore do snapshot e eis que a minha casa voltou à vida. Fiz vários restarts para testar e não há duvida está muito mais rápido. Anteriormente, tinha vezes que demorava mais de 10 minutos para o SO estar operacional. Quanto ao servidor do HA não há grande diferença porque ele não saia do SO e esse problema não se colocava, era apenas quando tinha desligar o PI.

1 Like

Acho que ele não está bloqueado, mas que está numa transferência de dados muito lenta.
reparaste no led verde do Pi? ele está a trabalhar, mas com muitas paragens prolongadas.
Se tiveres paciência deixa-o a trabalhar uma noite para ver se confirma a minha teoria / experiencia. De qualquer modo já resolvi esse problema. Vê o post que coloquei em baixo.

Podes fornecer o link da imagem que utilizaste?

Correr através de uma pen usb é melhor do que através de um microSD?

Não, avariam com a mesma facilidade pois usam a mesma tecnologia, a única diferença é que uma liga a uma ficha USB e a outra numa slot SD ou microSD.

ou aqui: http://unofficialpi.org/Distros/OctoPi/nightly/

1 Like

O que é que o OctoPi tem a ver com instalar o HA?

Pois, de facto consegui fazer boot mas cheguei ao OctoPi e não percebi qual seria o objetivo.

Seja como for, entretanto estive a ler em mais fóruns e finalmente consegui correr o HA a partir do SSD na minha porta USB3.0 num Pi 4 4Gb com esta imagem:

https://github.com/home-assistant/operating-system/releases/download/5.3/hassos_rpi4-64-5.3.img.gz

Com uma caixa USB 2.0, consigo fazer boot e ter o HA totalmente carregado em 110 segundos!

Neste post, leste os testes feitos?
As conclusões no momento são:

  • adaptador USB/SSD pode ter influencia no exito do boot pela porta USB3.0 , comprei outro adaptdor e já consigo boot na USB3.0
  • PiOS arranca , … ? será que dá para instalar o HA manulmente “em cima” ?
  • HassOS versões stable (4.xx) não arrancaram
  • HassOS beta/pre-release (5.xx) arrancam , se fores procurar já há a ver 5.5

OctoPi a ideia seria instalar o HA por cima? será que dá?
PS: HassOS beta/pre-release (5.xx) arrancou só com as versões 64bit

Vou testar a versão 5.5.

Eu instalei o HA em cima do PiOS. Supervised method.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install network-manager apparmor-utils git -y
Créditos do Andrea Spiess
git clone https://github.com/SensorsIot/IOTstack.git ~/IOTstack
cd ~/IOTstack && bash ./menu.sh

INSTALAR DOCKER e Reboot com opção do Pi que usas (3/4?). Estamos a comentar Pi certo? Existe também opções para odroid, orange e qemu

Depois do Pi fazer reboot:

Voltar a:
cd ~/IOTstack && bash ./menu.sh
Seleccionar HA. O resto é igual - os tais 20min.
Créditos e Keryl Peyanski.
NOTA: sem suporte da equipa HA, mas estão lá os addons todos e os que queiras introduzir.

Relativamente ao OctoPi, pois! considerando a versão nigthly a mais atualizada e já com os drives adaptados ao boot considero que permite. Assumi, não tentei! Será uma das próximas “brincadeiras”

Grato pela info, fica como registo para quem queira ir por essa via, como vi muitos comandos linux…
Dado à facilidade de instalação (basta flashar para o SSD e aguardar os bons minutos habituais para instalação) vou manter-me com a solução provisória HassOS beta/pre-release (5.5) que arrancou só com a versão 64bit no com rpi4 (4Gb) e aguardar que saia a ver. stable com o boot a funcionar.


Copyright © 2017-2021. Todos os direitos reservados
CPHA.pt - info@cpha.pt


FAQ | Termos de Serviço/Regras | Política de Privacidade