I'm just getting started with UML, and can't get past square 1. UML
just gives itself SIGSTOP. Version info:
CPU: i86, Pentium 3 Mobile (Coppermine), 1.0 GHz
System: Dell Inspiron 4100, 256 MB RAM
Distro: SuSE 9.2
Host kernel: 2.6.8 (SuSE build: kernel-default-2.6.8-24.11)
Guest kernel: 2.6.8 (SuSE build: kernel-um-2.6.8-24.10), no local hacks
Root filesys: root_fs_toms1.7.205.bz2 + others
UML utilities: uml-utilities-20040114-21.1
Following instructions I created a swap image. I decompressed the root
filesystem. I mounted it (it's valid ext2) and snooped around; it
seemed believable, though the modules are for 2.0.37 so my UML couldn't
have loaded them. (No configuration file told it to load any of them.)
Kernel 2.6.x no longer has devfs; rather it has udev; so I edited
/etc/inittab in Tom's root so the single getty will open the tty device
actually present in /dev. I unmounted the root, then used this
/boot/linux ubd0=root_fs_toms.img ubd1=swap.img
It said on stdout or stderr:
Checking for the skas3 patch in the host...found
Checking for /proc/mm...found
There was no tracing process, xterm, or other child process.
/proc/<PID> revealed that it had opened its program text, several shared
libraries, the 33 MB /tmp/vm_file (deleted), and stdin-out-err, but not
the filesystem images on the command line.
When I did "kill -CONT its_pid", it used 99% of the CPU but never showed
other signs of life. The same files were open.
In other attempts I tried a root created with SuSE's UML setup script,
with exactly the same behavior. One time I accidentally ran UML in the
wrong directory, i.e. no images, and the behavior was the same. I
conclude that the finger of blame points elsewhere than the root
filesystem, even if the root might later turn out to have its own issues.
Digging on user-mode-linux.sourceforge.net and using Google, I found
descriptions of "normal" behavior; with Tom's root a getty should have
been spawned on /dev/tty1 which should have been passed through (without
command-line assignment) to fd:0,fd:1, i.e. the invoking terminal.
However, I found no discussion of SIGSTOP, except for a race condition
involving PTRACE_STOP which (I hope) was not involved here.
Can anyone suggest what might have gone wrong, or what to try next?
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@... http://www.math.ucla.edu/~jimc (q.v. for PGP key)