Bugzilla – Bug 155281
update from NFS inst-source hangs after first reboot
Last modified: 2006-04-02 17:51:26 UTC
I updated from beta3 to beta6 using an NFS installation source. After the initial reboot, YaST hang and used 100% CPU. Looking at the y2log showed me where the problem was: YaST could not access the install source. This wasn't really surprising because: - ifconfig showed that only "lo" was up - the NFS source obviously wasn't mounted therefore. Manually starting the network, creating the mountpoint and mounting the installation source to the directory YaST tried to use worked around this problem. I think this bug consists of several related sub-bugs: - network not started after reboot (remember, we are installing from NFS!) - installation source not mounted (not surprising without network ;-) - endless loop in YaST when installation source is not mounted - no error message shown in YaST
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!