Bugzilla – Bug 304657
Yast2 repair doesn't check or repair system installed on MD Raid
Last modified: 2008-05-15 08:37:46 UTC
Created attachment 159847 [details] Folder containing several supporting files and screenshots I installed Beta 2 on a MDRaid system in its entirety IAW the HowTo on the OpenSUSE.org website starting with Alpha 5. Upgrading to Beta 2, I wanted to verify the installation so I tried the INSTALLATION REPAIR on the CD. It tried to repair everything EXCEPT the installed beta 2 system. I had a 10.2 system on a IDE drive that it went after and it ignored the MD partitions but tried to mount the drives making up the MD array. It also tried to modify the 10.2 GRUB and FSTAB. I rebooted the 10.3 and ran yast2-repair which did the same thing and I was able to document what it looked like as an attachment. I am attaching my partition tables (note the 10.2 drive was NOT mounted) the fstab of the running 10.3 system, the 10.3 grub files and various screen shots of the 'repair' sequence showing that it initially knew about the fact that the md0,1,2,3 partitions existed and were mounted and the sda partitions were not yet wnen it started doing fsck tests, it started doing it on the wrong drives including the drives associated with the wrong OS version, not the 10.3 version on the MD raid partitions. The first time this happened, I did it in 'auto' and it 'fixed' everything "real good". I spent several days unfixing it. It ruined a perfecly good 10.2 installation. For this test I skipped or refused all repairs but the repair program WILL NOT allow an ABORY which I consider another bug.
Could you please attach your yast logs (http://en.opensuse.org/Bugs/YaST) ?
Created attachment 159952 [details] YaST2 v10.2 log files erroneously written to by 10.3 repair program
The logs from the 10.3 system are long gone but they were of no use anyway as they were never changed by the repair program. As it turns out, the repair program made all the changes to the unmounted IDE drive on the 10.2 system drive that was NOT supposed to be tested and was not mounted. I was able to salvage the YaST2 logs from that drive and they are in the attachment above. If you take a look at the end of the log entries you will note that it never looked at the file system on the MD raid but was doing everything on the 10.2 filesystem which was NOT what was being tested, or which was not what was SUPPOSED to be being tested. IF there is more than one valid Linux filesystem on a computer, the repair program should not only scan for and detect that fact, but it should offer which one the operator which one to be validated rather than just grabbing the first one it finds. It did warn that the FS it found wasn't the correct version, that should have been a clue for it to keep looking. It did note (look at the screen shot) that there was a MD raid system) and should have tested it for a file system and finding one for a vaiid Linux file structure for testing.
Created attachment 159973 [details] Yast2 directory files of MDRaid Drive complete from functioning 10.3 install This is from the MDRaid drive I was attemting to verify when the Yast2-repair program wrote everything to the unmounted 10.2 system IDE drive damaging it's GRUB and appending/overwriting the Yast2.log files previously attached.
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. 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. 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.
> > --- Comment #5 from JiřàSuchomel <jsuchome@novell.com> 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.
> 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 I overlooked the first part of your statement in my last reply. Yes, if it finds more than one valid (damaged or otherwise) installation, it should offer a choice of which one it should try to repair regardless of the media upon which it is installed, and it did not do this which I hope the screen shots conveyed.
Well, it is true that "Repair" is able to some nasty things to your system, which is the dark side of the fact that it is (at least in most and common cases) able to repair it. And I understand your frustration after the broken repair, but there is no other option than asking user to confirm possible dangerous action. However, I still think that at least bootloader configuration should be quite easy to restore: if you'd boot installation CD of 10.3, you could select Repair just there (I think at the Installation Mode screen), and once repair module is loaded, in Expert settings it is possible to run bootloader configuration which should be able to propose the correct setting. Expert settings also allow calling partitioner module, and maybe it would be possible to recover your system from that point, but I'm not sure if it would be enough. > 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 Yes, there's obvious logic in this requirement, but in fact, repair module is regarded as a helper for common situation instead of tool able to fix everything done in installation. I'll try to look into the logs and see what can be done.
I forgot to finish the sentence in comment 5: The correct way is to run it from media; before you finish it and reboot, you need to switch to text console, and save the logs to e.g. usb stick or copy them over the network (they are in the ramdisk at that time).
(In reply to comment #8 from Jiri Suchomel) > Well, it is true that "Repair" is able to some nasty things to your system, > which is the dark side of the fact that it is (at least in most and common > cases) able to repair it. And I understand your frustration after the broken > repair, but there is no other option than asking user to confirm possible > dangerous action. > > However, I still think that at least bootloader configuration should be quite > easy to restore: if you'd boot installation CD of 10.3, you could select Repair > just there (I think at the Installation Mode screen), and once repair module is > loaded, in Expert settings it is possible to run bootloader configuration which > should be able to propose the correct setting. Expert settings also allow > calling partitioner module, and maybe it would be possible to recover your > system from that point, but I'm not sure if it would be enough. Yes, I agree, however in this case I was never presented with that option. I was initially notified that there was my 10.2 drive (which it correctly identified as not mounted) and it discovered the MD0 to MD3 drives as well which can be seen on one of the screen shots but does not mention file systems or offerss of repair options. It directly goes into FSCK of the raw devices and never does a FSCK or other check of the MD raid devices. During the FSCK of the devices comprising the MDx devices, it reports many errors, yet it 'knew' the type was part of a raid and should not have run the test in the first place so that is one bug right there. The second bug is it did NOT detect the 2nd FS,and immediately went to work on the only one it did find which was the 10.2 FS and not the desired 10.3 FS on the MD raid device. So not only did it not offer to work on the correct FS, it apparantly did not even scan for it or detect it even though it is obvious it knew the raid device existed because it presented the info in the screenshot. > > > 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 > > Yes, there's obvious logic in this requirement, but in fact, repair module is > regarded as a helper for common situation instead of tool able to fix > everything done in installation. > > I'll try to look into the logs and see what can be done. > I really appreciate the work you are doing. The repair function is primarily for those that are inexperienced and their systems are malfunctioning and they need help and when it makes things worse, it makes SuSE look bad as a product. I have been supporting Linux since almost it was first released and truly want it to succeed and provide an alternative to MS, but until the average non technical person can safely expect 'REPAIR' to do just that on the install disk of their chosen distribution, I am afraid Linux/SuSE will remain a 3rd world wannabe and that is a shame that I am working to overcome.
Created attachment 162838 [details] Additional Beta 3 documentation of this problem This document is in support of the contents of the folder contained in BadUpdate which is compressed and attached. There are 4 screen shots and 3 log files, 2 from the 10.3 B3 system and 1 from the 10.2 system which was NOT booted nor mounted and should not have been affected by the 10.3 Beta 3 installation DVD. Initially I received an UPDATE message from the system updater which included a kernel patch and a number of programs. I was instructed to reboot, which I did and during the boot, I noticed ''BadUpdate.jpg' on my screen which prompted me to explore the repair system on the Beta 3 DVD. "BadRepair1.png" is a screenshot which looked similar to the one I saw when I booted from the DVD and went into the installation, chose 'other' 'repair installed system' and found it obviously wrong. I took screenshots but it does not save them on disk, but apparently in ram so not knowing that, they were lost. I re-ran the program from within Beta-3 as root by typing 'yast2 repair' and got the same screens as before and got the screenshot 'BadRepair1.png'. This screenshot is VERY interesting because it shows that it knew about MD1 and MD3 but immediately it also shows that it intended to do file system checks on sda1 and sdb2 among others which are NOT part of the installed Beta 3 system if you will refer to the PartTbl10.3.png. Those devices are part of the 10.2 file system shown also in Partn10.2.png. I chose to NOT allow it to 'repair' the so called defective partitions it found. It never did check or offer to check the /dev/mdx where x=0 1 2 and 3 which would have contained a valid 10.3 beta 3 file system as indicated in the partition table image and which was acknowledged initially by the repair program. If I had allowed the repair of the sdxn partitions, it would have ruined the 10.2 file system AND the MD raid array containing the valid 10.3 beta 3 installation. This type of installation is documented on your website and works well so the "repair" should do that, not destroy the installation as well as the original installation which happes to be an earlier version of SuSe. I believe the mixture of IDE and SATA equipment is the trigger based upon my experience and reading many other bug reports in bugzilla with a common theme. I have included Y2log-0 which is from the 10.3B3 system. It may show why the original error occurred but not why the mixup with the repair system occurs. That honor is reserved for the file recovered from the y2log10.2 obtained from the 10.2 system which was NOT supposed to be written to by the 10.3 installation DVD or the 10.3 yast2 raair program.
> Initially I received an UPDATE ... If you want to report any other problem than this one about repair, file a separate bug. > I took screenshots but it does not save them on disk, but apparently in ram so > notknowing that, they were lost. See comment 9 about how to save the logfiles or screenshot from that session. > This screenshot is VERY interesting because it > shows that it knew about MD1 and MD3 but immediately it also shows that it > intended to do file system checks on sda1 and sdb2 among others which are NOT > part of the installed Beta 3 system if you will refer to the PartTbl10.3.png. > Those devices are part of the 10.2 file system shown also in Partn10.2.png. How is that possible? PartTbl10.3.png shows that sdb1 is used by md1, sdb2 by md0 etc. Thomas: Storage::GetTargetMap reports that /dev/sdb2 in devices list of /dev/md0: $["chunk_size":32, "detected_fs":`swap, "device":"/dev/md0", "devices":["/dev/sdb2", "/dev/ sdc2"], "fstopt":"defaults", "fstype":"MD Raid", "label":"swap", "mount":"swap", "mountby":`label, "name":"md0", "nr":0, "raid_type":"raid0", "size_k":2104320, "type":`sw_raid, "used_fs":`swap]
Created attachment 164079 [details] patch for /usr/share/YaST2/modules/OSRFstab.ycp Richard, here is my first attempt: use this patch on /usr/share/YaST2/modules/OSRFstab.ycp and run 'ycpc -c /usr/share/YaST2/modules/OSRFstab.ycp'. Than run 'yast2 repair' and attach the log files from your "check session" (I do not advise you to do any repairs, but I hope you would not need them anyway)
(In reply to comment #13 from Jiří Suchomel) > Created an attachment (id=164079) [details] > patch for /usr/share/YaST2/modules/OSRFstab.ycp > > Richard, here is my first attempt: use this patch on > /usr/share/YaST2/modules/OSRFstab.ycp and run 'ycpc -c > /usr/share/YaST2/modules/OSRFstab.ycp'. Than run 'yast2 repair' and attach the > log files from your "check session" (I do not advise you to do any repairs, > but I hope you would not need them anyway) > Since we last 'spoke', I totally reinstalled 10.2 on that DMraid machine then ran 10.3 upgrade from the B3 DVD so the environment has changed somewhat, but the upgrade still failed but I was afraid to try the repair because last time it almost ruined my 10.2 system on my IDE drive. This machine has 9 drives 4 of which are only accessable by a raid controller that as yet won't run with kernels past 2.6.18. I had thought that drive safe previously (and under 10.2 it had been) but with the SATA/IDE rename thing in 10.3, everything has been subject to damage including the MBR of that supposedly immune IDE drive. Now, I am willing to risk it again now that I know I *can* recover but I am NOT a programmer so I am not real sure how to apply the patch you have provided. Im I correct in assuming that there is a program available to me as root called 'ycpc' that I can run and use the patch as an argument? Then re-run yast2 repair an capture the log file for you. If that is correct, I will be happy to oblige. Sorry for my stupidity...I am 64 years old and play with Linux but am not a serious system programmer and I respect you that are.
I do not ask you to risk anything: just test the scanning, no repairing. And I am only speaking about 10.3, not 10.2. Note that this patch is not intended to make it work, it is just one minor step (hopefully forward). Apply the patch with the call (as root) "patch < OSRFstab.diff" (where OSRFstab.diff is the attached patch) in /usr/share/YaST2/modules directory. Than call another command "ycpc -c /usr/share/YaST2/modules/OSRFstab.ycp". Of course, there's no stupidity in not knowing that, I should have been more clear.
Comment on attachment 164079 [details] patch for /usr/share/YaST2/modules/OSRFstab.ycp >Index: OSRFstab.ycp >=================================================================== >--- OSRFstab.ycp (revision 40176) >+++ OSRFstab.ycp (working copy) >@@ -267,6 +267,17 @@ > linux_partition_list = add (linux_partition_list, > partition["device"]:""); > } >+ else if (partition["type"]:`primary == `sw_raid) >+ { >+ boolean checked = true; >+ foreach (string d, partition["devices"]:[], { >+ if (!contains (checked_partitions, d)) >+ checked = false; >+ }); >+ if (checked) >+ linux_partition_list = add (linux_partition_list, >+ partition["device"]:""); >+ } > } > else > {
Sorry...#16 was my mistake...trying to download the patch. I copied it cut and paste and used vi to create it. I'll try to do the rest as you instructed and get back with you. I know how to upload to you, just not download from you. :(
Created attachment 164120 [details] Document the test of the patch I hope this helps. I am more than willing to try to apply patches in the future but there must be a better way than cut and paste to get the patch from there to here, but I couldn't figure out how to download the patch file other than to display it and cut/paste it into vi and save it. That may have induced the error that shows up in the documentation of the patch I am inclosing. Anyway, I really appreciate the effort you are expending. I believe this affects not only MD raid, but anyone with IDE and SATA systems which means a lot of people upgrading systems that want to keep their old IDE drives intact and install / upgrade to the newer SATA devices. If you solve this, you probably will solve a lot of headaches.
(In reply to comment #12 from Jiri Suchomel) > > This screenshot is VERY interesting because it > > shows that it knew about MD1 and MD3 but immediately it also shows that it > > intended to do file system checks on sda1 and sdb2 among others which are NOT > > part of the installed Beta 3 system if you will refer to the PartTbl10.3.png. > > Those devices are part of the 10.2 file system shown also in Partn10.2.png. > > How is that possible? PartTbl10.3.png shows that sdb1 is used by md1, sdb2 by > md0 etc. Thomas: Storage::GetTargetMap reports that /dev/sdb2 in devices list > of /dev/md0: > It took me a bit to understand the question, sorry. SDAx is part of the IDE drive which is part of the 10.2 system which should not be being subject to the repair/test. SDB to SDE are part of MD0 to MD3 which contain the actual filesystems. The SDB-E are only partition/disks which themselves do not contain a filesystem of anykind and should not have fsck run against them as it will always fail. The partition table clearly states that these devices are part of MDRaid devices and not regular EXT2/3 or FAT or other normal type of file systems that can be checked by some variant of FSCK. Thus, the attempt to run fsck /dev/sdbN I feel is part of the problem as there certainly would be nothing to repair. Anything repairable would be withing the filesystem contained in MD1 or 2 for instance, and that was never checked at any time, nor was it offerd to be checked. If I understand your question, that is what I was trying to point out by the comment #12 above.
Richard, was yout test attempt with the patch different to the previous ones without the patch? Were more/less partitions checked or reported as broken? Thomas, could you help me with deciding (according the values from Storage::GetTargetMap etc.) what should yast2-repair check and what should be ignored?
(In reply to comment #20 from Jiří Suchomel) > Richard, was yout test attempt with the patch different to the previous ones > without the patch? Were more/less partitions checked or reported as broken? > I submitted the logs from the test in #18, but in a word, It still tested the raw devices and not the MD arrays the devices were part of. My sense was 'same'. Something (not your patch) caused the installation to destruct (after an update) and resulted in having to completely reinstall B3 which I did by starting again as a functioning 10.2 system and doing an update install of B3 (which still failed) which did go more smoothly despite the failure. I can see the effects of all the work because most of the install came from FACTORY. GRUB still got grunged, repair still doesn't (this bug), repair wants to 'fix' a perfectly good IDE 10.2 installation (which I have now removed for protection) but overall I can see progress and I want you to know it is appreciated. Short answer: No effect because of patch noted
To comment #10: That depends on what exactly yast2-repair checks? As far as I understand yast2-repair only checks real disk partitions. These are part of entries on target map with "type" : `CT_DISK. So you should ignore all entries of target map with other type entries. Currently there are eight different types: CT_DISK - normal disk drives CT_MD - software raid CT_LVM - LVM volume groups CT_EVMS - EVMS container CT_LOOP - file based loop devices CT_DM - device mapper devices CT_CMRAID - dmraid disks CT_NFS - NFS mount points The types CT_MD, CT_DM, CT_LOOP and CT_NFS may exist at most once in any target map, others may be there multiple times. Generally, all partitions and disks that have the keys "used_by_type" and "used_by" set are part of other entities (e.g. lvm, md, evms, dmraid) and it does not make much sense to check them by yast2-repair even if they seem to contain valid filesystems (this may be the case for raid1 setups where the underlying partitions containvalid filesystem signatures). Furthermore all partitons with a entry for "detected_fs" like `unknown do not make much sense with checking since they do not seem to contain a filesystem yast2-storage knows about. For example in the above case /dev/sdb2 should have "used_by_type" : `CT_MD and "used_by" : "md0".
RE#22 Looking at the screenshots (and logs) however, it is apparant that part of the problem is that repair *is* executing fsck on drives marked as part of MD raid arrays, which if allowed to 'fix' them, would damage data contained on those drives. This is part of the problem. I routinely fsck /dev/mdN as part of maintenance efforts. I can see no real reason given that repair can identify (and did) the MD arrays and file systems, why it chose to fsck the raw device rather than the filesystem the devices held. Regardless, it should exclude the devices part of MD, DM LVM ... etc special purpose devices from fsck scans IMO. I thought repair checked file *systems* or structures, not the drives, eg, badblock tests etc.
Created attachment 173056 [details] patch for /usr/share/YaST2/modules/OSRFsck.ycp Richard, try this patch for your /usr/share/YaST2/modules/OSRFsck.ycp. You can download the patch simply by clicking on the link "Created an attachment..." in this comment. Save the link into OSRFsck.diff file, go to /usr/share/YaST2/modules and call 'patch < OSRFsck.diff' and 'ycpc -c OSRFsck.ycp' Run the 'yast2 repair' (if you don't accept any repair proposals, it won't do anything to your system, just do the scanning) and attach new yast2 logfiles.
BTW, there's during the scan for partitions, it is not important if there is some different version of system installed on them. The content is not touched at all - and you could of course run repair on 10.3 to repair partitions of 10.2. But again, the patch from previous comment should actually prevent testing on partitions without `CT_DISK type. If it still reports some of your partition as broken, just ignore it, don't try to repair it.
Created attachment 173078 [details] Document patch operation as requested This attachment consists of 4 screenshots, a commentary about each shot as to why I included it and what I saw that I felt was important. Included also was a "y2log" of the session. This log was 'clean' in that I zeroed it out just before typing yast2 repair and it runs until the program exited. I hope this helps Richard
Thanks much for a test and a report! (Also the idea of clearing y2log was nice) I'll try to do more, but unfortunately I do not expect having real fix for this issue ready for 10.3, as it is close to release and I have some more important tasks :-( But I hope it could get better in next version.
(In reply to comment #27 from Jiri Suchomel) > Thanks much for a test and a report! (Also the idea of clearing y2log was nice) > > I'll try to do more, but unfortunately I do not expect having real fix for this > issue ready for 10.3, as it is close to release and I have some more important > tasks :-( But I hope it could get better in next version. > My pleasure. Apparently we have a fan club. I have received several E-Mail from several countries from people with MD raid installs that have wanted a solution for quite some time. I was one of the original authors of QuickBBS before the internet got going so I understand what it is to have to troubleshoot remotely and the value of a good report. What you are doing exceeds by far what programming I used to do but I haven't forgotten deadlines and pressures of release dates. Technology has moved so fast that I feel like I'm moving backwards :) Remember the goal is to make Linux work for the average person. It needs to be smart so they don't have to be. This repair module is one of the most important tools on the whole DVD, IMNSHO, not just for MD RAID, but for all users.
Created attachment 179119 [details] Current state of Yast repair module This is from an otherwise fully functional GM 10.3 installation of SuSE. It is using the latest *released* kernel 2.6.22.9-0.4-bigsmp and finally has both the MD raid and the hardware raid controller from RocketRaid rr174x.ko fully functional. This gives the machine 2.5TB of pure raid. Due to the IDE/SATA bug, the IDE drive is still off-line, so the troubleshooting efforts are purely directed at getting the repair program to recognize and repair the system as installed on MD raid or other LVM type installations which according to my E-Mails, are becoming quite common with the larger drives and raid controllers built-in to the MBds. I feel the repair program is a first line of defense for the non-technical user and it needs to work. As you can see from the enclosures, the only thing that does work is that the repair program detects the partitions on the drives and their types and it recognizes the fact that there are MD raids in use. It then proceeds to try to fsck the raw devices rather than the file systems they contain. I believe this is an error in logic. FSCK should be checking the LOGICAL devices detected, and only checking the physical device when the logical and physical are one and the same, ie, don't check devices that have LVM's or MD or other non raw type file structures. You wouldn't check and try to repair NTFS. You might check it in some way but you aren't in the business of trying to repair the drive it lives on unless the user says to reformat the device as a part of the repair, and then that is another issue entirely. Let's get back to work on this, OK? Richard
Hi Richard, could you please try to install Beta1 of openSUSE11.0, do the scanning of your disks and attach the fresh YaST logfiles? Do not try to repair anything, I haven't had time to work on the detection, so I expect the state will be very similar to the current one. But I'm requesting logs as a starting point of my work based on openSUSE 11...
(In reply to comment #30 from Jiri Suchomel) > Hi Richard, > could you please try to install Beta1 of openSUSE11.0, do the scanning of your > disks and attach the fresh YaST logfiles? > > Do not try to repair anything, I haven't had time to work on the detection, so > I expect the state will be very similar to the current one. But I'm requesting > logs as a starting point of my work based on openSUSE 11... > Hi, It will be a few days before I can set up a machine to do this. The machine I was using before is now a production machine. As I know you are interested in the repair functions in a MD RAID environment, I will have to set up a machine to do this again. In the FWIW dept., I have been unable to do a Beta1 install from the DVD (yes, the DVD verifies) but I can sucessfully UPGRADE from FACTORY, just not by the DVD. When the upgrade is complete, I seem to have a B1 installation, albeit, not on a RAID machine, but on otherwise the same motherboard and memory, etc. Would it help to run the repair function on that machine until I can upgrade it to a MD raid configuration? Again, for the moment, I am unable to do an INSTALL or UPGRADE from the DVD, only from factory over the internet via YAST. Richard
Well, I thought it would be easier for you. Now I think it would be better for you not to put time into this and wait until I have available at least somehow improved version.
(In reply to comment #32 from Jiří Suchomel) > Well, I thought it would be easier for you. > Now I think it would be better for you not to put time into this and wait until > I have available at least somehow improved version. > I really think this is one of the more important bugs to squash. If a Windoze convert has a problem and tries to 'repair' something and it boogers it worse, OpenSuSE will really get a bad reputation quick. I can't let that happen because it is difficult or inconvenient or time consuming and I am retired and other than a heap of doctor appointments, I have little else to do so other than going out and getting a few disk drives and configuring them as a raid array in the new machine, I am happy to work with you. All I need to know is if a baseline repair log on this machine would be useful to you or not even without the raid configuration setup yet? I do intend to invest whatever time it takes to help you make this work. It is one of the more important bugs facing OpenSuSE, IMNSOHO. (In My Not So Humble Opinion) :)
No, it doesn't have sense without the raid setup.
(In reply to comment #34 from Jiří Suchomel) > No, it doesn't have sense without the raid setup. > I will try to have it set up sometime this weekend. I have catarat surgery scheduled but I think that won't interfere. I'll get back to you in a few days when I have it set up. That will also give you some time to work on the code on your end. With luck, by early next week, I will have the drives installed and a MD raid working on that machine. It will be B1 with about 1TB of RAID 5 Software raid MD raid, similar to the setup I used to have and will use the identical motherboard, bios and memory. I liked that machine, so I duplicated it except for the raid :)
Beta1 and probably nor beta2 will have the latest yast2-repair: try installing the latest one from http://download.opensuse.org/repositories/home:/jsuchome/openSUSE_Factory/noarch/ It has the "support" for RAIDs you probably won't like very much: it should be able to detect the relevant partitions and skip their check and repair. Well, it is not as good as being able to repair broken ones, but it is much better than offering a possibility to break them by "repairing".
Well, I consider this bug being fixed now (if you test it, check you have yast2-repair-2.16.10 or newer). If there would be a strong wish for a full support to repair RAID partitions, we should create official feature and go through the correct feature process.