IIRC, I read somewhere that functionality should be implemented first in kickstart and then in the gui. Thus, everything I can do in a kickstart install I should be able to do in a gui install. Correct?
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?
Gene
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.
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.
- Chris
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.
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?
Gene
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@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Fri, Oct 10, 2014 at 10:55:43AM -0400, Gene Czarcinski wrote:
IIRC, I read somewhere that functionality should be implemented first in kickstart and then in the gui. Thus, everything I can do in a kickstart install I should be able to do in a gui install. Correct?
No, definitely not correct.
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?
This reverse, however, should be true.
anaconda-devel@lists.fedoraproject.org
-
Chris Lumens -
David Lehman -
Gene Czarcinski -
Matthew Miller