
Quiero crear un rootfs para usarlo con un kernel UML y poder usar Internet. Estaba usando febootstrap
con paquetes: bash
, coreutils
, net-tools
, iputils
. Después de usarlo febootstrap-supermin-helper
obtuve mi rootfs
pero al intentar iniciarlo con UML me aparecen estos errores:
[ 4.340000] systemd[1]: systemd-logind.service holdoff time over, scheduling restart.
[ 4.340000] systemd[1]: dbus.service start request repeated too quickly, refusing to start.
[ 4.340000] systemd-logind[638]: Failed to get system D-Bus connection: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[ 4.340000] systemd-logind[638]: Failed to fully start up daemon: Connection refused
Me pregunto para qué paquetes son necesarios rootfs
y si hay alguna otra forma además febootstrap
.
Respuesta1
Quizás podrías probar PRoot (http://proot.me) como alternativa a UML. Ambos se basan en ptrace(2), aunque PRoot no requiere ninguna configuración para obtener acceso a Internet desde el sistema invitado:
host$ proot -R ./fedora-18-x86_64/ bash
guest$ wget http://google.fr
...
donde "./fedora-18-x86_64/" es el contenido de un rootfs descargado desdehttp://download.openvz.org/template/precreated/
Respuesta2
raíz de compilación
El qemu_x86_64_defconfig
defconfig casi funcionó, excepto que tuve que agregarlo ::sysinit:/sbin/mdev -s
al archivo inittab
. Creo que esto se debe a que Buildroot se basa en CONFIG_DEVTMPFS_MOUNT
crear /dev
.
Raíces:
git clone git://git.buildroot.net/buildroot
cd buildroot
git checkout 2017.02
make qemu_x86_64_defconfig
# Custom inittab.
echo 'BR2_ROOTFS_OVERLAY="rootfs_overlay"' >>.config
make olddefconfig
mkdir -p rootfs_overlay/etc
printf '
::sysinit:/bin/mount -t proc proc /proc
::sysinit:/bin/mount -o remount,rw /
::sysinit:/bin/mkdir -p /dev/pts
::sysinit:/bin/mkdir -p /dev/shm
::sysinit:/bin/mount -a
::sysinit:/sbin/mdev -s
::sysinit:/bin/hostname -F /etc/hostname
::sysinit:/etc/init.d/rcS
console::respawn:/sbin/getty -n -L console 0 vt100
::ctrlaltdel:/sbin/reboot
::shutdown:/etc/init.d/rcK
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
' > rootfs_overlay/etc/inittab
# Build image.
make BR2_JLEVEL=$(($(nproc)-2))
cp output/images/rootfs.ext2 /path/to/linux
Luego en la fuente del kernel:
cd /path/to/linux
git checkout v4.9
make mrproper
make defconfig ARCH=um
make ARCH=um
./linux eth0=tuntap,,,192.168.0.254
Ahora estás dentro de la VM y puedes salir con:
poweroff
El sistema de archivos es persistente, pruébalo con:
date >f
y reiniciar.
TODO para que la red funcione. La corriente eth0=
es solo un muñeco para evitar que el inicio de Buildroot se detenga mientras espera el dispositivo de red.
También puede depurar paso a paso el kernel como se muestra en:https://stackoverflow.com/questions/4943857/linux-kernel-live-debugging-how-its-done-and-what-tools-are-used/44669413#44669413
TODO No sé cómo lidiar con los módulos del kernel, ya que deben compilarse en UML, no en x86. El primer problema es que insmod
fallará porque UML no tiene SMP
ningún efecto vermagic
, y si fuerza vermagic, suceden cosas raras como que printk
no imprime nada. Relacionado:https://stackoverflow.com/questions/2488625/user-mode-linux-installing-a-module-error
También puedes inspeccionar esa imagen con QEMU si lo prefieres:
qemu-system-x86_64 -M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2,if=virtio,format=raw -append root=/dev/vda -net nic,model=virtio -net user
Probado en Ubuntu 14.04, host del kernel 3.13.0.