The full error output looks like this:

Failed to open 'root_fs', errno = 2
VFS: Cannot open root device "98:0" or unknown-block(98,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0)

• Make sure the file you specified with the ubda= option actually exists.
• Check the early boot output for

  udba=FedoraCore5-x86-root_fs specified on command line is almost
  certainly a ubd -> udb TYPO
  

  If it's there, you specified "udba=" instead of "ubda=".

The full error output looks like this:

Failed to lock '/home/jdike/linux/root_fs.fc5', err = 11
Failed to open '/home/jdike/linux/root_fs.fc5', errno = 11
VFS: Cannot open root device "98:0" or unknown-block(98,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0)

You have another UML using the same filesystem image already. UML takes an exclusive, read-write lock on any image it will access read-write. This includes images with no COW files and COW files. In the case of a COWed ubd device, the backing file is locked with a non-exclusive read-only lock.

The solutions are

• Boot the new UML on a new image or COW file
• Shut down the other UML. If you don't think you have one running, but one previously died uncleanly, then look for processes that may be left over from it and kill them. The process name may be "linux", empty, or garbage. The pid may not (and likely won't) be the one mentioned in the error message.

Rerun UML with "stderr=1" added to the command line. If you then see

Kernel panic - not syncing: Segfault with no mm

and you have enabled gprof support (CONFIG_GPROF) and you are running a kernel earlier than around 2.6.17-rc5 (2.6.16.x is earlier), then either disable CONFIG_GPROF or upgrade to a newer version of UML.

The filesystem where UML is keeping its physical memory files is full. This is normally a tmpfs mount, either /dev/shm or /tmp. A UML's consumption of this space will asymptotically approach its physical memory size as it continues to run. This filesystem should be at least as big as the sum of the physical memory sizes of the UMLs that will be using it.

The full panic is

Kernel panic - not syncing: handle_trap - failed to wait at end of
syscall, errno = 0, status = 2943

This is a host bug introduced during the 2.6.16 series which broke ptrace. In the course of fixing a different bug (see the random segfault problem below), ptrace returned two system call return notifications rather than the one it's supposed to. It's fixed in 2.6.16-rc6, so upgrade the host to at least that.

This is also a host bug, fixed during the 2.6.16 series. It appears that these segfaults were caused by ptraced system calls on x86_64 returning via sysret, rather than iret. sysret requires that the process preserve at least %RCX because the instruction uses that as the userspace address to resume. In the case of sigreturn, that's impossible since signals happen asynchronously to the process. So, ptracing sigreturn will cause %RCX to be changed, and that seems to be the cause of the random process segfaults.

The VDSOs provided by the host kernel are confusing UML. Until this is fixed in UML, a workaround to to disable CONFIG_COMPAT_VDSO on the host.