¿Cómo crear rootfs para Linux en modo usuario en Fedora 18?

¿Cómo crear rootfs para Linux en modo usuario en Fedora 18?

Quiero crear un rootfs para usarlo con un kernel UML y poder usar Internet. Estaba usando febootstrapcon paquetes: bash, coreutils, net-tools, iputils. Después de usarlo febootstrap-supermin-helperobtuve mi rootfspero 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 rootfsy 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_defconfigdefconfig casi funcionó, excepto que tuve que agregarlo ::sysinit:/sbin/mdev -sal archivo inittab. Creo que esto se debe a que Buildroot se basa en CONFIG_DEVTMPFS_MOUNTcrear /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 insmodfallará porque UML no tiene SMPningún efecto vermagic, y si fuerza vermagic, suceden cosas raras como que printkno 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.

información relacionada