Bug 1166598 - going back to installation destination picker swaps partitions on disks
Summary: going back to installation destination picker swaps partitions on disks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 22
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:402fec84f3c73861261419db5c1...
: 1158911 1201207 (view as bug list)
Depends On:
Blocks: F22FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2014-11-21 10:26 UTC by Marian Csontos
Modified: 2021-10-21 10:20 UTC (History)
21 users (show)

Fixed In Version: anaconda-22.20.11-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of: 1158533
Environment:
Last Closed: 2015-05-03 17:23:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
bug demonstration video (1.74 MB, application/ogg)
2014-12-03 18:08 UTC, Kamil Páral
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1158911 0 unspecified CLOSED FormatDestroyError: error wiping old signatures from /dev/sda2: 1 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1170153 0 unspecified CLOSED anaconda gets stuck during creating a partition, when there is some existing partition after that one 2021-02-22 00:41:40 UTC

Internal Links: 1158911 1170153

Description Marian Csontos 2014-11-21 10:26:57 UTC
Going through disk selection spoke multiple times selecting and deselecting disk to use may lead to partition names swapped.

1. As the disk selection is very brief displaying only disk's size without any hints what's on each of those disks user may need to go through the spoke multiple times

2. If installer allows the workflow, it should be supposed fine.

3. There is a high risk of removing partition which was supposed to be kept.

Either going through the disk selection multiple times should be forbidden or the partition names should be correct.
And no, documenting it in known issues is not enough.

IMHO a clear blocker. // Criteria: Violent psychopath losing data.

I have heavilly edited the comments below...

+++ This bug was initially created as a clone of Bug #1158533 +++

--- Additional comment from Petr Schindler on 2014-10-30 04:43:36 EDT ---

Version-Release number of selected component:
anaconda-core-21.48.13-1.fc21.x86_64

I run installation. Only thing I did is: I chose both my disk for installation (with delete all) and then I changed my mind and went to installation destination again but this time I chose just one disk (with delete all). Then I started installation. This bug apeared during formating (I think).

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:UUID=5982-5591 rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 nomodeset BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.17.1-302.fc21.x86_64
other involved packages: python-blivet-0.61.8-1.fc21.noarch, python-libs-2.7.8-4.1.fc21.x86_64
package:        anaconda-core-21.48.13-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         LVMError: lvactivate failed for swap: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/fedora_dhcp-29-208$|","r|/sdb1$|","r|/sdb$|"] }  fedora_dhcp-28-114/swap failed
release:        Fedora release 21 (Twenty One)
version:        Fedora

--- Additional comment from Petr Schindler on 2014-10-30 05:34:45 EDT ---

So, here is what's going on on my computer.

I have two disks: On the first one there is the default installation of Fedora 21. sda1 is /boot and sda2 is LVM with root and swap.
On the second disk there is one LVM which is there from old installation of Fedora (original installation was on two disks with one big LVM. Then the new installation took place on the first disk and second disk was untouched by that).

When I go to installation destination for the first time I choose both disks and in reclaim space I click on delete all and confirm. There seems to be everything alright in reclaim space dialog (see first attached picture). Then when I change my mind I go to installation destination again. This time I choose only first disk and second one I leave unchecked. The reclaim space dialog is opened again, but this time there is one error. sda1 and sda2 are swapped. Anaconda shows that there is lvm on sda1 and /boot on sda2 (see second attached screenshot). After I click on delete all, confirm and I start the installation it fails.

--- From the original BZ ---

The stacktrace still applies:

> The following was filed automatically by anaconda:
> anaconda 21.48.13-1 exception report
> Traceback (most recent call first):
>   File "/usr/lib/python2.7/site-packages/blivet/devicelibs/lvm.py", line 532, in lvactivate
>     raise LVMError("lvactivate failed for %s: %s" % (lv_name, msg))
>   File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 3086, in _setup
>     lvm.lvactivate(self.vg.name, self._name)
>   File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 856, in setup
>     self._setup(orig=orig)
>   File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 642, in execute
>     self.device.setup(orig=True)
>   File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 361, in processActions
>     action.execute(callbacks)
>   File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 364, in doIt
>     self.devicetree.processActions(callbacks)
>   File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 216, in turnOnFilesystems
>     storage.doIt(callbacks)
>   File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 190, in doInstall
>     turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg)
>   File "/usr/lib64/python2.7/threading.py", line 766, in run
>     self.__target(*self.__args, **self.__kwargs)
>   File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run
>     threading.Thread.run(self, *args, **kwargs)
> LVMError: lvactivate failed for home: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/sda1$|","r|/sda2$|","r|/sda3$|","r|/sda$|","r|/sdc1$|","r|/sdc2$|","r|/sdc$|"] }  fedora/home failed

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-LXDE-x86_64-21_Beta- rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.17.1-302.fc21.x86_64
other involved packages: python-blivet-0.61.8-1.fc21.noarch, python-libs-2.7.8-4.1.fc21.x86_64
product:        Fedora"
release:        Fedora release 21 (Twenty One)
type:           anaconda
version:        Fedora

--- Additional comment from Petr Schindler on 2014-10-30 05:39:24 EDT ---

I propose this as beta blocker as it violates the criterion: "When using the guided partitioning flow, the installer must be able to:
* Complete an installation using any combination of disk configuration options it allows the user to select 
* Remove existing storage volumes to free up space, at the user's direction"

--- Additional comment from Fedora Blocker Bugs Application on 2014-10-29 11:12:24 EDT ---

Proposed as a Freeze Exception for 21-final by Fedora user satellit using the blocker tracking app because:

 The installer must be able to complete an installation using all supported interfaces 
anaconda 21.48.13-1

--- Additional comment from Petr Schindler on 2014-10-30 06:26:59 EDT ---

I tested this with another computer with two disks. And I wasn't able to reproduce this bug. The difference seems to be that on the pc where this bug happens is gpt table on /dev/sda but there is mbr on the second pc's /dev/sda.

--- Additional comment from Petr Schindler on 2014-10-30 10:03:03 EDT ---

I reproduced this using virtual machine with two disks (both with mbr). Both have to be full so reclaim space dialog is used.

See https://pschindl.fedorapeople.org/bug1158533.ogv - mention the layout of the first disk during first and second reclaim space.

--- Additional comment from Jan Sedlák on 2014-10-30 10:17:03 EDT ---

Another user experienced a similar problem:

Tried to install Fedora on system with two disks, each with two partitions. Selected both disks to install, selected "delete all" in reclaim dialog, changed my mind, unselected second disk, "delete all" in reclaim dialog and run installation.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-21_B-x86_64 quiet
hashmarkername: anaconda
kernel:         3.17.1-302.fc21.x86_64
package:        anaconda-21.48.13-1
product:        Fedora"
reason:         LVMError: lvactivate failed for root: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/vda1$|","r|/vda2$|","r|/vda$|"] }  fedora-server/root failed
release:        Cannot get release name.
version:        Fedora

--- Additional comment from Adam Williamson (Red Hat) on 2014-10-30 11:56:04 EDT ---

It would be very useful to know if anyone can reproduce this without the 'change my mind and do it differently' bit, My inclination is to vote -1 blocker on a bug which involves running through the spoke multiple times and changing your mind, at this point.

--- Additional comment from Kamil Páral on 2014-10-30 12:50:49 EDT ---

AFAIK, it always involved running through the spoke multiple times. None of us reproduced in just a single pass.

--- Additional comment from Adam Williamson (Red Hat) on 2014-10-30 13:41:40 EDT ---

Discussed at 2014-10-30 Go/No-Go meeting: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-10-30/f21_beta_gono-go_meeting.2014-10-30-17.00.log.txt . Rejected as a blocker on the basis that the clear reproducer we have for this involves multiple runs through the spoke - we generally don't consider that kind of thing to block Beta, especially when it's a last-minute discovery (tending to indicate it's not very commonly encountered).

--- Additional comment from Kamil Páral on 2014-11-03 09:31:22 EST ---

(In reply to Adam Williamson (Red Hat) from comment #28)
> satellit said his case did not involve multiple runs, for the record.
> kparal, do you have the logs from your reproducers?

Petr Schindler already appended those in comments 21 - 24. Do you need anything else?

Re-proposing as Final blocker.

--- Additional comment from Kamil Páral on 2014-11-05 11:44:40 EST ---

Discussed at 2014-11-05 blocker review meeting [1]. Accepted as a blocker. This bug violates the beta criterion "Complete an installation using any combination of disk configuration options it allows the user to select" in the case you change your mind.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-05/

--- Additional comment from Jan Sedlák on 2014-11-20 09:08:37 EST ---

Another user experienced a similar problem:

Tried to reproduce bug 1158533 with one disk. Had one disk with two partitions - /boot (vda1) and / (vda2). Went to partitioning spoke, selected that disk for installation, clicked done, clicked "delete all" on reclaim space dialog. Then went to partitioning spoke again, unselected that disk and clicked "done". Finally, went to partitioning spoke again, selected that disk again and clicked "done". In reclaim space dialog, both partitions had swapped names (/boot was vda2 and / was vda1). When I started installation, this showed up.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-21_T2-x86_64 quiet
hashmarkername: anaconda
kernel:         3.17.2-300.fc21.x86_64
package:        anaconda-21.48.14-1
product:        Fedora"
reason:         LVMError: lvactivate failed for root: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] }  fedora-server/root failed
release:        Cannot get release name.
version:        Fedora

--- Additional comment from Jan Sedlák on 2014-11-20 09:22:07 EST ---

Another thing is that it seems that to reproduce this bug, LVM should be valid. I have booted same machine again, I have same partitioning on it, but parted doesn't display first partition as "/boot" and second partition as LVM. If I try select-unselect-select combo, partitions are again swapped in reclaim space dialog, but installation proceeds without problem.

--- Additional comment from Jan Sedlák on 2014-11-20 09:40:53 EST ---

(In reply to Marian Csontos from comment #32)
> Anaconda allows you to select one disk from VG spanning over multiple PVs
> which will cause all kind of troubles - e.g. duplicate VG names and other.

I don't know if there are more bugs that has caused this, but I had only one PV but this still happened to me.

Forgot to mention: vda1 was normal partition (with ext4 I think) and vda2 was LVM partition (showed actually as "fedora-server", not "/" in reclaim space dialog).

--- Additional comment from Marian Csontos on 2014-11-20 11:05:23 EST ---

I am not sure anaconda manipulates lvm.conf in any way, but I see lot of lines like this in lvm2 commands' output:

    13:59:54,504 INFO program:   WARNING: Ignoring duplicate config node: global (seeking global/metadata_read_only)

Could you submit /etc/lvm/lvm.conf please?

Looking further this looks intersting:

08:00:32,915 INFO program: Running... lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] }  fedora-server/root
08:00:32,999 INFO program:   Volume group "fedora-server" not found
08:00:33,000 INFO program:   Skipping volume group fedora-server

I wonder what exactly is wipefs erasing LVM's PV doing here?

08:00:32,616 INFO program: Running... wipefs -f -a /dev/vda2
08:00:32,732 INFO program: /dev/vda2: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31
08:00:32,733 DEBUG program: Return code: 0

Oh! It is trying to destroy /boot which is actually on /dev/vda1! BINGO Jan, you nailed it, except it is different bug than the original reported, but the same Petr Schindler reported.

Comment 1 Marian Csontos 2014-11-21 14:09:00 UTC
"Cloning" relevant attachments:

(In reply to Petr Schindler from comment #16)
> Created attachment 952037 [details]
> reclaim space dialog when opened for the first time

(In reply to Petr Schindler from comment #17)
> Created attachment 952039 [details]
> reclaim space dialog when opened for the second time with just first disk

(In reply to Petr Schindler from comment #21)
> Created attachment 952142 [details]
> anaconda.log

(In reply to Petr Schindler from comment #22)
> Created attachment 952143 [details]
> traceback

(In reply to Petr Schindler from comment #23)
> Created attachment 952146 [details]
> program.log

(In reply to Petr Schindler from comment #24)
> Created attachment 952147 [details]
> storage.log

Comment 2 Marian Csontos 2014-11-21 14:12:19 UTC
And the other reporter's files:

(In reply to Jan Sedlák from bug 1158533, comment 35)
> Created attachment 959379 [details]
> anaconda traceback

(In reply to Jan Sedlák from bug 1158533, comment 36)
> Created attachment 959380 [details]
> storage.log

Comment 3 Marian Csontos 2014-11-21 14:34:47 UTC
It reverts disks too - it is visible in the Bug 1158911:

attachment 952119 [details]
File: lsblk_output

attachment 952122 [details]
File: program.log

attachment 952123 [details]
File: storage.log

There is no /dev/sda2 in lsblk_output but there are two partitions on /dev/vda.

Comment 4 Marian Csontos 2014-11-22 16:19:33 UTC
*** Bug 1158911 has been marked as a duplicate of this bug. ***

Comment 5 Vratislav Podzimek 2014-11-26 10:36:40 UTC
I managed to identify the core of the problem and I'm now working on a patch for pyparted and blivet to fix this issue. The patches should be ready in an hour or two.

Comment 6 Kamil Páral 2014-11-26 13:40:18 UTC
Vratislav, if you can produce an updates.img for TC4, we can test it right away. Thanks.

Comment 7 Vratislav Podzimek 2014-11-26 14:20:11 UTC
(In reply to Kamil Páral from comment #6)
> Vratislav, if you can produce an updates.img for TC4, we can test it right
> away. Thanks.
http://vpodzime.fedorapeople.org/1166598_updates.img

(hopefully I didn't leave any debugging lines in it)

Comment 8 Fedora Update System 2014-11-26 20:47:16 UTC
anaconda-21.48.17-1.fc21, python-blivet-0.61.11-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/python-blivet-0.61.11-1.fc21,anaconda-21.48.17-1.fc21

Comment 9 Jan Sedlák 2014-11-27 09:54:43 UTC
Ok, tried updates.img from comment 5 and it works now. Disks have correct labels in reclaim space dialog and installation completes without error.

Comment 10 Kamil Páral 2014-11-27 12:43:33 UTC
I tried with https://vpodzime.fedorapeople.org/ultimate_f21_updates.img and the problem is fixed. I used this reproducer:

> Had one disk with two partitions - /boot (vda1) and / (vda2). Went to 
> partitioning spoke, selected that disk for installation, clicked done, clicked 
> "delete all" on reclaim space dialog. Then went to partitioning spoke again, 
> unselected that disk and clicked "done". Finally, went to partitioning spoke 
> again, selected that disk again and clicked "done". In reclaim space dialog, 
> both partitions had swapped names (/boot was vda2 and / was vda1). When I 
> started installation, the exception showed up.

There's still one small glitch, though. After you open the storage screen for the third time (after you unselected the disk and want to select it again), its label says its completely free ("10 GiB free") even though it's completely full.

Comment 11 Fedora Update System 2014-11-27 19:29:01 UTC
Package anaconda-21.48.17-1.fc21, python-blivet-0.61.11-1.fc21, pyparted-3.10.2-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-21.48.17-1.fc21 python-blivet-0.61.11-1.fc21 pyparted-3.10.2-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15910/pyparted-3.10.2-1.fc21,python-blivet-0.61.11-1.fc21,anaconda-21.48.17-1.fc21
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2014-11-29 20:59:24 UTC
Package pyparted-3.10.2-1.fc21, python-blivet-0.61.12-1.fc21, anaconda-21.48.18-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pyparted-3.10.2-1.fc21 python-blivet-0.61.12-1.fc21 anaconda-21.48.18-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15910/pyparted-3.10.2-1.fc21,python-blivet-0.61.12-1.fc21,anaconda-21.48.18-1.fc21
then log in and leave karma (feedback).

Comment 13 Kamil Páral 2014-12-01 11:18:51 UTC
This works well in RC1.

Comment 14 Kamil Páral 2014-12-03 14:32:28 UTC
Just a note (because we're discussing it right now), this bug in new in F21 and hasn't been present in F20. We might need this information during today's blocker bug meeting.

Comment 15 Kamil Páral 2014-12-03 16:54:42 UTC
(In reply to Kamil Páral from comment #14)
> Just a note (because we're discussing it right now), this bug in new in F21
> and hasn't been present in F20. We might need this information during
> today's blocker bug meeting.

Correction, I can't hit this with the single disk use case in F20, but it can be hit using multiple disks use case in F20.

Comment 16 Adam Williamson 2014-12-03 17:51:52 UTC
For the record, I can't reproduce this as described with the c#10 reproducer. Following those steps I see the partitions the wrong way round in the reclaim space dialog - sda2 is the first entry on the list, sda1 is the second - but all the information matches up: sda1's mount point is /boot and its size is 500MB, sda2's mount point is / and its size is XXGiB.

Comment 17 Mike Ruckman 2014-12-03 18:02:43 UTC
Discussed in 2014-12-03 blocker review meeting. We're reverting this bugs blocker status: The provided fix for this bug caused a larger issue. At this point in the release it's better to revert and document the problem clearly. Repropose this as a F22 Alpha blocker to get a fix early in the next release.

Comment 18 Kamil Páral 2014-12-03 18:08:45 UTC
Created attachment 964267 [details]
bug demonstration video

To illustrate the problem, this is reproduced with TC4.

Comment 19 Adam Williamson 2014-12-03 18:58:18 UTC
OK, we figured out the difference in cases. Refined reproducer:

1. Start with a single existing disk with a 500MB ext4 /boot partition as its first partition (Xda1) and the rest of the disk occupied by an LVM VG (Xda2) - an easy way to do this is to do a stock Fedora installation.
2. Boot Fedora 21 Final TC4 installer.
3. Go to Installation Destination, leave the disk selected as the install target, click Done.
4. On the Installation Options popup, click 'Reclaim space'.
5. On the RECLAIM DISK SPACE screen, click 'Delete all', click 'Reclaim space'.
6. Go to Installation Destination (second time), click the disk to unselect it, and click Done.
7. Go to Installation Destination (third time), leave the disk selected, and click Done.
8. On the Installation Options popup, click 'Reclaim space'.

The bug should now be reproduced on the RECLAIM DISK SPACE screen: the 500MB /boot partition will be listed as 'Xda2' and the LVM VG as 'Xda1'.

Setting back to ASSIGNED as the fix for this is being reverted.

Comment 20 Kamil Páral 2014-12-04 12:30:38 UTC
Confirmed that this bug is present in RC5.

Comment 21 Adam Williamson 2014-12-04 12:37:52 UTC
kparal: you can test with https://dlehman.fedorapeople.org/updates/updates-1166598.1.img I guess - dlehman posted it for me today. It seems to resolve the bug, for me. It's against TC4, though.

Comment 22 Kamil Páral 2014-12-04 15:09:24 UTC
(In reply to Adam Williamson (Red Hat) from comment #21)
> kparal: you can test with
> https://dlehman.fedorapeople.org/updates/updates-1166598.1.img I guess -
> dlehman posted it for me today. It seems to resolve the bug, for me. It's
> against TC4, though.

It still swaps the lines (vda2 shows before vda1), but it does not mix them up (vda2 is still vda2, not in fact vda1). So in the use case from comment 19 it's an improvement. Tested with TC4.

Comment 23 Petr Schindler 2015-01-07 17:14:30 UTC
Discussed at today's blocker review meeting [1]. Agreed to delay decision on this. It's not clear where this bug or the fix currently stands. Punting until we have more information.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-01-07/

Comment 24 Adam Williamson 2015-01-12 16:33:37 UTC
Discussed at 2015-01-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-01-12/f22-blocker-review.2015-01-12-16.06.log.txt . Accepted as a Beta blocker as a conditional violation of criterion https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Guided_partitioning - "When using the guided partitioning flow, the installer must be able to: ... Complete an installation using any combination of disk configuration options it allows the user to select" - in the case described.

Comment 25 Mohit Tokas 2015-01-13 20:43:33 UTC
Another user experienced a similar problem:

I was installing fedora on my system, set fedora to reclaim all the space on a disk and clicked next. Then this error appeared when i click on set root password on the next screen.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-blivet-0.61.13-1.fc21.noarch, python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         FormatDestroyError: error wiping old signatures from /dev/sdb2: 1
release:        Fedora release 21 (Twenty One)
version:        Fedora

Comment 26 Tadej Janež 2015-01-27 12:52:02 UTC
Another user experienced a similar problem:

I was setting partitioning and used the option to "Delete all" existing partitions and after clicking Next, Anaconda crashed.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-blivet-0.61.13-1.fc21.noarch, python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         FormatDestroyError: error wiping old signatures from /dev/sda1: 1
release:        Fedora release 21 (Twenty One)
version:        Fedora

Comment 27 cedric.lecocq 2015-02-07 12:02:45 UTC
Another user experienced a similar problem:

Incident causé lors de l'installation de Fedora sur le disque dur.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-blivet-0.61.13-1.fc21.noarch, python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         FormatDestroyError: error wiping old signatures from /dev/sdb2: 1
release:        Fedora release 21 (Twenty One)
version:        Fedora

Comment 28 Adam Williamson 2015-03-10 04:07:37 UTC
Has someone checked the current status of this with 22?

Comment 29 Lukas Brabec 2015-03-12 10:30:17 UTC
Not sure if this is the same, but I tried to reproduce this and ended with new bug 1201207

Comment 30 Lukas Brabec 2015-03-12 12:20:06 UTC
*** Bug 1201207 has been marked as a duplicate of this bug. ***

Comment 31 Lukas Brabec 2015-03-12 12:21:52 UTC
Bumping to F22

Comment 32 Petr Schindler 2015-03-13 12:34:29 UTC
I just tried it and it's still there. It's the same as in 21. (Tested with Beta TC1)

Comment 33 Vratislav Podzimek 2015-03-31 17:10:43 UTC
So.... I discussed this issue with other members of the team and we agreed on the fact that the nice solution of really fixing action cancelling and override partitions numbers from blivet would very likely cause some more severe issues just like all the previous attempts did. Thus we would like to do a bit uglier, but still not completely bad change that should make this work as expected. However, it's not clear that we will make it in time to fix it for Beta. It would be great if this could be moved to Final as a blocker instead of beta.

Comment 34 Jaroslav Reznik 2015-04-02 12:28:42 UTC
As Beta is getting closer, I'm ok with moving this to final if it will be fixed early in the final release phase. And have it as freeze exception in case we would slip Beta and it will be ready for inclusion.

Comment 35 Adam Williamson 2015-04-06 23:33:15 UTC
I forgot to drop the AcceptedBlocker from this so it would come up for review at the meeting this morning - sorry. I'm OK with punting at least to Final for this, it's sufficiently uncommon to be OK with just documentation for Beta.

Any other votes?

Comment 36 Kamil Páral 2015-04-07 08:33:32 UTC
+1 for moving to Final

Comment 37 Petr Schindler 2015-04-07 08:36:12 UTC
+1 for Final too.

Comment 38 Adam Williamson 2015-04-07 15:14:03 UTC
That's five votes for moving to Final, let's do it.

Comment 39 Vratislav Podzimek 2015-04-16 11:35:18 UTC
https://github.com/rhinstaller/anaconda/pull/74

Comment 40 Vratislav Podzimek 2015-04-16 11:43:42 UTC
updates.img containing the potential fix:
http://vpodzime.fedorapeople.org/1166598_updates.img (for anaconda-22.20.9-1 [Beta RC3])

Comment 41 Lukas Brabec 2015-04-17 11:33:00 UTC
(In reply to Vratislav Podzimek from comment #40)
> updates.img containing the potential fix:
> http://vpodzime.fedorapeople.org/1166598_updates.img (for anaconda-22.20.9-1
> [Beta RC3])

this fixed the bug for me

Comment 42 Fedora Update System 2015-04-27 17:51:41 UTC
anaconda-22.20.11-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/anaconda-22.20.11-1.fc22

Comment 43 Fedora Update System 2015-04-28 12:59:50 UTC
Package anaconda-22.20.11-1.fc22, libblockdev-0.12-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-22.20.11-1.fc22 libblockdev-0.12-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7011/libblockdev-0.12-1.fc22,anaconda-22.20.11-1.fc22
then log in and leave karma (feedback).

Comment 44 Fedora Update System 2015-05-03 17:23:36 UTC
anaconda-22.20.11-1.fc22, libblockdev-0.12-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 45 Kamil Páral 2015-05-22 13:09:48 UTC
Verified fixed in F22 RC3.

Comment 46 Akriti Verma 2021-10-21 10:20:17 UTC Comment hidden (spam)

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