A minha ideia era justamente usar Flatpaks, já que eles são independentes do sistema para serem atualizados.
Então esquece esse SD de 10MB/s vc precisa de algo com mais gravação sequencial.
Quando eu fiz o teste ainda não era usado flatpak e nem snap.
Uma att de 3GB vai levar 5 min com o acesso do SD travado.
@rapoelho e ai, alguma noticia nova dos testes? qualquer noticia nova dos seus testes de OS portátil, posta ai.
A única coisa de novidade é que acabei ferrando o Boot do meu notebook antigo, que está servindo como cobaia para esses testes.
Terei que reinstalar o Windows e o Linux nele. E estou vendo outras distros para testar, e dessa vez com o KDE Plasma, e estou tentando o OpenMandriva.
Tentei instalar ontem, mas a instalação falhou.
E cara, erro os SSDs…
Restaura com o grub repair, ou boot repair, sei la como chama.
Instala o boot repair no seu OS portátil e recupera o boot da instalação interna.
E parece que ele n é instalável, precisa queimar a ISO.
Acho que a UEFI do notebook fez caca. Era para instalar o Boot apenas no SSD portátil, mas acabou instalando no notebook também.
E basicamente tinha instalado o Mint no notebook e no SSD portátil e o Grub do Mint do SSD portátil instalou por cima do Grub do Mint no Notebook.
E o mesmo ocorreu com o Ubuntu Mate que instalei em seguida. O Grub do Ubuntu Mate instalou no SSD Portátil, mas ficou registrado também no notebook.
Provavelmente eu vá reinstalar tudo no notebook antigo para reorganizar esse zona.
Estava usando o Ventoy. Mas acho que foi na hora de retirar o pendrive, que não esperei o tempo para terminar de copiar a ISO para o Pendrive e com isso, corrompeu a ISO.
Mas usei um outro pendrive genérico para colocar o OpenMandriva com o Balena.
Consegui restaurar o Boot! De uma maneira não muito ortodoxa. Instalei o OpenMandriva no SSD portátil, e a instalação falhou justamente quando foi instalar o Grub. O Motivo, não sei.
Aproveitei que o meu notebook antigo registrou o boot do Ubuntu MATE, então bootei por ele, habilitei o OS_PROBER e mandei atualizar o Grub, o que fez reaparecer as entradas do OpenMandriva, do Linux Mint e do Windows. Entrei no Mint pelo Grub do Ubuntu MATE que estava no SSD Portátil, e pelo Mint, reparei o boot dele.
E o Boot do Windows voltou a funcionar.
@rapoelho O OS Probe foi desativado devido a uma vulnerabilidade de segurança grave no grub.
Não sei como acontece o ataque, se quiser pesquisar deve ter explicação na internet, acredito eu que necessita de acesso físico a maquina. Se o backdoor passa por criptografia é perigoso se o note for roubado.
@rapoelho pesquisa ai direitinho, pq como vc vai carregar o SSD, se o backdoor passa pela criptografia vc vai ter um problema se vc perder seu SSD.
@rapoelho Eu abri um link do google para mim ver o que é o motivo na epoca, e esse site dizia isso:
A causa? O recurso OS_prober vem desabilitado por padrão no GRUB 2.06, que é a versão incluída no Ubuntu 22.04. Esta é uma mudança upstream projetada para combater possíveis problemas de segurança com o recurso de detecção de sistema operacional (ele monta partições para verificar outros sistemas operacionais, isso pode ser aproveitado, etc).
Eu não me lembro mais o motivo, já faz muito tempo.
Alguém lembra, se era backdoor?
Usei mais para detectar os outros sistemas e para poder consertar o boot do Mint. E curiosamente, quando dei o update-grub o Mint detectou os outros sistemas de boa, sem precisar configurar o OS_PROBER.
@rapoelho Reddit - Dive into anything
Este link do geddit tem um papo que aparentemente uma vulnerabilidade teórica ainda não sendo explorada, não é um backdoor em si, mas uma coisa teórica.
O os-prober é inerentemente inseguro, pois ele monta todas as partições do seu disco usando o grub-mount para verificar se há outros sistemas operacionais, o que não é uma boa prática como root, pois você pode explorar facilmente bugs no código do sistema de arquivos.
@rapoelho É que nem diz o Linuz Torvalds:
"Honestamente, estou de saco cheio de hardware com bugs e ataques completamente teóricos que nunca se mostraram realmente usados na prática. Então, acho que desta vez vamos pressionar o pessoal do hardware e falar para eles que o maldito problema é *SEU*, e se eles não se dão ao trabalho de dizer sim ou não, apenas aguardamos.
Porque, caramba, vamos colocar a responsabilidade sobre onde está a culpa, e não apenas pegar qualquer "...." aleatório de hardware ruim e dizer "ah, mas *pode* ser um problema"