#56 SuSE YAST in textmode does not work

open
nobody
5
2003-11-30
2003-11-30
Anonymous
No

hi!
i have problems using YAST(suse setup tool) inside uml.
my uml is kernel2.6.0-test11 with suse9 rootfs.

when starting yast(textmode), i select "software". after
selecting "Install and Remove Software" yast just sits
there and seems to hang.
when i watch this with "top" from another console,i see
there is a process y2base just consuming cpu.
if i attach strace to that process, strace shows
me:nothing :( no single system call seems to be made.
eventually, after a long time y2base segfaults and
surprisingly yast continues to work and lets me select
software packages. this is weird,isn`t it?

i have straced the uml process on the host, when yast
is just hanging. strace exits after a very short amount of
time with "SIGVTALRM (Virtual timer expired)". there
seems no relation to the segfault of y2base inside uml,
because if i reattach the strace to the uml kernel, it
gives lots of output and exits again (and so on). y2base
inside uml still keeps running and do nothing - just
consuming cpu.
i have attached the output from strace to this bug
report. any hints how to proceed further, for analyzing
this problem?

regards
roland
(contact: for_spam@gmx.de)

Discussion

  • Logged In: NO

    damn - SF didn`t let me attach the file because it was >256k.
    unfortunately i cannot attach it afterwards - so i have
    uploaded the file to: http://www.my-
    vserver.de/uml/bugs/yast.strace

     
  • Logged In: NO

    damn - SF didn`t let me attach the file because it was >256k.
    unfortunately i cannot attach it afterwards - so i have
    uploaded the file to: http://www.my-
    vserver.de/uml/bugs/yast.strace

     
  • Logged In: NO

    >Unfortunately, fenris doesn't work under UML (neither does
    strace if I remember correctly).

    oh - is that true? so no wonder, that i don`t see any output.

     
  • Logged In: NO

    I have seen a similar bug with YaST using SuSE8.2 running
    under UML. I don't know a fix, but I do know a work around:

    Login via ssh, run top, locate the process that is consumming
    most of the CPU cycles and send it a SIGHUP. Once the signal
    is sent, YaST recovers and the CPU cycles drop to normal.

    But here is the strange thing, Sometimes, usually the first
    attempt, it is only necessary to make the ssh connection to
    recover the box. But on subsequent invocations of YaST, only
    the signal will do.

     
  • Logged In: NO

    I found a better workaround:

    digging deeper into yast, i found that yast (fortunately) uses
    a special "ycp" Scripting language. A menu-entry in yast
    consinsts of several ycp modules. a module, which loads quite
    often is the module "Arch.ycp". with that, yast seems to
    detect, which hardware architecture it`s running on.
    unfortunately, the detection within uml doesn`t seem to work
    correctly and results in the hanging "y2base" process. (i can
    supply more detailed strace output, because i have narrowed
    down the problem a little bit). y2base receives SIGSEGV after
    a fork (and still keeps running)

    as a workaround, i would recommend the following:

    edit /usr/share/Yast2/modules/Arch.ycp

    and replace the line
    "list systemProbe = SCR:Read(.probe.system);"
    with
    "list systemProbe = nil;"

    that works for me and fixes a lot of "hangups" in yast.
    unfortunatly, starting the software-installation-module in yast
    is HORRIBLY slow under uml, when it reads the package
    information. strace (works inside uml, after all) shows me,
    that there are LOTS of llseeks.
    is llseek "extra slow" within uml and can be called a "worse
    case" ?

    regards
    roland

     
  • Logged In: NO

    > "list systemProbe = SCR:Read(.probe.system);"

    That is actually a bug in the uml kernel (there should be a mail
    in the -devel archive
    ...). One if the things the hardware probes does is to check
    whenever
    it runs within vmware or not, and that test hangs (source
    code below).

    Known workarounds:
    * boot with "hwprobe=-sys" (that will make the hardware
    detect
    skip the critical test), or
    * don't use skas mode (it hangs in skas mode only for some
    musterious reason), or
    * just do something else in another terminal, that will unblock
    it too (scheduler bug in the uml kernel?).

    > btw: what would be a better solution: asking the suse
    people to make
    > yast "uml-aware" or fixing those things inside uml?

    IMHO this one is a UML kernel bug.