quickinst: http://projects.archlinux.org/?p=installer.git;a=blob;f=quickinst;h=23e41ccb... Is there anyone who actually uses this? If so, can you tell me why?
It's stated quickinst is meant for people who want to mkfs/mount their filesystems themselves, okay I understand that. But, as a "consequence" you can only install the base packages, your keyboard/time/.. settings don't go into /mnt/etc/rc.conf automatically, you need to install the bootloader manually (which means having to mount some things yourself, chroot etc.
What is the advantage of this over just using the normal installer and skipping the steps you don't want to do?
I'm wondering if shouldn't just drop it.
Note that with AIF it's quite easy to implement a "partial procedure", which is a procedure to do one or a few specific things. (right now there are partial procedures which let you do keymap/font selection, disk/partition/filesystem config, and network setup). I could add one to let the user just do package selection & installation, for example.
Dieter
On Sun, Mar 8, 2009 at 10:05 AM, Dieter Plaetinck dieter@plaetinck.be wrote:
quickinst: http://projects.archlinux.org/?p=installer.git;a=blob;f=quickinst;h=23e41ccb... Is there anyone who actually uses this? If so, can you tell me why?
It's stated quickinst is meant for people who want to mkfs/mount their filesystems themselves, okay I understand that. But, as a "consequence" you can only install the base packages, your keyboard/time/.. settings don't go into /mnt/etc/rc.conf automatically, you need to install the bootloader manually (which means having to mount some things yourself, chroot etc.
What is the advantage of this over just using the normal installer and skipping the steps you don't want to do?
Because the normal installer is a manual process. You can't easily do a remote install on 30 machines with a dialog-based installer, while with quickinst that becomes quite easy.
I'm wondering if shouldn't just drop it.
Note that with AIF it's quite easy to implement a "partial procedure", which is a procedure to do one or a few specific things. (right now there are partial procedures which let you do keymap/font selection, disk/partition/filesystem config, and network setup). I could add one to let the user just do package selection & installation, for example.
Dieter
Dan McGee schrieb:
On Sun, Mar 8, 2009 at 10:05 AM, Dieter Plaetinck dieter@plaetinck.be wrote:
quickinst: http://projects.archlinux.org/?p=installer.git;a=blob;f=quickinst;h=23e41ccb... Is there anyone who actually uses this? If so, can you tell me why?
It's stated quickinst is meant for people who want to mkfs/mount their filesystems themselves, okay I understand that. But, as a "consequence" you can only install the base packages, your keyboard/time/.. settings don't go into /mnt/etc/rc.conf automatically, you need to install the bootloader manually (which means having to mount some things yourself, chroot etc.
What is the advantage of this over just using the normal installer and skipping the steps you don't want to do?
Because the normal installer is a manual process. You can't easily do a remote install on 30 machines with a dialog-based installer, while with quickinst that becomes quite easy.
I never used it, but I imagine that is its purpose.
Dieter, didn't your original AIF design say that you can do automatic installations as well? Can you provide a quickinst equivalent based on AIF? If so, it can replace quickinst.
On Sun, 08 Mar 2009 23:00:00 +0100 Thomas Bächler thomas@archlinux.org wrote:
Dan McGee schrieb:
On Sun, Mar 8, 2009 at 10:05 AM, Dieter Plaetinck dieter@plaetinck.be wrote:
quickinst: http://projects.archlinux.org/?p=installer.git;a=blob;f=quickinst;h=23e41ccb... Is there anyone who actually uses this? If so, can you tell me why?
It's stated quickinst is meant for people who want to mkfs/mount their filesystems themselves, okay I understand that. But, as a "consequence" you can only install the base packages, your keyboard/time/.. settings don't go into /mnt/etc/rc.conf automatically, you need to install the bootloader manually (which means having to mount some things yourself, chroot etc.
What is the advantage of this over just using the normal installer and skipping the steps you don't want to do?
Because the normal installer is a manual process. You can't easily do a remote install on 30 machines with a dialog-based installer, while with quickinst that becomes quite easy.
I never used it, but I imagine that is its purpose.
Dieter, didn't your original AIF design say that you can do automatic installations as well? Can you provide a quickinst equivalent based on AIF? If so, it can replace quickinst.
That's correct. The automatic procedure is not ready for use, but it's being worked on as we speak :)
So, quickinst is a means to get a basic system with very low interactivity (though partitioning etc still needs to be taken care of manually).
Well, first of all scratch my idea of implementing a partial procedure for package installation, it wouldn't offer much added value over a plain "pacman -S --root /mnt --config ..."
Instead I'll just continue to work on the automatic procedure. The way I think it should work is like this: (invocation: explanation)
* aif -p automatic: do the sort-of equivalent of quickinst. (this is actually more a side effect then a design goal) if no separate filesystem in mounted on /mnt bail out. I don't think I'll bother to allow passing things like ftp/packages path/.. through command line arguments. unless maybe if i have enough spare letters :) One thing that I think would be useful to pass as commandline argument is a block device (eg -aif -p automatic -<something> /dev/sda), which would setup /dev/sda in a default layout (like autoprepare but with values pre-filled in)
* aif -p automatic -c /path/to/configfile: the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config
We could also deliver one or more simple sample configs, that should compensate the lack of commandline arguments in the first method of invocation. (think of at least a sample config that contains some clearly documented variables such as ftp/cd, location of target system,.. basically the variables which you can pass to quickinst now ;-)
Dieter
PS: an example of a config file for the automatic procedure: http://github.com/Dieterbe/aif/blob/71f5510aaaa20ae5ae9c773dca12028bd96aafdf...
On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck dieter@plaetinck.be wrote:
- aif -p automatic -c /path/to/configfile:
the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config
This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine.
I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though
Aaron Griffin schrieb:
On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck dieter@plaetinck.be wrote:
- aif -p automatic -c /path/to/configfile:
the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config
This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine.
I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though
I agree.
Someone could easily create a custom installation medium with a custom aif automatic configuration and use that for mass installation.
On Mon, Mar 9, 2009 at 5:29 PM, Thomas Bächler thomas@archlinux.org wrote:
Aaron Griffin schrieb:
On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck dieter@plaetinck.be wrote:
- aif -p automatic -c /path/to/configfile:
the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config
This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine.
I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though
I agree.
Someone could easily create a custom installation medium with a custom aif automatic configuration and use that for mass installation.
My only thought is whether this is even necessary- I'm guessing most people used quickinst as just a part of a full automated install (e.g. shell script that first does partitioning, mounting, etc).
I wouldn't mind a tool that takes care of this for me, but if it isn't useful for a wide variety of cases, it won't be used. In addition, any config file format we write is surely not as flexible as a shell script would be.
-Dan
On Mon, 9 Mar 2009 20:01:35 -0500 Dan McGee dpmcgee@gmail.com wrote:
On Mon, Mar 9, 2009 at 5:29 PM, Thomas Bächler thomas@archlinux.org wrote:
Aaron Griffin schrieb:
On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck dieter@plaetinck.be wrote:
- aif -p automatic -c /path/to/configfile:
the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config
This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine.
I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though
I agree.
Someone could easily create a custom installation medium with a custom aif automatic configuration and use that for mass installation.
My only thought is whether this is even necessary- I'm guessing most people used quickinst as just a part of a full automated install (e.g. shell script that first does partitioning, mounting, etc).
I wouldn't mind a tool that takes care of this for me, but if it isn't useful for a wide variety of cases, it won't be used. In addition, any config file format we write is surely not as flexible as a shell script would be.
-Dan
Aha ! This is actually the very reason I started this all. I want for myself to have a script that does all this cool stuff. (the port of /arch/setup is just a little side project as far as I'm concerned ;-)
And you're right that a file format adds another layer of complexity, but you get some free stuff in return such as the rolling back in case of failure, no need to program sfdisk input (which is quite ugly). If no one will use this particular part of aif.. well that's fine by me. we'll see :)
Dieter
On Tue, 10 Mar 2009 09:32:54 +0100 Dieter Plaetinck dieter@plaetinck.be wrote:
On Mon, 9 Mar 2009 20:01:35 -0500 Dan McGee dpmcgee@gmail.com wrote:
On Mon, Mar 9, 2009 at 5:29 PM, Thomas Bächler thomas@archlinux.org wrote:
Aaron Griffin schrieb:
On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck dieter@plaetinck.be wrote:
- aif -p automatic -c /path/to/configfile:
the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config
This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine.
I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though
I agree.
Someone could easily create a custom installation medium with a custom aif automatic configuration and use that for mass installation.
My only thought is whether this is even necessary- I'm guessing most people used quickinst as just a part of a full automated install (e.g. shell script that first does partitioning, mounting, etc).
I wouldn't mind a tool that takes care of this for me, but if it isn't useful for a wide variety of cases, it won't be used. In addition, any config file format we write is surely not as flexible as a shell script would be.
-Dan
Aha ! This is actually the very reason I started this all. I want for myself to have a script that does all this cool stuff. (the port of /arch/setup is just a little side project as far as I'm concerned ;-)
And you're right that a file format adds another layer of complexity, but you get some free stuff in return such as the rolling back in case of failure, no need to program sfdisk input (which is quite ugly). If no one will use this particular part of aif.. well that's fine by me. we'll see :)
Dieter
Hey dudes. I got rid of the quickinst stuff and implemented the automatic procedure. In my tests, it produces working systems. One thing to note: when the process is done, and you type reboot, you'll get squashfs and i/o errors on the live /. didn't figure that one out yet.
You can install it by installing aif-experimental-git package from AUR. Invocation: aif -p automatic -d -c /usr/share/aif/examples/generic-install-on-sda
To get an immediate idea of the code and sample config (which are actually very simple), see: http://projects.archlinux.org/?p=aif.git;a=blob;f=src/core/procedures/automa... http://projects.archlinux.org/?p=aif.git;a=blob;f=examples/generic-install-o...
Have fun!
Dieter
On Sun, Mar 8, 2009 at 6:38 PM, Dan McGee dpmcgee@gmail.com wrote:
On Sun, Mar 8, 2009 at 10:05 AM, Dieter Plaetinck dieter@plaetinck.be wrote:
quickinst:
http://projects.archlinux.org/?p=installer.git;a=blob;f=quickinst;h=23e41ccb...
Is there anyone who actually uses this? If so, can you tell me why?
It's stated quickinst is meant for people who want to mkfs/mount their filesystems themselves, okay I understand that. But, as a "consequence" you can only install the base packages, your keyboard/time/.. settings don't go into /mnt/etc/rc.conf automatically, you need to install the bootloader manually (which means having to mount some things yourself, chroot etc.
What is the advantage of this over just using the normal installer and skipping the steps you don't want to do?
Because the normal installer is a manual process. You can't easily do a remote install on 30 machines with a dialog-based installer, while with quickinst that becomes quite easy.
I'm wondering if shouldn't just drop it.
Note that with AIF it's quite easy to implement a "partial procedure", which is a procedure to do one or a few specific things. (right now there are partial procedures which let you do keymap/font selection, disk/partition/filesystem config, and network setup). I could add one to let the user just do package selection & installation, for example.
I use by same reason.
Dieter
arch-releng@lists.archlinux.org