Início / unix / Perguntas / 441417
Accepted
0xC0000022L
Asked: 2018-05-03 14:45:22 +0800 CST

Tendo um pouco de dificuldade para debootstrapping um Ubuntu (18.04) via Debian 8.10

  • 772

O hoster que estou usando fornece um Debian 8.10 (kernel 4.9.85) como um sistema de resgate. No passado, eu usei isso para inicializar o Ubuntu usando debootstrap daqui .

Estou usando algumas etapas de preparação, como a instalação, apt-cacher-ngque é o motivo localhost:3142da URL que estou usando ( http://localhost:3142/us.archive.ubuntu.com/ubuntu/ ) e ubuntu-archive-keyring.

A debootstrapinvocação é 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/

(Adicionei o --verboseúnico na esperança de ver se algo está errado, sem sucesso.)

Agora o que é estranho na debootstrapexecução é que com essa nova versão acabo vendo apenas as etapas Retrieving , Validating e Extracting (para um subconjunto dos pacotes) mas nada sobre esses pacotes sendo configurados.

Então pensei comigo mesmo "tudo bem, 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 é ignorado silenciosamente?! Uma debootstrapversão mais antiga não serve, porque eles não conhecem o Bionic Beaver (Ubuntu 18.04).

Havia duas coisas que eu pensei que poderiam ser um problema:

  1. a discrepância de 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 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 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 chrootentrar /targetcom o comando /bin/bashapenas dá

# 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 resulta em não /etc/passwde assim por diante. /dev, /proce /syssão montados em /target.

Como posso solucionar esse problema para inicializar com sucesso um Ubuntu a partir do referido sistema de resgate 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 primeiro algum tipo de sistema de resgate local.

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

Também tentei passar --foreignpara debootstrap, o que deve causar o comportamento que estou vendo, mas também deve deixar um executável /debootstrap/debootstrapque posso invocar com --second-stage. No entanto, embora exiba exatamente o mesmo comportamento que estou vendo sem a --foreignopção de linha de comando, não há /debootstrap/debootstrapno sistema de arquivos de destino para concluir a inicialização.

Além disso, tentei usar debootstrapfrom jessie-backportsinstalando-o desta forma: apt-get install -t jessie-backports debootstrap(identifica-se como debootstrap 1.0.89~bpo8+1). E, em seguida, ligando /usr/share/debootstrap/scripts/bionicpara /usr/share/debootstrap/scripts/gutsy.

debian ubuntu

1 respostas

  1. Best Answer

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

    Depois de descobrir isso, tive que descobrir qual problema debootstrapestava encontrando. Não era óbvio /debootstrap/debootstrap.log(dentro do alvo), embora em retrospectiva seja. Então eu precisava de introspecção debootstrap. Para fazer isso, invocou o /usr/sbin/debootstrapscript de shell explicitamente via /bin/sh -x(para ativar o rastreamento) e a saída pode realmente ser vista dentro /debootstrap/debootstrap.log(dentro do destino). No meu caso, o problema foi mknodmostrado por esta entrada de rastreamento 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, /proce /sysno alvo na frente (algo que funcionou no passado!).

    Em novas debootstrapversões, isso parece falhar incondicionalmente. A respectiva chamada de função mknodé setup_devices_simplede /usr/share/debootstrap/functions.

    Uma mudança notável que vi comparando os debootstrapscripts para 1.0.59e 1.0.89~bpo8+1(e versões subsequentes) foi que a invocação da função setup_devicesmudou de função second_stage_installpara função first_stage_install(do gutsyscript). Esta função chama setup_devices_simple, a menos que esteja executando uma variante fakechrootou em um kernel "estrangeiro" e, portanto, faz mknodcom que seja invocada um pouco mais cedo do que antes.

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

    • 8

relate perguntas