As of test11, it is necessary to have "ARCH=um" in the environment or on the make command line for all steps in building UML, including clean, distclean, or mrproper, config, menuconfig, or xconfig, dep, and linux. If you forget for any of them, the i386 build seems to contaminate the UML build. If this happens, start from scratch with
and repeat the build process with ARCH=um on all the steps.
host% make mrproper ARCH=um
See Compiling the kernel and modules for more details.
Another cause of strange compilation errors is building UML in /usr/src/linux. If you do this, the first thing you need to do is clean up the mess you made. The /usr/src/linux/asm link will now point to /usr/src/linux/asm-um. Make it point back to /usr/src/linux/asm-i386. Then, move your UML pool someplace else and build it there. Also see below, where a more specific set of symptoms is described.
The boot looks like this:
You're probably running a recent distribution on an old machine. I saw this with the RH7.1 filesystem running on a Pentium. The shared library loader, ld.so, was executing an instruction (cmove) which the Pentium didn't support. That instruction was apparently added later. If you run UML under the debugger, you'll see the hang caused by one instruction causing an infinite SIGILL stream.
VFS: Mounted root (ext2 filesystem) readonly. Mounted devfs on /dev
The fix is to boot UML on an older filesystem.
I saw this on reiserfs 3.5.21 and it seems to be fixed in 3.5.27. Panics preceded by
are diagnostic of this problem. This is a reiserfs bug which causes a thread to occasionally read stale data from a mmapped page shared with another thread. The fix is to upgrade the filesystem or to have /tmp be an ext2 filesystem.
Detaching pid nnnn
This happens when you build in /usr/src/linux. The UML build makes the include/asm link point to include/asm-um. /usr/include/asm points to /usr/src/linux/include/asm, so when that link gets moved, files which need to include the asm-i386 versions of headers get the incompatible asm-um versions. The fix is to move the include/asm link back to include/asm-i386 and to do UML builds someplace else.
This seems to be a similar situation with the resierfs problem above. Some versions of NFS seems not to handle mmap correctly, which UML depends on. The workaround is have /tmp be non-NFS directory.
If you build UML with gprof support and, early in the boot, it does this
you have a buggy gcc. You can work around the problem by removing UM_FASTCALL from CFLAGS in arch/um/Makefile-i386. This will open up another bug, but that one is fairly hard to reproduce.
kernel BUG at page_alloc.c:100!
The exact boot error depends on the distribution that you're booting, but Debian produces this:
This is a syslogd bug. There's a race between a parent process installing a signal handler and its child sending the signal. See this uml-devel post for the details.
/etc/rc2.d/S10sysklogd: line 49: 93 Terminated start-stop-daemon --start --quiet --exec /sbin/syslogd -- $SYSLOGD
There are a couple of problems which were http://www.geocrawler.com/lists/3/SourceForge/597/0/ name="pointed out"> by Tim Robinson
when you bring up the device inside UML, you have a header mismatch between the original kernel and the upgraded one. Make /usr/src/linux point at the new headers. This will only be a problem if you build uml_net yourself.
File descriptor in bad state
If you can connect to the host, and the host can connect to UML, but you can not connect to any other machines, then you may need to enable IP Masquerading on the host. Usually this is only experienced when using private IP addresses (192.168.x.x or 10.x.x.x) for host/UML networking, rather than the public address space that your host is connected to. UML does not enable IP Masquerading, so you will need to create a static rule to enable it:
Replace eth0 with the interface that you use to talk to the rest of the world.
host% iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Documentation on IP Masquerading, and SNAT, can be found at www.netfilter.org .
If you can reach the local net, but not the outside Internet, then that is usually a routing problem. The UML needs a default route:
The gateway IP can be any machine on the local net that knows how to reach the outside world. Usually, this is the host or the local network's gateway.
UML# route add default gw gateway IP
Occasionally, we hear from someone who can reach some machines, but not others on the same net, or who can reach some ports on other machines, but not others. These are usually caused by strange firewalling somewhere between the UML and the other box. You track this down by running tcpdump on every interface the packets travel over and see where they disappear. When you find a machine that takes the packets in, but does not send them onward, that's the culprit.
Thanks to Birgit Wahlich for telling me about this strange one. It turns out that there's a limit of six environment variables on the kernel command line. When that limit is reached or exceeded, argument processing stops, which means that the 'root=' argument that UML usually adds is not seen. So, the filesystem has no idea what the root device is, so it panics.
The fix is to put less stuff on the command line. Glomming all your setup variables into one is probably the best way to go.
On some older systems, /usr/include/asm/ptrace.h and /usr/include/sys/ucontext.h define the same names. So, when they're included together, the defines from one completely mess up the parsing of the other, producing errors like:
plus a pile of warnings.
/usr/include/sys/ucontext.h:47: parse error before `10'
This is a libc botch, which has since been fixed, and I don't see any way around it besides upgrading.
On i386 kernels, there are two ways of running the loop that is used to calculate the BogoMips rating, using the TSC if it's there or using a one-instruction loop. The TSC produces twice the BogoMips as the loop. UML uses the loop, since it has nothing resembling a TSC, and will get almost exactly the same BogoMips as a host using the loop. However, on a host with a TSC, its BogoMips will be double the loop BogoMips, and therefore double the UML BogoMips.
If the host is configured with the 2G/2G address space split, that's why. See UML on 2G/2G hosts for the details on getting UML to run on your host.
If you're running an up to date kernel with an old release of uml_utilities, the port-helper program will not work properly, so xterms will exit straight after they appear. The solution is to upgrade to the latest release of uml_utilities. Usually this problem occurs when you have installed a packaged release of UML then compiled your own development kernel without upgrading the uml_utilities from the source distribution.
This problem is fixed by the skas-hold-own-ldt patch that went into 2.6.15-rc1.
The boot looks like this:
cannot set up thread-local storage: cannot set up LDT for thread-local storage Kernel panic - not syncing: Attempted to kill init!
Your UML kernel doesn't support Native Posix Thread Library (NPTL) and the binaries you're running are being dynamically linked to it. Try running in SKAS3 mode first. You might be able to avoid the kernel panic setting the LD_ASSUME_KERNEL environment variable on the command line:
./linux init=/bin/sh LD_ASSUME_KERNEL=2.4.1
Many commands are very restrictive about what is preserved in the environment when starting child processes, so relying on LD_ASSUME_KERNEL to be globally set for all processes in the whole system is generally not a good idea. It's very hard to guarantee. Thus it's better to move the NPTL libraries away:
# mount root_fs mnt-uml/ -o loop # mv mnt-uml/lib/tls mnt-uml/lib/tls.away # umount mnt-uml
If you're running Debian, you might prefer to use dpkg-divert:
# export LD_ASSUME_KERNEL=2.4.1 # mount root_fs mnt-uml/ -o loop # chroot mnt-uml # mkdir /lib/tls.off # cd /lib/tls # for f in *; do dpkg-divert --divert --local --rename --divert /lib/tls.off/$f --add /lib/tls/$f; done # exit # umount mnt-uml # unset LD_ASSUME_KERNEL
These appear to be fixed with the tls patches from Blaisorblade that are currently in my patchset . You can apply the entire patchset, or you can move /lib/tls in the image away, as described above.
If you're seeing truly strange behavior, such as hangs or panics that happen in random places, or you try running the debugger to see what's happening and it acts strangely, then it could be a problem in the host kernel. If you're not running a stock Linus or -ac kernel, then try that. An early version of the preemption patch and a 2.4.10 SuSE kernel have caused very strange problems in UML.
Otherwise, let me know about it. Send a message to one of the UML mailing lists - either the developer list - user-mode-linux-devel at lists dot sourceforge dot net (subscription info) or the user list - user-mode-linux-user at lists dot sourceforge do net (subscription info), whichever you prefer. Don't assume that everyone knows about it and that a fix is imminent.
If you want to be super-helpful, read Diagnosing Problems and follow the instructions contained therein.