Tendo um pouco de dificuldade em desobstruir um Ubuntu (18.04) via Debian 8.10

5

O hoster que estou usando fornece um Debian 8.10 (kernel 4.9.85) como um sistema de recuperação. No passado eu tenho usado isso para fazer o bootstrap do Ubuntu usando debootstrap aqui .

Estou usando algumas etapas preparativas, como a instalação de apt-cacher-ng , que é a razão para o localhost:3142 na URL que estou usando ( link ) e ubuntu-archive-keyring .

A invocação debootstrap é a seguinte:

LANG=C debootstrap --keep-debootstrap-dir --verbose --include=ubuntu-server,bash-completion,sudo,lshw,tmux,unzip,pciutils,usbutils,openssh-server,unattended-upgrades,linux-image-generic,cron --variant=minbase --arch=$(dpkg --print-architecture) bionic /target http://localhost:3142/us.archive.ubuntu.com/ubuntu/

(Eu adicionei o --verbose apenas na esperança de ver se algo está errado, sem sucesso.)

Agora, o que é estranho sobre a execução de debootstrap é que, com essa nova versão, acabo vendo apenas as etapas Recuperando , Validando e Extraindo (para um subconjunto dos pacotes), mas nada sobre esses pacotes sendo configurados.

Então eu pensei comigo mesmo "tudo bem, eu fiz isso com xenial , então vamos tentar de novo" e isso me dá a mesma rotina.

+ debootstrap --keep-debootstrap-dir --verbose --include=ubuntu-server,bash-completion,sudo,lshw,tmux,unzip,pciutils,usbutils,openssh-server,unattended-upgrades,linux-image-generic,cron --variant=minbase --arch=
amd64 xenial /target http://localhost:3142/us.archive.ubuntu.com/ubuntu/
I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id 790BC7277767219C42C86F933B4FE6ACC0B21F32)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional base dependencies: acpid apport apt-utils at bcache-tools btrfs-tools busybox-initramfs byobu ca-certificates cloud-guest-utils cloud-initramfs-copymods cloud-initramfs-dyn-netconf cpio crda
cryptsetup cryptsetup-bin curl dh-python distro-info-data dmeventd dmsetup ethtool fonts-ubuntu-font-family-console gawk gcc-5-base gettext-base gir1.2-glib-2.0 git git-man gnupg gpgv grub-legacy-ec2 ifenslave i
fupdown initramfs-tools initramfs-tools-bin initramfs-tools-core iproute2 iso-codes iw klibc-utils kmod libapt-inst2.0 libapt-pkg5.0 libasn1-8-heimdal libasprintf0v5 libbsd0 libcurl3-gnutls libdbus-1-3 libdbus-g
lib-1-2 libdevmapper-event1.02.1 libdrm2 libdumbnet1 libedit2 liberror-perl libevent-2.0-5 libexpat1 libffi6 libfuse2 libgdbm3 libgirepository-1.0-1 libglib2.0-0 libgmp10 libgnutls30 libgpm2 libgssapi-krb5-2 lib
gssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libicu55 libidn11 libk5crypto3 libkeyutils1 libklibc libkrb5-26-heimdal libkrb5-3 libkrb5support0 libl
dap-2.4-2 liblvm2app2.2 liblvm2cmd2.02 liblz4-1 liblzo2-2 libmnl0 libmpdec2 libmpfr4 libmspack0 libnettle6 libnewt0.52 libnl-3-200 libnl-genl-3-200 libp11-kit0 libpci3 libperl5.22 libplymouth4 libpng12-0 libpopt
0 libpython-stdlib libpython2.7-minimal libpython2.7-stdlib libpython3-stdlib libpython3.5-minimal libpython3.5-stdlib libreadline5 libreadline6 libroken18-heimdal librtmp1 libsasl2-2 libsasl2-modules-db libsigs
egv2 libslang2 libsqlite3-0 libssl1.0.0 libstdc++6 libtasn1-6 libusb-0.1-4 libusb-1.0-0 libutempter0 libwind0-heimdal libwrap0 linux-base linux-firmware linux-image-4.4.0-21-generic linux-image-extra-4.4.0-21-ge
neric lsb-release lvm2 mdadm mime-support open-iscsi open-vm-tools openssh-client openssh-sftp-server openssl overlayroot patch perl perl-modules-5.22 plymouth python python-apt-common python-minimal python2.7 p
ython2.7-minimal python3 python3-apport python3-apt python3-chardet python3-dbus python3-debian python3-gi python3-minimal python3-newt python3-pkg-resources python3-problem-report python3-pycurl python3-six pyt
hon3-software-properties python3.5 python3.5-minimal readline-common screen software-properties-common sosreport ubuntu-cloudimage-keyring ubuntu-keyring ucf udev update-notifier-common vim vim-common vim-runtim
e vlan wireless-regdb xfsprogs xz-utils
I: Checking component main on http://localhost:3142/us.archive.ubuntu.com/ubuntu...
I: Retrieving acpid 1:2.0.26-1ubuntu2
I: Validating acpid 1:2.0.26-1ubuntu2
[...]
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting adduser...
I: Extracting base-files...
I: Extracting base-passwd...
[...]
I: Extracting zlib1g...

A razão pela qual isso é estranho é porque, no passado, o estágio de configuração funcionava sem problemas. Mas agora fica silenciosamente ignorado ?! Uma versão debootstrap mais antiga não funcionará, porque eles não conhecem o Bionic Beaver (Ubuntu 18.04).

Houve duas coisas que pensei que poderiam ser um problema:

  1. a discrepância da versão do kernel: 4.15 no Ubuntu 18.04 versus 4.9.85 no Debian 8.10.
  2. a discrepância da versão da libc: 2.27-3ubuntu1 versus 2.19-18 + deb8u10.

... mas em ambos os casos eu esperaria algum tipo de mensagem de erro de debootstrap . Também para xenial (Ubuntu 16.04) eu não deveria ter que esperar as mesmas discrepâncias. Mas não vejo nenhum erro, em vez disso, a etapa de configuração vital é ignorada e a tentativa de chroot em /target com o comando /bin/bash apenas fornece

# LANG=en_US.UTF-8 chroot /target /bin/bash
groups: cannot find name for group ID 0
I have no name!@rescue:/#

Cavar um pouco não gera /etc/passwd e assim por diante. /dev , /proc e /sys são montados por bind em /target .

Como posso solucionar esse problema para fazer o bootstrap com sucesso do Ubuntu a partir do sistema de resgate do Debian? A arquitetura corresponde ao host e ao destino, então o que está impedindo a execução da etapa de configuração?

NB: Não consigo inicializar em um kernel mais recente. Ou melhor, a única maneira de conseguir algo assim seria instalando algum tipo de sistema de resgate local primeiro.

O software que estou usando

$ debootstrap --version
debootstrap 1.0.95ubuntu1
$ uname -a
Linux rescue 4.9.85 #2 SMP Thu Mar 1 08:06:18 CET 2018 x86_64 GNU/Linux

Eu também instalei ubuntu-archive-keyring .

O que mais eu tentei

Eu também tentei passar --foreign para debootstrap , o que deve causar o comportamento que estou vendo, mas também deve deixar um executável /debootstrap/debootstrap que eu possa invocar com --second-stage . No entanto, embora exiba exatamente o mesmo comportamento que estou vendo sem a opção de linha de comando --foreign , não há /debootstrap/debootstrap no sistema de arquivos de destino para concluir o bootstrapping.

Além disso, tentei usar debootstrap de jessie-backports instalando desta forma: apt-get install -t jessie-backports debootstrap (identifica como debootstrap 1.0.89~bpo8+1 ). E, em seguida, vinculando /usr/share/debootstrap/scripts/bionic a /usr/share/debootstrap/scripts/gutsy .

    
por 0xC0000022L 03.05.2018 / 00:45

1 resposta

6

Tudo bem, eu percebi isso. A invocação de debootstrap de fato indicou falha retornando um código de saída 1. Eu perdi isso por causa de como eu estava encadeando vários comandos e usando subshells.

Depois que descobri, tive que descobrir qual problema debootstrap estava encontrando. Não era óbvio do /debootstrap/debootstrap.log (dentro do alvo), embora em retrospectiva seja. Então, eu precisava de introspecção em debootstrap . Para isso, invocou o script /usr/sbin/debootstrap explicitamente via /bin/sh -x (para ativar o rastreio) e a saída pode realmente ser vista dentro de /debootstrap/debootstrap.log (dentro do destino). No meu caso, o problema foi mknod , conforme mostrado por esta entrada de rastreio e a saída:

+ mknod -m 666 /target/dev/null c 1 3
mknod: '/target/dev/null': File exists

que, por sua vez, foi causado por eu montar /dev , /proc e /sys no alvo na frente (algo que havia funcionado no passado! ).

Nas novas versões debootstrap , isso parece falhar incondicionalmente. A respectiva função chamando mknod é setup_devices_simple de /usr/share/debootstrap/functions .

Uma mudança notável que vi ao comparar os scripts debootstrap para 1.0.59 e 1.0.89~bpo8+1 (e versões subseqüentes) foi que a invocação da função setup_devices foi movida da função second_stage_install para a função first_stage_install ( do script gutsy ). Essa função chama setup_devices_simple , a menos que esteja fazendo variante fakechroot ou executando em um kernel "externo" e, portanto, faz com que mknod seja invocado um pouco antes do que antes.

A razão pela qual isso não falhou antes, parece, é porque no passado os dispositivos eram mantidos dentro de um arquivo .tgz e descompactados no lugar, enquanto agora debootstrap usa mkdnod diretamente.

    
por 03.05.2018 / 13:32