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(a)zeff.us> 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.