George Robinson's questions

Ao procurar por GRUB2pacotes disponíveis para o Debian v9.11.0 "Stretch", recebo apenas os betapacotes listados:

root@Debian:~# apt search GRUB2
Sorting... Done
Full Text Search... Done
grub-imageboot/oldstable 0.6 all
  boot iso, harddisk and floppy images with grub2 and syslinux memdisk

grub2/oldstable,now 2.02~beta3-5+deb9u2 amd64 [residual-config]
  GRand Unified Bootloader, version 2 (dummy package)

grub2-common/oldstable 2.02~beta3-5+deb9u2 amd64
  GRand Unified Bootloader (common files for version 2)

grub2-splashimages/oldstable 1.0.1+nmu1 all
  a collection of great GRUB2 splashimages

live-wrapper/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images

live-wrapper-doc/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images (Documentation)

vmdebootstrap/oldstable 1.7-1 amd64
  Bootstrap Debian into a (virtual machine) disk image

Como você pode ver, esta busca retorna apenas pacotes beta . Eu tive que pular etapas para instalar um GRUB2pacote estável, veja: Como atualizar o GRUB v1 para o GRUB v2 sem instalar uma versão Beta?

PERGUNTA: Por que o repositório "Stretch" do Debian contém apenas versões betaGRUB2 do ? Afinal, a versão estável GRUBv2.00 foi lançada 5 anos ANTES do lançamento do Debian "Stretch", veja aqui: ftp.gnu.org/gnu/grub

Isso é um bug no repositório desta distribuição?

Meu Linux Debian v9.11.0 (Stretch) está GRUB1instalado atualmente.

root@Debian:~# grub-install -v
grub-install (GNU GRUB 0.97)

Meu outro Ubuntu Linux GRUB2instalou:

root@Ubuntu:~# grub-install -V
grub-install (GRUB) 2.02+dfsg1-20

Eu quero instalar GRUB2, mas se eu tentar instalar no Debian com apt-get install grub2, uma versão beta do GRUB2é instalada !!!

root@Debian:~# grub-install -V
grub-install (GRUB) 2.02~beta3-5+deb9u2

Eu não quero esta versão beta - quero uma versão estável GRUB2como a que o Ubuntu instalou.

Ao procurar por GRUB2pacotes disponíveis no Debian, recebo apenas os betapacotes listados:

root@Debian:~# apt search GRUB2
Sorting... Done
Full Text Search... Done
grub-imageboot/oldstable 0.6 all
  boot iso, harddisk and floppy images with grub2 and syslinux memdisk

grub2/oldstable,now 2.02~beta3-5+deb9u2 amd64 [residual-config]
  GRand Unified Bootloader, version 2 (dummy package)

grub2-common/oldstable 2.02~beta3-5+deb9u2 amd64
  GRand Unified Bootloader (common files for version 2)

grub2-splashimages/oldstable 1.0.1+nmu1 all
  a collection of great GRUB2 splashimages

live-wrapper/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images

live-wrapper-doc/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images (Documentation)

vmdebootstrap/oldstable 1.7-1 amd64
  Bootstrap Debian into a (virtual machine) disk image

Como instalar uma versão não-betaGRUB2 no Debian?

A página de manual de extensões do Netfilter afirma que:

MASQUERADE: Este alvo só é válido na nattabela, na POSTROUTINGcadeia

PERGUNTA: Como clonar a saída do MASQUERADEdestino com um TEEdestino?

Se você observar o diagrama netfilter/iptablesabaixo, notará que nat.POSTROUTINGé a última cadeia a ser avaliada antes que o pacote seja enviado para a interface de saída. Não há uma raw.POSTROUTINGcadeia, ... ou há?

Veja também isso .

PS
Qual é a razão para processar as tabelas manglee natna mesma ordem na interface outbounde inbound, quando os dados fluem em direções opostas através dessas interfaces (egresso e ingresso)?

O pacote foi clonado por iptables-mod-teeir após a clonagem quando adiciono uma regra como esta?:

iptables -t mangle -A POSTROUTING -o eth2 -j TEE --gateway 192.168.0.3

Consulte o diagrama abaixo. Eu acho que é óbvio que com o comando acima, o iptables-mod-teemódulo usa o POSTROUTING chaincomo fontemangle table de clonagem , mas o que acontece com o pacote depois que ele é clonado? ou seja, para qual cadeia e tabela o clone vai?

EDIT: Adicionada uma linha tracejada vermelha ao diagrama acima, para descrever o caminho do pacote clonado descrito na resposta.

Qual é o esquema de nomenclatura das partições MTD listadas no log de inicialização a seguir?

5 cmdlinepart partitions found on MTD device phys_mapped_flash
Creating 5 MTD partitions on "phys_mapped_flash":
0x00000000-0x00080000 : "bootloader" 
0x00080000-0x00680000 : "kernel"
0x00680000-0x01680000 : "rootfs" 
0x01680000-0x01780000 : "data"
0x01780000-0x017a0000 : "bootload-env"

Em particular, estou perguntando qual esquema de nomenclatura usar para especificar a partição "rootfs" no prompt do U-Boot como um argumento para o comando:

setenv bootargs 'root= ???????'

IMO, preciso especificar o root= porque o log de inicialização mostra que o kernel não sabe qual é o dispositivo raiz.

VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

...e também o log de inicialização mostra:

Kernel command line:  bootoctlinux 0x2a00200 mtdparts=phys_mapped_flash:512k(bootloader)ro,6M(kernel),16M(rootfs),1024k(data),128k(bootload-env) console=ttyS0,115200

BTW: O sistema de arquivos raiz é armazenado em uma seção incorporada (.init.ramfs) do arquivo ELF do kernel (vmlinux64) como um arquivo cpio compactado e o log de inicialização indica que ele foi carregado na RAM com sucesso:

Loading .init.ramfs @ 0xffffffff806ac000 (0x185ac7 bytes)

Isso está em um sistema embarcado com 32 MB de armazenamento flash somente ( kernel Linux v2.6.21.7 ( Distro: Cavium-Octeon for MIPS64 ) ).
U-Boot 1.1.1 (compilação de desenvolvimento, svnversion: 176)

EDIT: Algumas pessoas dizem que é MTD1, alguns que MTD2 alguns /dev/MTD1, alguns /dev/mtd1, alguns que é MTDblock1, alguns mtdblock1, alguns mtdblock2, alguns ubi.mtdblock1, alguns ubi:mtdblock1, (por que os dois pontos ?) etc...
Qual é a verdade? Como ele pode ser descoberto apenas no prompt do U-Boot ou no log de inicialização?

O seguinte arquivo de inicialização (vmlinux64) para o kernel Linux v2.6.21.7 (Distro: Cavium-Octeon for MIPS64):

ELF HEADER:
------------------------------------------
Magic: 0x7f 0x45 0x4c 0x46 ("ELF")
Class: 64-bit
Encoding: Big-Endian
ELF version: 1
OS ABI: System V
ABI Version: 0
Type: ET_EXEC
Machine: MIPS
Version: 1
Entry Point: 0xffffffff804b0000
Program Headers Offset: 0x40
Section Headers Offset: 0x572C70
Flags: 0x808b0001
ELF Header Size: 0x40
Program Header Entry Size: 0x38
Program Header Entries: 1
Section Header Entry Size: 0x40
Section Header Entries: 0x21
.shstrtab Index: 0x20

Tem estes segmentos e seções:

_______________________________________________________________________________________________
PROGRAM HEADERS:
_______________________________________________________________________________________________
Index Type    Flags           SizeInMem  MemVirtAddress      FileOffs  SizeInFile
-----------------------------------------------------------------------------------------------
0    PT_LOAD  Write+Read+Exec 0x5AB200   0xffffffff80100000  0x4000    0x56EAC7                                           

_______________________________________________________________________________________________
SECTION HEADERS:
_______________________________________________________________________________________________
Index Name                   Type        Flags        MemVirtAddress      FileOffs  SizeInFile
-----------------------------------------------------------------------------------------------
0                            K_NULL                                  0x0       0x0       0x0
1   .text                    K_PROGBITS  Alloc+Exec   0xffffffff80100000    0x4000  0x30DFE8
2   __ex_table               K_PROGBITS  Alloc+       0xffffffff8040dff0  0x311FF0    0x5EA0
3   __dbe_table              K_PROGBITS  Alloc+       0xffffffff80413e90  0x317E90       0x0
4   .rodata                  K_PROGBITS  Alloc+       0xffffffff80414000  0x318000   0x48B68
5   .pci_fixup               K_PROGBITS  Alloc+       0xffffffff8045cb68  0x360B68     0xB20
7   __ksymtab                K_PROGBITS  Alloc+       0xffffffff8045d688  0x361688    0x8EA0
8    __ksymtab_gpl           K_PROGBITS  Alloc+       0xffffffff80466528  0x36A528    0x2580
17  __ksymtab_strings        K_PROGBITS  Alloc+       0xffffffff80468aa8  0x36CAA8    0xEBA8
18   __param                 K_PROGBITS  Alloc+       0xffffffff80477650  0x37B650     0x6E0
19  .data                    K_PROGBITS  Alloc+Write  0xffffffff80478000  0x37C000   0x2FD20
20  .data.cacheline_aligned  K_PROGBITS  Alloc+Write  0xffffffff804a8000  0x3AC000    0x7280
21  .init.text               K_PROGBITS  Alloc+Exec   0xffffffff804b0000  0x3B4000   0x31270
22  .init.data               K_PROGBITS  Alloc+Write  0xffffffff804e1270  0x3E5270    0x3708
23  .init.setup              K_PROGBITS  Alloc+Write  0xffffffff804e4980  0x3E8980     0x5B8
24  .initcall.init           K_PROGBITS  Alloc+Write  0xffffffff804e4f38  0x3E8F38     0x6D8
25  .con_initcall.init       K_PROGBITS  Alloc+Write  0xffffffff804e5610  0x3E9610      0x10
27  .exit.text               K_PROGBITS  Alloc+Exec   0xffffffff804e5620  0x3E9620    0x30C0
28  .init.ramfs              K_PROGBITS  Alloc+       0xffffffff804e9000  0x3ED000  0x185AC7
32  .shstrtab                K_STRTAB                                0x0  0x572AC7     0x1A7
6   .rio_route               K_PROGBITS  Write        0xffffffff8045d688  0x572AC7       0x0
9   __ksymtab_unused         K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
10  __ksymtab_unused_gpl     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
11  __ksymtab_gpl_future     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
12  __kcrctab                K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
13  __kcrctab_gpl            K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
14  __kcrctab_unused         K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
15  __kcrctab_unused_gpl     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
16  __kcrctab_gpl_future     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
26  .security_initcall.init  K_PROGBITS  Write        0xffffffff804e5620  0x572AC7       0x0
29  .sbss                    K_PROGBITS  Alloc+Write  0xffffffff8066f000  0x572AC7       0x0
30  .bss                     K_NOBITS    Alloc+Write  0xffffffff80670000  0x572AC7   0x3AEF0
31  .cvmx_shared_bss         K_NOBITS    Alloc+Write  0xffffffff806aaef0  0x572AC7     0x310  
_______________________________________________________________________________________________

Observe que este arquivo ELF possui uma seção init.ramfs de 1558kB incorporada contendo arquivos essenciais para o sistema operacional. Esta seção é compactada com gzip e contém um arquivo cpio com 1805 arquivos e diretórios.

De acordo com: Kernel.org e Wikipedia , o extrator cpio do Linux Kernel descompacta esta seção init.ramfs em algum lugar da memória.

Minhas perguntas são:

1. O que determina o endereço de memória onde o conteúdo do arquivo cpio é extraído?
2. Após a extração, como o kernel encontra os endereços de memória para os dados de um arquivo específico, como o arquivo /sbin/init ?
3. O conteúdo do arquivo cpio é extraído em algum tipo de sistema de arquivos que permite que o kernel encontre esses arquivos mais tarde ... ou os endereços de memória desses arquivos são codificados no código do kernel?

Re: Pergunta 1: Eu não acho que a seção .init.ramfs pode ser descompactada para o endereço de memória 0xffffffff804e9000 indicado no cabeçalho da seção do arquivo ELF, porque há apenas 1560kB de espaço disponível antes da próxima seção (". sbss") começa na memória em 0xffffffff8066f000, e o arquivo cpio descompactado ocupa 4035kB.