Bug 448247 - [PATCH] Anaconda's invocation of mkfs.vfat results in duplicate volume-id's / serial-numbers
[PATCH] Anaconda's invocation of mkfs.vfat results in duplicate volume-id's /...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dosfstools (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Stepan Kasal
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10AnacondaBlocker
  Show dependency treegraph
 
Reported: 2008-05-24 18:19 EDT by Andreas Øye
Modified: 2013-01-09 23:42 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-18 23:50:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch! (1.25 KB, patch)
2008-11-04 12:46 EST, Bill Nottingham
no flags Details | Diff

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

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