Bug 790158 - Fedora-17-Alpha-TC2-i686-Live-KDE.iso is larger than 700 MiB
Fedora-17-Alpha-TC2-i686-Live-KDE.iso is larger than 700 MiB
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: spin-kickstarts (Show other bugs)
rawhide
i686 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kevin Kofler
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F17Beta/F17BetaBlocker
  Show dependency treegraph
 
Reported: 2012-02-13 14:43 EST by Andre Robatino
Modified: 2012-02-15 18:33 EST (History)
14 users (show)

See Also:
Fixed In Version: spin-kickstarts 776ebbc
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-15 18:33:14 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)

  None (edit)
Description Andre Robatino 2012-02-13 14:43:47 EST
Description of problem:
Size of Fedora-17-Alpha-TC2-i686-Live-KDE.iso is 738197504 bytes which is larger than 700 MiB = 734003200 bytes. Sizes of all other Lives for both i686 and x86_64 are okay.

Proposing as 17 Beta blocker according to the following from https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria :

3.  The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements

Version-Release number of selected component (if applicable):
17 Alpha TC2
Comment 1 Bill Nottingham 2012-02-13 15:43:34 EST
Moving to a core KDE component to get the right eyes on this bug. (Presumably a spin-kickstarts issue, or a rogue dep on something large.)

Andre - do you have the spin compose logs?
Comment 2 Andre Robatino 2012-02-13 15:47:49 EST
(In reply to comment #1)
> Moving to a core KDE component to get the right eyes on this bug. (Presumably a
> spin-kickstarts issue, or a rogue dep on something large.)
> 
> Andre - do you have the spin compose logs?

I'm just a tester. I'm not involved with the compose at all.
Comment 3 Rex Dieter 2012-02-13 16:01:47 EST
OK, I think we were aware that the kde live image was going to be *very* close to the size limit.  I thought previous daily images did fit at one time, but as usual, stuff keeps growing bit by bit over time.
Comment 4 Kevin Kofler 2012-02-13 16:09:28 EST
So the consensus in the KDE SIG is that the actual threshold should be the maximum size of a "700 MB" CD, which is 703 MiB, rather than exactly 700 MiB.

However, here, we're at 704 MiB, which is bad.
Comment 5 Kevin Kofler 2012-02-13 16:12:25 EST
For the alpha, being oversized by less than a MiB (the exact size limit is slightly above 703 MiB) should not be critical (overburn exists) and it infringes only Beta criteria, but we need to solve this one way or the other by Beta.

But while we are at it, please set the limit to 703 MiB rather than 700.
Comment 6 Andre Robatino 2012-02-13 16:19:51 EST
In setting the size test at 700 MiB I argued that the difference between the advertised size and the actual size for optical media, in addition to being somewhat dependent on the exact type of media (for example R vs. RW), is less than half a percent. In addition, users aware of the advertised size who see an image larger than that may be confused and think it won't fit. So I think it would be better to stick to the advertised size (700 MiB for CDs - with the understanding that that's what the label actually means, 4.7 GB for DVDs, and 8.5 GB for Blu-ray).

For an example of what can happen when this isn't done, see the recent experience with CentOS 6.2 where they were willing to split the x86_64 DVD, but decided not to split the i386 DVD even though it went slightly over the advertised size of 4.7 GB. This requires using a specific type of DVD, since the actual maximum depends on that. Someone not reading the release notes and using a different type gets a coaster.
Comment 7 Bill Nottingham 2012-02-13 16:20:51 EST
koji.fedoraproject.org/koji/tasks?state=all&owner=ausil&view=flat&method=createLiveCD&order=-id is where logs may be found.
Comment 8 Andre Robatino 2012-02-13 16:31:10 EST
Sorry, it was CentOS 6.0, not 6.2. For example see https://www.centos.org/modules/newbb/viewtopic.php?topic_id=32287 . It appears that for 6.1 and 6.2 they're splitting the i386 DVD.
Comment 9 Kevin Kofler 2012-02-13 16:41:15 EST
> In setting the size test at 700 MiB I argued that the difference between the
> advertised size and the actual size for optical media, in addition to being
> somewhat dependent on the exact type of media (for example R vs. RW),

That is not true. The CD-R and CD-RW standards require the same minimum capacity of 360000 sectors, i.e. 737280000000 bytes, i.e. ~703⅛ MiB.

> is less than half a percent.

That half percent can make the difference between fitting and not fitting, so we care a lot about that half percent and are not willing to remove anything from our spin if we are in the 700-703 MiB range. (I put this up in a KDE SIG meeting and we all agreed that the limit should be the maximum CD size (737280000000 bytes) for our spin.)

As for users of larger than CD media (e.g. persistent USB stick), exactly the fact that it's only half a percent means that going with the larger limit should not make any practical difference for them.

> In addition, users aware of the advertised size who see an image larger than
> that may be confused and think it won't fit.

Then we need to educate our users. IIRC, we already shipped KDE images in the 700-703 MiB range in the past and it has never been an issue.

> For an example of what can happen when this isn't done, see the recent
> experience with CentOS [6.0] where they were willing to split the x86_64 DVD,
> but decided not to split the i386 DVD even though it went slightly over the
> advertised size of 4.7 GB. This requires using a specific type of DVD, since
> the actual maximum depends on that. Someone not reading the release notes and
> using a different type gets a coaster.

That is true for DVDs where there are different competing standards: DVD-R and DVD+R have a different maximum size, so you have to pick the smaller one as your maximum. "700 MB" CDs have a single well-established minimal maximum size required by the standards. (And FWIW, the actual maximum of physical media tends to be higher, e.g. I've once successfully burned a 712 MiB Alpha release of Fedora KDE on a "700 MB" CD-R. But burning software will start whining if you exceed the 360000 sector limit.)

As for where that number comes from: the media also advertises an audio recording time of 80 minutes, and a minute of Red Book audio requires exactly 75×60=4500 sectors, thus the media needs to carry at least 4500×80=360000 sectors to work as advertised.
Comment 10 Kevin Kofler 2012-02-13 16:49:49 EST
So, looking at the logs, TC2 still had the old verne artwork on it, as did the latest successful nightly (the 20120211 compose failed due to xorg-x11 dependency issues), so the next compose might actually turn out either larger or smaller.
Comment 11 Andre Robatino 2012-02-13 16:53:05 EST
(In reply to comment #9)
> > In setting the size test at 700 MiB I argued that the difference between the
> > advertised size and the actual size for optical media, in addition to being
> > somewhat dependent on the exact type of media (for example R vs. RW),
> 
> That is not true. The CD-R and CD-RW standards require the same minimum
> capacity of 360000 sectors, i.e. 737280000000 bytes, i.e. ~703⅛ MiB.

See for example http://lists.fedoraproject.org/pipermail/test/2010-April/089943.html .

BTW, for 8.5 GB I should have said "dual-layer DVD", not "Blu-ray" - sorry about that.
Comment 12 Andre Robatino 2012-02-13 18:47:40 EST
The test list post says "One might think a disc_image.iso file no larger than 737280000 bytes is OK, but there are other format requirements that reduce the effective capacity of a 737280000 byte CD to 736970752 bytes
(reported by the wodim command).  Still, that is about 702.83 MB." He doesn't mention what the "other format requirements" are. http://www.berklix.com/~jhs/txt/cdroms.html lists capacities for specific brands. Most but not all for "700 MB" are 736970752 bytes, one is slightly smaller, 736968704 bytes.
Comment 13 Kevin Kofler 2012-02-13 20:14:03 EST
FWIW, the latest nightly (still with Verne theming, we need to update kde-settings to pick up the new theming!) is now 706 MiB, so even more oversized. :-(
Comment 14 Kevin Kofler 2012-02-15 18:33:14 EST
F17 Alpha RC2 is now well below 700 MiB. We dropped Amarok (and readded Krusader in the freed room, it is much smaller).

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