Bugzilla – Bug 143685
Installation 2nd Stage fails to continue
Last modified: 2006-04-05 20:55:49 UTC
System: Intel STL main board with daul PIII 1GHz CPUs RAM 512 MB Adaptec I2O RAID controller in mode 1 4x 70 GB Seagate SCSI (140GB capacity) DVD-ROM System restarts and begins executing /etc/init.d/boot System fails to continue but in responsive mode still after displaying: System Boot Control: Running /etc/init.d/boot.local I did notice that the boot script manages to get to the point of creating /var/lib/YaST2/run_suseconfig but does not complete the outer if block. # # Let YaST2 finish its installation, if you installed with YaST2 # if test -f /var/lib/YaST2/runme_at_boot ; then HOSTTYPE=$(uname -m) splashtrigger "YaST" exec 0<> $REDIRECT 1>&0 2>&0 # if yast2 failed, this ensures proper system setup touch /var/lib/YaST2/run_suseconfig if test -x /usr/lib/YaST2/startup/YaST2.Second-Stage; then /usr/lib/YaST2/startup/YaST2.Second-Stage elif test -x /usr/lib/YaST2/bin/YaST2.firstboot; then /usr/lib/YaST2/bin/YaST2.firstboot else # oops, yast2 not installed rm -f /var/lib/YaST2/runme_at_boot fi fi Yet in the /var/log/YaST2/y2start.log there is no entry for Stage [2], there is only entries for Stage [1] and Stage [call] PS: I had to use acpi=off to begin installation.
No way this can possibly be a blocker with several 100.000 10.0 users out there that don't have this problem.
please provide the log files - y2start.log metioned above - y2logs according to http://www.opensuse.org/Bug_Reporting_FAQ#YaST btw. How long did you wait after your system "failed to continue"? (Was/Is there any disk access after the last message?) Can you assure that your hard disk(s) do not have any badblocks and work properly?
The RAID was formatted using I2O BIOS tools, then format fully using the partition wizard of Suse 10.0 during installation. Neither formatting reported bad blocks. After the last message is displayed "Running /etc/init.d/boot.local" the disk activity stops. Does not enter into graphical mode. Keyboard is responsive as characters are echoed to screen, yet system does not respond to when commands are entered nor does Alt+Ctrl+Del initiate reboot. Hard reset required. Only way I can obtain the logs is to select Suse 10.0 on boot screen and pass the optional parameter "init=/bin/bash", which gives me a shell to work with. The log y2start.log I can obtain from /var/log/YaST2/
Created attachment 63926 [details] Required y2start.log
I just tried the 10.1 beta 1 CD that I downloaded yesterday. It does manage to get to the point of starting up X with the GUI YaST wanting CD 2. PS: Nice pic of Geko for Boot loader. :) Only thing I noticed so far with Beta, the screen is rather jumpy when change contents.
Oooops Meant 11.1 beta 1
Thomas, is this y2-storage related?
From the logs I cannot see any problems realated to yast2-storage. The log from the first startup in installed system does not even show first line of initialisation from libstorage. No idea to whom this could be reassigned.
maybe some kernel guy knows about some problems with the hardware (controller, disks, board)??
Alun, you are saying that you can access the logs when booting with init=/bin/bash. I assume the logs are on a disk attached to this controller, and not on another disk. This suggests that the kernel is able to access the disks properly, and the problem is somewhere in user space. Please have a look at /var/log/messages though; it might contain some hints. When the system is in the state where it is apparently waiting for something, it might help to check which processes are active, and in which state they are (ps ax). You can also add a "set -x" to /etc/init.d/boot.local to see what it is doing. Other than that, I don't have a good idea how to debug this issue. It looks like a YaST problem from what we know so far though, so I'm reassigning to Stefan for now.
not mine for sure -> y2-maint
see comment 10
It is true that I am booting from the I2O RAID 1 SCSI drives when I use init=/bin/bash. So doubt it is the I2O driver that is giving the problem. I be able to obtain the message logs and other messages when I include "set -x" in the boot.local script on Monday when I am at the server again. It does reach the point of executing after boot.local just before the X server is started to continue with the GUI installation.
I have added the following to boot.local: set -x and rebooted. Last message displayed is: System Boot Control: Running /etc/init.d/boot.local System is still responsive in terms of keyboard keystrokes are echoed to display, though not interpreted as commands upon pressing <Enter>. <Alt+Ctrl+Del> is also not responding, thus require hard reset.
It seems the YaST2 startup after boot hangs. Please either boot with init=/bin/bash and do a the following sh -x /usr/lib/YaST2/startup/YaST2.Second-Stage or simply add a "set -x" to the beginning of /usr/lib/YaST2/startup/YaST2.Second-Stage It seems some of the early steps in /usr/lib/YaST2/startup/YaST2.Second-Stage hang. Reassigning to Marcus how is repsonsible for startup scripts.
I tried 1st just to uncomment "set -x" in /usr/lib/YaST2/startup/YaST2.Second-Stage which did not improve the situation at all Then booted with "init=/bin/bash" and tried sh -x /usr/lib/YaST2/startup/YaST2.Second-Stage This time the little dots at the bottom of screen ran the full width while plenty output to the screen, and then started X with Istall GUI requesting 2nd CD. What information do you require. I just left the installation at the point of requesting the 2nd CD.
This in my opinion means that the script YaST2.Second-Stage works as it should but it wasn't called in the normal workflow. Thanks for testing I will ask the linuxrc maintainer for details
Ehm, yes?
The YaST2.Second-Stage is started from YaST. As far as I know yast touched a file named /var/lib/YaST2/runme_at_boot if this file is present after reboot the YaST2.Second-Stage is called. I assume this file is missing. not a startup script bug
Alun, can you confirm, that after the reboot, /var/lib/YaST2/runme_at_boot is missing? Does this bug also occurre with newer betas?
no reaction for 6 weeks, closing as invalid