Rpi-imager: opções avançadas não funcionam no windows 10

Que imagem você estava escrevendo?

E você realmente verificou no Pi o processo sshd não estava em execução?
(Só não conseguir se conectar pode ter outros motivos).

Se, em vez de colocar o cartão SD no Pi, você o colocasse de volta no computador imediatamente após a gravação, ele criou um arquivo chamado firstrun.sh na partição FAT?

E se não, há alguma diferença dependendo se você marcar a caixa "ejetar mídia quando terminar"?

Obrigado pela resposta!

A imagem é a data de lançamento original do Rasberry Pi OS (32-BIT) 2021-01-11
Eu verifiquei o próprio Pi para o ssh. Mas não é apenas a função ssh enable que não está funcionando. Nada no menu de opções está funcionando. Tentei as outras opções também. Tentei também diferentes SD-Cards só para ter certeza ;)

Acabei de verificar e usei outro cartão SD, fiz tudo exatamente como antes e não criou um arquivo chamado firstrun.sh.
a caixa de mídia de ejeção foi desmarcada.

OK. Eu olho para este problema um pouco mais e parece que o imager tem um problema com grandes cartões SD e drives USB.

Eu tentei um cartão SD de 16 GB e com esse gerador de imagens de cartão produzi o arquivo firstrun.sh desejado. Os primeiros cartões SD que eu estava usando eram 32 e 128 Gb. em seguida, tentei uma unidade USB externa de 250 Gb, mas sem sucesso. Nenhum arquivo firstrun.sh.
Então o problema é o tamanho do cartão SD, talvez?

ejetar a caixa de mídia foi desmarcada

Verificar não faz diferença?

Sua unidade mantém a mesma letra de unidade antes e depois da geração de imagens?

ejetar a caixa de mídia marcar ou desmarcar não faz diferença Minha letra de unidade permanece a mesma.

Por enquanto não é grande coisa porque eu não escrevo SO para cartões SD diariamente. Mas ei, definir essas opções torna o processo de instalação do sistema operacional mais útil para mim, porque ativar o ssh por padrão significa que você pode instalar o sistema operacional sem a necessidade de conectar uma tela ao RPI. Você pode configurar um RPI completamente por conexão remota via ssh

Os primeiros cartões SD que eu estava usando eram 32 e 128 Gb. em seguida, tentei uma unidade USB externa de 250 Gb, mas sem sucesso. Nenhum arquivo firstrun.sh.
Então o problema é o tamanho do cartão SD, talvez?

Ele foi testado em um cartão SD Samsung de 64 GB e Toshiba de 32 GB, então o tamanho em si não deve ser um problema.

As unidades USB mais recentes podem ser um problema se falarem o protocolo UASP em vez do protocolo de armazenamento em massa USB padrão.
Eu tenho um SSD Samsung T7, que o Windows não trata como armazenamento removível, mas como unidade interna e, portanto, não atribui uma letra de unidade automaticamente após a criação de imagens. Em vez disso, você precisa acessar o gerenciamento de disco do Windows e atribuir uma letra de unidade manualmente para que ele veja os arquivos na partição FAT.
Ao usar essa unidade, o Imager obviamente não pode corrigir os arquivos automaticamente, mas exibe uma mensagem de erro clara nesse caso:

O que é diferente do seu caso das alterações que gravamos no disco sendo perdidas.

Eu tenho problemas semelhantes. Estou recebendo um erro "não é possível escrever firstrun.sh". Eu incluiria uma captura de tela, mas++X entra em conflito com o Snagit 2021, então tive que desativá-lo. ;)

O erro ocorreu com um cartão SD de 32 GB, mas não com um pendrive de 16 GB.

Eu tenho problemas semelhantes. Estou recebendo um erro "não é possível escrever firstrun.sh".

Isso significa que o Windows indicou que a partição FAT recebeu uma letra de unidade (caso contrário, você obtém "O sistema operacional não montou a partição FAT32"), mas a abertura do arquivo para gravação ainda falhou.
Talvez haja um atraso no Windows atribuindo uma letra de unidade e quando o sistema de arquivos terminou de montar.
Se for esse o caso, talvez seja necessário tentar novamente várias vezes.

Depois de receber o erro, você consegue ver os arquivos na partição FAT no explorer sem precisar reconectar o cartão ou fazer algo especial?

Eu posso ver a partição FAT32, mas é claro que nenhum arquivo firstrun.sh. Na minha máquina é E: pois tenho 2 partições no meu HDD (não pergunte). Mas também é E: para o pendrive.

Eu posso ver a partição FAT32, mas é claro que nenhum arquivo firstrun.sh.

OK.
Você pode tentar se este funciona melhor?

imager-1.7beta.zip

Aguarda até 3 segundos verificando se o config.txt existe na letra da unidade antes de continuar a gravar as alterações.

Funciona como esperado. Testado com cartão SD de 32 GB desde a criação até o ciclo de inicialização no Pi 4.

Obrigado.

Funciona como esperado.

Bom de se ouvir.

@TeeSee64 você também pode experimentar o beta?
(Não faço ideia se isso faz alguma coisa para o seu problema, pois você tem sintomas diferentes).

@maxnet
Sim! Posso confirmar que o problema foi resolvido com a versão 1.7beta. Ele agora grava o arquivo firstrun.sh e todas as opções estão funcionando. Funciona com cartão SD de 128 Gb e uma unidade USB de 250 Gb

Obrigado !!

Oi @maxnet , eu tive o mesmo problema como @CharlesGodwin. Também tentei o 1.7beta, mas infelizmente não funciona para mim. Apenas a mensagem de erro foi alterada devido às suas alterações. Ele agora exibe "Não foi possível personalizar. O arquivo 'I:\/config.txt' não existe.".
O problema pode ser que a partição FAT32 esteja montada em "J:\" em vez de "I:\".
Desculpe, mas no momento não posso fazer nenhuma análise adicional sobre por que ele está montado em "J:\" ou por que o Imager pensa que está montado em "I:\", mas pelo menos eu queria compartilhar isso com você .

O problema pode ser que a partição FAT32 esteja montada em "J:\" em vez de "I:\".

Hmm, acho que tivemos relatórios sobre letras de unidade não sendo liberadas e uma nova letra de unidade sendo atribuída à unidade antes.
Curta: https://github.com/raspberrypi/rpi-imager/issues/31
Nunca conseguiu reproduzir tais problemas embora. Portanto, não faço ideia do que está causando isso.
Talvez algo segurando um bloqueio na unidade (algum serviço do sistema ou antivírus?)

Ou o cartão nunca esteve disponível em I: antes?
Qual letra de unidade foi mostrada quando você selecionou a unidade no Imager?

O Imager assume que o primeiro volume que o Windows nos diz que está associado à unidade é a partição FAT que estamos procurando.
Não tenho certeza se existe um mecanismo melhor, como pesquisar todos os volumes associados à unidade para config.txt.

Se você iniciar o "diskpart" em um prompt de comando e digitar "list volumes", ele mostrará I: e J: lá?
Também pode tentar selecioná-los com "selecionar volume [número do volume]" e ver se "volume de detalhes" (e "partição de detalhes" "disco de detalhes") imprime algo fora do comum.

Talvez algo segurando um bloqueio na unidade (algum serviço do sistema ou antivírus?)

Não pense assim.

Qual letra de unidade foi mostrada quando você selecionou a unidade no Imager?

O cartão, que já foi fotografado, exibe "Montado como I:\,J:\"(traduzido, usando a versão alemã).
Também tentei com um cartão não utilizado. Ele exibe "Montado como J:\" (I:\ está faltando completo, também no explorer. Não me pergunte por que ...)

Se você iniciar o "diskpart" em um prompt de comando e digitar "list volumes", ele mostrará I: e J: lá?

Não, só mostra J:\ lá. Mas no explorer mostra ambos, I:\ e J:\.

O Imager assume que o primeiro volume que o Windows nos diz que está associado à unidade é a partição FAT que estamos procurando.

Esse parece ser o problema.

@maxnet Só uma ideia...
Talvez o indexador de pesquisa do Windows? Às vezes, quando tento remover com segurança um cartão SD do meu computador, é impossível porque o indexador de pesquisa do windwos está ocupado nesse cartão. após alguns momentos, o indexador está pronto e a remoção segura é possível.

Talvez o indexador de pesquisa do Windows?

Nós terceirizamos a limpeza da tabela de partições no início do Imaging para o utilitário diskpart da Microsoft, na esperança de que ele saiba como fazer com que todos os serviços da Microsoft parem de usar a unidade e liberem todas as letras de bloqueio/unidade corretamente.
Além dos serviços do sistema, também existem programas de terceiros que gostam de reivindicar e manter aberto um arquivo dentro de "\System Volume Information" em cada unidade.
Por exemplo, eu lembro que o Symantec Endpoint Security é conhecido por manter a contabilidade sobre quais arquivos já foram verificados e as assinaturas desses arquivos lá.
É por isso que mencionei antivírus.

@CRGer

Você pode tentar se este funciona melhor?

imager-20210322.zip

Deve pesquisar todos os pontos de montagem associados à unidade para config.txt em vez de apenas o primeiro.

@maxnet Mesmo que a letra da unidade montada automaticamente mude antes e depois de gravar a imagem, presumo que o número do disco físico não mude? Então, talvez você possa usar algumas das coisas do WMI para correlacionar letras de unidade antes e depois de piscar a imagem? :shrug: Alternativamente, acho que você poderia usar o tamanho bruto da unidade, pois provavelmente é improvável que o usuário tenha duas unidades com o mesmo tamanho bruto conectado? (e isso também não mudará antes/depois de piscar)

@maxnet Mesmo que a letra da unidade montada automaticamente mude antes e depois de gravar a imagem, assumo o número do disco físico
não vai mudar? Então, talvez você possa usar algumas das coisas do WMI para correlacionar letras de unidade antes e depois de piscar a imagem?

Já buscamos a lista de volumes pertencentes a esse número de unidade física após a geração de imagens.

No entanto, no caso do CRGer, dois volumes são retornados (I: e J:) como pertencentes a essa unidade física .
Nosso código anteriormente assumiu que o primeiro é a partição FAT, mas no caso dele o segundo é o único volume válido.
O novo código deve verificar os dois volumes retornados para config.txt

Pode acabar em um jogo de wack a mole. talvez codifique em uma caixa de diálogo "Qual é a unidade, por favor" quando tudo mais falhar.

Ahh, entendi errado, desculpe o barulho! :piscadela:

Você pode tentar se este funciona melhor?

Testei e funcionou como esperado. "firstrun.sh" foi criado em minha partição FAT com todas as configurações selecionadas. Bom trabalho @maxnet , obrigado!

Estou vendo esse problema no Ubuntu tentando escrever o Raspberry PI OS Lite, parece que não espera o tempo suficiente para a partição de inicialização ser montada, antes de tentar gravar o firstrun.sh na partição. Existe uma compilação com um atraso maior para o Ubuntu?

Além disso, em vez de uma espera arbitrária de 3 segundos, que tal apenas testar se você pode acessar a partição em um loop por, digamos, 60 segundos antes de errar ou algo assim?

Estou vendo esse problema no Ubuntu tentando escrever o Raspberry PI OS Lite, parece que não espera o suficiente para a inicialização
partição para montar, antes de tentar gravar o firstrun.sh na partição. Existe uma compilação com um atraso maior para o Ubuntu?

Este funciona melhor?

rpi-imager-ubuntu-20210324.zip

Além disso, em vez de uma espera arbitrária de 3 segundos, que tal apenas testar se você pode acessar a partição em um loop por, digamos, 60
segundos antes de errar ou algo assim?

Para referência: leva 0,008 segundo antes que a partição FAT seja montada no meu computador Ubuntu.

Estou vendo esse problema no Ubuntu tentando escrever o Raspberry PI OS Lite, parece que não espera o suficiente para a inicialização
partição para montar, antes de tentar gravar o firstrun.sh na partição. Existe uma compilação com um atraso maior para o Ubuntu?

BTW, você usou o .deb do site Raspberry Pi anteriormente ou o snap fornecido pela canonical?

Como outra pessoa está mencionando, o problema ocorre apenas no snap: https://www.raspberrypi.org/forums/viewtopic.php?f=63&p=1842486

por que o Ubuntu rpi-imager está sendo discutido em um problema intitulado opções avançadas não funcionando no Windows 10

ninguém vai encontrá-lo

por que o Ubuntu rpi-imager está sendo discutido em um problema intitulado opções avançadas não funcionando no Windows 10

Isso é mais um problema com o título, do que são problemas diferentes.

O problema nos dois casos é o mesmo.
O sistema operacional informa que uma montagem foi concluída, quando ainda não está pronta.

Isso NÃO deve acontecer em sistemas Linux normais.
Mas pode acontecer no pacote de snap de terceiros que não criamos.
Ah, bem, como um efeito colateral de solucionar esse problema no Windows, ele também pode solucionar o problema do snap ...

Eu acho que o problema _poderia_ ser renomeado para "opções avançadas não gravando configurações no cartão SD", mas não parece valer a pena se @maxnet já tiver uma correção potencial em mãos? :slightly_smiling_face:

Acho que o problema pode ser renomeado para "opções avançadas que não gravam configurações no cartão SD", mas não parece valer a pena se @maxnet
já tem uma possível correção em mãos?

Suspeito que o problema já foi corrigido.
Mas deixando isso aberto por enquanto, para evitar que outros usando 1.6 (em vez do git mais recente) abram um novo problema.

Corrigido em 1.6.1