|
Bugzilla – Full Text Bug Listing |
| Summary: | soft RAID 1 with XFS for / cannot be booted by GRUB | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Forgotten User Drfk9mafMw <forgotten_Drfk9mafMw> |
| Component: | Basesystem | Assignee: | Neil Brown <nfbrown> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | nfbrown |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
first boot after installation
next shot final shot first boot trial second boot trial, first mention of md next shot, raid not clean error next shot final shot, after some seconds of no action |
||
|
Description
Forgotten User Drfk9mafMw
2008-09-23 11:47:19 UTC
The only difference between the SLES 10 setup and the openSUSE 11.0 setup I am playing with is that the servers uses SATA drives as opposed to IDE drives in the openSUSE desktop box... If it is possible to get exact error message, that would be very helpful. Maybe with a digital camera? Created attachment 244671 [details]
first boot after installation
Created attachment 244673 [details]
next shot
Created attachment 244674 [details]
final shot first boot trial
Created attachment 244676 [details]
second boot trial, first mention of md
Created attachment 244678 [details]
next shot, raid not clean error
Created attachment 244679 [details]
next shot
Created attachment 244680 [details]
final shot, after some seconds of no action
Sorry for the bad quality of the shots but the messages run through too quickly.
Also, with 11.1 Beta2 I can't even install at all, the installation hangs when installing the grub rpm-package... I will file a separate bug report for that.
Sorry for the long delay in replying. This looks like a bug in mdadm which I thought had been fixed. mdadm versions before about April 2008 could create arrays badly so that the 'bitmap' intersected with the data or metadata. The kernel would detect this and report exact the error that you are seeing. If you created the array with the 11.0 install disk, then I am surprised and I thought 11.0 was released after the bug was fixes. However I could be wrong. Looking back over your description, it could be that the install disk had an older kernel which did not detect the overlap, but that the kernel which was installed did. In that case you might be able to: boot with the install disk and select the 'rescue' option. get a shell assemble the array is it isn't already assembled remove the bitmap with "mdadm --grow --bitmap=none /dev/md0" reboot That should then boot successfully. Once booted with all uptodate software, you can add the bitmap back with mdadm --grow --bitmap=internal /dev/md0 Please let me know how you go - or whether you given up and done something else with the machine :-) I have given up on this and the machine in productive use with 11.0 softRAID 1 with ext3. This works. However, it has a free partitions which I use for testing of upcoming 11.1. Here, the issue is even worse (ever since Beta1, and at least until Beta3. Beta4 I haven't tried so far): bug #433980 I can't tell if there is any mdadm bug in this, because the installation on an XFS partition fails, no matter where I put grub. Installing on ext3 with a softRAID configuration works, though. Based on the last comment, I think this problem isn't occurring in current releases, or is hidden by some other bug that makes this impossible to proceed with. So I'm closing this bug now. Please reopen if you have new information. |