A unidade flash USB formatada como “Linux Live CD” mantém o nome do CD-ROM após a nova partição

3

Eu tenho uma unidade flash USB que eu usei anteriormente como meio de instalação para o Linux Fedora.

O stick ainda tem os arquivos de instalação do "Fedora Live USB". Quando eu o insiro no meu laptop olde, ele aparece como um disco chamado "Fedora-Live-KDE-x86_64-22-3" no KDE. Justo o suficiente.

Então, eu destruo todas as partições usando fdisk , crie uma nova partição, configure um sistema de arquivos ext4 na partição.

Eu insiro o pen drive. Eu aparece como "Fedora-Live-KDE-x86_64-22-3" no KDE golfinho.

UNDEAD FLASH DRIVE TIME!

De onde vem esse nome? Parece que não vem da unidade flash USB, mas factoid (3) abaixo indica que ele realmente faz.

De onde vem esse nome e como posso alterá-lo?

Aqui está alguma pesquisa sobre de onde o nome está vindo, a conclusão é que aparentemente vem dos dados ISO-9660 deixados no disco. Mas como é esse comportamento são pelo Linux?

e2label /dev/sdd1 não mostra nada: o sistema de arquivos não tem rótulo

blkid /dev/sdd1 mostra

/dev/sdd1: UUID="10aab422-4212-45c8-9f99-35e5eb719154" TYPE="ext4" PARTUUID="5c4a815c-01"

▶ O uso da unidade flash em outra máquina também resulta no nome "Fedora-Live-KDE-x86_64-22-3" sendo exibido.

▶ É possível descarregar os "rótulos" (quaisquer que sejam esses) observando o sistema de arquivos em /dev :

ls -l /dev/disk/by-label/

Isso mostra o symlink

Fedora-Live-KDE-x86_64-22-3 -> ../../sdb

Observe que o link simbólico aponta para o dispositivo, não para a partição. Portanto, este não é um rótulo de sistema de arquivos, mas algo como um "rótulo de disco".

▶ A "etiqueta do sistema de arquivos" original obtenível com e2label estando vazia, nós a configuramos e então veremos o que está acontecendo:

# e2label /dev/sdb1 "Scooby Doo"
# ls -l /dev/disk/by-label/
lrwxrwxrwx. 1 root root  9 Feb  4 23:43 Fedora-Live-KDE-x86_64-22-3 -> ../../sdb
lrwxrwxrwx. 1 root root 10 Feb  4 23:43 Scooby\x20Doo -> ../../sdb1

Então agora tanto o disco quanto o sistema de arquivos / partição tem um rótulo. No entanto, após a remoção / reinserção, o golfinho (ou melhor, o Linux) agora se instala no nome "Scooby Doo" do sistema de arquivos. E porque não! Podemos então apagar o rótulo novamente usando e2label /dev/sdb1 "" ... e então o nome está de volta, mas apenas parcialmente: "Fedora-Live-KDE-" (por que parcialmente? Porque é lido de 0x9000 em diante, enquanto o rótulo completo está em 0x8000, veja abaixo)

▶ Também tentou ver o que o parted faz. Parece poderosamente confuso: ele acha que o 8GiB ficar com blocos de 512 bytes é na verdade um stick 32GiB com blocos de 2048 bytes e detecta uma partição Apple, enquanto fdisk está absolutamente feliz em encontrar uma partição Linux 8GiB. Curioser e curioser.

(parted) print
Warning: The driver descriptor says the physical block size is 2048
bytes, but Linux says it is 512 bytes.
Ignore/Cancel? i
Model: Generic USB Flash Disk (scsi)
Disk /dev/sdb: 32.2GB
Sector size (logical/physical): 2048B/512B
Partition Table: mac
Disk Flags:

Number  Start   End     Size    File system  Name   Flags
 1      2048B   10.2kB  8192B                Apple
 2      88.1kB  5278kB  5190kB               EFI
 3      5319kB  26.1MB  20.8MB               EFI

Provavelmente não é TOTALMENTE confuso, porque no bastão encontramos isso:

▶Estranhoadicional:OstickUSBreformatadoparecenãosergravável,maspodeserusadoporumusuárionão-root.Escrevendocomorootfuncionaembora.Masissoéapenasumaobservaçãolateral.

▶Obterumdiskdumpcomoktetamostraastringdonomedodisconaposiçãologoapós0x8000,ouseja,nobloco64(blocoscomtamanhode512bytes):

IssoevidentementederivadaestruturadoLiveCD.

▶ProcurandomaisadiantemostraonomeprovavelmentenoformatoUTF-16logoapós0x9000,comosufixodaversãodescartadoprovavelmenteporqueocampotemtamanhoconstante:

▶HoradePOKEeveroqueacontece.Nósmodificamosastringnamarca0x8000:

Tambémmodificamosastringnamarca0x9000:

Emseguida,escrevaosblocosdevoltaaobastão(porqueestamosmodificandoumarquivoobtidousandodd),sincronize,sincronizeeejete.

Emseguida,insiranovamenteobastão.OLinuxseinstalanessecasonastringem0x9000.

[root@elf~]#ls-l/dev/disk/by-label/total0lrwxrwxrwx.1rootroot10Feb922:09DellUtility->../../sda1lrwxrwxrwx.1rootroot10Feb923:20MOTHRA-Dead-KDE-->../../sdb1lrwxrwxrwx.1rootroot10Feb922:09OS->../../sda2lrwxrwxrwx.1rootroot10Feb922:09RECOVERY->../../sda4

ODolphinmostraoconteúdode/dev/disk/by-label:

Então, sabemos de onde vem a string. Não parece útil poder alterá-lo, pois ele vem da estrutura do CD-ROM, enquanto colocamos um esquema de particionamento padrão no disco USB. Por que o Linux tritura essas duas duas estruturas?

    
por David Tonhofer 04.02.2016 / 21:21

2 respostas

1

É o rótulo do volume. Esse é o sinal -L em mkfs.ext4 ou, penso eu, o -n em mkfs.vfat e assim por diante.

Você pode alterá-lo passando um novo marcador para ele com e2label ou matando-o totalmente com dd .

    
por 04.02.2016 / 22:52
0

No final, a resposta parece ser a seguinte:

  1. O nome vem do restante dos dados do CD-ROM (o que, em retrospecto, é embaraçosamente óbvio)
  2. Você não pode alterá-lo porque não é nem para ser usado nem para estar lá - afinal, você quer usar a unidade flash USB como um disco, não como um CD-ROM. Estes dois têm formatos diferentes. Geralmente não há string utilizável em 0x8000 ou 0x9000.
  3. Por que o nome é usado quando o bastão é inserido não é claro. É preciso dar uma olhada na fonte de qualquer parte do Linux responsável por reconhecer o formato de um dispositivo de bloco.

A lição:

Redefina a unidade flash USB zerando-a antes de configurar um esquema de partição do disco rígido nela. Caso contrário, os resultados serão "indefinidos" e dependerão da heurística usada pelo sistema que lê a unidade flash. Como visto para parted , que detecta um sistema de arquivos mac.

P.S.

Como "zerar a unidade flash USB" em incrementos de 128K (128K devem ter 1 ou mais células de memória flash em tamanho, portanto, qualquer célula de memória flash só será gravada uma vez):

dd if=/dev/zero of=/dev/sdXXX bs=128K 

"zerar a unidade flash USB" é, na verdade e surpreendentemente, repleto de complicações inesperadas. Talvez seja necessário adicionar count=1024 para manter baixos os blocos gravados:

por 10.02.2016 / 02:22