Esses dias eu precisei criar um pendrive bootável com Windows e o Ventoy não funcionava de jeito nenhum, mas navegando na internet encontrei este guia que ensina a criar um pendrive bootável com Windows sem utilizar nenhuma dessas ferramentas especiais:
3 curtidas
Essa informação é incorreta! Sempre criei pendrives de boot do Windows desde o Ubuntu 18.04 (independentemente da versão do kernel). N sei de onde o autor tirou q era necessário dividir o arquivo em varias partes ou q isso só funciona por causa do novo driver NTFS. Mas além de dizer q isso é incorreto vou demonstrar como pode ser feito em qualquer Linux.
1 - Formate o pendrive em esquema GPT com uma partição (1GB) Fat32 e o resto em NTFS.
2 - Monte a ISO do Windows e no gerenciador de arquivos copie todas as pastas com exceção da pasta sources para a partição fat32, dps crie uma pasta sources vazia na partição fat32 e pegue o arquivo boot.wim da pasta sources da ISO e cole nela.
3 - Copie toda a pasta sources para a partição ntfs.
Semana passada mesmo criei um pendrive de boot do windows 10 pelo Ubuntu 20.04 para fazer a formatação de uma maquina.
Ps. Sou técnico em informática e realizo muitas formatações de Windows.
Aqui o link de referencia: Creating a Bootable Windows 10 UEFI USB Drive Using Linux
Como pode ver a matéria é de 2019.
Agr a explicação resumida do problema: Ele n tem absolutamente nda haver com o driver ntfs e sim a limitação de fat32 ao trabalhar com arquivos maiores que 4GB. Então o que acontece é q o arquivo install.wim aumentou de tamanho nas novas ISO do Windows n suportando mais partição fat32 por conta da limitação de tamanho individual de arquivo q esse tipo de partição tem.
Informação complementar: Algumas maquinas conseguem dar boot num pendrive em ntfs,e nesses casos basta copiar todo o conteúdo da ISO para uma única partição em NTFS num pendrive. Mas a maioria precisam da partição fat32 para dar o boot, por isso o tutorial funciona pra geral.
1 curtida
Bem, eu descobri esse método aí na semana retrasada, então se já dá pra fazer desde sempre ou não não me interessa. Só fiz esse post pra compartilhar essa dica com outras pessoas que não querem usar o Ventoy por algum motivo e que assim como eu não conheciam esse método.
1 curtida
E sua dica é valida! Só quis corrigir a parte errada da informação.
2 curtidas
beleza então, editei o post aqui 
É bacana que possa ser feito dessa forma. 
Eu ainda não tentei criar pendrives de boot do Windows assim. Mas tentei de várias outras formas e a única solução que sempre funciona comigo é o Ventoy. Ao usá-lo, é importante ter muito cuidado com o momento para remover o pendrive. Ele indica que a cópia da .iso foi concluída enquanto ela ainda está acontecendo, então é bom deixar por um tempo bem maior para ter certeza.
1 curtida
Quando era mais novo e iniciando no linux, dava total preferencia as soluções/ jeito raiz de fazer as coisas no Linux. Com os anos entendi que é bom conhecer o jeito raiz para emergencias, mas a praticidade e simplicidade de um Ventoy ainda é mais vantajoso pra quem usa Linux como sistema pessoal, mas no dia-a-dia de trabalho lida com N versões de windows e linux. Time is Money!!
3 curtidas
O @romulopb sabe explicar isso.
1 curtida
O problema ao meu ver em soluções como ventoy e etc é q demoram quase umas 5x mais do q simplesmente copiar manualmente os arquivos para os locais certos. Acho q por isso até hj nunca quis usar esses softwares para essas finalidades.
1 curtida
muito interessante. gostei.
1 curtida
A minha dica para quem quer saber com mais precisão quando tirar o pendrive, é ficar de olho na memória de paginação suja em /proc/meminfo. Infelizmente muitos programas no Linux voltados para tarefas que podem envolver escrever em dispositivos lentos (pendrives), não implementam backpressure.
1 curtida
Ou simplesmente quando for remover esperar que o sistema avise q pode. kkk
No Mac, Windows e Ubuntu sempre espero e pronto.
Nunca precisei esperar no Mac nem no Windows 10, pois quando a interface avisa, de fato terminou. Isso é um conceito já muito conhecido, tanto que existem primitivos de programação como streams exatamente para isso, a glibc tem os primitivos necessários para implementar, apenas acontece que muitos programas não implementam, provavelmente porque é mais fácil apenas jogar tudo no kernel (e realmente é…).
1 curtida
O que to dizendo é q quando a janela informa que copiou tudo, basta clicar em remover que no Ubuntu, Mac e Windows ele avisa quando pode remover com segurança após terminar a copia de fato. Então n há necessidade de monitorar absolutamente nda, a interface do sistema já provê o aviso “Agr vc pode remover seu pendrive que tudo foi copiado de fato”. Pelo menos aqui nas minhas maquinas com Mint, Ubuntu, Mac e Windows SEMPRE há anos que funciona assim.
Se alguém usa alguma interface/Distro exótica em q esse comportamento não acontece aí já acho q é outro problema.
Nem sempre, isso depende do programa, não é especifico de uma DE ou outra, alguns não fazem nem o fdsync do descritor do arquivo (que é quem bloqueia o desmonte, pois o arquivo fica no estado aberto) e dai acontece como alguns descrevem, “que a tarefa não funcionou” porque desmontou antes da transferência terminar.
Acontece que no Mac OS e no Windows 10+ não só bloqueia como hoje em dia também informa uma previsão sã de transferência do arquivo. Isso é possível no linux também via Streams bufferizados, mas muitos não implementam.
Pelo menos, que eu sei, o dolphin e o gnome files ao menos bloqueiam o descritor ao transferir, então nesses casos não tem perigo de perder os dados apesar de as informações de progresso não fazerem sentido, mas alguns outros programas não fazem isso.
2 curtidas
Sinto que as vezes n sou muito claro rs. Eu uso Ubuntu e Windows há mais de 6 anos, copiando muitos arquivos pra HDs externos e pendrive nos mais diversos system files. Nunca tive arquivos corrompidos ou problemas de copias entre os sistemas e mídias externas. Sempre que copio algo pra um HD Externo ou pendrive, clico na opção remover e aguardo o sistema informar que pode ser removido. N entendi o que vc falou sobre “Nem sempre, isso depende do programa”. Que programa? O Nautilus (gerenciador de arquivos)? Pois uso ele para manipular os dados nos HD’s e Pendrives.
Tudo bem, eu não estou direcionando aquela dica a você, estou direcionando para as pessoas que tem esse problema ok?
Entendi. O que eu sei é q de fato quando vou por exemplo copiar arquivos de uma ISO do Windows para dentro de um pendrive, mesmo após a barra de transferência do nautilus informar que completou a copia, quando eu peço pra remover o sistema informa que ainda esta transferindo alguns dados e aí dps avisa que terminou. Após isso eu removo o pendrive.
O que eu falei em relação a sua dica é q n há necessidade de monitorar o arquivo q vc citou, pois (a n ser q o usuário esteja usando uma distro bizarra ou mexeu nas configurações padrão) o sistema vai avisar quando puder remover com segurança.
OBS: Citei a ISO do Windows, porq pelo q me lembro so vejo essa demora na hora de remover quando copio arquivos desse tipo. No Geral raramente tenho esse tipo de “problema”.
Eu te expliquei porque você não encontra esse problema ali em cima, infelizmente não tem uma forma mais simples de descrever a implementação de transferência de arquivos em C via glibc.
Simplesmente alguns programas fazem o bloqueio via fdsync (o que pelo menos evita o corrompimento de dados, pois bloqueia o desmonte) do descritor de arquivos, outros não. Nem todas as transferências de dados no mundo Linux se dão via gestor de arquivos, existe uma infinidade de coisas como ventoy, rsync, scp, tar, cp, pv, etc que manipulam descritores de arquivos, cada um implementa isso ao seu modo. Existem dezenas de formas de se usar as chamadas da biblioteca glibc para implementar transferências de arquivos de tudo que é tipo de jeito com todo tipo de resultado, casos especiais, etc e geralmente a maioria dos programas no Linux recorre diretamente a glibc e geralmente implementam o caso mais simples, porque de fato é mais simples.
Alguns esquecem de fazer um fdsync e esperar antes de fechar o descritor, isso não corrompe os dados em si, mas libera o kernel para desmontar a partição mesmo que nem tudo tenha sido escrito.
De qualquer forma escrever dados em arquivos não é uma tarefa trivial, depende do caso (o que está sendo transferido, para onde, etc), pelo menos do ponto de vista da programação em baixo nível. Não é a toa que a glibc tem tantas chamadas diferentes para transferências de arquivos.
3 curtidas