Created attachment 661687 [details] anaconda error report... /tmp/anaconda-tb-PtS72e Description of problem: anaconda 18.36 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicelibs/swap.py", line 81, in swapon raise UnknownSwapError File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/swap.py", line 136, in setup swap.swapon(self.device, priority=self.priority) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2798, in turnOnSwap device.format.setup() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1638, in turnOnSwap upgrading=upgrading) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 190, in turnOnFilesystems storage.turnOnSwap() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 114, in doInstall turnOnFilesystems(storage) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run threading.Thread.run(self, *args, **kwargs) UnknownSwapError Version-Release number of selected component (if applicable): 18.36 How reproducible: Steps to Reproduce: 1. Installation target is a single disk. 2. New partitions defined for /boot and / from unused space. 3. Existing swap partition (previously formatted for 16K pages) Actual results: Exception described above. Expected results: Either the swap partition would be reformatted (if necessary) for the newly installed system, or the swap partition would be ignored. Additional info:
Created attachment 661689 [details] /tmp/anaconda.log
Created attachment 661690 [details] /tmp/storage.log
This is a little silly, I agree, but it's part of a check to prevent us from reformatting in-use suspend space as swap.
Check or not, it looks like a bug to see the installer crash with an unhandled exception simply because there is a swap space in use on the installation target disk. If the user includes a swap space as one of the designated "mount points" for the new system, why should this space not be formatted? How is this different from reuse of an existing space for the root mount point, which is always formatted? While I have not looked into the details, I believe it is possible to tell whether a swap space is nominally "in use". With a clean system shutdown, I expect swapoff will mark a swap space as "not in use". When a system boots, "swapon -a" will not use a swap space marked as "in use". Regardless of whether a swap space might appear to be "in use", I expect swapon will arrange for the current system to use it if this space is an explicit argument: the simple fact swapon is invoked for this particular space is understood to mean the user no longer cares about what previous data it may have held. In my case, the swap partition was formatted by mkswap before I started the F18 installation, but I believe it had never been used (wrong page size) by any operating system. Anaconda should be especially fussy about swap spaces... after all, if the new installation fails, it could be especially valuable for the user to be able simply to resume an older system that is suspended or hibernating in swap spaces. In this case (when anaconda cannot determine that a swap space is "not in use") the installer may ignore this swap space (anaconda will not format it) and the remainder of the installation can proceed. Anaconda could still include the swap space in its generated /etc/fstab, perhaps with the "noauto" option and a comment that mkswap was not used to format this space during system installation because the swap space appeared to be "in use". With several reasonable choices in view about what to do with swap spaces at the time of installation, it is bad for anaconda to simply die with a software error that aborts the installation process. Installation can and should continue. What to do about such swap spaces can be decided after the new system is booted.
Throwing an exception when the installer encounters a properly formatted swap space is inexcusable. The installer should display an informative error message and ask the user to reformat the swap space if appropriate. Richard: Your log files would be easier to read if they were MIME type plain/text instead of application/octet-stream. Unfortunanely, BZ doesn't seem to be able to recognize plain/text files ... Also, could you post the exact command you used to create the swap space? This bug report is incomplete without it.
(In reply to comment #5) > ... if they were MIME type plain/text ... text/plain
The swap space was created by the command: mkswap -p 16384 /dev/sdi1 The tmp/anaconda-tb-PtS72e file contains some binary data, therefore "application/octet-stream" does seem appropriate. I have changed the MIME type of the anaconda.log and storage.log files to "text/plain".
(In reply to comment #7) > The swap space was created by the command: > > mkswap -p 16384 /dev/sdi1 > > The tmp/anaconda-tb-PtS72e file contains some binary data, therefore > "application/octet-stream" does seem appropriate. I have changed the MIME > type of the anaconda.log and storage.log files to "text/plain". Thanks, Richard: Bug 886983 - binary data embedded in anaconda-tb
(In reply to comment #8) ... > Thanks, Richard: > Bug 886983 - binary data embedded in anaconda-tb That binary data appears to cause automated bug reporting to fail (Bug 886983, Comment 1). Did you first attempt to report this bug using the automated bug reporting dialog reading "An unknown error has occurred"?
Here is a detailed reproducer. Note that because of Bug 886983, automated bug reporting fails, however all of the log files are preserved in /tmp. Create an empty 12 GB disk image: $ qemu-img create f18-test-2.img 12G Start the F18 TC1 Live CD: $ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/TC1/Fedora-18-TC1-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse Complete a default install and quit the installer. From a terminal run: # swapoff -a # mkswap -p 16384 /dev/mapper/fedora-swap Restart the installer. From Manual Partitioning, reformat "/" and "/boot". Observe that the installer reuses the swap space without reformatting. Click Finish Partitioning. Click Begin Installation. The install fails at Creating ext4 on /dev/sda1 with: An unknown error has occurred UnknownSwapError The local variables after the traceback are truncated at "sig:". Click Report Bug. The exception reporting window disappears. No further windows are displayed. The installer Configuration pane remains shaded. No libreport processes are running.
For the record, the exception occurs here: http://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/storage/devicelibs/swap.py?h=f18-branch&id=anaconda-18.36-1#n81 The exception occurs when the installer is reenabling swap _for its own use_.
Created attachment 663224 [details] anaconda-tb-tt05jQ corresponding to the reproducer in Comment 10
This is a hexdump of the first 18 KiB of the swap space created with: # mkswap -p 16384 /dev/mapper/fedora-swap The attached log files show a swap space signature having all null bytes, but there is indeed a swap space signature there. That seems like a bug in its own right. $ cat swap-space-header-1.txt [root@localhost tmp]# dd if=/dev/mapper/fedora-swap count=18 bs=1024 2>/dev/null | hexdump -C 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 01 00 00 00 ff ef 03 00 00 00 00 00 0e 85 46 fb |..............F.| 00000410 e4 7a 47 5c 87 a5 cf 6f f1 51 ee 3b 00 00 00 00 |.zG\...o.Q.;....| 00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00003ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2| 00004000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000041e0 d8 c3 07 00 00 00 00 00 d8 c3 07 00 00 00 00 00 |................| 000041f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000043d0 68 29 06 00 00 00 00 00 68 29 06 00 00 00 00 00 |h)......h)......| 000043e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004670 90 5d 07 00 00 00 00 00 90 5d 07 00 00 00 00 00 |.].......]......| 00004680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000046f0 b8 2c 0a 00 00 00 00 00 b8 2c 0a 00 00 00 00 00 |.,.......,......| 00004700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004800
(In reply to comment #9) > (In reply to comment #8) > ... > > Thanks, Richard: > > Bug 886983 - binary data embedded in anaconda-tb > > That binary data appears to cause automated bug reporting to fail (Bug > 886983, Comment 1). Did you first attempt to report this bug using the > automated bug reporting dialog reading "An unknown error has occurred"? I did click to report the error, but I saw no indication the report was successful. I repeated the attempt to install F18 TC1, then switched to another console and copied files from /tmp to a USB flash drive in order to capture them for a manual bug report.
OK, thanks. Normally there are several dialogs, including ones to enter your BZ login info and to type in a bug comment. At the end of the process, there is a bug report progress window that shows whether your bug is new or a duplicate and what the bug report number is. Thanks for going to the extra trouble of reporting manually.