Red Hat Bugzilla – Bug 127064
facility for dumping traceback to floppy doesn't work
Last modified: 2007-11-30 17:10:45 EST
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...
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.
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.
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.)
nls_ascii wasn't built in also. Arjan's fixing and then that should make things happy.
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. ;)