For example:
Burn iso to usb
use git to checkout from X://blah
copy files to /xx/ on usb
boot off of usb
go to directory
edit file x with your settings
run script
etc..
I dont see any documentation as to actually how to use it. Just a quick blurb about 'you have to configure a file to suit your installation' and really nothing else.
Thanks
]]>The responsibility for setting the BOOT_DRIVE variable falls to the filesystem block (see the current efi-luks-gpt example filesystem block). As intended, the filesystem block is doing most of the heavy lifting in terms of system config.
]]>Hey, this looks pretty cool. I'm confused about a couple of things though: in the example script it says "boot into Arch Install media and run:
curl https://raw.github.com/altercation/archblocks/master/install_tau.sh" > install.sh; bash install.sh
However install_tau.sh doesn't seem to exist.
I've renamed the sample installer a couple times (right now it's example.sh). I'll update that information. I had named it install_tau.sh originally since I'm testing this on my ThinkPad which is named tau. I may rename this to "sample_laptop.sh" or some such later on...
It's worth noting that I structured this so that, if there was a big enough "library" of blocks, a user could keep just the config file (this example.sh installer) in their own repo and could source everything else from, for example, my master repo.
Also, if the point of
curl url > out.sh; bash out.sh
is to ensure the script is fully downloaded before it's run (as opposed to `curl url | bash`, which (iiuc) runs the script as it's downloaded), shouldn't you use
curl url > out.sh && bash out.sh
to ensure the `curl` command didn't fail before running the script? Just a small thing, but I thought I'd ask.
Yes, that's totally correct. I actually didn't want people doing that (so probably should just break that sample code out into two lines) since I still want them to peek at the installer first, particularly since there is a lot that happens automatically (and while there is a warning of DOOM upfront, it's always nice to make people type a bit more to think things through ;-) ).
Awesome project by the way, just what I'm looking for (unattended installation). I look forward to testing/making my own blocks soon (for instance an 'install my dotfiles' one)!
Excellent! Please do consider submitting any blocks you feel are general enough for group consumption back to the project as pull requests.
I'm actually adding in an "install my dotfiles" block now, but it's based on my using mr and a simply symlinking script in my dotfiles repo. It's a slick and easy way to do it, if anyone is interested.
]]>curl https://raw.github.com/altercation/archblocks/master/install_tau.sh" > install.sh; bash install.sh
However install_tau.sh doesn't seem to exist. Also, if the point of
curl url > out.sh; bash out.sh
is to ensure the script is fully downloaded before it's run (as opposed to `curl url | bash`, which (iiuc) runs the script as it's downloaded), shouldn't you use
curl url > out.sh && bash out.sh
to ensure the `curl` command didn't fail before running the script? Just a small thing, but I thought I'd ask.
Awesome project by the way, just what I'm looking for (unattended installation). I look forward to testing/making my own blocks soon (for instance an 'install my dotfiles' one)!
The short of it is that I've implemented subdirectories and cleaned up the main install script (the part that will differ most significantly between systems). Additionally, this paves the way for interactive blocks if there is interest.
]]>Looks like a nice backend.
Have you thought about making the disk/partition setup more configurable?
1. Installing alongside an existing OS
2. Use only % of disk
3. Separate home, dev, sys, ... partitions (Yes/No questions)
4. Configurable partition size for root and maybe others
5. Optional swap partition.
I had initially intended the configuration to be purely done by selecting different blocks and hadn't intended this to turn into an interactive installer *but* it is possible that it could be interactive. One could even mix non-interactive with interactive blocks, or allow some basic interactivity in the main install script (install_tau.sh in my example repo). I want to be careful about how/if that would be added in to this framework since I don't want it become AIF level complex
As long as complexity is limited, I could make an example block with some queries in it (e.g. an initial query of the variables that are defined in the installer). Maybe I'll mock this up in a branch for consideration.
And how about configuration of multiple network interfaces (wired, wireless, mobile broadband)?
There are two NETWORK_* blocks in the current repo and I am working on a NETWORK_wired_static.sh as an example block for a static IP server style installation. I'd love to get more examples of these blocks contributed to the project.
Another thing that might be cool is if I could keep a separate configuration file that I could feed into the installer. That way I could initiate the installation process on several machines really fast based on my pre-made configuration file
Right now the goal is that the main install script (install_tau.sh) is also the config (in that the "stack" of blocks determines the configuration). Another option would be to create default install script that one only needs to override values in, but that is a slightly different approach. I'll consider how that might relate to the current form of this framework.
(note that I did previously create a project called backpac - https://github.com/altercation/backpac - that was designed to create config files for use during install/reinstall of Arch, so there is some overlap with that thinking)
]]>Have you thought about making the disk/partition setup more configurable?
1. Installing alongside an existing OS
2. Use only % of disk
3. Separate home, dev, sys, ... partitions (Yes/No questions)
4. Configurable partition size for root and maybe others
5. Optional swap partition.
And how about configuration of multiple network interfaces (wired, wireless, mobile broadband)?
Another thing that might be cool is if I could keep a separate configuration file that I could feed into the installer. That way I could initiate the installation process on several machines really fast based on my pre-made configuration file
]]>