For what it's worth, some of the boards I work with aren't emulated by QEMU either.
However, for me that did not turn out to be a problem for chrooting into my alien rootfs just to run apt/dpkg & friends. Qemu only has to emulate a very minimal/"thin" CPU environment when chrooting with binfmts, just enough to support a few kernel syscalls to your host computer's native Linux kernel. I don't think qemu is doing any peripheral/memory-layout/IO etc emulation when used like this - those things (Eg. networking, file-system access) are provided by thin wrappers to the host system's kernel, kind of like WINE. On 07/11/14 20:00, Thorsten Glaser wrote: > On Fri, 7 Nov 2014, Adam Borowski wrote: > >> You can chroot to the system from the host machine, and upgrade to sysvinit. >> If your host can't run arm code, install qemu-user-static and copy >> /usr/bin/qemu-arm-static to the target system. > This is no fix. There are systems Qemu does not emulate. > debootstrap --include and --exclude should work. (I very > vaguely recall getting angry at them at some point in > the past too, and just resorting to $EXTRAPACKAGES in > pbuilderrc instead, requiring cowbuilder --update right > after cowbuilder --create, once or even twice, to get > things to the right state. So they might not work ☹) > > bye, > //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545c96a2....@yahoo.com.au
