Bug 448247

Summary: [PATCH] Anaconda's invocation of mkfs.vfat results in duplicate volume-id's / serial-numbers
Product: [Fedora] Fedora Reporter: Andreas Øye <aoy>
Component: dosfstoolsAssignee: Stepan Kasal <kasal>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: daniel, dcantrell, notting, tcallawa, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-19 04:50:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 469046    
Attachments:
Description Flags
patch! none

Description Andreas Øye 2008-05-24 22:19:55 UTC 
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.
Comment 1 Jeremy Katz 2008-05-27 15:37:11 UTC 
This should be fixed in dosfstools rather than trying to do odd special cases in
anaconda
Comment 2 Jesse Keating 2008-10-03 23:19:03 UTC 
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.
Comment 3 Jesse Keating 2008-10-25 00:23:18 UTC 
We're well past any sort of feature freeze like this.  PUNT.
Comment 4 Jeremy Katz 2008-10-26 16:45:02 UTC 
(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.
Comment 5 Bill Nottingham 2008-11-04 17:46:48 UTC 
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.
Comment 6 Jesse Keating 2008-11-11 23:00:10 UTC 
 Stepan ping?  We really need to get this in for Fedora 10.
Comment 7 Will Woods 2008-11-14 19:10:12 UTC 
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.
Comment 8 Daniel Baumann 2008-11-14 20:04:45 UTC 
Got ping from notting, will have a look at this tomorrow and release 3.0.1.
Comment 9 Bill Nottingham 2008-11-18 16:47:56 UTC 
Spot built this... can we get some rawhide testing?
Comment 10 Jesse Keating 2008-11-19 04:50:08 UTC 
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.
Comment 11 Daniel Baumann 2008-11-24 12:09:40 UTC 
This is now part of 3.0.1 (uploaded yesterday); thanks for the patch and sorry for the delay.