Bug 155281

Created attachment 71245 [details]
y2logs

You can find some "[cboltz]" comments in the log - I added them after starting the network and after mounting the installation source manually.

I assume the network will not work again for you on the same machine.
Could you, please, attach gdb to the looping y2base process?

If you tell me what I have to do exactly, yes. (I'm not very experienced in debugging.)

If there's another possible way to trigger this, I'd like to know - reinstalling the whole distribution takes some time :-(
(I remember there's a way to force YaST to run at boot by touching a file, but don't remember the path/filename :-( )

BTW: In the installed system, the network works without problems.

The log says: no network interface eth0 - so kernel module was not loaded IMO.

To restart 2nd stage: 'touch /var/lib/YaST2/runme_at_boot'

What I need you to do is find out PID of y2base, then on the console 2 do:

gdb -p <PID> 

And attach here the output of 'bt' issued to gdb.
At least first 5 lines.

Thanks a lot!

I will test this tomorrow - thanks for your HowTo ;-)

Just two maybe related notes:
- could this be related to bug #116537? (I have a wired and a WLAN interface, 
  but only "lo" was up.)
- my wired network interface (which is used for update) is not named "eth0", 
  but "kabel" (using a /etc/udev/rules.d/30-net_persistent_names.rules entry)

I'll leave this bug in NEEDINFO state until I have the backtrace available.

Hmmm...

# grep -v ^# 30-net_persistent_names.rules
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:23:9a:3e:9a", 
    IMPORT="/sbin/rename_netiface %k wlan"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:c0:9f:33:58:45", 
    IMPORT="/sbin/rename_netiface %k kabel"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:c0:9f:33:58:45", 
    IMPORT="/sbin/rename_netiface %k eth0"

I'm quite sure I did _not_ add the last line (eth0) myself - but it is already present in my 10.0 system which I cloned for the update.

"kabel" and "eth0" adress the same device, but ifconfig tells me that "kabel" won ;-)  (at least in 10.0)

Created attachment 71740 [details]
gdb backtrace as requested

(bug was reproducable by touching runme_at_boot)

Klaus, Michael?

#0  0xb75dd3c0 in _int_malloc () from /lib/libc.so.6
#1  0xb75df216 in malloc () from /lib/libc.so.6
#2  0xb777bb97 in operator new () from /usr/lib/libstdc++.so.6
#3  0xb71263d2 in zypp::pool::NameHash::insert () from /usr/lib/libzypp.so.0
#4  0xb71267d2 in zypp::pool::CapHash::erase () from /usr/lib/libzypp.so.0
#5  0xb71268c8 in zypp::pool::PoolImplDeleter::operator() () from /usr/lib/libzypp.so.0
#6  0xb7309a22 in zypp::zypp_detail::ZYppImpl::removeInstalledResolvables () from /usr/lib/libzypp.so.0
#7  0xb730b9b4 in zypp::zypp_detail::ZYppImpl::commit () from /usr/lib/libzypp.so.0
#8  0xb7114b93 in zypp::ZYpp::commit () from /usr/lib/libzypp.so.0
#9  0xb5f5c118 in PkgModuleFunctions::PkgCommit () from /usr/lib/YaST2/plugin/libpy2Pkg.so.2

Huh ? 'removeInstalledResolvables()' is called after every commit. So this probably can't be a generic bug.

The stack trace looks fishey. CapHash::erase calling NameHash::insert ?!?

happened again when updating to beta8 :-(

I'll attach a new backtrace and fresh y2logs.

Created attachment 73822 [details]
backtrace from beta8

Created attachment 73823 [details]
y2logs from beta8

Thanks, the backtrace was helpful.
Fixed.

comment #15: fixed

Installation from NFS worked with beta9 :-)

Thanks for fixing this!