I have had a preliminary look at Anaconda. I appreciate what is being attempted here so I am not going to fire broadsides. BUT, before I attempt an install, I would appreciate some guidance as to how to handle existing partitions.
The server has 3 large drives (which Anaconda sees, marking the first drive as the boot drive which is also fine with me.) The partitions are defined across the 3 drives in such a way that each partition has a backup on another drive. Weekly backups are written on still another, all by rsync scripts. This has worked perfectly for some 5 years now. There is no LVM or RAID to complicate matters.
But I am not quite sure how to handle labelling under the new installer.
There are the regular partitions for /boot, swap, /home and /, of course, along with /usr/local, var/lib/pgsql, and var/www. The corresponding backup partitions are /bup/home, /bup/local, /bup/sys, /bup/pgsql, and bup/www, with weekly backups in /bup/weekly and finally /archive to hold the last few weeks of history.
Anaconda starts by telling me that there is no room to install Fedora 18 and wants to reclaim space because the drives are fully partitioned. I would normally format /boot, /, and /bup/sys on a fresh install.
Because I don't feel quite confident about referring to partitions by labels I stopped at this point. Assuming I request manual (custom) partitioning, and 'standard' file type (existing are all ext4) I would presumably label /boot as 'boot', and / as something like 'root' or 'base' or 'system. If that is the case, then is it permissible to label existing /bup/home as 'bup/home' or would I have to use 'bup_home' to avoid the slash?
Once that is done, I am assuming I will be able to view the partition details similar to F17 and make the choice there as to whether to reformat or not, thereby protecting other partitions through the install process.
Wordy, I know, but I am more than willing to work through it as long as I know I have the same level of protection, and assume the same level of risk as I had with F17's installer and those before it.
The server has 3 large drives (which Anaconda sees, marking the first drive as the boot drive which is also fine with me.) The partitions are defined across the 3 drives in such a way that each partition has a backup on another drive. Weekly backups are written on still another, all by rsync scripts. This has worked perfectly for some 5 years now. There is no LVM or RAID to complicate matters.
But I am not quite sure how to handle labelling under the new installer.
There are the regular partitions for /boot, swap, /home and /, of course, along with /usr/local, var/lib/pgsql, and var/www. The corresponding backup partitions are /bup/home, /bup/local, /bup/sys, /bup/pgsql, and bup/www, with weekly backups in /bup/weekly and finally /archive to hold the last few weeks of history.
Anaconda starts by telling me that there is no room to install Fedora 18 and wants to reclaim space because the drives are fully partitioned. I would normally format /boot, /, and /bup/sys on a fresh install.
Because I don't feel quite confident about referring to partitions by labels I stopped at this point. Assuming I request manual (custom) partitioning, and 'standard' file type (existing are all ext4) I would presumably label /boot as 'boot', and / as something like 'root' or 'base' or 'system. If that is the case, then is it permissible to label existing /bup/home as 'bup/home' or would I have to use 'bup_home' to avoid the slash?
Once that is done, I am assuming I will be able to view the partition details similar to F17 and make the choice there as to whether to reformat or not, thereby protecting other partitions through the install process.
Wordy, I know, but I am more than willing to work through it as long as I know I have the same level of protection, and assume the same level of risk as I had with F17's installer and those before it.