https://bugzilla.novell.com/show_bug.cgi?id=788224 https://bugzilla.novell.com/show_bug.cgi?id=788224#c Thomas Schmidt <tschmidt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |Final Component|openFATE |Bootloader AssignedTo|tschmidt@suse.com |jsrain@suse.com QAContact|roland.haidl@suse.com |jsrain@suse.com Product|openSUSE.org |openSUSE 12.2 -- 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=788224 https://bugzilla.novell.com/show_bug.cgi?id=788224#c2 Scott Couston <secure@aphofis.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|CLOSED |REOPENED CC| |monkey9@iae.nl, | |secure@aphofis.com Component|Bootloader |Installation Found By|--- |System Test AssignedTo|jsrain@suse.com |bnc-team-screening@forge.pr | |ovo.novell.com Resolution|WONTFIX | Summary|Bring back the repair |Bring Back the Repair |options inside the |Options Inside the |installation on the install |Installation on a New |media. |Install! Severity|Enhancement |Major OS/Version|SUSE Other |openSUSE 12.2 --- Comment #2 from Scott Couston <secure@aphofis.com> 2013-05-26 17:17:09 EST --- Sorry Jiri I am going to come in and join Robby about the Repair Option with the Installation Program. What we are both trying to say is that we dont want another heading on the Installation boot program and we dont want to change one thing about the Rescue System Option that no one really knows how and what is does. During the New Install and when we got to the selection of either Gnome, KDE and Other Desktop, one of the 'other' selection was repair existing installation. It is here when we selected Other we saw the option to REPAIRING the existing Installation. Its probably still in Yast 2 text based. This Repair option offered two (from Memory) type tools. An automatic repair process which checked the validity of the Volume descriptors, Root Partition, Active Partition and and HDD that fell off the partitioning description files. It also provided an automatic option to fix and mount point or remove a whole HDD drive in the case of complete failure and then rewrite the complete boot loader information. The Manual Repair Process gave the ability to use which of the above tools we run manually. All in all the Module probably needs NO maintenance as it give gives us The Partitioner. Tools for checking the drives which were non-mounted at this point in time. Tools for examining the HDD's surface ananysis. Tools to change the boot loaded after we repaired the mount points that had fallen away by, say a defective sector on the physical HDD. Tools for checking all the RAM registers over night. Tools for testing non destructive as well as destructive HDD Analysis read/write/read an upon an invalid re-read the block was marked as bad and a new sector was created containing the original read and first read. Tools for re-writing of the boot loader files. Repair gave us a Graphic representation for loading the O/S Kernel and other services; having all current mount points no yet mounted and the tools to correct the volume descriptors etc. I think its still there sitting and whats the worse going to happen if we put it back and it fails to repair. All of us are under no illusion that repair tools are sometimes well out of the scope of fixing everything. I still believe that every new install wound run a comp-serve over all of the HDD's before formatting them - what what would a user know...:-) Robby I hope this is o.k with you mate -- 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=788224 https://bugzilla.novell.com/show_bug.cgi?id=788224#c4 --- Comment #4 from Scott Couston <secure@aphofis.com> 2013-05-27 12:20:55 EST --- (In reply to comment #3)

Well, as Jiri said: Amaintainer is needed. Every new system is different from the previous, so the modules won't trigger the right files. Has to completely be renewed. Nobody does that. That is the problem here. But if you can get someone to do it, i am fine with it, because i think it is absolutely a better option compared with the other OS.

I hear you Robby and agree. Most problems can often be solved by just doing an update using the same versions. There are places in doing this to re-write the boot loader to a new location if that mount point can no longer be mounted. HDD failure over time seem so acceptable and are treated so casually now a days. Sometime not even formatting a new volume cannot find defective areas and mark them bad and continue. ?If I had USD100.00 for ever time a new format failed to validate the integrity of volume and continue on; I would be rich. The most valuable part of the repair option was to be able to access tools where all volumes were not mounted or could be dismounted fully, I think are worthy of reinstating... Some of the other peripheral tools in the code can easily be left out as no one is going to sit through a program to test every register of the RAM. RAM is so cheap a resource these days that we can afford to just simply replace the lot of suspected defective RAM Modules. Lets see if Jiri and other's can find both a maintainer and justify the retention of manhours to retain some of the old code - Personally I dont think it is possible but I would like to think that one day we can justify reinstating and testing the old repair code or part there of.. Sorry Jiri, you got the job of re-closure and I dont envy the often difficult task of closure as cant fix... -- 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=788224 https://bugzilla.novell.com/show_bug.cgi?id=788224#c6 --- Comment #6 from Scott Couston <secure@aphofis.com> 2013-05-29 17:39:44 EST --- I understand Jiri, I could happily rewrite the whole of yast and fix up bits that dont work or parts of things that have fallen off and make sure all the Network Services all functioned. I could only do it in Assembler - You see I am a Dynastor and with the code we would need a VM to sit the code on! But it would be the fastest thing on earth but near impossible to find a text editor to hold so much open before compiling:-) ;_) Being so far away if we dont ask, we dont know what is possible or not...thats why I wanted a new reason code to close a report as 'Cant Fix' - 'Resources Not Available' We could the get better stats on reporting to financial stakeholders that clearly shows the need for more manpower. I was a little disappointed that the suggestion was so quickly dismissed. Gee! find a serious bug in gnome and its fixed in 48 hours no matter what, however you first need the courage to create the Bug report. Thanks to all - No Contest! :-) -- 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=788224 https://bugzilla.novell.com/show_bug.cgi?id=788224#c8 --- Comment #8 from Scott Couston <secure@aphofis.com> 2013-08-01 18:59:11 EST --- Its a bit hard when I live half a world away and am at GMT+10...Its not really conducive to working with cooperation me being down here in .AU. If you dont want me to find constructive, non petty bugs I suggest you close off each version from new fault access if your man power cannot clearly support it. Dont shoot the messenger when you have a management problem -- 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.