On Monday 23 February 2015 09:10:24 Andrew R Paterson wrote:
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@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.
my apologies for top-posting. Andy