Description of problem: Anaconda installer 8 breaks upgrade to 9. The actual bug is that mkfs.vfat when invoked generates the same serialnumber / volumeid for the vfat partitions that I selected for formatting during install. This makes the upgrade feature of anaconda 9 angry and it complains about duplicate serial numbers. Version-Release number of selected component (if applicable): Uncertain. The default anaconda installer available as PXE images 7th january 2008. How reproducible: Not tested yet. Steps to Reproduce: Excerpt from anaconda-ks.conf #clearpart --linux #part raid.27 --size=100 --ondisk=sda --asprimary #part raid.28 --size=100 --ondisk=sdb --asprimary #part /mnt/windata --fstype vfat --onpart sdb1 #part /mnt/windows --fstype vfat --onpart sda1 #part raid.31 --size=100 --grow --ondisk=sdb #part raid.30 --size=100 --grow --ondisk=sda #raid /boot --fstype ext3 --level=RAID1 --device=md0 raid.27 raid.28 #raid pv.32 --fstype "physical volume (LVM)" --level=RAID1 --device=md1 raid.30 raid.31 #volgroup WorkVG00 --pesize=32768 pv.32 #logvol /home --fstype ext3 --name=HomeVol --vgname=WorkVG00 --size=20000 #logvol swap --fstype swap --name=SwapVol --vgname=WorkVG00 --size=4096 #logvol / --fstype ext3 --name=RootVol --vgname=WorkVG00 --size=20000 1. Make two vfat partitions in diskdruid during install of Fedora and format. 2. Check volumeid's with file -s /dev/sda1 and /dev/sdb1. They're the same. 2. Boot Fedora 9 installer and select upgrade. Upgrade fails. Actual results: Expected results: Generate different volumeid's for each formatted partition. Additional info: This is perhaps a bug in dosfstools. all I could glean from the manpage was that volumeid generation is timebased, and mkfs.vfat is pretty snappy on modern machines. Perhaps an artificial delay in anaconda or checking for duplicate id's and reformatting.
This should be fixed in dosfstools rather than trying to do odd special cases in anaconda
Stepan, any updates on this? It's been a number of months since this was filed, and it's currently a blocker for F10. I'd like to see it fixed if possible, or a realistic idea of what it will take so that we can set blockers appropriately.
We're well past any sort of feature freeze like this. PUNT.
(In reply to comment #3) > PUNT. NAK. This needs to be fixed for F10. Otherwise, we're making installs which won't later be upgradable.
Created attachment 322456 [details] patch! Here's a patch - it expands the creation time used to include microseconds. Since the volume ID is limited to 32 bits, it gets truncated somewhat, but this is probably the simplest solution. Alternative would be to use libuuid and truncate that to 32-bits.
Stepan ping? We really need to get this in for Fedora 10.
Patch has been reviewed a couple of times, seems obviously correct. AFAIK nothing *depends* on volume-id being a timestamp, so the change shouldn't matter. Package maintainer might be on vacation, though, so we haven't gotten a proper review. notting is contacting upstream dosfstools maintainers for their opinion.
Got ping from notting, will have a look at this tomorrow and release 3.0.1.
Spot built this... can we get some rawhide testing?
I just attempted an install with many vfat partitions, some small some large. Each partition had an actual unique uuid according to blkid. file -s doesn't give me any useful information. I'm assuming that blkid's uuid and the above mentioned volumeid is one in the same. Considering this confirmed.
This is now part of 3.0.1 (uploaded yesterday); thanks for the patch and sorry for the delay.