Bug 192725 - 2nd stage of installation fails
Summary: 2nd stage of installation fails
Status: RESOLVED FIXED
Alias: None
Product: openSUSE 10.2
Classification: openSUSE
Component: Installation (show other bugs)
Version: Alpha 2
Hardware: i686 Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Hannes Reinecke
QA Contact: Stanislav Visnovsky
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-15 18:49 UTC by Per Jessen
Modified: 2006-10-27 11:16 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
/var/log/YaST2 - tarred and gzipped (534.97 KB, application/x-tar)
2006-07-15 18:50 UTC, Per Jessen
Details
Output of "hwinfo" (205.20 KB, application/octet-stream)
2006-07-17 10:22 UTC, Per Jessen
Details
Output of "lspci" (1.88 KB, application/octet-stream)
2006-07-17 10:23 UTC, Per Jessen
Details
Output of "lspci -vv" (12.17 KB, application/octet-stream)
2006-07-17 10:24 UTC, Per Jessen
Details
Updated /sbin/mkinitrd (80.47 KB, text/plain)
2006-07-26 15:01 UTC, Hannes Reinecke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Per Jessen 2006-07-15 18:49:23 UTC
I'm installing a Compaq Proliant 8500R over ssh which works fine right up until the first reboot.  The reboot ends up with "Waiting for /dev/root to appear" ... and then exits into /bin/sh when it doesn't.  I'm using kernel options "i8042.nomux".
Comment 1 Per Jessen 2006-07-15 18:50:37 UTC
Created attachment 93650 [details]
/var/log/YaST2 - tarred and gzipped
Comment 2 Per Jessen 2006-07-17 06:40:11 UTC
Update: I switched to kernel 2.6.16.13-4-bigsmp (from 10.1) and the problem has disappeared. 
Comment 3 Michael Gross 2006-07-17 09:07:34 UTC
Please be more verbose about the used hardware. What are you using as root device? 
Please attach /var/log/boot.msg (that contains the failure) and 500 lines of /var/log/messages.
Comment 4 Per Jessen 2006-07-17 10:21:42 UTC
The hardware is an 8-way Proliant 8500R with 3Gb RAM.  It has a number of fibrechannel interfaces etc.  See attached hwinfo and lspci output.  The root device is a RAID1 array via an integrated Compaq Smart Array Controller.  I have two RAID1 arrays and I've tried both.  I'll get the /var/log/boot.msg, but I doubt if anything is in /var/log/messages at this point. 
Comment 5 Per Jessen 2006-07-17 10:22:36 UTC
Created attachment 93685 [details]
Output of "hwinfo"
Comment 6 Per Jessen 2006-07-17 10:23:56 UTC
Created attachment 93686 [details]
Output of "lspci"
Comment 7 Per Jessen 2006-07-17 10:24:20 UTC
Created attachment 93687 [details]
Output of "lspci -vv"
Comment 8 Per Jessen 2006-07-17 13:18:12 UTC
Hi, I don't think I can get hold of /var/log/boot.msg and /var/log/messages - the root-filesystem is not mounted, so none of those are written to disk.  
But I did see two other errors when I tried the installation again: 

udevd add_to_rules: Invalid SUBSYSTEM ....
udevd add_to_rules: invalid rule rules.d/05-lilo.rules:1

The format is probably not quite accurate, I copied it by hand. 
Comment 9 Michael Gross 2006-07-18 05:39:53 UTC
Thomas, any chance you can help here? If not assign it back to the screening team.
Comment 10 Per Jessen 2006-07-18 11:20:43 UTC
Update: same scenario on Compaq Proliant 1600R (450MHZ PII, 512M RAM, Compaq SMART array) and ASUS Booksize Pundit-R (Celeron 2.4GHz, 512M RAM, plain IDE harddrive). I haven't tried going back to the kernel from 10.1. 
Comment 11 Per Jessen 2006-07-21 07:55:42 UTC
I've been looking into this, and I believe I've found the problem - the invalid udev rule mentioned in comment 8 is probably the cause. Because of that, we don't get a root-device identified.  When the system defaults to /bin/sh after having waited for /dev/root to appear, I've managed to get the bootup to continue by creating a symlink /dev/root -> /dev/ida/c0d0p3 (72,3) = my root file system. 
Comment 12 Thomas Fehr 2006-07-24 10:26:49 UTC
I have nothing to do with udev, so I cannot see why this bug got assigned to me.
Comment 13 Kay Sievers 2006-07-25 13:57:01 UTC
Please paste the content of:
  /etc/udev/rules.d/05-lilo.rules
here, or attach the file.
Comment 14 Per Jessen 2006-07-25 19:22:02 UTC
/etc/udev/rules.d/05-lilo.rules is created by the init-script in the initrd. 
It probably looks like this:

SUBSYSTEM="block", SYSFS{dev}="72:3", SYMLINK+="root"

Comment 15 Kay Sievers 2006-07-25 19:34:01 UTC
Ick, why is that file called lilo? Anyway, matches like the SUBSYSTEM key need to use '==' to work correctly. The wrong udev key is a bug in /sbin/mkinitrd, but that should not prevent the rule from working. No idea what's going wrong here. Hannes, care to fix the rule creation in mkinitrd.
Comment 16 Per Jessen 2006-07-26 08:10:41 UTC
FYI, I fixed the creation of the rule in mkinitrd (SUBSYSTEM and SYSFS), and it works fine. 
Comment 17 Hannes Reinecke 2006-07-26 15:01:08 UTC
Created attachment 94558 [details]
Updated /sbin/mkinitrd

Updated to automatically generated rules to adhere to recent udev changes.
Comment 18 Hannes Reinecke 2006-07-26 15:01:35 UTC
Updated rpm has been submitted to autobuild.
Comment 19 Anja Stock 2006-10-27 11:16:50 UTC
released