Bug 77994 - Problems running kernel-uml
Summary: Problems running kernel-uml
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-11-17 02:31 UTC by Claus L. Rasmussen
Modified: 2007-03-27 03:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-06-05 12:42:23 UTC

Attachments (Terms of Use)

Description Claus L. Rasmussen 2002-11-17 02:31:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Strange behavior running kernel-uml including 

  1). Hangs (or exceedingly slow startup) at random points in the
      startup process when services are started
  2). UML do not come down cleanly. Processes on the host are left
  3). Problems when mounting images

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
I have tried three difference procedures

A1. Download root_fs.rh-7.2-full.pristine.20020312.bz2 from 
A2. Uncompress image
A3. Loop-mount the image
A4. Edit /etc/inittab to default to run-level 3 and alter all 'ttys/#'
    to 'tty#'.
A5. Save and umount
A6. Execute '/boot/vmlinuz-2.4.18-14uml \
      ubd0=root_fs.rh-7.2-full.pristine.20020312 con=xterm'

B1. Download root_fs_toms1.7.205.bz2 from the same site as above
B2. Uncompress image
B3. Loop-mount the image
B4. Edit /etc/inittab to default to run-level 3 and alter all 'ttys/#'
    to 'tty#'.
B5. Save and umount
B6. Execute '/boot/vmlinuz-2.4.18-14uml \
      ubd0=root_fs_toms1.7.205 con=xterm
C1. Follow the procedure described at http://linuxhacker.ru/uml/

I did try various settings for RAM, but to no avail.

(The RH 7.2 image are slightly altered from the version RH distributes. The
ttys/# -> tty# undoes one of these changes. If this is not done no terminals
will start and you'll be unable to log in)

Actual Results:  
A: Hangs:

The hangs are coming at rather random points in the service startup process (the
earliest one is if the disk is to be fsck'd). CTRL+C in the X console seems to
break the halt sometimes, but it can hang again later on. I have tried to leave
the process hanging to see if it would resume processing and sometimes it did
(after waiting several minutes). I havn't seen any hangs in the kernel startup

The tomsrtbt image do not hang at all. OTOH: It hardly starts any

A+B: UML do not come down cleanly.

When one shuts the UML kernel down the processes on the host are left
running. The problem is the same whatever method you use: uml_mcontrol,
'shutdown -h' from inside the UML kernel or a hard CTRL+C in the host console.
Killing the tracing thread sometimes takes all other process down with it, but
sometimes not.

C: Problems when mounting images (not that important - I tried it out   
   of frustration with the other images)

The boot process stops when the installer tries to mount the /base/stage2.img
image as root. The problem lies in a script called 'rootmnt' or 'mntroot' or
something like that. The actual NFS mount of the installation disks works fine.

Expected Results:  No hanging processes in the startup and no hanging processes
when the UML quits.

Additional info:

    Intel Pentium III
    VIA chipset (VT82C693A/694x, VT82C598/694x, VT82C686)

    Linux version 2.4.18-17.8.0 (bhcompile@daffy.perf.redhat.com) 
    (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue Oct 
    8 13:51:08 EDT 2002


Note: In addition to this report I am filing an enhancement request for an UML
image to be included in the distribution for testing purposes. I don't like
filing a bug-report involving modified third party root images, but without an
included image there is no other option.

Comment 1 Claus L. Rasmussen 2002-11-17 04:44:36 UTC
Some additional information:

>  2). UML do not come down cleanly. Processes on the host are left
>      running.

...and consuming huge amounts of CPU power. Here is a listing of the left-over
processes after a 'shutdown -h now' command was issued from within the UML:

20924 pts/7    S      0:37 /boot/vmlinuz-2.4.18-14uml  [(tracing thread)]
20927 pts/7    S      0:05 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20934 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20936 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20938 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20940 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20942 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20944 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20949 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [(kernel thread)]
20952 pts/7    S      0:04 /boot/vmlinuz-2.4.18-14uml  [init]
27575 pts/7    S      0:00 /boot/vmlinuz-2.4.18-14uml  [/bin/bash]
27663 pts/7    R     69:02 /boot/vmlinuz-2.4.18-14uml  [halt]

'top' showed PID 27663 gobling up all available CPU. 

(As a tribute to the responsiveness of the kernel in RH8, I must mention that I
didn't notice any slowdown on the host machine at all, and only discovered the
offending process when I did a 'top' much later when working on an unrelated
problem :-)

Comment 2 Alan Cox 2003-06-05 12:42:23 UTC
UML is very experimental, its value in the RH shipped is basically as a
debugging tool. Linux 2.5 kernel trees have a much better UML environment that
may make production grade

Note You need to log in before you can comment on or make changes to this bug.