I have to say I find this disucssion interesting.... I have spent what amounts to a small fortune (for me!) making sure that when I upgrade from one version of LINUX to another (initially slackware but so far fedora 9 - 20) that I can minimise the risk of (anaconda or whatever the current installer might be) deciding in its wisdom whilst doing the partitioning that it thinks best, blowing away my /opt and/home partitions - which have nearly 20 years of accumulated digital clutter! To that end I have my home and multimedia filesystems on a separate raid pair of disks and my /boot & root on a separate "system" disk. All my disks are in removable caddies! When I "upgrade" I usually buy a new "system disk" install onto it and only when its stable do I go about connecting and mounting my home and multimedia filesystems. If the "upgrade" isn't to my liking - I can reload the old system disk. I used to have a hellish time due to things like the size of /boot being too small and problems like that associated with having to repartition. So I just point out that "been there - done that" and I came to the conclusion that anaconda just has a "holier than thou" attitude and the only way round it is to do what I have done. But as I say its an expensive option. Andy On Sunday 22 February 2015 16:05:57 Chris Murphy wrote: > On Sun, Feb 22, 2015 at 3:19 PM, Joe Zeff <joe@xxxxxxx> wrote: > > On 02/22/2015 02:01 PM, Chris Murphy wrote: > >> If > >> you, who seems to care about such things so much, won't do that work, > >> then why should anyone else do it? > > > > I haven't done any programming worth mentioning since the late '80s and > > never learned python. My impression was that back then, anaconda used > > whatever standard partitioning programs were available, rather than > > rolling > > their own. > > ? They use parted, mdadm, lvm, grub-install/mkconfig, and mkfs. But > that's not where the bulk of the code is. I don't know python either, > but I can still make out some sense of the complexity involved by > looking at anaconda, python-blivet (that's the bulk of the storage > code), and even the new python-bytesize package will give you some > idea of the complexity involved in all of this. > > Any GUI installer is not just some dumb wrapper for existing tools, > more so with Anaconda that has a huge amount of logic wrapped into it. > It's worth skimming the code. 443 lines just for iSCSI (which depends > on a bunch of other code, this is just the iscsi portion), > devicefactory is nearly 2000 lines. The installer is > substituting/emulating a human being's logic. > > https://github.com/rhinstaller/anaconda > https://github.com/rhinstaller/blivet > > > Let me ask you this: could I, if needed, boot from a Live Gpartd CD/USB, > > set up and format things the way I wanted and then use those existing > > partitions when installing Fedora? > > Yes. Matthew already mentioned that. The exception is that the > installer insists on root fs being formatted by the installer. I > understand why this is considered safer, but at the same time I think > a fsck check (no repairing) passes without errors should permit that > volume to be used. This turns into a problem if you have say, hardware > raid and you need to use custom mkfs options to tune the file system > to the raid. With software raid, mkfs becomes aware of the underlying > geometry. This isn't guaranteed with many types of hardware raid, so > custom options are needed, and we have no way to do that in the > installer so instead you'll have to do this post-install with fstab > mount options. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
