Por que o armazenamento USB removível não aparece no Iniciador ou nos Arquivos como um pen drive regulat?

Question

Usando o 17.04 no modo "Experimentar antes de instalar"

Um USB 'normal', como em formatado com uma tabela de partição MBR, pelo Windows aparece com um ícone USB no Launcher, e é ejetável de uma barra lateral de Arquivos.

Mas a formatação do mesmo dispositivo com uma tabela de partição GPT mostra um ícone de "disco", como os discos internos, e não é ejetável de Arquivos. Em nunca aparece na barra lateral, e você não pode ejetá-lo de "outros lugares". Uma caixa de diálogo modal de erro é exibida com "Não foi possível desmontar o volume" "Operação não permitida".

Mas sudo umount funciona bem.

Meu palpite é que o Ubuntu está tratando-o como uma unidade de disco interna.

Em ambos os casos, as unidades são montadas por meio de entradas em /etc/fstab em vez de udisks2 e as entradas são as mesmas, exceto pelo nome do dispositivo

Então, por que o stick formatado com GPT está sendo tratado dessa maneira? Eu gostaria que ele aparecesse na barra lateral de Arquivos como o MBR formatado.

Formatado via

parted -s --align optimal /dev/sdc \
 mktable gpt \
 mkpart primary fat32 0% 100% \

mkfs.vfat -F32 /dev/sdc1

# mount and copy files to disk here

parted -s /dev/sdc set 1 boot on

O objetivo é ser capaz de montar discos, incluindo discos de inicialização GPT e MBR feitos por Rufus (no Windows). O GPT que inspirou a questão deveria ser um clone do método Rufus, feito apenas no Linux. / p>

[adicionado]

Olhando para um Rufus USB real, surge um ícone diferente dos outros. Desta vez, seu ícone é uma caixa (em vez de um graveto) impressa com um símbolo de árvore USB. Ele mostra na barra lateral. É ejetável.

Olhando para a partição GPT do Rufus, as duas diferenças proeminentes parecem ser um nome de "Microsoft Basic Data" e um sinalizador msftdata na partição. então é aí que vou tentar olhar em seguida

    

Answer 1

Algumas informações básicas podem ajudar. Nos discos GPT, os "flags" nas ferramentas baseadas na libpart, incluindo GParted e parted , são uma mistura de duas coisas: atributos GPT, qualquer número dos quais pode ser aplicado simultaneamente a qualquer partição; e códigos de tipo GPT (que são valores GUID de 16 bytes internamente), dos quais cada partição tem precisamente um. Isso pode criar muita confusão, já que uma partição pode ter vários sinalizadores, mas, às vezes, aplicar um sinalizador automaticamente remove outro, já que esses dois sinalizadores são códigos de tipo. Além disso, a libparted não exibe explicitamente alguns códigos de tipo; esses são apenas considerados implícitos para o tipo de sistema de arquivos. (Isso vale também para o código do tipo Linux Filesystem.) Além disso, o código de tipo para identificar a partição de sistema EFI (ESP) tem dois sinalizadores associados a ele nas versões recentes da libparted: boot e esp . Costumava ser apenas boot , mas isso tinha um significado totalmente diferente nos discos MBR. (Eu suspeito que a intenção é depreciar o sinalizador boot nos discos GPT para minimizar a confusão neste ponto a longo prazo, mas não tenho certeza disso.)

Assim, alguns do que você está vendo está relacionado aos códigos de tipo. Há três deles que parecem relevantes para sua pergunta:

• Linux Filesystem - Este código de tipo (0FC63DAF-8483-4772-8E79-3D69D8477DE4) identifica sistemas de arquivos Linux (ext2 / 3 / 4fs, Btrfs, etc.). Ele não é sinalizado explicitamente na libparted, mas em gdisk tem um código de tipo de 8300.
• Microsoft Basic Data - Este código de tipo (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) identifica partições de dados FAT, exFAT ou NTFS, incluindo partições de inicialização do Windows. No passado, o Linux "pegava carona" nesse código de tipo, o que criava problemas. É identificado em libparted pelo sinalizador "msftdata" ou em gdisk por um código de tipo de 0700.
• Partição do sistema EFI (ESP) - Este código de tipo (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) identifica uma partição que é usada pelos computadores baseados em EFI para inicializar. Deve manter um sistema de arquivos FAT32. Como mencionado acima, ele é identificado na libparted pelos flags "boot" e (em novas versões) "esp", e em gdisk pelo código do tipo EF00.

Note que as ferramentas baseadas na libparted são terríveis se você realmente precisa saber o tipo de código de uma partição, já que apenas um punhado de códigos de tipo é relatado. Se você quiser saber o código de tipo, use gdisk . Mesmo sua exibição de resumo é um pouco limitada; se não reconhecer um código de tipo GUID, ele será exibido como FFFF. Você pode encontrar o valor GUID completo usando a opção i no menu principal, que exibe informações completas sobre partições. ( gdisk usa um código abreviado do tipo de 2 bytes em vez do GUID completo de 16 bytes em sua interface de usuário para simplificar. A maioria dos códigos de tipo gdisk corresponde a seus equivalentes de MBR, mas multiplicados por 0x100. As partições do sistema de arquivos Linux são 0x83, portanto 8300 em gdisk .)

Acabei de fazer algumas experiências e, para mim, o programa Unity Files manipula as partições do Linux Filesystem e Microsoft Basic Data de forma idêntica - pelo menos, até onde eu testei. Em ambos os casos, a inserção de um disco faz com que apareça no menu, sendo montada automaticamente e sendo ejetável. Os ESPs, no entanto, não apareceram no menu Arquivos e não foram montados automaticamente. Isso é pelo menos um pouco sensato, já que alguns ambientes podem criar ESPs vazios (e em grande parte sem sentido) em discos rígidos e mídias removíveis. (O Disk Utility do OS X cria um ESP sempre que você cria um GPT, por exemplo).

Observe que a maioria das EFIs será inicializada a partir de qualquer partição FAT, mesmo que não esteja marcada como um ESP. Este não é um comportamento garantido, no entanto; é concebível que alguns ESPs sejam mais exigentes quanto a isso. Na verdade, tenho certeza de que isso era verdade para a velha Gigabyte Hybrid EFI, que era horrível de várias maneiras. (Há muito que me livrei do único exemplo deste firmware que possuía, por isso não posso verificar novamente este detalhe.)

Ferramentas como o Rufus, que são projetadas para criar um disco inicializável, podem fazê-lo criando um ESP - mas eu não verifiquei o que o Rufus realmente faz, então eu não sei se o Rufus faz isso, ou se pode fazer coisas diferentes, dependendo das configurações do programa.

O artigo da Wikipedia sobre o GPT pode expandir isso. As seções envolvendo os GUIDs estão em

• link
• link

Answer 2

O problema ocorreu ao tentar definir a partição como inicializável.

Em partições GPT, o sinal boot é sinônimo de esp flag

Um sinalizador esp é mutuamente exclusivo com o sinalizador msftdata .

É o sinalizador msftdata que faz as unidades aparecerem na barra lateral da janela files e serem ejetáveis

Assim, você não pode definir a inicialização em uma partição de disco GPT e colocá-la na barra lateral.

Mas parece que você não precisa de esp set para inicializar em uma máquina UEFI. Então, não configure a inicialização.