On 10/10/2014 11:27 AM, Gene Czarcinski wrote:
On 10/10/2014 11:30 AM, Chris Lumens wrote:
IIRC, I read somewhere that functionality should be implemented first in
kickstart and then in the gui.
We try to do things this way, yeah, especially for complicated new stuff
where figuring out the UI might take a while.
Thus, everything I can do in a kickstart
install I should be able to do in a gui install. Correct?
No.
Actually, I am OK with this and thinking about it I should have expected
it.
OK, now let me reverse that. I believe that everything (all
functionality)
I can do in a gui install I should be able to do in a kickstart install.
Correct?
Yes. Remember that the UI now internally is generating a kickstart
file.
Now this is the answer I was interested in and the answer I wanted.
Gene, we can do this until the end of time if that's what you want to
do. You're doing everyone, most of all yourself, a disservice by
refusing to use the tools already available to you.
When I do a gui install and I will be using BTRFS "partitioning", I can
reuse (don't format) subvols such as home on /home or perhaps www on
/srv/www. But, for the rootfs ("/") and /boot, they need to be "freshly
formatted." I can reuse the subvol names and disk space by first
deleting the subvol and then allocate it again with the same name. This
will work if /boot is on a subvol or if it is a directory on the rootfs.
Now, what I would like is to have this same capability to "reuse" /boot
and rootfs subvols when I do a kickstart install. The only way I can
currently do this is to go out-of-band of the kickstart process (bootup
in rescue mode and delete the subvols and then reboot to do the
kickstart install).
If the gui is generating a kickstart file, how does it specify that
subvol is to be deleted and then reallocated?
Why do I want this in kickstart. On my virtual systems I will reinstall
over an existing system many times while keeping some data. And, more
than once I have needed to reinstall on real hardware when doing a
kickstart install.
I have previously submitted a couple of relatively simple patches for
anaconda and pykickstart. Th update to pykickstart adds the "--reclaim"
option to the btrfs command. The update to anaconda adds code to
kickstart.py which checks to see if --reclaim was specified. If it was
not, then processing will be as it is now. If it was AND the subvol
currently exists, then it is deleted first followed by the allocate.
Here is a summary of what gets changed:
Gene Czarcinski (1):
v3 update anaconda to add reclaim
pyanaconda/kickstart.py | 8 ++++++++
1 file changed, 8 insertions(+)
Gene Czarcinski (1):
v3 update pykickstart to add reclaim to btrfs command
pykickstart/commands/btrfs.py | 5 +++++
1 file changed, 5 insertions(+)
Why isn't this something that should work?
It won't work because there are several other avenues available to you
that you continue to willfully ignore. Nor am I interested in adding a
new option that is only for btrfs subvolumes when existing functionality
should cover what you want to do.
If there are bugs in clearpart --list=<...> we can fix them. You could
also easily add a new root subvolume with a slightly different name or
remove the old one in %pre.
Let me reiterate: This is a non-starter. We're not looking to maximize
the number of different ways to accomplish the same task.
David
Gene
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
