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.