What partition layout did you define?

dcantrell:
this might be dupe of 491722.

All,
I carved the drive for an installation of Fedora 11(rawhide) on one LVM and created a second LVM for another Linux installation
The partition scheme was as follows:

Device		MountPoint/RAID/Volume	Type	Format	sizeMB	Start	End ▫LVMVolumeGroups
▫VG_
   swap				        swap		
   root				        ext3		
 ▫VG_Fedora						
   swapFedora				swap		
   rootFedora				ext4		
▫HardDrives
 ▫/dev/sda
   /dev/sda1	/boot			ext3
   /dev/sda2	/bootOther		ext3		
   /dev/sda3    VG_Fedora		LVM PV		
   ▫/dev/sda4				Extended	
    /dev/sda5	VG_		        LVM PV		


-PaulB

*** Bug 491887 has been marked as a duplicate of this bug. ***

*** Bug 493481 has been marked as a duplicate of this bug. ***

*** Bug 491722 has been marked as a duplicate of this bug. ***

I think this problem has been fixed as of pyparted-2.0.10.  I've tried to recreate the problem locally with two different set ups and it's not happening for me.

Created attachment 340407 [details]
Attached traceback automatically from anaconda.

I'm still seeing this on an IBM power5 system using anaconda-11.5.0.47

*** Bug 500723 has been marked as a duplicate of this bug. ***

*** Bug 496660 has been marked as a duplicate of this bug. ***

This issue has been documented at https://fedoraproject.org/wiki/Common_F11_bugs#491754

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I am seeing this on an upgrade from (fully updated) F10 to F11, using preupgrade. I'm not modifying the partition layout at all (unless anaconda has decided to do that without asking).

The 'Common Bugs' page suggests that if I follow exactly the same steps again, it will succeed. But I've now tried it three times, and it's failed every time.

This is on an HP Compaq nx7400 laptop. If more details would be helpful, please let me know what details, and I'll be happy to oblige.

Created attachment 347329 [details]
Expection Occured by anaconda

This what the anaconda said would be helpful for bug reporting
Please fix this error fast..

This is on Dell Inspiron 1420, contact me if more info needed...but please fix this fast...

The same error on Asus M50SV, BUT it does not happen on the same laptop if I choose to install root on external USB drive... May be this information will help to locate problem.

Rather surprised that this has priority of 'low' when it is stopping people installing!

I suspect that's because of the claim that trying a second time resolves the issue (see Common Bugs page).

Unfortunately that doesn't seem to be true. I suggest that the priority tag be changed to 'high', and that the Common Bugs page be changed to reflect the fact that this isn't (always) resolved by trying again.

Hello,

for me this is also a show-stopper. BTW: I got the same
error message, but without any possibility to save
the anaconda exception. However, I saved the complete
/tmp directory manually and added a screenshot of the 
final screen with the notorious "Exit the installer."

The anaconda does not seem to be able to deal with
LVM volumes where the underlying physical devices are
SATA disks.

So, actually, these are 3 bugs:

1. The deeper reason for why the device setup failed.
2. A possibility to save the error output (and some logfiles) is missing.
3. In a situation where no creation of a partition, 
   no formatting and no resizing was needed, the installer
   has no business in committing anything to any disk whatsoever.
   It should have simply left it untouched.  Only /etc/fstab
   must be written. Nothing else.  So a condition where the
   above error message can occur, should be not even be
   theoretically possible.

Bye, bye

Juergen

(now trying to add that attachment...)

Created attachment 347824 [details]
bzip2 compressed archive of /tmp/ as it could be found when I failed with installing fc11 because of "Cannot commit to disk...".


Please note, that I did NOT get the usual anaconda exception backtraces.

(In reply to comment #18)
> Rather surprised that this has priority of 'low' when it is stopping people
> installing!

Priority is mostly a no-op in Fedora Bugzilla at present. Most components do not use it for anything, so it stays at the default value for most bugs (low).

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

No exception for me, just anaconda window:

An error was encountered while setting up device /dev/sda
cannot commit to disk after 5 attempts

bootloader --location=mbr --driveorder=sda,sda
clearpart --linux --drives=sda
part /boot --size=100
part swap --recommended
part / --size=9000 --grow

Disk is 500GB.  There is a second 250GB /dev/sdb with a single linux partition.

Rebooted and re-attemped with:

bootloader --location=mbr --driveorder=sda

Then get:

Could not allocate requested partitions: not enough free space on disks.

Then cleared out /dev/sda of all partitions and it could install.

*** Bug 507541 has been marked as a duplicate of this bug. ***

I had this issue when doing fresh install of Fedora-11-i386 from DVD onto 73GB SCSI disk. First, I made a mistake of specifying ext4 for / filesystem (custom layout). gparted on the installation media does not seem to 'know' what ext4 is, so partitioning fails. I tried to install with everything ext3 and it failed again - now it was because partition sizes were reported as 4GB only (seems to be a python script bug). Finally I created all partitions (/ as ext3 and swap only, no /boot)manually from command line before partitioning in Anaconda GUI and it seemed to work fine.

There is a patch in rawhide for this issue now.  Since there have been so many comments added to this bug, I am asking for anyone seeing this problem in rawhide after anaconda-12.2-1.fc12 is built to please file NEW bugs with details about your specific use case.

Commit regarding this issue:
f765384437f273d3685b8e05abf448c1dc4499e5

David,

$ git show f765384437f273d3685b8e05abf448c1dc4499e5
fatal: bad object f765384437f273d3685b8e05abf448c1dc4499e5

And Fedora CVS has only anaconda-12.1-1.fc12 in devel/.

Is the commit only in some private repository so far?

This bug is featured in https://fedoraproject.org/wiki/Common_F11_bugs . Is there going to be an updates.img available for F11?

My mistake, here's the commit:

http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=60ff94ed3fade0716086deeb99892bf1c5103e62

12.2-1.fc12 will be the next build of anaconda for rawhide.  Yes, 12.1 is the latest in the tree.  The next build we do of anaconda will include this fix.

And yes, I can make an updates.img for this fix and update the F-11 common bugs page.

Updated the Fedora 11 common bugs wiki page:

https://fedoraproject.org/wiki/Common_F11_bugs#491754

Created attachment 351052 [details]
anaconda-logs.tgz (w/ 491754.img)

While testing http://dcantrel.fedorapeople.org/491754.img, I encountered this failure on a power5 ppc64 system that originally exhibited this failure.  I have attached '/tmp/*log*' to this bugzilla.  The system is online now at the time of the failure.  Please let me know if additional information is needed.

Thanks!

Reopening, based on comment#30

Created attachment 351055 [details]
Patch to disable boot flag modification for upgrade

I found problem using tracing from commit place to where it is called. I dont much understand in what cases boot flag should be modified or what was meant by it. Maybe it should be negated (if there is no bootable entry for partition, create one), maybe it does apply only for new installations. It worked for me. There is present also some debugging and delay, they are not important.

Created attachment 351056 [details]
My updates file that helped me to upgrade

My file created with patch above.

Created attachment 351059 [details]
Storage log with stack trace to problem origin

I used this log to figure out where commit is done. At first i thought i will add some time to drive and it will fix it. Then i realized it is modifying partition table that is beeing used, and cannot handle immediate reload will fail.

Comment on attachment 351059 [details]
Storage log with stack trace to problem origin

posted wrong file, sorry

Created attachment 351066 [details]
Storage.log with backtrace

"An updates.img file is available to work around the defect. This image is provided through the Fedora project space of David Cantrell, one of the Anaconda maintainers."

I tested the updates.img for installing with my notebook. Lenevo TSI Y430. It failed still.

Please fix the bug as soon as possible. Thanks.

(In reply to comment #33)
> Created an attachment (id=351056) [details]
> My updates file that helped me to upgrade
> 
> My file created with patch above.  

I used the patch that you provided for us. it also failed. I upgrade from Fedora 10 t0 11 with Fedora 11 DVD disk.

Since no one read comment #25, could people please at least provide details on the installer failing on your system?  I need reproducers in order to actually work the problem for your case.

(In reply to comment #39)
> Since no one read comment #25, could people please at least provide details on
> the installer failing on your system?  I need reproducers in order to actually
> work the problem for your case.  

I have managed to reproduce the problem on a F-11/ppc system using the update image (http://dcantrel.fedorapeople.org/491754.img).

The steps I used to recreate:

1) Install F-10 using default partition layout

    autopart
    # Partition clearing information
    clearpart --all --initlabel 

2) Install F-11 with updates=http://dcantrel.fedorapeople.org/491754.img on the same system with the same physical disks being used in the transaction

    # Partition clearing information
    clearpart --all --initlabel 
    # Disk partitioning information
    part prepboot --fstype="PPC PReP Boot" --size=8
    part /boot --asprimary --fstype="ext3" --size=200 --label=BOOT
    part swap --fstype="swap" --recommended --label=SWAP
    part /multi-stage --fstype="ext3" --size=100 --label=MULTISTAGE
    part pv.01 --grow --maxsize=3072 --size=1536
    part pv.02 --grow --maxsize=3072 --size=1536
    volgroup SNAKEVG --pesize=32768 pv.01 pv.02
    logvol /  --fstype="ext3" --grow --maxsize=10240 --size=2048 --name=SNAKEROOT --vgname=SNAKEVG
    logvol swap  --fstype="swap" --recommended --name=SNAKE_SWAP --vgname=SNAKEVG
    logvol /SNAKE-LV0  --fstype="ext3" --grow --maxsize=1024 --size=1024 --name=SNAKELV0 --vgname=SNAKEVG

The system is available for remote debugging if needed.

(In reply to comment #38)
> (In reply to comment #33)
> > Created an attachment (id=351056) [details] [details]
> > My updates file that helped me to upgrade
> > 
> > My file created with patch above.  
> 
> I used the patch that you provided for us. it also failed. I upgrade from
> Fedora 10 t0 11 with Fedora 11 DVD disk.  

If you tried my patch, please post somewhere your /tmp/storage.log. I put backtrace to commit failure, it might help locate where is commit called from. I updated with F11 x64 DVD and worked for me. I do not guarantee it fixed real problem, or there are might be more problems to fix.

I have't got any LVM partitions or logical volumes on my disk, still i got failure at partition change commit. I have read #25 message, but i don't think it would fix anything to me. Also i upgraded successfuly already. I am waiting to some statement about my fix beeing correct, incorrect, or doing nothing.

Created attachment 358801 [details]
Contains all the /tmp directory after a failed installation using the patch http://dcantrel.fedorapeople.org/491754.img

This is a tar file containing all the /tmp/ directory. Hopefully it might help, I can't install Fedora 11 after many attempts. Thanks for your time.

Just a word to say it's still present in Fedora 12 A1. I don't know what have change since the last release ( I'm not really used to Fedora ), but I can't enable network in the install process, so I can't send my log through ftp ..

This should be fixed in the current build of anaconda/parted/etc.

The update by David Cantrell in https://fedoraproject.org/wiki/Common_F11_bugs#491754 doesnot work.

The error is after the update is retrived, it says running anaconda, the fedors system installer, please wait and then install exited abnornally [1/1] and says you may safely reboot your system.

This issue is still occurring in RHEL6 20090930 build. It has anaconda 12.32 version.

I tested with Fedora 12 beta, and problem seems to be fixed. I have only one CD, so i haven't finish upgrade, but it got over point it failed at before. So this time you seem to be correct, that bug is fixed in upstream. Thanks.

jesse, I think it may be a little premature to close this on the basis of one report, as it was a very widespread problem and may have had slightly different causes in different cases...I'd quite like to see more than one confirmation that it's better in F12 Beta.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Verified with RHEL6-20091015 build. This issue is no more happening.

*** Bug 507541 has been marked as a duplicate of this bug. ***