#56 SuSE YAST in textmode does not work

[Anonymous]

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)

[Nobody/Anonymous]

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

[Nobody/Anonymous]

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

[Nobody/Anonymous]

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.

[Nobody/Anonymous]

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.

[Nobody/Anonymous]

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

[Nobody/Anonymous]

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.