https://bugzilla.novell.com/show_bug.cgi?id=304657#c1 Matej Horvath changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |rccj@ricreig.com --- Comment #1 from Matej Horvath 2007-08-27 04:53:07 MST --- Could you please attach your yast logs (http://en.opensuse.org/Bugs/YaST) ? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c3 Richard Creighton changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|rccj@ricreig.com | --- Comment #3 from Richard Creighton 2007-08-27 05:50:05 MST --- 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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |snwint@novell.com -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657 Katarina Machalkova changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|yast2-maintainers@suse.de |jsuchome@novell.com -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c6 Richard Creighton changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|rccj@ricreig.com | --- Comment #6 from Richard Creighton 2007-08-29 02:18:08 MST ---

--- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c8 Jiří­ Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #8 from Jiří­ Suchomel 2007-08-29 02:55:08 MST --- 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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c10 --- Comment #10 from Richard Creighton 2007-08-29 06:43:25 MST --- (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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c12 Jiří­ Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |fehr@novell.com --- Comment #12 from Jiří­ Suchomel 2007-09-14 05:33:54 MST ---

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] -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c14 --- Comment #14 from Richard Creighton 2007-09-14 06:41:50 MST --- (In reply to comment #13 from Jiří­ Suchomel)

Created an attachment (id=164079) --> (https://bugzilla.novell.com/attachment.cgi?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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c18 Richard Creighton changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|fehr@novell.com | --- Comment #18 from Richard Creighton 2007-09-14 10:08:55 MST --- Created an attachment (id=164120) --> (https://bugzilla.novell.com/attachment.cgi?id=164120) 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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c20 Jiří­ Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |fehr@novell.com --- Comment #20 from Jiří­ Suchomel 2007-09-18 03:47:09 MST --- 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? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c22 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fehr@novell.com --- Comment #22 from Thomas Fehr 2007-09-18 04:23:52 MST --- 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". -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c24 --- Comment #24 from Jiří­ Suchomel 2007-09-18 06:08:21 MST --- Created an attachment (id=173056) --> (https://bugzilla.novell.com/attachment.cgi?id=173056) 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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c26 Richard Creighton changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|rccj@ricreig.com | --- Comment #26 from Richard Creighton 2007-09-18 07:44:37 MST --- Created an attachment (id=173078) --> (https://bugzilla.novell.com/attachment.cgi?id=173078) 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 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657#c28 --- Comment #28 from Richard Creighton 2007-09-18 09:46:56 MST --- (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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657 User jsuchome@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=304657#c30 Jiří­ Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |rccj@ricreig.com --- Comment #30 from Jiří­ Suchomel 2008-04-29 05:22:06 MST --- 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... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657 User jsuchome@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=304657#c32 --- Comment #32 from Jiří­ Suchomel 2008-04-30 07:10:30 MST --- 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. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657 User jsuchome@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=304657#c34 --- Comment #34 from Jiří­ Suchomel 2008-04-30 07:36:25 MST --- No, it doesn't have sense without the raid setup. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=304657 User jsuchome@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=304657#c36 Jiří­ Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |rccj@ricreig.com --- Comment #36 from Jiří­ Suchomel 2008-05-12 08:05:49 MST --- 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/no... 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". -- 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.