Ubuntu "*-dev" package equivalent for Arch?

I'm just trying Arch for the first time, migrating from Ubuntu. I'm trying to set up as equivalent a system as I can, software-wise, from a list I kept of of key packages I installed on Ubuntu.
One thing Ubuntu does (for those unfamiliar with it) is the developers create a package with the compiled/configured binary, and sometimes they also create a development package to be used by other applications that rely on the original package. Ie, you might have "libgtk2.0" and "libgtk2.0-dev", which you usually install separately.
What's the equivalent of the Ubuntu "*-dev" packages on Arch?

Ubuntu devs separate them because that's how Debian does it, and it would be a waste of time to reintegrate them again, and it would be messy to not do it for the packages they build themselves but keep the split out headers for the packages they inherit from Debian.
Debian splits them up for the reason you said though . Without Debian, Ubuntu wouldn't be where it is today. People tend to forget that.

Similar Messages

Debian type package guidelines for Arch.

Well, maybe not as anal or strick.
With the recent breed of Debian based distro's coming out (Ubuntu in particular) and with a Debian release just around the corner, there has been a lot of talk regarding this distro. So I decided to take a closer look in this flavour of Linux.
I myself coming from Slackware, have heard and used (very little) Debian before in the past decided to take a look at how far this distro has come since my first encounter with it.
Reading a lot of the Slashdot comments and Osnews comments I noticed that the hardcore/avid Debian users made a lot of good argument points regarding the "superiority" of there distro compared to the rest.
They argue the ease of Apt-get/dpkg and how powerful these tools are and how you only need to install Debian once. Especially now that the installer has been given a huge facelift, it is much easier to install Debian than previous versions.
Now none of that really sounds very enticing as Arch has Pacman, with Arch's rolling-release packaging scheme and the fact that I think the Arch installer is by far the fastest install I have ever done of a Linux system before, I see no reason to use Debian in place of Arch, at least not for what I use my system for.
But the one thing that stood out that made a lot of sense was the fact that Debian has a very strict packaging guideline. Things for menu's, config files and the works all had a standard place in a Debian system, making all of the packages very intergrated and work well together on the same system. Due to these guidelines, one can argue that the package quality for a .DEB, compared to most others is much higher. That is not to say it's perfect, as even on the "stable" branch there are packages that don't always work, but that is very rare.
What I'm getting to is I think that Arch should adopt something similar. I didn't really think it through to much as it is just an idea and I want to see what others think of this.
Basically there should be an offical set of documents that outline where configs go (/etc usually) where large packages go (in Arch /opt) and menu entries etc. This way new maintainers or people who would like to learn Arch's packaging system would know the "right way" for an Arch system, which would, in my opinion, skip a lot of the headaches of malfunctioning packages in the repos.
Another thing Debian has which is an okay idea is they have a system in place that checks the packages being submitted to the repos follow the guidelines and if the packages don't check out they are rejected, as to keep the system clean regarding standards.
Now the AUR (I forget what it's called) system being developed does what again? I only heard about it but didn't do enough digging to find out what its for exactly.
I don't know how to explain my idea exactly, but I thought I would throw it out there anyway and see what people have to say, if anything at all .

We have a not-all-that-strict guideline in the official documentation...
http://www.archlinux.org/docs/en/guide/ … guidelines
And we don't have things like menu specifications, because we haven't figured them out yet.
We also have namcap which checks for some packaging guideline checking in iit.
Most of the stuff you talked about is there, in the works, or being planned.

Ubuntu look-alike gnome theme for arch linux

Is there any theme/gnome package(s) for arch linux that will give me gnome that looks kind of like the gnome package for ubuntu? I'm moving over from ubuntu to arch, and I'm hoping to ease the transition at first while I get used to the rest of the system. Thanks!
EDIT: Actually, how configurable is xfce? I've used gnome and kde for arch a bit, but they're just so vanilla, and I'm still looking for a relatively nice graphical interface on top of cli. Thanks!
Last edited by pythonscript (2009-07-27 23:29:40)

xfce4 is just about as configurable as GNOME at the level of gconf/ xfconf and way more configurable via the settings GUI.

How to compile for arch on Ubuntu without root?

Maybe this is not the right section, but since it is about compiling...
I have access to a rather powerful server, so I thought I could maybe compile some AUR packages like kernel-rc there. Unfortunately it runs ubuntu so gcc is still 4.4 and all the base libs don't match.
I thought about installing a minimal arch system in a chroot but you need root to chroot...
My next thought was crosscompiling gcc for ubuntu set up to crosscompile for arch... Doesn't sound fun to set up.
Any other ideas?

*edit: rephrasing*
Do you have (or can you get) permission to run a virtual machine on the server? I compile packages for i686 on x86_64 using a minimal (i686) Arch system in KVM and it works well. I find it to be very clean and easy to manage.
Last edited by Xyne (2010-05-05 12:29:52)

Backpac: A package state snapshot and restore tool for Arch Linux

backpac:
A package state snapshot and restore tool for Arch Linux with config file save/restore support.
https://aur.archlinux.org/packages.php?ID=52957
https://github.com/altercation/backpac (see readme on the github repository for more information)
Summary & Features
It's a common method of setting up a single system: take some notes about what packages you've installed, what files you've modified.
Backpac creates those notes for you and helps back up important configuration files. Specifically, backpac does the following:
maintains a list of installed groups (based on 80% of group packages being installed)
maintains a list of packages (including official and aur packages, listed separately)
maintains a list of files (manually created)
backs up key config files as detailed in the files list you create
The package, group and files lists along with the snapshot config files allows system state to be easily committed to version control such as git.
Backpac can also use these lists to install packages and files. Essentially, then, backpac takes a snapshot of your system and can recreate that state from the files and lists it archives.
Use Cases
Ongoing system state backup to github
Quick install of new system from existing backpac config
Conform current system to given state in backpac config
Backpac is a very, very lightweight way of saving and restoring system state.
It's not intended for rolling out and maintaining multiple similar systems, it's designed to assist individual users in the maintainance of their own Arch Linux box.
Status
Alpha, release for testing among those interested. Passing all tests right now but will continue to rework and refine. Bug reports needed.
Why?
There are a lot of 'big-iron' solutions to maintaining, backing up and restoring system state. Setting these up for a single system or a handful of personal systems has always seemed like overkill.
There are also some existing pacman list making utilities around, but most of them seem to list either all packages or don't separate the official and aur packages the way I wanted. Some detect group install state, some don't. I wanted all these features in backpac.
Finally, whatever tool I use, I'd like it to be simple (c.f. the Arch Way). Lists that are produced should be human readable, human maintainable and not different from what I'm using in non-automated form. Backpac fulfills these requirements.
Regarding files, I wanted to be able to backup arbitrary system files to a git repository. Tools like etckeeper are interesting but non /etc files in that case aren't backed up (without some link trickery) and there isn't any automatic integration with pacman, so there is no current advantage to using a tool like that. I also like making an explicit list of files to snapshot.
Sample Output
This is the command line report. Additionally, backpac saves this information to the backpac groups, packages and files lists and the files snapshot directory.
$ backpac -Qf
backpac
(-b) Backups ON; Files will be saved in place with backup suffix.
-f Force mode ON; No prompts presented (CAUTION).
(-F) Full Force mode OFF; Prompt displayed before script runs.
(-g) Suppress group check OFF; Groups will be checked for currency.
(-h) Display option and usage summary.
(-p) Default backpac: /home/es/.config/backpac/tau.
-Q Simple Query ON; Report shown; no changes made to system.
(-R) Auto-Remove OFF; Remove/Uninstall action default to NO.
(-S) System update OFF; No system files will be updated.
(-U) backpac config update OFF; backpac files will not be updated.
Sourcing from backpac config directory: /home/es/.config/backpac/tau
Initializing.................Done
GROUPS
============================================================================
/home/es/.config/backpac/tau/groups
GROUPS UP TO DATE: group listed in backpac and >80% local install:
base base-devel xfce4 xorg xorg-apps xorg-drivers xorg-fonts
GROUP PACKAGES; MISSING?: group member packages not installed:
(base: nano)
(xfce4: thunar xfdesktop)
PACKAGES
============================================================================
/home/es/.config/backpac/tau/packages
PACKAGES UP TO DATE: packages listed in backpac also installed on system:
acpi acpid acpitool aif alsa-utils augeas cowsay cpufrequtils curl dialog
firefox gamin git ifplugd iw mesa mesa-demos mutt netcfg openssh rfkill
rsync rxvt-unicode sudo terminus-font vim wpa_actiond wpa_supplicant_gui
xmobar xorg-server-utils xorg-twm xorg-utils xorg-xclock xorg-xinit xterm
yacpi yajl youtube-dl zsh
AUR UP TO DATE: aur packages listed in backpac also installed on system:
flashplugin-beta freetype2-git-infinality git-annex haskell-json
package-query-git packer wpa_auto xmonad-contrib-darcs xmonad-darcs
AUR NOT IN backpac: installed aur packages not listed in backpac config:
yaourt-git
FILES
============================================================================
/home/es/.config/backpac/tau/files
MATCHES ON SYSTEM/CONFIG:
/boot/grub/menu.lst
/etc/acpi/handler.sh
/etc/rc.conf
/etc/rc.local

firecat53 wrote:I think your plan for handling an AUR_HELPER is good. If AUR_HELPER is defined by the user, then either you might need a list of major AUR helpers and their command line switches so you can pick the correct switch for what needs to be done (most use some variation of -S for installing, but not all), or have the user define the correct switch(es) somehow for their chosen AUR helper.
That's a good idea. I'll add that to my AUR refactoring todo.
I also found directory tracking to be a weakness in other dotfile managers that I tried. I think you would definitely have to recursively list out the contents of a tracked directory and deal with each file individually. Wildcard support would be nice...I just haven't personally found a use case for it yet.
I've been thinking that I could just add the directory and scan through it for any non-default attribute files. If those are found then they get automatically added to the files list. That's pretty close to what etckeeper does.
Edit: I just compiled the dev version and removed my comments for already fixed things...sorry!
The master branch should have those fixes as well, but I didn't update the version number in the package build. I'll have to do that.
1. Still apparently didn't handle the escaped space for this item: (the file does exist on my system)
Ok, good to know. This wildcard directory business will require some new code and refactoring so I'll also rework my filenames handling.
2. Suggestion: you should make that awesome README into a man page!
I was working on one (the pkgbuild has a commented out line for the man page) but I had to leave it for later. Definitely want a man page. Once this stabilizes and I'm sure there aren't any big structural changes, I'll convert it to man format.
3. Suggestion: add the word 'dotfile' into your description somewhere on this page, the github page, and in the package description so people looking for dotfile managers will find it. You could also consider modularizing the script into a dotfile manager and the package manager, so people on other distros could take advantage of your dotfile management scheme.
I actually have a different script for dotfile management that doesn't touch packages, but there is definitely overlap with this one. That script isn't released yet, though, and if people find this useful for dotfile management that's great. I'll add that in.
4. Suggestion: since -Q is a read-only operation, why not just make it run with -f automatically to avoid the prompt?
Originally, running backpac without any command line options produced the Query output. I was concerned that since it is a utility that can potentially overwrite system files, it is important to give users a clear statement prior to execution about what will be done. Since the Query output is essentially the same as the Update and System reports in format and content, I wanted to be explicit about the Query being a passive no-change operation. The current command line options aren't set in stone though. If you feel strongly about it being different, let me know.
Long answer to a short question
5. Another suggestion: any thought to providing some sort of 'scrub' function to remove private information from the stored files if desired? This would be cool for publishing public dotfiles to github. Perhaps a credentials file (I did this with python for my own configs). Probably detecting email addresses and passwords without a scrub file would be rather difficult because dotfiles come in so many flavors.
Yes, absolutely. In fact, if you look at the lib/local file (pretty sure it's in both master and dev branches in this state) you'll see some references to a sanitize function. The idea there is that the user will list out bash associative arrays like this:
SANITIZE_WPA_=(
[FILE]='/etc/wpa_supplicant.conf'
[CMD]='sed s/expungepattern/sanitizedoutput/g'
Question: am I missing an obvious option to remove a file from the files.d directory if I delete it from the files list? Or do I have to delete it manually? It might be helpful to add a section to the README on how to update and delete dotfiles from being tracked, and also a more detailed description of what the -b option does (and what is actually created when it's not used).
You are only missing the function I didn't finish. There should be either dummy code or a TODO in the backpac main script referencing garbage collection, which isn't difficult but I just haven't finished it. The idea being another loop of "hey I found these old files in your files.d, mind if I delete them?" It's on my list and I'll try to get it in asap.
And finally, just out of curiosity, why did you choose to actually copy the files instead of symlink like so many other dotfile managers do?
git not following symlinks, hardlinks also out for permissions issues (git wouldn't be able to read the files, change them, etc.)
I definitely would prefer to not make an entire copy of the file, but I haven't come up with a better option. Shout with ideas, though. Also, if there is a way around the link issues I noted above, let me know. I don't see one but that doesn't mean it's not there.
edit: I think a Seattle area Arch meetup would be cool! Perhaps coffee someplace? Bellevue? U-district? Anyone else? BYOPOL (bring your own pimped out laptop)
A general meetup sounds good. I was also thinking it would be fun to do a mini archcon with some demos.

Palaver speech recognition app packaged for Arch

Palaver (formerly Ubuntu-Speech-Recognition), has been packaged for Arch:
https://aur.archlinux.org/packages/palaver-git/
The git repo is located here:
https://github.com/JamezQ/Palaver
A great video demo of what is possible can be found here:
http://www.techdrivein.com/2013/02/ubun … -demo.html
This is shaping up to be an interesting project, and as long as it keeps on a good development track, could become the Siri of Linux (don't laugh, it could!)
The current code is beta, and will be going through restructuring changes as it moves from git to launchpad, so expect a lot of changes in the near future.
The beta can actually do quite a lot at the moment, especially if you add your own dictionary (which is very easy to do BTW).
Oh, and just a warning regarding privacy, the application uses Googles speech recognition, and requires a network connection to work. Your voice command is recorded locally and deciphered on Google servers.......
Cheers.

Xyne wrote:
Padfoot wrote:Oh, and just a warning regarding privacy, the application uses Googles speech recognition, and requires a network connection to work. Your voice command is recorded locally and deciphered on Google servers........
Oh well. Aside from the privacy concerns* I am also disappointed that it is just a wrapper around a web service. A local speech recognition engine would be even more impressive.
Thanks for the privacy warning.
* Seriously, sending speech samples to Google so that they can store and analyse them is crazy to me. Do you really want to live in a future of interactive advertisements that can identify you by voice alone and associate it with everything else that you have ever done online? A conversation with a friend at a bus stop may one day trigger targeted ads that reveal things about you that you consider private. I do not understand how so many people can be completely ok with having their private lives catalogued for companies and governments just to get some non-essential services in return. Beyond that having such tools lying around when your government eventually becomes oppressive will ensure its longevity at everyone's expense. Open, democratic societies have an unpatched memory leak that requires a hard reboot every so often.
I completely understand, and while a local engine would be teriffic, the only one I can think of on Linux with any potential is sphinx. Unfortunately, (last time I checked) it's not in an easily useable state, yet. I should check out the pace of development on that project. Of course, I would be delighted to be proven wrong on this project.
And while this in no way is intended to dispell any privacy concerns, or justify any possible motives of the companies providing online deciphering, I am guessing this is exactly whar Siri does on Apple products. Also, as Palaver is currently targeting Ubuntu (while still being agnostic enough to easily work on any distro), It needs to have a small footprint considering the push at Ubuntu towards mobile devices. Unfortunately, mobile devices do not lend to local storage of the many samples in multiple languages required to perform the deciphering.
Cheers.
[EDIT] While Palaver is a wrapper around an online service, the wrapper is limited to sending the voice sample and getting a string of text back, the application performs the task of deciphering the meaning of the text and taking the appropriate action based on local dictionaries and plugins.[/EDIT]
Last edited by Padfoot (2013-03-23 22:21:13)

System encryption using LUKS and GPG encrypted keys for arch linux

Update: As of 2012-03-28, arch changed from gnupg 1.4 to 2.x which uses pinentry for the password dialog. The "etwo" hook described here doesn't work with gnupg 2. Either use the openssl hook below or use a statically compiled version of gnupg 1.4.
Update: As of 2012-12-19, the mkinitcpio is not called during boot, unless the "install" file for the hook contains "add_runscript". This resulted in an unbootable system for me. Also, the method name was changed from install () to build ().
Update: 2013-01-13: Updated the hook files using the corrections by Deth.
Note: This guide is a bit dated now, in particular the arch installation might be different now. But essentially, the approach stays the same. Please also take a look at the posts further down, specifically the alternative hooks that use openssl.
I always wanted to set up a fully encrypted arch linux server that uses gpg encrypted keyfiles on an external usb stick and luks for root filesystem encryption. I already did it once in gentoo using this guide. For arch, I had to play alot with initcpio hooks and after one day of experimentation, I finally got it working. I wrote a little guide for myself which I'm going to share here for anyone that might be interested. There might be better or easier ways, like I said this is just how I did it. I hope it might help someone else. Constructive feedback is always welcome
Intro
Using arch linux mkinitcpio's encrypt hook, one can easily use encrypted root partitions with LUKS. It's also possible to use key files stored on an external drive, like an usb stick. However, if someone steals your usb stick, he can just copy the key and potentially access the system. I wanted to have a little extra security by additionally encrypting the key file with gpg using a symmetric cipher and a passphrase.
Since the encrypt hook doesn't support this scenario, I created a modifed hook called “etwo” (silly name I know, it was the first thing that came to my mind). It will simply look if the key file has the extension .gpg and, if yes, use gpg to decrypt it, then pipe the result into cryptsetup.
Conventions
In this short guide, I use the following disk/partition names:
/dev/sda: is the hard disk that will contain an encrypted swap (/dev/sda1), /var (/dev/sda2) and root (/dev/sda3) partition.
/dev/sdb is the usb stick that will contain the gpg encrypted luks keys, the kernel and grub. It will have one partition /dev/sdb1 formatted with ext2.
/dev/mapper/root, /dev/mapper/swap and /dev/mapper/var will be the encrypted devices.
Credits
Thanks to the authors of SECURITY_System_Encryption_DM-Crypt_with_LUKS (gentoo wiki), System Encryption with LUKS (arch wiki), mkinitcpio (arch wiki) and Early Userspace in Arch Linux (/dev/brain0 blog)!
Guide
1. Boot the arch live cd
I had to use a newer testing version, because the 2010.05 cd came with a broken gpg. You can download one here: http://releng.archlinux.org/isos/. I chose the “core“ version. Go ahead and boot the live cd, but don't start the setup yet.
2. Set keymap
Use km to set your keymap. This is important for non-qwerty keyboards to avoid suprises with passphrases...
3. Wipe your discs
ATTENTION: this will DELETE everything on /dev/sda and /dev/sdb forever! Do not blame me for any lost data!
Before encrypting the hard disc, it has to be completely wiped and overwritten with random data. I used shred for this. Others use badblocks or dd with /dev/urandom. Either way, this will take a long time, depending on the size of your disc. I also wiped my usb stick just to be sure.
shred -v /dev/sda
shred -v /dev/sdb
4. Partitioning
Fire up fdisk and create the following partitions:
/dev/sda1, type linux swap.
/dev/sda2: type linux
/dev/sda3: type linux
/dev/sdb1, type linux
Of course you can choose a different layout, this is just how I did it. Keep in mind that only the root filesystem will be decrypted by the initcpio. The rest will be decypted during normal init boot using /etc/crypttab, the keys being somewhere on the root filesystem.
5. Format and mount the usb stick
Create an ext2 filesystem on /dev/sdb1:
mkfs.ext2 /dev/sdb1
mkdir /root/usb
mount /dev/sdb1 /root/usb
cd /root/usb # this will be our working directory for now.
Do not mount anything to /mnt, because the arch installer will use that directory later to mount the encrypted root filesystem.
6. Configure the network (if not already done automatically)
ifconfig eth0 192.168.0.2 netmask 255.255.255.0
route add default gw 192.168.0.1
echo "nameserver 192.168.0.1" >> /etc/resolv.conf
(this is just an example, your mileage may vary)
7. Install gnupg
pacman -Sy
pacman -S gnupg
Verify that gnupg works by launching gpg.
8. Create the keys
Just to be sure, make sure swap is off:
cat /proc/swaps
should return no entries.
Create gpg encrypted keys (remember, we're still in our working dir /root/usb):
dd if=/dev/urandom bs=512 count=4 | gpg -v --cipher-algo aes256 --digest-algo sha512 -c -a > root.gpg
dd if=/dev/urandom bs=512 count=4 | gpg -v --cipher-algo aes256 --digest-algo sha512 -c -a > var.gpg
Choose a strong password!!
Don't do this in two steps, e.g don't do dd to a file and then gpg on that file. The key should never be stored in plain text on an unencrypted device, except if that device is wiped on system restart (ramfs)!
Note that the default cipher for gpg is cast5, I just chose to use a different one.
9. Create the encrypted devices with cryptsetup
Create encrypted swap:
cryptsetup -c aes-cbc-essiv:sha256 -s 256 -h whirlpool -d /dev/urandom create swap /dev/sda1
You should see /dev/mapper/swap now. Don't format nor turn it on for now. This will be done by the arch installer.
Important: From the Cryptsetup 1.1.2 Release notes:
Cryptsetup can accept passphrase on stdin (standard input). Handling of new line (\n) character is defined by input specification:
if keyfile is specified as "-" (using --key-file=- or by positional argument in luksFormat and luksAddKey, like cat file | cryptsetup --key-file=- <action> ), input is processed
as normal binary file and no new line is interpreted.
if there is no key file specification (with default input from stdin pipe like echo passphrase | cryptsetup <action> ) input is processed as input from terminal, reading will
stop after new line is detected.
If I understand this correctly, since the randomly generated key can contain a newline early on, piping the key into cryptsetup without specifying --key-file=- could result in a big part of the key to be ignored by cryptsetup. Example: if the random key was "foo\nandsomemorebaratheendofthekey", piping it directly into cryptsetup without --key-file=- would result in cryptsetup using only "foo" as key which would have big security implications. We should therefor ALWAYS pipe the key into cryptsetup using --key-file=- which ignores newlines.
gpg -q -d root.gpg 2>/dev/null | cryptsetup -v -–key-file=- -c aes-cbc-essiv:sha256 -s 256 -h whirlpool luksFormat /dev/sda3
gpg -q -d var.gpg 2>/dev/null | cryptsetup -v –-key-file=- -c aes-cbc-essiv:sha256 -s 256 -h whirlpool -v luksFormat /dev/sda2
Check for any errors.
10. Open the luks devices
gpg -d root.gpg 2>/dev/null | cryptsetup -v –-key-file=- luksOpen /dev/sda3 root
gpg -d var.gpg 2>/dev/null | cryptsetup -v –-key-file=- luksOpen /dev/sda2 var
If you see /dev/mapper/root and /dev/mapper/var now, everything is ok.
11. Start the installer /arch/setup
Follow steps 1 to 3.
At step 4 (Prepare hard drive(s), select “3 – Manually Configure block devices, filesystems and mountpoints. Choose /dev/sdb1 (the usb stick) as /boot, /dev/mapper/swap for swap, /dev/mapper/root for / and /dev/mapper/var for /var.
Format all drives (choose “yes” when asked “do you want to have this filesystem (re)created”) EXCEPT for /dev/sdb1, choose “no”. Choose the correct filesystem for /dev/sdb1, ext2 in my case. Use swap for /dev/mapper/swap. For the rest, I chose ext4.
Select DONE to start formatting.
At step 5 (Select packages), select grub as boot loader. Select the base group. Add mkinitcpio.
Start step 6 (Install packages).
Go to step 7 (Configure System).
By sure to set the correct KEYMAP, LOCALE and TIMEZONE in /etc/rc.conf.
Edit /etc/fstab:
/dev/mapper/root / ext4 defaults 0 1
/dev/mapper/swap swap swap defaults 0 0
/dev/mapper/var /var ext4 defaults 0 1
# /dev/sdb1 /boot ext2 defaults 0 1
Configure the rest normally. When you're done, setup will launch mkinitcpio. We'll manually launch this again later.
Go to step 8 (install boot loader).
Be sure to change the kernel line in menu.lst:
kernel /vmlinuz26 root=/dev/mapper/root cryptdevice=/dev/sda3:root cryptkey=/dev/sdb1:ext2:/root.gpg
Don't forget the :root suffix in cryptdevice!
Also, my root line was set to (hd1,0). Had to change that to
root (hd0,0)
Install grub to /dev/sdb (the usb stick).
Now, we can exit the installer.
12. Install mkinitcpio with the etwo hook.
Create /mnt/lib/initcpio/hooks/etwo:
#!/usr/bin/ash
run_hook() {
/sbin/modprobe -a -q dm-crypt >/dev/null 2>&1
if [ -e "/sys/class/misc/device-mapper" ]; then
if [ ! -e "/dev/mapper/control" ]; then
/bin/mknod "/dev/mapper/control" c $(cat /sys/class/misc/device-mapper/dev | sed 's|:| |')
fi
[ "${quiet}" = "y" ] && CSQUIET=">/dev/null"
# Get keyfile if specified
ckeyfile="/crypto_keyfile"
usegpg="n"
if [ "x${cryptkey}" != "x" ]; then
ckdev="$(echo "${cryptkey}" | cut -d: -f1)"
ckarg1="$(echo "${cryptkey}" | cut -d: -f2)"
ckarg2="$(echo "${cryptkey}" | cut -d: -f3)"
if poll_device "${ckdev}" ${rootdelay}; then
case ${ckarg1} in
*[!0-9]*)
# Use a file on the device
# ckarg1 is not numeric: ckarg1=filesystem, ckarg2=path
if [ "${ckarg2#*.}" = "gpg" ]; then
ckeyfile="${ckeyfile}.gpg"
usegpg="y"
fi
mkdir /ckey
mount -r -t ${ckarg1} ${ckdev} /ckey
dd if=/ckey/${ckarg2} of=${ckeyfile} >/dev/null 2>&1
umount /ckey
# Read raw data from the block device
# ckarg1 is numeric: ckarg1=offset, ckarg2=length
dd if=${ckdev} of=${ckeyfile} bs=1 skip=${ckarg1} count=${ckarg2} >/dev/null 2>&1
esac
fi
[ ! -f ${ckeyfile} ] && echo "Keyfile could not be opened. Reverting to passphrase."
fi
if [ -n "${cryptdevice}" ]; then
DEPRECATED_CRYPT=0
cryptdev="$(echo "${cryptdevice}" | cut -d: -f1)"
cryptname="$(echo "${cryptdevice}" | cut -d: -f2)"
else
DEPRECATED_CRYPT=1
cryptdev="${root}"
cryptname="root"
fi
warn_deprecated() {
echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"
echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."
if poll_device "${cryptdev}" ${rootdelay}; then
if /sbin/cryptsetup isLuks ${cryptdev} >/dev/null 2>&1; then
[ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
dopassphrase=1
# If keyfile exists, try to use that
if [ -f ${ckeyfile} ]; then
if [ "${usegpg}" = "y" ]; then
# gpg tty fixup
if [ -e /dev/tty ]; then mv /dev/tty /dev/tty.backup; fi
cp -a /dev/console /dev/tty
while [ ! -e /dev/mapper/${cryptname} ];
do
sleep 2
/usr/bin/gpg -d "${ckeyfile}" 2>/dev/null | cryptsetup --key-file=- luksOpen ${cryptdev} ${cryptname} ${CSQUIET}
dopassphrase=0
done
rm /dev/tty
if [ -e /dev/tty.backup ]; then mv /dev/tty.backup /dev/tty; fi
else
if eval /sbin/cryptsetup --key-file ${ckeyfile} luksOpen ${cryptdev} ${cryptname} ${CSQUIET}; then
dopassphrase=0
else
echo "Invalid keyfile. Reverting to passphrase."
fi
fi
fi
# Ask for a passphrase
if [ ${dopassphrase} -gt 0 ]; then
echo ""
echo "A password is required to access the ${cryptname} volume:"
#loop until we get a real password
while ! eval /sbin/cryptsetup luksOpen ${cryptdev} ${cryptname} ${CSQUIET}; do
sleep 2;
done
fi
if [ -e "/dev/mapper/${cryptname}" ]; then
if [ ${DEPRECATED_CRYPT} -eq 1 ]; then
export root="/dev/mapper/root"
fi
else
err "Password succeeded, but ${cryptname} creation failed, aborting..."
exit 1
fi
elif [ -n "${crypto}" ]; then
[ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
msg "Non-LUKS encrypted device found..."
if [ $# -ne 5 ]; then
err "Verify parameter format: crypto=hash:cipher:keysize:offset:skip"
err "Non-LUKS decryption not attempted..."
return 1
fi
exe="/sbin/cryptsetup create ${cryptname} ${cryptdev}"
tmp=$(echo "${crypto}" | cut -d: -f1)
[ -n "${tmp}" ] && exe="${exe} --hash \"${tmp}\""
tmp=$(echo "${crypto}" | cut -d: -f2)
[ -n "${tmp}" ] && exe="${exe} --cipher \"${tmp}\""
tmp=$(echo "${crypto}" | cut -d: -f3)
[ -n "${tmp}" ] && exe="${exe} --key-size \"${tmp}\""
tmp=$(echo "${crypto}" | cut -d: -f4)
[ -n "${tmp}" ] && exe="${exe} --offset \"${tmp}\""
tmp=$(echo "${crypto}" | cut -d: -f5)
[ -n "${tmp}" ] && exe="${exe} --skip \"${tmp}\""
if [ -f ${ckeyfile} ]; then
exe="${exe} --key-file ${ckeyfile}"
else
exe="${exe} --verify-passphrase"
echo ""
echo "A password is required to access the ${cryptname} volume:"
fi
eval "${exe} ${CSQUIET}"
if [ $? -ne 0 ]; then
err "Non-LUKS device decryption failed. verify format: "
err " crypto=hash:cipher:keysize:offset:skip"
exit 1
fi
if [ -e "/dev/mapper/${cryptname}" ]; then
if [ ${DEPRECATED_CRYPT} -eq 1 ]; then
export root="/dev/mapper/root"
fi
else
err "Password succeeded, but ${cryptname} creation failed, aborting..."
exit 1
fi
else
err "Failed to open encryption mapping: The device ${cryptdev} is not a LUKS volume and the crypto= paramater was not specified."
fi
fi
rm -f ${ckeyfile}
fi
Create /mnt/lib/initcpio/install/etwo:
#!/bin/bash
build() {
local mod
add_module dm-crypt
if [[ $CRYPTO_MODULES ]]; then
for mod in $CRYPTO_MODULES; do
add_module "$mod"
done
else
add_all_modules '/crypto/'
fi
add_dir "/dev/mapper"
add_binary "cryptsetup"
add_binary "dmsetup"
add_binary "/usr/bin/gpg"
add_file "/usr/lib/udev/rules.d/10-dm.rules"
add_file "/usr/lib/udev/rules.d/13-dm-disk.rules"
add_file "/usr/lib/udev/rules.d/95-dm-notify.rules"
add_file "/usr/lib/initcpio/udev/11-dm-initramfs.rules" "/usr/lib/udev/rules.d/11-dm-initramfs.rules"
add_runscript
help ()
cat<<HELPEOF
This hook allows for an encrypted root device with support for gpg encrypted key files.
To use gpg, the key file must have the extension .gpg and you have to install gpg and add /usr/bin/gpg
to your BINARIES var in /etc/mkinitcpio.conf.
HELPEOF
Edit /mnt/etc/mkinitcpio.conf (only relevant sections displayed):
MODULES=”ext2 ext4” # not sure if this is really nessecary.
BINARIES=”/usr/bin/gpg” # this could probably be done in install/etwo...
HOOKS=”base udev usbinput keymap autodetect pata scsi sata usb etwo filesystems” # (usbinput is only needed if you have an usb keyboard)
Copy the initcpio stuff over to the live cd:
cp /mnt/lib/initcpio/hooks/etwo /lib/initcpio/hooks/
cp /mnt/lib/initcpio/install/etwo /lib/initcpio/install/
cp /mnt/etc/mkinitcpio.conf /etc/
Verify your LOCALE, KEYMAP and TIMEZONE in /etc/rc.conf!
Now reinstall the initcpio:
mkinitcpio -g /mnt/boot/kernel26.img
Make sure there were no errors and that all hooks were included.
13. Decrypt the "var" key to the encrypted root
mkdir /mnt/keys
chmod 500 /mnt/keys
gpg –output /mnt/keys/var -d /mnt/boot/var.gpg
chmod 400 /mnt/keys/var
14. Setup crypttab
Edit /mnt/etc/crypttab:
swap /dev/sda1 SWAP -c aes-cbc-essiv:sha256 -s 256 -h whirlpool
var /dev/sda2 /keys/var
15. Reboot
We're done, you may reboot. Make sure you select the usb stick as the boot device in your bios and hope for the best. . If it didn't work, play with grub's settings or boot from the live cd, mount your encrypted devices and check all settings. You might also have less trouble by using uuid's instead of device names. I chose device names to keep things as simple as possible, even though it's not the optimal way to do it.
Make backups of your data and your usb stick and do not forget your password(s)! Or you can say goodbye to your data forever...
Last edited by fabriceb (2013-01-15 22:36:23)

I'm trying to run my install script that is based on https://bbs.archlinux.org/viewtopic.php?id=129885
Decrypting the gpg key after grub works, but then "Devce root already exists." appears every second.
any idea ?
#!/bin/bash
# This script is designed to be run in conjunction with a UEFI boot using Archboot intall media.
# prereqs:
# EFI "BIOS" set to boot *only* from EFI
# successful EFI boot of Archboot USB
# mount /dev/sdb1 /src
set -o nounset
#set -o errexit
# Host specific configuration
# this whole script needs to be customized, particularly disk partitions
# and configuration, but this section contains global variables that
# are used during the system configuration phase for convenience
HOSTNAME=daniel
USERNAME=user
# Globals
# We don't need to set these here but they are used repeatedly throughout
# so it makes sense to reuse them and allow an easy, one-time change if we
# need to alter values such as the install target mount point.
INSTALL_TARGET="/install"
HR="--------------------------------------------------------------------------------"
PACMAN="pacman --noconfirm --config /tmp/pacman.conf"
TARGET_PACMAN="pacman --noconfirm --config /tmp/pacman.conf -r ${INSTALL_TARGET}"
CHROOT_PACMAN="pacman --noconfirm --cachedir /var/cache/pacman/pkg --config /tmp/pacman.conf -r ${INSTALL_TARGET}"
FILE_URL="file:///packages/core-$(uname -m)/pkg"
FTP_URL='ftp://mirrors.kernel.org/archlinux/$repo/os/$arch'
HTTP_URL='http://mirrors.kernel.org/archlinux/$repo/os/$arch'
# Functions
# I've avoided using functions in this script as they aren't required and
# I think it's more of a learning tool if you see the step-by-step
# procedures even with minor duplciations along the way, but I feel that
# these functions clarify the particular steps of setting values in config
# files.
SetValue () {
# EXAMPLE: SetValue VARIABLENAME '\"Quoted Value\"' /file/path
VALUENAME="$1" NEWVALUE="$2" FILEPATH="$3"
sed -i "s+^#\?$${VALUENAME}$=.*$+\1=${NEWVALUE}+" "${FILEPATH}"
CommentOutValue () {
VALUENAME="$1" FILEPATH="$2"
sed -i "s/^$${VALUENAME}.*$$/#\1/" "${FILEPATH}"
UncommentValue () {
VALUENAME="$1" FILEPATH="$2"
sed -i "s/^#$${VALUENAME}.*$$/\1/" "${FILEPATH}"
# Initialize
# Warn the user about impending doom, set up the network on eth0, mount
# the squashfs images (Archboot does this normally, we're just filling in
# the gaps resulting from the fact that we're doing a simple scripted
# install). We also create a temporary pacman.conf that looks for packages
# locally first before sourcing them from the network. It would be better
# to do either *all* local or *all* network but we can't for two reasons.
# 1. The Archboot installation image might have an out of date kernel
# (currently the case) which results in problems when chrooting
# into the install mount point to modprobe efivars. So we use the
# package snapshot on the Archboot media to ensure our kernel is
# the same as the one we booted with.
# 2. Ideally we'd source all local then, but some critical items,
# notably grub2-efi variants, aren't yet on the Archboot media.
# Warn
timer=9
echo -e "\n\nMAC WARNING: This script is not designed for APPLE MAC installs and will potentially misconfigure boot to your existing OS X installation. STOP NOW IF YOU ARE ON A MAC.\n\n"
echo -n "GENERAL WARNING: This procedure will completely format /dev/sda. Please cancel with ctrl-c to cancel within $timer seconds..."
while [[ $timer -gt 0 ]]
do
sleep 1
let timer-=1
echo -en "$timer seconds..."
done
echo "STARTING"
# Get Network
echo -n "Waiting for network address.."
#dhclient eth0
dhcpcd -p eth0
echo -n "Network address acquired."
# Mount packages squashfs images
umount "/packages/core-$(uname -m)"
umount "/packages/core-any"
rm -rf "/packages/core-$(uname -m)"
rm -rf "/packages/core-any"
mkdir -p "/packages/core-$(uname -m)"
mkdir -p "/packages/core-any"
modprobe -q loop
modprobe -q squashfs
mount -o ro,loop -t squashfs "/src/packages/archboot_packages_$(uname -m).squashfs" "/packages/core-$(uname -m)"
mount -o ro,loop -t squashfs "/src/packages/archboot_packages_any.squashfs" "/packages/core-any"
# Create temporary pacman.conf file
cat << PACMANEOF > /tmp/pacman.conf
[options]
Architecture = auto
CacheDir = ${INSTALL_TARGET}/var/cache/pacman/pkg
CacheDir = /packages/core-$(uname -m)/pkg
CacheDir = /packages/core-any/pkg
[core]
Server = ${FILE_URL}
Server = ${FTP_URL}
Server = ${HTTP_URL}
[extra]
Server = ${FILE_URL}
Server = ${FTP_URL}
Server = ${HTTP_URL}
#Uncomment to enable pacman -Sy yaourt
[archlinuxfr]
Server = http://repo.archlinux.fr/\$arch
PACMANEOF
# Prepare pacman
[[ ! -d "${INSTALL_TARGET}/var/cache/pacman/pkg" ]] && mkdir -m 755 -p "${INSTALL_TARGET}/var/cache/pacman/pkg"
[[ ! -d "${INSTALL_TARGET}/var/lib/pacman" ]] && mkdir -m 755 -p "${INSTALL_TARGET}/var/lib/pacman"
${PACMAN} -Sy
${TARGET_PACMAN} -Sy
# Install prereqs from network (not on archboot media)
echo -e "\nInstalling prereqs...\n$HR"
#sed -i "s/^#S/S/" /etc/pacman.d/mirrorlist # Uncomment all Server lines
UncommentValue S /etc/pacman.d/mirrorlist # Uncomment all Server lines
${PACMAN} --noconfirm -Sy gptfdisk btrfs-progs-unstable libusb-compat gnupg
# Configure Host
# Here we create three partitions:
# 1. efi and /boot (one partition does double duty)
# 2. swap
# 3. our encrypted root
# Note that all of these are on a GUID partition table scheme. This proves
# to be quite clean and simple since we're not doing anything with MBR
# boot partitions and the like.
echo -e "format\n"
# shred -v /dev/sda
# disk prep
sgdisk -Z /dev/sda # zap all on disk
#sgdisk -Z /dev/mmcb1k0 # zap all on sdcard
sgdisk -a 2048 -o /dev/sda # new gpt disk 2048 alignment
#sgdisk -a 2048 -o /dev/mmcb1k0
# create partitions
sgdisk -n 1:0:+200M /dev/sda # partition 1 (UEFI BOOT), default start block, 200MB
sgdisk -n 2:0:+4G /dev/sda # partition 2 (SWAP), default start block, 200MB
sgdisk -n 3:0:0 /dev/sda # partition 3, (LUKS), default start, remaining space
#sgdisk -n 1:0:1800M /dev/mmcb1k0 # root.gpg
# set partition types
sgdisk -t 1:ef00 /dev/sda
sgdisk -t 2:8200 /dev/sda
sgdisk -t 3:8300 /dev/sda
#sgdisk -t 1:0700 /dev/mmcb1k0
# label partitions
sgdisk -c 1:"UEFI Boot" /dev/sda
sgdisk -c 2:"Swap" /dev/sda
sgdisk -c 3:"LUKS" /dev/sda
#sgdisk -c 1:"Key" /dev/mmcb1k0
echo -e "create gpg file\n"
# create gpg file
dd if=/dev/urandom bs=512 count=4 | gpg -v --cipher-algo aes256 --digest-algo sha512 -c -a > /root/root.gpg
echo -e "format LUKS on root\n"
# format LUKS on root
gpg -q -d /root/root.gpg 2>/dev/null | cryptsetup -v --key-file=- -c aes-xts-plain -s 512 --hash sha512 luksFormat /dev/sda3
echo -e "open LUKS on root\n"
gpg -d /root/root.gpg 2>/dev/null | cryptsetup -v --key-file=- luksOpen /dev/sda3 root
# NOTE: make sure to add dm_crypt and aes_i586 to MODULES in rc.conf
# NOTE2: actually this isn't required since we're mounting an encrypted root and grub2/initramfs handles this before we even get to rc.conf
# make filesystems
# following swap related commands not used now that we're encrypting our swap partition
#mkswap /dev/sda2
#swapon /dev/sda2
#mkfs.ext4 /dev/sda3 # this is where we'd create an unencrypted root partition, but we're using luks instead
echo -e "\nCreating Filesystems...\n$HR"
# make filesystems
mkfs.ext4 /dev/mapper/root
mkfs.vfat -F32 /dev/sda1
#mkfs.vfat -F32 /dev/mmcb1k0p1
echo -e "mount targets\n"
# mount target
#mount /dev/sda3 ${INSTALL_TARGET} # this is where we'd mount the unencrypted root partition
mount /dev/mapper/root ${INSTALL_TARGET}
# mount target
mkdir ${INSTALL_TARGET}
# mkdir ${INSTALL_TARGET}/key
# mount -t vfat /dev/mmcb1k0p1 ${INSTALL_TARGET}/key
mkdir ${INSTALL_TARGET}/boot
mount -t vfat /dev/sda1 ${INSTALL_TARGET}/boot
# Install base, necessary utilities
mkdir -p ${INSTALL_TARGET}/var/lib/pacman
${TARGET_PACMAN} -Sy
${TARGET_PACMAN} -Su base
# curl could be installed later but we want it ready for rankmirrors
${TARGET_PACMAN} -S curl
${TARGET_PACMAN} -S libusb-compat gnupg
${TARGET_PACMAN} -R grub
rm -rf ${INSTALL_TARGET}/boot/grub
${TARGET_PACMAN} -S grub2-efi-x86_64
# Configure new system
SetValue HOSTNAME ${HOSTNAME} ${INSTALL_TARGET}/etc/rc.conf
sed -i "s/^$127\.0\.0\.1.*$$/\1 ${HOSTNAME}/" ${INSTALL_TARGET}/etc/hosts
SetValue CONSOLEFONT Lat2-Terminus16 ${INSTALL_TARGET}/etc/rc.conf
#following replaced due to netcfg
#SetValue interface eth0 ${INSTALL_TARGET}/etc/rc.conf
# write fstab
# You can use UUID's or whatever you want here, of course. This is just
# the simplest approach and as long as your drives aren't changing values
# randomly it should work fine.
cat > ${INSTALL_TARGET}/etc/fstab <<FSTAB_EOF
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
tmpfs /tmp tmpfs nodev,nosuid 0 0
/dev/sda1 /boot vfat defaults 0 0
/dev/mapper/cryptswap none swap defaults 0 0
/dev/mapper/root / ext4 defaults,noatime 0 1
FSTAB_EOF
# write etwo
mkdir -p /lib/initcpio/hooks/
mkdir -p /lib/initcpio/install/
cp /src/etwo_hooks /lib/initcpio/hooks/etwo
cp /src/etwo_install /lib/initcpio/install/etwo
mkdir -p ${INSTALL_TARGET}/lib/initcpio/hooks/
mkdir -p ${INSTALL_TARGET}/lib/initcpio/install/
cp /src/etwo_hooks ${INSTALL_TARGET}/lib/initcpio/hooks/etwo
cp /src/etwo_install ${INSTALL_TARGET}/lib/initcpio/install/etwo
# write crypttab
# encrypted swap (random passphrase on boot)
echo cryptswap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> ${INSTALL_TARGET}/etc/crypttab
# copy configs we want to carry over to target from install environment
mv ${INSTALL_TARGET}/etc/resolv.conf ${INSTALL_TARGET}/etc/resolv.conf.orig
cp /etc/resolv.conf ${INSTALL_TARGET}/etc/resolv.conf
mkdir -p ${INSTALL_TARGET}/tmp
cp /tmp/pacman.conf ${INSTALL_TARGET}/tmp/pacman.conf
# mount proc, sys, dev in install root
mount -t proc proc ${INSTALL_TARGET}/proc
mount -t sysfs sys ${INSTALL_TARGET}/sys
mount -o bind /dev ${INSTALL_TARGET}/dev
echo -e "umount boot\n"
# we have to remount /boot from inside the chroot
umount ${INSTALL_TARGET}/boot
# Create install_efi script (to be run *after* chroot /install)
touch ${INSTALL_TARGET}/install_efi
chmod a+x ${INSTALL_TARGET}/install_efi
cat > ${INSTALL_TARGET}/install_efi <<EFI_EOF
# functions (these could be a library, but why overcomplicate things
SetValue () { VALUENAME="\$1" NEWVALUE="\$2" FILEPATH="\$3"; sed -i "s+^#\?$\${VALUENAME}$=.*\$+\1=\${NEWVALUE}+" "\${FILEPATH}"; }
CommentOutValue () { VALUENAME="\$1" FILEPATH="\$2"; sed -i "s/^$\${VALUENAME}.*$\$/#\1/" "\${FILEPATH}"; }
UncommentValue () { VALUENAME="\$1" FILEPATH="\$2"; sed -i "s/^#$\${VALUENAME}.*$\$/\1/" "\${FILEPATH}"; }
echo -e "mount boot\n"
# remount here or grub et al gets confused
mount -t vfat /dev/sda1 /boot
# mkinitcpio
# NOTE: intel_agp drm and i915 for intel graphics
SetValue MODULES '\\"dm_mod dm_crypt aes_x86_64 ext2 ext4 vfat intel_agp drm i915\\"' /etc/mkinitcpio.conf
SetValue HOOKS '\\"base udev pata scsi sata usb usbinput keymap consolefont etwo encrypt filesystems\\"' /etc/mkinitcpio.conf
SetValue BINARIES '\\"/usr/bin/gpg\\"' /etc/mkinitcpio.conf
mkinitcpio -p linux
# kernel modules for EFI install
modprobe efivars
modprobe dm-mod
# locale-gen
UncommentValue de_AT /etc/locale.gen
locale-gen
# install and configure grub2
# did this above
#${CHROOT_PACMAN} -Sy
#${CHROOT_PACMAN} -R grub
#rm -rf /boot/grub
#${CHROOT_PACMAN} -S grub2-efi-x86_64
# you can be surprisingly sloppy with the root value you give grub2 as a kernel option and
# even omit the cryptdevice altogether, though it will wag a finger at you for using
# a deprecated syntax, so we're using the correct form here
# NOTE: take out i915.modeset=1 unless you are on intel graphics
SetValue GRUB_CMDLINE_LINUX '\\"cryptdevice=/dev/sda3:root cryptkey=/dev/sda1:vfat:/root.gpg add_efi_memmap i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 pcie_aspm=force quiet\\"' /etc/default/grub
# set output to graphical
SetValue GRUB_TERMINAL_OUTPUT gfxterm /etc/default/grub
SetValue GRUB_GFXMODE 960x600x32,auto /etc/default/grub
SetValue GRUB_GFXPAYLOAD_LINUX keep /etc/default/grub # comment out this value if text only mode
# install the actual grub2. Note that despite our --boot-directory option we will still need to move
# the grub directory to /boot/grub during grub-mkconfig operations until grub2 gets patched (see below)
grub_efi_x86_64-install --bootloader-id=grub --no-floppy --recheck
# create our EFI boot entry
# bug in the HP bios firmware (F.08)
efibootmgr --create --gpt --disk /dev/sda --part 1 --write-signature --label "ARCH LINUX" --loader "\\\\grub\\\\grub.efi"
# copy font for grub2
cp /usr/share/grub/unicode.pf2 /boot/grub
# generate config file
grub-mkconfig -o /boot/grub/grub.cfg
exit
EFI_EOF
# Install EFI using script inside chroot
chroot ${INSTALL_TARGET} /install_efi
rm ${INSTALL_TARGET}/install_efi
# Post install steps
# anything you want to do post install. run the script automatically or
# manually
touch ${INSTALL_TARGET}/post_install
chmod a+x ${INSTALL_TARGET}/post_install
cat > ${INSTALL_TARGET}/post_install <<POST_EOF
set -o errexit
set -o nounset
# functions (these could be a library, but why overcomplicate things
SetValue () { VALUENAME="\$1" NEWVALUE="\$2" FILEPATH="\$3"; sed -i "s+^#\?$\${VALUENAME}$=.*\$+\1=\${NEWVALUE}+" "\${FILEPATH}"; }
CommentOutValue () { VALUENAME="\$1" FILEPATH="\$2"; sed -i "s/^$\${VALUENAME}.*$\$/#\1/" "\${FILEPATH}"; }
UncommentValue () { VALUENAME="\$1" FILEPATH="\$2"; sed -i "s/^#$\${VALUENAME}.*$\$/\1/" "\${FILEPATH}"; }
# root password
echo -e "${HR}\\nNew root user password\\n${HR}"
passwd
# add user
echo -e "${HR}\\nNew non-root user password (username:${USERNAME})\\n${HR}"
groupadd sudo
useradd -m -g users -G audio,lp,optical,storage,video,games,power,scanner,network,sudo,wheel -s /bin/bash ${USERNAME}
passwd ${USERNAME}
# mirror ranking
echo -e "${HR}\\nRanking Mirrors (this will take a while)\\n${HR}"
cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.orig
mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.all
sed -i "s/#S/S/" /etc/pacman.d/mirrorlist.all
rankmirrors -n 5 /etc/pacman.d/mirrorlist.all > /etc/pacman.d/mirrorlist
# temporary fix for locale.sh update conflict
mv /etc/profile.d/locale.sh /etc/profile.d/locale.sh.preupdate || true
# yaourt repo (add to target pacman, not tmp pacman.conf, for ongoing use)
echo -e "\\n[archlinuxfr]\\nServer = http://repo.archlinux.fr/\\\$arch" >> /etc/pacman.conf
echo -e "\\n[haskell]\\nServer = http://www.kiwilight.com/\\\$repo/\\\$arch" >> /etc/pacman.conf
# additional groups and utilities
pacman --noconfirm -Syu
pacman --noconfirm -S base-devel
pacman --noconfirm -S yaourt
# sudo
pacman --noconfirm -S sudo
cp /etc/sudoers /tmp/sudoers.edit
sed -i "s/#\s*$%wheel\s*ALL=(ALL)\s*ALL.*$$/\1/" /tmp/sudoers.edit
sed -i "s/#\s*$%sudo\s*ALL=(ALL)\s*ALL.*$$/\1/" /tmp/sudoers.edit
visudo -qcsf /tmp/sudoers.edit && cat /tmp/sudoers.edit > /etc/sudoers
# power
pacman --noconfirm -S acpi acpid acpitool cpufrequtils
yaourt --noconfirm -S powertop2
sed -i "/^DAEMONS/ s/)/ @acpid)/" /etc/rc.conf
sed -i "/^MODULES/ s/)/ acpi-cpufreq cpufreq_ondemand cpufreq_powersave coretemp)/" /etc/rc.conf
# following requires my acpi handler script
echo "/etc/acpi/handler.sh boot" > /etc/rc.local
# time
pacman --noconfirm -S ntp
sed -i "/^DAEMONS/ s/hwclock /!hwclock @ntpd /" /etc/rc.conf
# wireless (wpa supplicant should already be installed)
pacman --noconfirm -S iw wpa_supplicant rfkill
pacman --noconfirm -S netcfg wpa_actiond ifplugd
mv /etc/wpa_supplicant.conf /etc/wpa_supplicant.conf.orig
echo -e "ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=network\nupdate_config=1" > /etc/wpa_supplicant.conf
# make sure to copy /etc/network.d/examples/wireless-wpa-config to /etc/network.d/home and edit
sed -i "/^DAEMONS/ s/)/ @net-auto-wireless @net-auto-wired)/" /etc/rc.conf
sed -i "/^DAEMONS/ s/ network / /" /etc/rc.conf
echo -e "\nWIRELESS_INTERFACE=wlan0" >> /etc/rc.conf
echo -e "WIRED_INTERFACE=eth0" >> /etc/rc.conf
echo "options iwlagn led_mode=2" > /etc/modprobe.d/iwlagn.conf
# sound
pacman --noconfirm -S alsa-utils alsa-plugins
sed -i "/^DAEMONS/ s/)/ @alsa)/" /etc/rc.conf
mv /etc/asound.conf /etc/asound.conf.orig || true
#if alsamixer isn't working, try alsamixer -Dhw and speaker-test -Dhw -c 2
# video
pacman --noconfirm -S base-devel mesa mesa-demos
# x
#pacman --noconfirm -S xorg xorg-xinit xorg-utils xorg-server-utils xdotool xorg-xlsfonts
#yaourt --noconfirm -S xf86-input-wacom-git # NOT NEEDED? input-wacom-git
#TODO: cut down the install size
#pacman --noconfirm -S xorg-server xorg-xinit xorg-utils xorg-server-utils
# TODO: wacom
# environment/wm/etc.
#pacman --noconfirm -S xfce4 compiz ccsm
#pacman --noconfirm -S xcompmgr
#yaourt --noconfirm -S physlock unclutter
#pacman --noconfirm -S rxvt-unicode urxvt-url-select hsetroot
#pacman --noconfirm -S gtk2 #gtk3 # for taffybar?
#pacman --noconfirm -S ghc
# note: try installing alex and happy from cabal instead
#pacman --noconfirm -S haskell-platform haskell-hscolour
#yaourt --noconfirm -S xmonad-darcs xmonad-contrib-darcs xcompmgr
#yaourt --noconfirm -S xmobar-git
# TODO: edit xfce to use compiz
# TODO: xmonad, but deal with video tearing
# TODO: xmonad-darcs fails to install from AUR. haskell dependency hell.
# switching to cabal
# fonts
pacman --noconfirm -S terminus-font
yaourt --noconfirm -S webcore-fonts
yaourt --noconfirm -S fontforge libspiro
yaourt --noconfirm -S freetype2-git-infinality
# TODO: sed infinality and change to OSX or OSX2 mode
# and create the sym link from /etc/fonts/conf.avail to conf.d
# misc apps
#pacman --noconfirm -S htop openssh keychain bash-completion git vim
#pacman --noconfirm -S chromium flashplugin
#pacman --noconfirm -S scrot mypaint bc
#yaourt --noconfirm -S task-git stellarium googlecl
# TODO: argyll
POST_EOF
# Post install in chroot
#echo "chroot and run /post_install"
chroot /install /post_install
rm /install/post_install
# copy grub.efi file to the default HP EFI boot manager path
mkdir -p ${INSTALL_TARGET}/boot/EFI/Microsoft/BOOT/
mkdir -p ${INSTALL_TARGET}/boot/EFI/BOOT/
cp ${INSTALL_TARGET}/boot/grub/grub.efi ${INSTALL_TARGET}/boot/EFI/Microsoft/BOOT/bootmgfw.efi
cp ${INSTALL_TARGET}/boot/grub/grub.efi ${INSTALL_TARGET}/boot/EFI/BOOT/BOOTX64.EFI
cp /root/root.gpg ${INSTALL_TARGET}/boot/
# NOTES/TODO

Is there a python-dev package?

I can't compile python-sexy from aur because python headers not found:
checking for headers required to compile python extensions... not found
configure: error: could not find Python headers
is there python-dev package in arch?
What can i do?
Last edited by gaara (2007-11-15 05:48:58)

I have base-devel and the problem continue, I found my python headers with python-config --cflags, but i don't know what does python-sexy not found those libraries
Last edited by gaara (2007-11-15 16:25:02)

Landscape for Arch

Hi everyone,
The title says it all: Is there a program like landscape on Ubuntu, for Arch?
It looks rather commercialized so i would wager there is not, but I am specifically looking for the trick it does with the ssh MOTD, printing out system stats and package upgrades when you log in.
Thanks
Last edited by MystX (2010-08-08 11:31:19)

You can run remote commands using ssh. For example, to get a list of installed packages on "computer," you can run
ssh user@computer 'pacman -Qq'
A login script to query each of your computers could work for system stats, package upgrades, etc.
To avoid typing the password for every machine, you can use public key cryptography (see, for example, http://www.csua.berkeley.edu/~ranga/not … pass.html).

Documentation Project for Arch [UPDATE]

I read this topic about the popularity about Arch and it kept me thinking for a couple of weeks.
I'm really devoted to Arch and I'd like to start a professionally-aimed Documentation site for Arch Linux with an appropiate installation guide and other guides for installing X.Org, Servering, Desktop-stuff etc.
My question is: how would you feel about it? Anyone who wants to collaborate? Tips? Suggestions?
Upon your responses I will post my 'plan' with a concept lay-out and system based on your input and my thoughts within the next two weeks. I'm only able to do Dutch and English.
:arrow: [UPDATE #2: Contents]
Ok, I've taken notice of all your comments. Many thanks! However, I was wondering which categories "slash" manuals their should be. I was thinking about the following:
1. Guides
* [AInsG] Arch Installation Guide
Covers the Arch Installation from retrieving an ISO to the bash-prompt.
* [ADskG] Arch Desktop Guide
Covers the installation and configuration of software desktop users mostly use like: Gnome, KDE, Cups, Codecs, Gimp. Stuff like that. Installation from Bash Prompt to X.Org with software.
* [ASvrG] Arch Server Guide
Covers the installation and configuration of software that servers run, like: NTP, Apache, MySQL, PostegreSQL, PHP, FTP, SSH, etc.
* [APkgG] Arch Packaging and Maintenance Guide
Covers the deep internals of Pacman, ABS and buildpkg. How to maintain, update, install, make packages etc. What to do if things fail, etc.
* [AKnlG] Arch Kernel Compilation Guide
Discusses how to compile your own kernel. I think it just should be there for user convenience.
* [ADevG] Arch Developer Guide
Covers the installation of software developers use.
* [ASecG] Arch Security Guide[/i]
Learns the user how to secure your Arch installation thoroughly.
2. Categories
* Guides
Guides like I've listed above.
* Howto's
Maintained Howto's and a link to ArchWiki for unmaintained Howto's.
* Advisory
When you maintain a linux installation you come across many odds and weirds. Newcomers don't know these things cause they haven't experienced these odss and weirds yet. So we could place that here for convenience. For example: XFS works perfectly normal, but Grub may hang. Or the fact that on some systems Ati drivers are unstable. That kinda stuff.
* Community
References to other parts of Arch Linux, like the BBS, Wiki and Homepage and the policies for writing documentation etc.
Conclusion
So, this is what I come up with. What do you all think?
:arrow: [UPDATE #1: Why no wiki & quality notices]
I've taken notice of the first four posts and I have to make something clear. The wiki is not the way professional documention should be taken care of. I'm really thinking about a 'Documentation Project' rather than a dumpplace on the net where every moron can simply post his experiences. Just look at the wiki. Just look at it!
What I was thinking of is to build (Me, PHP/MySQL dev) an Arch Documentation webapplication (or deploy and customize an existing system) and form a project team consisting of a couple of really devoted people, including myself, to write and maintain documentation.
And if people have comments on the docs, they can discuss it at Arch BBS here, perhaps a new room for Arch Documentation Project?
In my opinion the quality of documentation should be highly improved and I don't think letting everyone collaborate is a good idea. Especially not if I look at the Arch Wiki.
:!: Oh, and one last note. I don't hate wiki or want it to disappear. I think there should be two places: one place for us all where we can freely collaborate (wiki) and one place (Arch Doc Project) where official and maintained docs are held.
So, any thoughts upon this? Let me know please. I'll keep on track.

The advantage of having a documentation team is that its possible to enforce high standards and strict quality control. As a result, you cover important topics that are always up to date. The documentation can cover Arch, GNOME, KDE and Other WM's installations as well as other guides relating to the ABS and managing your Arch install. This falls under the category of "Official Documentation".
In contrast, I think its important to maintain a separate wiki where members of the community are free to contribute. A documentation team could NOT keep up with every possible guide. For documentation other than the "Official Doco" that I've described above, I think the Wiki is appropriate. Gentoo follows a similar model with their official documentation and a separate Gentoo-Wiki (Which is completely 3rd party AFAIK). Gentoo is renowned for its excellent documentation, and through a dedicated documentation team we may be able to produce a similar, or even better result.
This doesnt change the fact that the existing Wiki needs some cleaning up in areas. I'd also propose a "Standard" of how Wiki's should be layed out, and an example of a "Good" and "Bad" entry. In addition, you'd need a watchdog to issue quality notices where appropriate.
I'm no programmer, so I'd love to be able to contribute to the Arch community in some form, and documentation seems ideal for me. Therefore, I'm putting forward my interest in this project. I've always heard various other people complain about the documentation on Arch, and I think it's an appropriate step.

Checkinstall-like prog for arch?

I was wondering if there was a more direct way of installing source via pacman. I could do the ABS thing if I understood better how to find deps, but as it is I can't make heads or tails of what's required in a pkgbuild vs what's optional. I understand that having pacman manage packages is a better solution than "make install" but I'm having a hard time groking how to do it more simply.
An example is that when I used pacman to install dvd::rip a while ago, the version of lsdvd packaged with it was incorrect. This was easy enough to fix - it took 30 seconds to download and another minute to compile a new version. It would have taken me hours to figure out how to make a pkgbuild template for lsdvd. Even if it wouldn't have, it would have taken a pretty good chunk of time just to fill out the template. Of course, when a week or so later lsdvd was updated via pacman, it collided with my compiled version, and I had to rm mine to get the pacman upgrade to do its thing. Not a biggie with a single file, but it could get very ugly very fast, obviously.
I assume that if there was a checkinstall-like program for arch, I'd have read posts about it/have been able to google for it. If there is no other solution, does anyone have any good pointers for ABS how-tos beyond the wiki page? I'm a rank-newbie at the arch way, though not at all a linux newbie, and not averse to reading. I just find that often the wiki entries assume a certain level of prior knowledge that I just don't seem to have. Help a n00b out?

Snarkout wrote:I could do the ABS thing if I understood better how to find deps
Emmm... read the app's website, read the README file. Worst case, run ./configure and see what it gives out about.
Snarkout wrote:I can't make heads or tails of what's required in a pkgbuild vs what's optional.
You'll pick up what's required by doing the above - as a rule, we don't include optional deps.
Snarkout wrote:It would have taken me hours to figure out how to make a pkgbuild template for lsdvd.
You can get the PKGBUILD for any official Arch package from CVS, or create the ABS tree on your system - Item 6 on the ABS wiki page. Either way, checking out the devs' PKGBUILDs is very informative.
Snarkout wrote:Of course, when a week or so later lsdvd was updated .. I had to rm mine to get the pacman upgrade to do its thing. Not a biggie with a single file, but it could get very ugly very fast, obviously.
A good reason to do it the Arch way from the start, right?
Snarkout wrote:If there is no other solution, does anyone have any good pointers for ABS how-tos beyond the wiki page?
I don't know of any others. Try it, and post your questions, I'd say. I know I was in your position when I started with Arch - I expect many of us were.
Of course, maybe creapkg or one of the others will help you, but I reckon it would be worth your while learning it from scratch - I certainly never regretted it.

Implementing Quickly for Arch Linux

Ubuntu has recently begun promoting a tool called Quickly which is aimed at providing developers with an easier way of developing and sharing new applications. It provides commands to create new projects with all the boilerplate gtk/glade code already in place, but more importantly, it allows very simple publishing of applications to launchpad, and optionally to create packages for distribution to the Ubuntu repos.
Quickly can be found with description from Ubuntu here: https://wiki.ubuntu.com/Quickly
Would it be interesting to have something similar for Arch? Quickly is supposed to be very flexible and easily adapted to new distros.
Any thoughts?

Quickly wrote:programming on Linux should be easy and fun. However, it's not easy and fun because it is too hard to learn. It is too hard to learn because there are too many choices, and too much information to wade through.
not sure how popular the idea of this would be with the arch community
A couple things you could do, build it yourself or contact the maintainer and ask them to please update the package for you (good luck). updating the PKGBUILD is easy enough if you read the documentation, else you can just download the source and build it from scratch using the provided install instructions.
also I'm pretty sure that this package is NOT out of date, but instead not updated to handle Arch's shift from python2-3. so all that should be required is small updates to a few of the scripts, and installing the immense number of dependencies
Last edited by Cyrusm (2011-01-11 22:51:40)

Pinux mouse icon theme for Arch

I just created an arch variant of the pingux mouse icon theme. I thought I might share it .
PKGBUILD
# Contributor: pressh <pressh>
pkgname=pArch
pkgver=1.0
pkgrel=1
pkgdesc="Pinux icon theme for Arch"
url="http://www.archlinux.org"
license="gpl"
source=(pArch-1.0.tar.bz2)
depends=('xorg-clients')
makedepends=('xorg-apps')
md5sums=('b9bc4d5dd6180449a03423f3ea174cde')
build() {
cd $startdir/src/$pkgname-$pkgver
./Build.sh
mkdir -p $startdir/pkg/usr/share/icons/pArch/cursors
cd cursors
install -Dm644 * $startdir/pkg/usr/share/icons/pArch/cursors
Get the file from here
Put both files in the same directory, and run makepkg and install with pacman -A
Well, that's it, if someone wants to make a package of it, or upload the archive on some decent space, you're free to do so 8)
And of course a screenshot

Romashka wrote:
pressh wrote:I will post instructions for a 32x32 version soon.
Thank you!
P.S.: I've already uploaded updated xcursor-pinux to AUR.
I created a new archive, which holds both 24x24 and 32x32 versions. Also I noticed that the old 24x24 version had wrong sized cursors in it, which is now corrected. I guess everything should be okay now.
The new archive can be found here
About the ubuntu theme, I have no idea. If some of their cursors are better, we should replace some in the arch theme as well

Aperture missing "Picture Package"equivalent to photoshop???

Correct me if I am wrong, but it seems that aperture is limited to printing very crude contact sheets that really do not compare to photoshops "picture package".
Basically I tried to print two 8x12s(different images) on a 13x19 photo paper. Ultimately I ended up going into photoshop where I resized the two images to 8x12s and positioned them onto a new 13x19 canvas. This then was a newly created file that I reimported back into aperture. I know this is not really a good work flow, but it seems that aperture has not even thought out a very crude picture package equivalent to photoshop
Also there is no measurement showing inches just pixels. It would be nice if they could show a ruler layout on the image it self similar to photoshop. Resizing in photoshop is much more practicle and straight forward.
I here that lightroom is far better for printing packages also.
Does any one agree about these shortcommings???

This is a glaring omission that has been noted since day 1 of Aperture 1.0, made more frustrating by the very robust printing features available in Lightroom. Surely Apple is aware of the problem, and hopefully they will find a fix in 1.6 or 2.0 or whatever comes next, but it's aggravating to know that a fairly sophisticated app like Aperture requires shareware oddities like ImageBuddy or Portraits-n-Prints in order to get packages working.
Time to fix this one, Apple. (Get the book tool working usefully while you're at it too!)

Automated build server for Arch? (like the sourceforge build system)

Has someone considered some kind of automated build system for Arch?
Something that would work like this:
- It'd have every library and dependency possible installed.
- It'd intelligently read the makefiles produced to see what libraries they used and compare them against a lookup table to see what Arch dependencies they then required. Failing that, it could use ldd and a second lookup table that matched libraries to packages.
- It'd attempt to figure out the target binary to run (again, from the makefiles produced), and then run it. If it worked, it'd be marked as usable. If it didn't work, it'd be marked as needing fixing.
All of these points can fail, especially in the parsing of the makefiles; in each case, this would be noted by the system and user action could be taken.
In operation, it wouldn't take away from users managing their own packages. It'd just provide a secure environment to build packages in, and attempt to automate some of the process. In the best cases, the system would theoretically be capable enough to download a package's sourcecode, ./configure it, make it, make a package out of it, get the package verified as usable, then update the repo with it.
Note the verification step in the previous paragraph: I would never want this to be an automated system. Sure, it sound amazing on paper, and might even work for a little while, but sooner or later something would come crashing down and since repo management is quite a trust-based issue, everyone would freak out and they wouldn't want the build server anymore.
-dav7
Last edited by dav7 (2008-10-17 18:41:22)

Who would have access to upload to such a build server? If it's the general public, then this is a security nightmare, as well as a growth curve nightmare. The monetary investment for a project like this would need to come from somewhere.
And yeah, something like this has been considered, and a working proof-of-concept has been sitting around for years. http://projects.archlinux.org/?p=pacbuild.git;a=summary . What this kind of project really needs is someone with some distributed computing smarts and dedication (and time) to get it off the ground in a form that will survive past a proof-of-concept barebones implementation.
One of the largest design challenges would be dependency resolution for batch upgrades. For instance, let's say we update libfoobar, which is depended upon by foo, bar, baz, and batman, the system needs to know that libfoobar needs to be built and installed in order to compile the rest of them against it.

Ubuntu "*-dev" package equivalent for Arch?

Similar Messages

Maybe you are looking for