Bug 127064

Summary:	facility for dumping traceback to floppy doesn't work
Product:	[Fedora] Fedora	Reporter:	Barry K. Nathan <barryn>
Component:	anaconda	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	barryn
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:	FC3
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-07-16 11:27:06 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:

Description Barry K. Nathan 2004-07-01 10:19:41 UTC

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 10:29:43 UTC

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 22:13:05 UTC

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 12:11:57 UTC

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 17:20:16 UTC

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 11:27:06 UTC

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