Site Home Page
The UML Wiki
UML Community Site

Problems and Solutions

Panic - Failed to open 'root_fs', errno = 2
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=".
F_SETLK failed, file already locked by pid n
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.
UML exits after a few lines of output
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.
'Kernel panic - not syncing: Kernel mode signal 7'
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.
'handle_trap - failed to wait at end of syscall'
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.
On x86_64, processes randomly segfault
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.
Hang after 'VFS: Mounted root...'
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.
Hosted at SourceForge Logo