https://bugzilla.novell.com/show_bug.cgi?id=304657#c6
Richard Creighton
--- Comment #5 from JiřàSuchomel
2007-08-29 00:21:01 MST --- Sorry, but not everything is clear from the report. You mention that repair broke your settings. However I doubt it did any real change without your confirmation
The first time it was run from the automatic mode and it was talking about SDx drives not HDx which to me elimnated the IDE drive and I was not expecting it to be writing to the wrong drive so I answered 'Y' like I have in the past for other repairs.
Did you run repair system always from the installaton media or from the installed system? The correct way is to run it from media; before you finish it,
Attachment of comment 2 doesn't mention any run of repair. I do not understand from the report how did you aquire it.
After the 'repair'', neither the 10.3 install, nor my original 10.2 system on the IDE drive which should have been hda would boot. (I wasn't aware that 10.3 renamed the IDE drives to 'SDn'.) and one of my 'Y' answers to the automatic repair from the installation media had written changes to the GRUB configuration on the 10.2 installition and not on the 10.3 drive set on the MD file structure as I had assumed it would. Thus a KNOPPIX boot to a root session. So, after almost a day of manually figuring out what had happened, discovering the HD to SD naming change, discovering the change to the 10.2 GRUB files, figuring out what they *should* have been and manually rewriting them from a KNOPPIX session, I then backed up the /boot partition "in case". I got the installation that had been installed on the MD raid to boot by booting from the install CD and selecting the option to boot the installed OS from the install menu options, (thereby bypassing GRUB) the installation (10.3 b2) continued normally and I was able to log in and with the exception of the drive renaming, all was apparantly normal except for the inability to directly boot. I fixed the GRUB files (on the MD raid /boot) and verified I could boot either the 10.2 or the 10.3b2 OS and I could (from BIOS) boot either OS first and using the GRUB on that OS, choose which OS I wanted to boot. So, I can boot off of the IDE drive or the MD raid which now leaves me ready to test YaST2 - repair. Now, to answer your question. First, I backed up my 10.2 system /boot partition and re-ran the test from the install disk again and it broke the same way again but this time, KNOPPIX and a copy of the backup fixed things rapidly leaving how to show you what was happening. What I did was to go ahead and boot 10.3 and run "yast2 repair" as root so I could screen print the sesssion which I couldn't figure out how to do from the installation disk repair session. Thus, this truly is a YaST2 repair session running from a running, booted 10.3b2 MD raid installed system.
When yast2-repair detects more installation, it should offer you a selection for which one to check/repair. If it wasn't shown, it may be because the RAID-based systems are not fully supported by repair module
Which is precicely the object of this report. Like you, I am trying to help make SuSE the best product possible. Installation of the entire OS is documented as being possible as of 10.2 on a MD raid system by documentation on the web site (I'll get you the openSUSE URL if you don't have it but it isn't handy at the moment) and it does work as the 10.3b2 system will and does boot and run completely from the MD raid system (even with the IDE drive electrically disconnected). Given that the OS obviously does fully support running from a MD raid installation, the repair module should fully support that installation, which is the point of the report even though I had to 'cheat' to get the pictures of the failure, but I assure you it looked essentially the same when it was happening without the benefit of the KDE screen print functions. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.