Red Hat Bugzilla – Bug 170728
Documenting problems in the automatic partitioning scheme
Last modified: 2007-04-18 13:32:55 EDT
The automatic partitioning scheme used in FC4 is very inflexible, since it creates a single logical volume
occupying virtually the whole available disk space. This partition scheme cannot then be changed
without either a considerable amount of expertise (and risk), or else dumping the whole system and re-
installing. To be honest, I think the default is plain wrong and should be changed - in general, defaults
should be safe, and should allow newbies to logical volumes (as I was) to set up a system that can later
be tailored as they gain experience. But so long as it remains as it is, it needs to be documented in the
installation guides (and preferably, in the installation macros themselves). In particular, it would be
highly desirable for the documentation to include a warning along the lines of:
"Warning: if you use the automatic partitioning scheme, it will be extremely difficult at a later stage to
tailor it. If you think you might later need to restructure the partitioning, you should read the
documentation on logical volumes, noting that they are easy to extend but very difficult to shrink. You
may wish to consider creating a partitioning scheme with relatively small logical volumes, for later
The automatic partitioning scheme uses LVM by default which is far more flexible
allows restructuring better than static partitions.
Fedora also includes a graphical LVM utility - system-config-lvm which allows
you to view and manipulate volumes easily. The installer also provides you a
option to review and change the options if required apart from custom
This is planned to be enhanced even more with a seperate /home volume
If you want to learn about LVM, refer to these documents
If you want to suggest any further enhancements or bug reports, file it against
lvm or anaconda components as appropriate.
Thank you for your comments. While it is true that LVM is far more flexible than static partitions, they are
not perfect. In particular, they are extremely difficult to shrink. But this is precisely the requirement that
the default partitioning scheme imposes - having used the whole disk space for a single logical volume,
the only way a user can later make changes is to shrink that volume (or add more disks). This won't be
alleviated much by the proposal under 150670, since the proposal is still to occupy the whole disk, the
debate is only about how to split the space.
I should add that the two documents referred to by Sundaram have limited relevance; the first describes
how to extend LVM partitions, but not how to shrink them, the point at issue here. The second deals with
LVM 1 only; the methods described there do not work with LVM 2.
The installer used static partitions that made use of the whole disk before and
it was difficult to either extend OR shrink them. Now if its possible to shrink
them, its a improvement over the previous scheme and hence requires no special
warning. The fact that the automatic installation uses LVM is already documented
in the installation guide, the implication of which is available in several
documents, some of which I have referred above.
It might useful to add a note that LVM does not allow shrinking if thats the
case already and when the next release of Fedora is made. It would be better to
file a enhancement suggesting the shrinking be supported against LVM if its not
already possible or requested. You might also want to suggest any other
enhancements to the default partitioning scheme against Anaconda and drop in
the bugzilla numbers here as comments. That would be helpful to keep track of
these issues and document them as appropriate.
Documenting work arounds is only needed if the tools dont do the right thing and
there isnt a way to fix them within constraints.
Note: LVM HOWTO also covers LVM2
Can we get some developer confirmation about LVM and shrinking volumes?
If necessary, we can document recommendations and workarounds.
Bob - do you have a bugzilla report, mailing list thread, or similar to
reference? We need some feedback from the LVM developers, and probably the
Anaconda developers. If you haven't found any relevant existing bugs, can you
file two separate RFEs against Anaconda and LVM? (To 'request' a feature,
choose Enhancement under Severity.)
I'm reassigning this to the Fedora Installation Guide bugzilla component for
consideration, and making it block the FC5 relnotes tracker so we can review if
anything more needs to be in the release notes.
Thank you for your response, and your guidance on how to handle things, I'm not entirely clear on
how bugzilla is supposed to be used. I did submit a bug at (anaconda)
but it has been marked as a duplicate of
In fact, I think it's a separate, though related, issue - even if the user and system directories are split
into separate volumes, the filesystem is still inflexible if the whole available disk space is used. I've now
posted it as an rfe also under lvm, as you suggest:
There is a fair bit out there on the web on this issue, the most useful thread I found was
However I couldn't make this solution work because it seemed that the FC4 boot disk uses
/dev/VolGroup00/LogVol00/sbin as its source for lvm binaries, so umounting it (which is necessary for
the resize) removes access to the very binaries needed. I posted a query about this at
One response suggested I should be able to make the FC4 boot disk work, but again I couldn't get it to
work the way suggested. Fortunately, that thread also suggested trying Knoppix. I did that, used info
from http://www.knoppix.net/wiki/LVM2 to update lvm on the fly (probably there is a way to do that
also for the FC4 boot disk, but I couldn't find it), and finally managed to get the resize done. I posted a
thread on how to do it at
The bottom line, though, is that LVM completely changes things. The LVM manager is a _really_ nice
tool for expanding volumes - it seems to be bullet- and newbie-proof (I didn't see any reports on any
problems with it, despite a fair amount of googling). So giving users a default of fairly small sizes, and
leaving unallocated space, is no longer a problem - so long as they get a warning that that is what is
happening, and what to do about it if they start to bump against the limits. On the other hand,
shrinking LVMs is not only difficult - see above - but also inherently dangerous. There are any number
of ways in which you could destroy the filesystem in trying to do it. If this can't be changed, then the
issues with the defaults need to be documented (of course, if LVM manager were to include a gui for
shrinking volumes, that would change things completely - the current defaults would be fine - but I
haven't seen any hints that that is in the wind).
Unblocking FC5 release notes; this is a situation best handled in the
I've now added text to the Installation Guide to advise on leaving unallocated
space, and growing LVM volumes to use free space as required, in preference to
fully allocating storage and then shrinking volumes to make the space available
The "Other Technical Documentation" Appendix now has a link to the LVM HOWTO.
The situation has changed somewhat, since the LVM GUI in FC5 now provides the option (presumably
safety-checked) of shrinking volumes. However it's only a partial solution, since it requires unmounting
the target volume. So the user must still understand the need to boot from a separate system from the
one being updated. Thus it's still a trap for newbies, though not nearly as badly as previously.
Bob: would you mind reviewing the relevant section of the Installation Guide for us?
I don't personally work with LVM much, so you may be able to suggest
improvements to the text there.
Created attachment 128412 [details]
Suggested revision for Ch 5.1
Firstly, thank you for the opportunity to comment. Actually, I think 5.2 is
fine, it covers the important
issues. The problem is that the users it needs to catch - new users who just
want to do everything the
'simple' way, but might later need to change things - aren't going to read 5.2,
because as far as they're
concerned, 5.1 has effectively told them it's OK to accept the default scheme,
so they can ignore 5.2. I've taken the liberty of drafting some minor changes
to 5.1 (using nvu - I'm sorry, I'm not sure what tool is normally used for
fedora docs). These consist of a warning early on, an extra section 5.1.4 for
new users, and some slight changes to the wording in 5.1.3, to be clearer about
logical volumes. I hope they can be of use. But I'm also not expert in LVM, so
it would be great if they could be checked by one of the LVM gurus.
Thanks - that was very helpful. I've amended 5.1.3, and added information from
your 5.1.4 into some existing sections.
We tend to encourage users to stick to the defaults unless they have specific
reasons (and the understanding) to change them, so I wouldn't feel comfortable
suggesting that new users go into manual LVM configuration for their first
installations. Hopefully future releases of Fedora will create a separate /home
partition by default, as is being discussed on #150670.