This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 127064 - facility for dumping traceback to floppy doesn't work
facility for dumping traceback to floppy doesn't work
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
FC3
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-01 06:19 EDT by Barry K. Nathan
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-16 07:27:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Barry K. Nathan 2004-07-01 06:19:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7) Gecko/20040625

Description of problem:
When I attempted to dump a traceback (of bug 126904, FWIW) onto a
floppy, it doesn't work.

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

How reproducible:
Always

Steps to Reproduce:
1. Start a graphical install.
2. Proceed until bug 126904 causes a traceback.
3. Click "Save to floppy".
4. Put a blank MS-DOS formatted known-working floppy into the
computer's known-working floppy drive and click "OK".
    

Actual Results:  OK button turns dark, some disk activity but less
than expected, OK button turns light again, dialog box stays there,
and checking the floppy disk on another computer shows that the disk
is still blank. Putting the disk back in and hitting "OK" again does
not change the situation (more disk activity, but the dialog box still
doesn't go away and the disk still stays blank).

Expected Results:  OK button turns dark, traceback is dumped, dialog
box disappears, floppy disk contains traceback file.

Additional info:

Each time I attempt to dump a traceback, this line is added to VT 3:
* isys.py:mount()- going to mount /tmp/fd0 on /tmp/crash

and each time, these two lines are added to VT 4:
<4>Unable to load NLS charset cp437
<3>FAT: codepage cp437 not found

and each time, this line is added to VT 5:
mkdosfs 2.8 (28 Feb 2001)

I can't find any other log output, but maybe this will help...
Comment 1 Barry K. Nathan 2004-07-01 06:29:43 EDT
Some more info:

If I run either of the following two commands on VT2:

mount /dev/fd0 /tmp/crash
mount -t vfat /dev/fd0 /tmp/crash

there's some disk activity, then I get the following error:
mount: Mounting /dev/fd0 on /tmp/crash failed: Invalid argument

This is a rawhide snapshot with an rpmdb-fedora package with
"20040630" in the version number; hopefully that will tell you the
versions of all the other packages. The kernel is 2.6.7-1.459.
Comment 2 Jeremy Katz 2004-07-06 18:13:05 EDT
Asking arjan about building the cp437 module in, if not, then I'll add
the appropriate bits for anaconda to get it and grab it.
Comment 3 Barry K. Nathan 2004-07-10 08:11:57 EDT
FWIW, this bug still appears to be present as of anaconda-10.0.1-2 and
kernel-2.6.7-1.478. (Perhaps this is to be expected, but it may be
worth mentioning anyway.)
Comment 4 Jeremy Katz 2004-07-12 13:20:16 EDT
nls_ascii wasn't built in also.  Arjan's fixing and then that should
make things happy.
Comment 5 Barry K. Nathan 2004-07-16 07:27:06 EDT
I confirmed that this is fixed in fc-devel as of 20040714, and in the
process I confirmed that bug 122605 is still present -- that's what
I'm using to test this bug. ;)

Note You need to log in before you can comment on or make changes to this bug.