|
Bugzilla – Full Text Bug Listing |
| Summary: | 2nd stage of installation fails | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.2 | Reporter: | Per Jessen <per> |
| Component: | Installation | Assignee: | Hannes Reinecke <hare> |
| Status: | RESOLVED FIXED | QA Contact: | Stanislav Visnovsky <visnov> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | suse-beta |
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
/var/log/YaST2 - tarred and gzipped
Output of "hwinfo" Output of "lspci" Output of "lspci -vv" Updated /sbin/mkinitrd |
||
|
Description
Per Jessen
2006-07-15 18:49:23 UTC
Created attachment 93650 [details]
/var/log/YaST2 - tarred and gzipped
Update: I switched to kernel 2.6.16.13-4-bigsmp (from 10.1) and the problem has disappeared. 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. 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. Created attachment 93685 [details]
Output of "hwinfo"
Created attachment 93686 [details]
Output of "lspci"
Created attachment 93687 [details]
Output of "lspci -vv"
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. Thomas, any chance you can help here? If not assign it back to the screening team. 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. 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. I have nothing to do with udev, so I cannot see why this bug got assigned to me. Please paste the content of: /etc/udev/rules.d/05-lilo.rules here, or attach the file. /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"
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. FYI, I fixed the creation of the rule in mkinitrd (SUBSYSTEM and SYSFS), and it works fine. Created attachment 94558 [details]
Updated /sbin/mkinitrd
Updated to automatically generated rules to adhere to recent udev changes.
Updated rpm has been submitted to autobuild. released |