For details see the second patch. First patch is to avoid code duplication.
This is based from my experimental branch (wating for ACK to merge in master).
Just building the baseline profile is sufficient to test it.
qemu-img create -f qcow2 /tmp/persi.qcow2 1G
qemu -cdrom archlinux-2011.08.23-i686.iso -hda /tmp/persi.qcow2 -boot d
Create one partiton, make an ext2/3/4 filesystem, set a label, reboot,
add to kernel cmdline cow_label=MY_LABEL, and enjoy.
I've been working on an AIF module for a while and yesterday posted a brief
note on the forum and exchanged a mail or two with Dieter about it. I'd welcome
feedback on it from the releng team and would like to cover an issue I'm
having during install from the ISO that appears to be either filesystem or
makepkg related. Archiso team feedback would be great, in particular since this
only occurs when run from ISO (which doesn't mean it's related to archiso, but
archiso team members might at least be able to tell me why it isn't if that's
I'll pop into #archlinux-releng as well later (nick altercation).
* Keep your system config in version control. Access locally or remotely
(github currently supported, framework in place for other dvcs/hosts)
* Separate hardware specific packages, configuration files,
and values from other profile scope. (implemented already)
* Add overlay files and expanded configuration values to AIF installation.
(implemented already). The systems/lenovo/x220/profile in github is an
example of a hardware specific profile that makes good use of overlays.
* Access the profile at install time from the Arch ISO via AIF
(figtree automatic procedure; already implemented)
* Easily update the profile from a live system; easily update
a live system from the profile. (partial procedures; work in progress)
The readme on the github page should be fairly comprehensive. I haven't
implemented user config/home directory functions but it's one of the next
big features to work on (I've already implemented it in an older script;
much of this is rewriting / refactoring of those older, non AIF functions).
Feedback on architecture
I hope this isn't off topic for releng and welcome feedback about the general
approach I've taken. I hope that figtree might become useful for others,
particular in regards to sharing hardware specific install starter configs.
I was hoping that system profiles might serve as an adjunct to the arch wiki
in terms of sharing config file samples, for instance.
The implementation as it stands, while not trivial, is up for revision. For
instance, the functions I am using in the profiles (packages/daemons/config)
are, I think, easy to understand and not needlessly abstracted or complex. It's
possible to do away with them entirely and just have the user add values to a
variable instead (CONFIG_CHANGES+=("more changes")) but I felt that this was
more error prone and potentially harder to scan.
Ultimately, I wanted to keep it simple and stick to DRY / DROP (don't repeat
other people) principles. Dieter's AIF architecture really works for this and
I hope that figtree might evolve into something useful that allows dvcs based
sharing. I'd like to actively solicit feedback on this here.
Install Issue (archiso team feedback requested)
(maybe split this mail thread if this is best handled separately)
I'd very much like to support AUR packages in this module as, particularly
for specific hardware, I rely on AUR to get the system functioning 100%.
I have the code in place to do this and many AUR packages work well during
install from a plain Arch ISO and a custom profile.
In some cases, during the installation of a aur-test profile, I am
encountering hundreds of the following errors once I hit the makepkg on
weechat-git in my aur-test profile (as sourced below). It happens during git
cloning in makepkg, so I thought it might be cache related?
Buffer I/O errors
sprinkled with an occasional
EXT4-fs This should not happen!!
I can reproduce this in a virtual machine using the following commands
after booting into a plain Arch ISO 2011.08.19 (the following should
work for any of you as well; I'd welcome other testers of this):
# aif -p partial-configure-network
# aif -p http://github.com/altercation/figtree/raw/master/procedures/automatic \\
-c profiles/aur-test -a
(the latter is of course all one command, -a is the flag to activate AUR
package install for my module)
I thought it might be related to running out of disk space because I was
using the runtime /tmp directory and it wasn't mounted where I thought, but
I've tested with running makepkg in /mnt/tmp as well with the same problem.
Precision Colors - Solarized - http://ethanschoonover.com/solarized
I am working on this now, the support is very basic, but I think the
most important symbols are remapped.
I created a scripts that generated *.ktl files from [kbd] package using
keytab-lilo. I also patch this program in this script, so can use map
thats needs unicode.
In some cases we have:
* two maps versions one non-unicode and other unicode.
* Non-unicode and other unicode but them are the same (keep with one)
* one map non-unicode only
* one map unicode only
* nothing because conversion fails.
The script also makes syslinux submenus (in a really basic way, no fancy
titles), also converts filenames to be more ISO-9660 friendly.
So the steps to implements this are:
* Make a package from generated files from the script.
* Install this package in build.sh
* Copy kbdmap/ directory (from installed package) to syslinux/
* Add to syslinux.cfg these lines:
MENU BEGIN kbdmap
MENU LABEL Change Keyboard Map
After you selected the desired keymap, syslinux drops to boot: prompt,
just hitting enter, returns to main menu (do in this way for now, at
least at this moment I can not find a way that does not reset keyboard
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1