Bug 70012

Summary: unhandled exception on 2 occasions: with and without the patch for anaconda
Product: [Retired] Red Hat Linux Reporter: Serge Naggar <naggar>
Component: anacondaAssignee: Michael Fulbright <msf>
Status: CLOSED DUPLICATE QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: high    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-07-31 15:04:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
I think this dump was with the patch - there is a file without the patch none

Description Serge Naggar 2002-07-28 23:28:18 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.61 [en] (OS/2; U)

Description of problem:
Previously I had trouble installing a Raid1 7.3 and was sent a patch for anaconda 67778-I believe.
The system installed but deterirated to the point the gui was ne longer - I had put in a bugzilla report but never got a reply 69639.
I decided to re-install but without raid partitions: /boot-47mb; /-30gig; /xtr-20gig. there is also os2warp and dos primary and extended.
It takes hours as I want the hd checked for bad areas.
The first time I had automatically included the linux patches for anaconda and assumed that the problem was due to the fact that the patch had been 
given to me because of the raid1 partition I had been installing.
As I was no longer interested in raid [I think it is not stable] I tried to install without the patch. The result was similar.

I need urgent help as the linux system is down - I am coming to you on os2.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.install 7.3 
2.
3.
	

Actual Results:  never completes the hd checks for bad areas and the formatting

Expected Results:  an uneventful and stable 7.3 installation

Additional info:
Comment 1 Serge Naggar 2002-07-28 23:32:14 UTC 
Created attachment 67424 [details]
I think this dump was with the patch - there is a file without the patch
Comment 2 Brock Organ 2002-07-30 18:15:16 UTC 
Attached is the dump file generated without the `linux updates' from the bug
reporter.

Traceback (innermost last):
  File "/usr/bin/anaconda", line 633, in ?
    intf.run(id, dispatch, configFileData)
  File "/usr/lib/anaconda/gui.py", line 353, in run
    self.icw.run (self.runres, configFileData)
  File "/usr/lib/anaconda/gui.py", line 814, in run
    mainloop ()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 2676, in mainloop
    _gtk.gtk_main()
  File "/usr/lib/anaconda/gui.py", line 529, in handleRenderCallback
    self.currentWindow.renderCallback()
  File "/usr/lib/anaconda/iw/progress_gui.py", line 135, in renderCallback
    self.intf.icw.nextClicked()
  File "/usr/lib/anaconda/gui.py", line 417, in nextClicked
    self.dispatch.gotoNext()
  File "/usr/lib/anaconda/dispatch.py", line 144, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/dispatch.py", line 209, in moveStep
    rc = apply(func, self.bindArgs(args))
  File "/usr/lib/anaconda/packages.py", line 375, in turnOnFilesystems
    thefsset.checkBadblocks(instPath)
  File "/usr/lib/anaconda/fsset.py", line 1007, in checkBadblocks
    self.badblocksEntry(entry, chroot)
  File "/usr/lib/anaconda/fsset.py", line 984, in badblocksEntry
    entry.fsystem.badblocksDevice(entry, self.progressWindow, chroot)
  File "/usr/lib/anaconda/fsset.py", line 211, in badblocksDevice
    val = (long(l[0]) * 100) / long(l[1])
ValueError: invalid literal for long(): 5797544
  5797545

Local variables in innermost frame:
childpid: 95
devicePath: /tmp/hda8
w: <gui.ProgressWindow instance at 8a89940>
fd: 24
num: 5797544
  5797545/ 20482843
s: 
p: (27, 28)
l: ['5797544\012  5797545', ' 20482843']
args: ['/usr/sbin/badblocks', '-vv', '/tmp/hda8']
self: <fsset.ext3FileSystem instance at 8123078>
windowCreator: <method InstallInterface.progressWindow of InstallInterface
instance at 867e5c8>
val: 28L
chroot: /mnt/sysimage
entry: <fsset.FileSystemSetEntry instance at 8484840>
Comment 3 Serge Naggar 2002-07-31 15:04:25 UTC 
Please let me know what I can do to expedite matters.
Some comment would be appreciated.
Comment 4 Michael Fulbright 2002-08-02 16:25:34 UTC 
The bad blocks check encountered bad blocks - this can cause the installer to
crash because it does not handle that exception correctly.

Since bad blocks were encountered I'm not sure I'd use the drive.

*** This bug has been marked as a duplicate of 66181 ***