Description of problem: Many attempts to get the layout I wanted in Manual partitioning, followed by Reset All, followed by another attempt. Installation had begun, and then installer crashed while creating ext4 on /dev/sda6. Version-Release number of selected component: anaconda-20.18-1.fc20.x86_64 The following was filed automatically by anaconda: anaconda 20.18-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/formats/fs.py", line 779, in create raise FSError("filesystem already exists") File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 471, in execute options=self.device.formatArgs) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions action.execute() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 310, in doIt self.devicetree.processActions() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 169, in turnOnFilesystems storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 142, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall) File "/usr/lib64/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run threading.Thread.run(self, *args, **kwargs) FSError: filesystem already exists Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-Al ro rd.live.image quiet rhgb executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.0-300.fc20.x86_64 other involved packages: python-libs-2.7.5-7.fc20.x86_64, python-blivet-0.20-1.fc20.noarch product: Fedora release: Fedora release 20 (Heisenbug) type: anaconda version: 20
Created attachment 803445 [details] File: anaconda.log
Created attachment 803446 [details] File: environ
Created attachment 803447 [details] File: lsblk_output
Created attachment 803448 [details] File: nmcli_dev_list
Created attachment 803449 [details] File: os_info
Created attachment 803450 [details] File: program.log
Created attachment 803451 [details] File: ifcfg.log
Created attachment 803452 [details] File: anaconda-tb
Created attachment 803453 [details] File: storage.log
Really weird. Same layout and procedure I've been using for a week and I keep getting crashes now. I've even used wipefs -a on prior partitions, and removed them with gdisk so that I'm working in anaconda with only free space. cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-Al ro rd.live.image quiet rhgb hashmarkername: anaconda kernel: 3.11.0-300.fc20.x86_64 other involved packages: python-libs-2.7.5-7.fc20.x86_64, python-blivet-0.20-1.fc20.noarch package: anaconda-20.18-1.fc20.x86_64 packaging.log: product: Fedora reason: FSError: filesystem already exists release: Fedora release 20 (Heisenbug) version: 20
Created attachment 803460 [details] c10, anaconda-tb
Created attachment 803461 [details] c10, program.log
Created attachment 803462 [details] c10, anaconda.log
Created attachment 803464 [details] c10, storage.log
c10 attachments are logs for the crash reported in comment 10, which might be simpler to follow because I created the layout I wanted in a single shot without backtracking. The failure occurs while the GUI says it's creating ext4 on /dev/sda6, which seems wrong because /dev/sda6 is supposed to be btrfs. Proposing as F20 beta blocker: "When using the custom partitioning flow, the installer must be able to create mount points backed by ext4 partitions, LVM volumes or btrfs volumes and reject or disallow invalid disk and volume configurations without crashing."
The one thing I can thing of I'm doing differently today, is setting a hostname in the installer. But I don't see how that'd be related. I just tried doing (what I think is) exactly the same thing in c10, but with these updated versions applied, and did not get a crash. Install completes. anaconda-20.20-1.fc20.x86_64.rpm anaconda-widgets-20.20-1.fc20.x86_64.rpm btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc20.x86_64.rpm python-blivet-0.22-1.fc20.noarch.rpm
It'd be great to find that this has been accidentally fixed, but I need to add something to blivet to prevent scheduling of non-btrfs formatting on btrfs volumes. I just need to find the time to decide where and how to enforce it. The root cause of this bug is in the anaconda custom storage spoke, so don't reassign this bug to python-blivet until/unless we're certain the anaconda part is resolved.
Discussed this in the 2013-10-02 Blocker Review Meeting [1]. This has been voted an AcceptedBlocker. This violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" [2]. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-02/ [2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Custom_partitioning
I've been unable to reproduce this failure at all, nor can I see why it might have happened in the first place.
Neither can I now that source media has been replaced. It might be related to other weird behavior I had in another bug, the result of which seems to be USB media face planting after it had been working for several days, and even though it was passing multiple badblock -w tests. It's since been fired.
Discussed this in 2013-10-09 Blocker Review Meeting [1]. This bug has been fixed. Closing. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-09/
Created attachment 813870 [details] ABRT Screenshot. anaconda 20.25.1-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/formats/fs.py", line 779, in create raise FSError("filesystem already exists") File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 471, in execute options=self.device.formatArgs) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions action.execute() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 310, in doIt self.devicetree.processActions() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 169, in turnOnFilesystems storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 142, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall) File "/usr/lib64/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run threading.Thread.run(self, *args, **kwargs) FSError: filesystem already exists ABRT pointed to this bug-report, but it CLOSED, it did no more... I don't line current ABRT behaviour, at least put something on the bugreport. Attaching ABRT screenshot. I was able to rerproduce it, by deleting the guest and re-creating it and repeating the steps. I basically tried to install F20-bTC5, with manual partitioning (btrfs) with: /boot, 512mb EXT4 ; swap, 512mb ; and the rest for / on btrfs. I do have the logs, i will attach them if someone wants them.
I cannot re-open it. Per comment #18, it was an accepted blocker for alpha. Maybe this should be checked again.
Please post the reproduce steps exactly and also post as separate attachments anaconda, program, storage logs; and also attach a "journalctl -b > journalctl.txt" file. It's an accepted blocker for beta IF reproducible but for now it's closed because it's not reproducible.
Created attachment 813877 [details] anaconda-tb-*
Created attachment 813878 [details] anaconda.log
Created attachment 813879 [details] storage.log
Created attachment 813880 [details] program.log
Created attachment 813882 [details] syslog
Ok, the workaround is to enter Manual/Custom partitioning setting the scheme to 'standard' and switching the / to btrfs manually. I think this should be re-opened.
From 'anaconda.log' (both with partition scheme set to 'btrfs'): Guest #1: 17:47:06,495 INFO anaconda: fs space: 6.91 GB needed: 2.56 GB 17:47:06,499 INFO anaconda: spoke is ready: <pyanaconda.ui.gui.spokes.storage.StorageSpoke object at 0x7f22a33bf1d0> 17:47:08,223 INFO anaconda: Running Thread: AnaInstallThread (139786704557824) 17:47:09,505 INFO anaconda: Ajustando el entorno de instalación 17:47:09,791 INFO anaconda: Creando disklabel en /dev/vda 17:47:10,607 INFO anaconda: Creando ext4 en /dev/vda1 17:47:12,568 INFO anaconda: Creando swap en /dev/vda3 17:47:13,025 INFO anaconda: Creando btrfs en /dev/vda2 17:47:13,807 INFO anaconda: Creando btrfs en /dev/vda2 17:47:14,582 INFO anaconda: Creando ext4 en /dev/vda2 <<<<< Guest #2: 18:20:52,120 INFO anaconda: fs space: 34.81 GB needed: 2.56 GB 18:20:52,124 INFO anaconda: spoke is ready: <pyanaconda.ui.gui.spokes.storage.StorageSpoke object at 0x7f2cce5ae090> 18:20:54,493 INFO anaconda: Running Thread: AnaInstallThread (139830396888832) 18:20:55,503 INFO anaconda: Ajustando el entorno de instalación 18:20:55,750 INFO anaconda: Creando disklabel en /dev/vda 18:20:56,465 INFO anaconda: Creando ext4 en /dev/vda1 18:20:57,487 INFO anaconda: Creando swap en /dev/vda2 18:20:58,307 INFO anaconda: Creando btrfs en /dev/vda3 18:20:58,851 INFO anaconda: Creando btrfs en /dev/vda3 18:20:59,349 INFO anaconda: Creando ext4 en /dev/vda3 <<<<< 18:20:59,351 DEBUG anaconda: running handleException
But *what* steps are you referring to? Do you have discrete steps for reproducing this bug?
I don't understand how this can have been closed, it is practically impossible to get around this bug. I have just tried several times. Unfortunately my long explantion of hos to reproduce is now lost, as my bugreport was rejected as a duplicate of this one. Is it kept somewhere on disk? There is no back button in the anaconda bug reporter!
If you'd read the comments, you'd understand that it's closed because no one has posted steps so that anyone else can reproduce it.
Here are the most simple steps to reproduce it. 0. Boot Fedora 20b TC5 (no kernel parameter, either on a new guest or on an unpartitioned disk) 1. Reach the Welcome Hub (either use the default -English- or select your language -mine is Spanish-) 2. Leave defaults for Date & Time, Language Support, Keyboard, Installation Source, Software Selection, Network Configuration. 3. Enter Installation Destination Spoke. 4. The single disk is already selected. Press 'done' 5. On Installation Options Dialog, choose to do custom/manual partitioning ("I want to review...") and select 'btrfs' for the Partition Scheme, then 'Continue'. 6. Click '+' add '/boot' of '512' 7. Click '+' add 'swap' of '512' 9. Click '+' add '/' of <null>, anaconda will select the maximum size (as intended). 10. Press 'done' to return to the Main Hub. 11. Press 'Accept Changes' in 'Summary Of Changes' dialog. There it can be seen (among other entries): * Create Format btrfs vda3 * Create Device btrfs volume fedora * Create Format btrfs fedora * Create Device btrfs subvolume root <<< HERE * Create Format ext4 root <<< HERE 12. In the Main Hub, Start Installing, an 'unknown error' will popup.
Perfect, comment 35 is it. There's something about NOT doing it via guided partitioning, or using the "automatically partitiong" link in Manual Partitioning. When manually creating each of the partitions as described, I always trigger this crash. Reopening.
Created attachment 814368 [details] screencast reproducing the conditions of crash In the Summary of Changes you can clearly see item 20 is to create format ext4 on device root mountpoint / even though steps 16-19 just created a btrfs volume and root subvolume.
I put the wrong bug id in the commit message. This should be fixed in python-blivet-0.23.2-1.
Squishing confirmed, does not occur with beta TC6: python-blivet-0.23.2-1, anaconda-20.25.4-1.
python-blivet-0.23.2-1.fc20 went stable as part of FEDORA-2013-20033 and the fix was verified, so this can be closed.