https://wiki.archlinux.org/api.php?action=feedcontributions&user=Idupree&feedformat=atom
ArchWiki - User contributions [en]
2024-03-28T11:15:33Z
User contributions
MediaWiki 1.41.0
https://wiki.archlinux.org/index.php?title=PulseAudio&diff=242925
PulseAudio
2013-01-04T02:13:56Z
<p>Idupree: fix bitrotted link</p>
<hr />
<div>[[Category:Audio/Video]]<br />
[[cs:PulseAudio]]<br />
[[es:PulseAudio]]<br />
[[fr:PulseAudio]]<br />
[[it:PulseAudio]]<br />
[[pt:PulseAudio]]<br />
[[ru:PulseAudio]]<br />
[[tr:PulseAudio]]<br />
[[Wikipedia:PulseAudio|PulseAudio]] is the default sound server that serves as a proxy to sound applications using existing kernel sound components like [[ALSA]] or [[OSS]]. Since [[ALSA]] is included in Arch Linux by default so the most common deployment scenarios include PulseAudio with [[ALSA]].<br />
<br />
{{Article summary start}}<br />
{{Article summary text|'''PulseAudio''' is a general purpose sound server. For a list of features, see [[Wikipedia:PulseAudio#Features]].}}<br />
{{Article summary heading|Related Articles}}<br />
{{Article summary wiki|PulseAudio/Examples}}<br />
{{Article summary end}}<br />
<br />
==Installation==<br />
*Required PKG: {{Pkg|pulseaudio}}<br />
*Optional GUIs: {{Pkg|paprefs}} and {{Pkg|pavucontrol}}<br />
*Optional volume control via mapped keyboard keys: {{AUR|pulseaudio_ctl}}<br />
*Optional console mixer: {{AUR|ponymix-git}} and {{AUR|pamixer-git}}<br />
*Optional system tray icon: {{AUR|pasystray-git}}<br />
*Optional kde plasma applet: {{AUR|kdeplasma-applets-veromix}}<br />
<br />
==Running==<br />
{{Note|Pulseaudio requires [[D-Bus]] to function.}}<br />
{{Note|Most X11 environments start pulseaudio automatically with the X11 session.}}<br />
<br />
In the unlikely event that pulseaudio is not automatically called upon entering X, it can can be started with:<br />
$ pulseaudio --start<br />
<br />
PulseAudio can be stopped with:<br />
$ pulseaudio --kill<br />
<br />
==Equalizer==<br />
<br />
Newer pulseaudio versions have an intergrated 10-band equalizer system. In order to use the equalizer do the following:<br />
<br />
===Load equalizer sink module===<br />
<br />
$ pactl load-module module-equalizer-sink<br />
<br />
===Install and run the gui frontend===<br />
<br />
# pacman -S --needed python2-pyqt<br />
<br />
$ qpaeq<br />
<br />
{{Note|If qpaeq has no effect, install pavucontrol and change "ALSA Playback on" to "FFT based equalizer on ..." while the media player is running.}}<br />
<br />
===Load equalizer module on every boot===<br />
<br />
Edit the file {{ic|/etc/pulse/default.pa}} with your favorite editor and append the following lines:<br />
<br />
### Load the integrated pulseaudio equalizer module<br />
load-module module-equalizer-sink<br />
<br />
==Backend Configuration==<br />
<br />
{{Out of date|Arch has moved to systemd and rc.conf is now deprecated.}}<br />
<br />
===ALSA===<br />
*Recommended PKG: {{Pkg|pulseaudio-alsa}}<br />
*Optional PKGs: {{Pkg|lib32-libpulse}} and {{Pkg|lib32-alsa-plugins}}<br />
<br />
{{Note|Optional PKGs are needed only if running x86_64 and wanting to have sound for 32 bit programs (like Wine).}}<br />
<br />
For the applications that do not support PulseAudio and support ALSA it is '''recommended''' to install the PulseAudio plugin for ALSA. This package also contains the necessary {{ic|/etc/asound.conf}} for configuring ALSA to use PulseAudio.<br />
<br />
To prevent applications from using ALSA's OSS emulation and bypassing Pulseaudio (thereby preventing other applications from playing sound), make sure the module {{ic|snd_pcm_oss}} is not in the {{ic|MODULES}} array in {{ic|/etc/[[rc.conf]]}}. If it is currently loaded (<code>lsmod|grep oss</code>), disable it by executing:<br />
# rmmod snd_pcm_oss<br />
<br />
===ALSA/dmix without grabbing hardware device===<br />
{{Note|This section describes alternative configuration, which is generally NOT recommended.}}<br />
<br />
You may want to use ALSA directly in most of your applications and to be able to use other applications, which constantly require PulseAudio at the same time. The following steps allow you to make PulseAudio use dmix instead of grabbing ALSA hardware device.<br />
<br />
*Remove package {{Pkg|pulseaudio-alsa}}, which provides compatibility layer between ALSA applications and PulseAudio. After this your ALSA apps will use ALSA directly without being hooked by Pulse.<br />
$ sudo pacman -R pulseaudio-alsa<br />
<br />
*Edit {{ic|/etc/pulse/default.pa}}.<br />
:Find and uncomment lines which load backend drivers. Add '''device''' parameters as follows. Then find and comment lines which load autodetect modules.<br />
load-module module-alsa-sink '''device=dmix'''<br />
load-module module-alsa-source '''device=dsnoop'''<br />
# load-module module-udev-detect<br />
# load-module module-detect<br />
<br />
*''Optional:'' If you use {{Pkg|kdemultimedia-kmix}} you may want to control ALSA volume instead of PulseAudio volume:<br />
$ echo export KMIX_PULSEAUDIO_DISABLE=1 > ~/.kde4/env/kmix_disable_pulse.sh<br />
$ chmod +x ~/.kde4/env/kmix_disable_pulse.sh<br />
<br />
*Now, reboot your computer and try running alsa and pulseaudio applications at the same time. They both should produce sound simultaneously.<br />
:Use {{Pkg|pavucontrol}} to control PulseAudio volume if needed.<br />
<br />
===OSS===<br />
There are multiple ways of making OSS-only programs play to PulseAudio:<br />
<br />
====ossp====<br />
Start {{Pkg|ossp}} with:<br />
rc.d start osspd<br />
<br />
Afterwards, add it to DAEMONS in {{ic|rc.conf}}.<br />
<br />
====padsp wrapper (part of PulseAudio)====<br />
Programs using OSS can work with PulseAudio by starting it with padsp:<br />
<br />
$ padsp OSSprogram<br />
A few examples:<br />
$ padsp aumix<br />
$ padsp sox foo.wav -t ossdsp /dev/dsp<br />
<br />
One can also rename the {{ic|OSSprogram-bin}} binary and replace it with a script like this: <br />
{{hc|/usr/bin/OSSProgram|<nowiki><br />
#!/bin/sh<br />
if test -x /usr/bin/padsp; then<br />
exec /usr/bin/padsp /usr/bin/OSSprogram-bin "$@"<br />
else<br />
exec /usr/bin/OSSprogram "$@"<br />
fi<br />
</nowiki>}}<br />
<br />
===GStreamer===<br />
To make [[GStreamer]] use PulseAudio, you need to install {{Pkg|gstreamer0.10-good-plugins}}, execute {{ic|gstreamer-properties}} (part of ''gnome-media'' package) and select ''PulseAudio Sound Server'' in both Audio Input and Output. Alternatively, this can be done by setting the gconf variables {{ic|/system/gstreamer/0.10/default/audiosink}} to ''pulsesink'' and {{ic|/system/gstreamer/0.10/default/audiosrc}} to ''pulsesrc'':<br />
$ gconftool-2 -t string --set /system/gstreamer/0.10/default/audiosink pulsesink<br />
$ gconftool-2 -t string --set /system/gstreamer/0.10/default/audiosrc pulsesrc<br />
<br />
Some applications (like Rhythmbox) ignore the ''audiosink'' property, but rely instead on ''musicaudiosink'', which cannot be configured using {{ic|gstreamer-properties}} but needs to be manually set using {{ic|gconf-editor}} or the {{ic|gconftool-2}}:<br />
$ gconftool-2 -t string --set /system/gstreamer/0.10/default/musicaudiosink pulsesink<br />
<br />
===OpenAL===<br />
OpenAL Soft should use PulseAudio by default, but can be explicitly configured to do so: {{hc|/etc/openal/alsoft.conf|2=drivers=pulse,alsa}}<br />
<br />
===libao===<br />
Edit the libao configuration file:<br />
{{hc|/etc/libao.conf|2=default_driver=pulse}}<br />
<br />
===ESD===<br />
PulseAudio is a drop-in replacement for the enlightened sound daemon (ESD). While PulseAudio is running, ESD clients should be able to output to it without configuration.<br />
<br />
==Desktop Environments==<br />
===General X11===<br />
{{Note|As mentioned previously, PulseAudio is very likely launched automatically via either {{ic|/etc/X11/xinit/xinitrc.d/pulseaudio}} or the files in {{ic|/etc/xdg/autostart/}} if users have some DE installed.}}<br />
<br />
Check to see if PulseAudio is running:<br />
<br />
$ ps aux | grep pulse<br />
facade 1794 0.0 0.0 360464 6532 ? S<l 15:33 0:00 /usr/bin/pulseaudio --start<br />
facade 1827 0.0 0.0 68888 2608 ? S 15:33 0:00 /usr/lib/pulse/gconf-helper<br />
<br />
If Pulseaudio is not running and users are using X, the following will start PulseAudio with the needed the X11 plugins manually:<br />
$ start-pulseaudio-x11<br />
<br />
If you are not running Gnome, KDE or XFCE and your {{ic|~/.xinitrc}} does not source the scripts in {{ic|/etc/X11/xinit/xinitrc.d}} (such as is done in the example file {{ic|/etc/skel/.xinitrc}}) then you can launch PulseAudio on boot by adding the following line to ~/.xinitrc:<br />
/usr/bin/start-pulseaudio-x11<br />
<br />
===GNOME===<br />
As of GNOME 3, GNOME fully integrates with PulseAudio and no extra configuration is needed.<br />
<br />
===KDE 3===<br />
PulseAudio is ''not'' a drop-in replacement for aRts. Users of KDE 3 cannot use PulseAudio. However note, recent versions of PulseAudio may have eliminated the prohibition:<br />
<br />
See: http://www.pulseaudio.org/wiki/PerfectSetup KDE 3 uses the artsd sound server by default. However, artsd itself can be configured to use an Esound backend. Edit kcmartsrc (either in /etc/kde or /usr/share/config for global configuration or .kde/share/config to configure only one user) like this:<br />
<br />
[Arts]<br />
Arguments=\s-F 10 -S 4096 -a esd -n -s 1 -m artsmessage -c drkonqi -l 3 -f<br />
NetworkTransparent=true<br />
SuspendTime=1<br />
<br />
===KDE Plasma Workspaces and Qt4===<br />
PulseAudio, it will be used by KDE/Qt4 applications. For more information see the [http://www.pulseaudio.org/wiki/KDE KDE page in the PulseAudio wiki].<br />
<br />
PulseAudio support has been merged into KMix, the default KDE sound mixer.<br />
<br />
One useful tidbit from that page is to add {{ic|load-module module-device-manager}} to {{ic|/etc/pulse/default.pa}}.<br />
<br />
Additionally, the {{AUR|kdeplasma-applets-veromix}} is available in the [[AUR]] as a KDE alternative to KMix or pavucontrol.<br />
<br />
===Xfce===<br />
Applications running under Xfce can take advantage of PulseAudio. To manage PulseAudio settings you can use {{Pkg|pavucontrol}}.<br />
<br />
==Applications==<br />
===Audacious===<br />
[[Audacious]] natively supports PulseAudio. In order to use it, set Audacious Preferences -> Audio -> Current output plugin to 'PulseAudio Output Plugin'.<br />
<br />
===Java/OpenJDK 6===<br />
Create a wrapper for the java executable using padsp as seen on the [[Java#Java_sound_with_Pulseaudio|Java sound with Pulseaudio]] page.<br />
<br />
===Music Player Daemon (MPD)===<br />
[http://mpd.wikia.com/wiki/PulseAudio configure] [[MPD]] to use PulseAudio.<br />
<br />
===MPlayer===<br />
[[MPlayer]] natively supports PulseAudio output with the "{{ic|-ao pulse}}" option. It can also be configured to default to PulseAudio output, in {{ic|~/.mplayer/config}} for per-user, or {{ic|/etc/mplayer/mplayer.conf}} for system-wide:<br />
{{hc|/etc/mplayer/mplayer.conf|2=ao=pulse}}<br />
<br />
===Skype (x86_64 only)===<br />
Install {{Pkg|lib32-libpulse}}, otherwise the following error will occur when trying to initiate a call: "Problem with Audio Playback".<br />
<br />
==Troubleshooting==<br />
===No sound after install===<br />
<br />
====Muted audio device====<br />
If one experiences no audio output via any means while using ALSA, attempt to unmute the sound card. To do this, launch alsamixer and make sure each column has a green 00 under it (this can be toggled by pressing 'm')<br />
$ alsamixer -c 0<br />
<br />
====Bad configuration files====<br />
If after starting pulseaudio, the system outputs no sound, it may be necessary to delete the contents of {{ic|~/.pulse}}. Pulseaudio will automatically create new configuration files on its next start.<br />
<br />
====Flash Content====<br />
Since Adobe Flash does not directly support PulseAudio the recommended way is to [https://wiki.archlinux.org/index.php/PulseAudio#ALSA configure ALSA to use the virtual PulseAudio soundcard].<br />
<br />
Alternatively you may try out {{AUR|libflashsupport-pulse}} from the [[AUR]].<br />
{{Note|This may invariably crash the flash plugin.}}<br />
<br />
====No cards====<br />
If PulseAudio starts, run {{ic|pacmd list}}. If no cards are reported, make sure that the ALSA devices are not in use:<br />
$ fuser -v /dev/snd/*<br />
$ fuser -v /dev/dsp<br />
<br />
Make sure any applications using the pcm or dsp files are shut down before restarting PulseAudio.<br />
<br />
====The only device shown is "dummy output"====<br />
This may be caused by different reasons, one of them being the .asoundrc file in $HOME is taking precedence over the systemwide /etc/asound.conf.<br />
<br />
The user file is modified also by the tool '''asoundconf''' or by its graphical variant '''asoundconf-gtk''' (the latter is named "Default sound card" in the menu) as soon as it runs. Prevent the effects of .asoundrc altogether by commenting the last line like this:<br />
<br />
#</home/<yourusername>/.asoundrc.asoundconf><br />
<br />
====KDE4====<br />
It may be that another output device set as preferred in phonon. Make sure that every setting reflects the preferred output device at the top, and check the playback streams tab in kmix to make sure that applications are using the device for output.<br />
<br />
===Bluetooth headset replay problems===<br />
Some user [https://bbs.archlinux.org/viewtopic.php?id=117420 report] huge delays or even no sound when the bluetooth connection does not send any data. This is due to an idle-suspend-module that puts the related sinks/sources automatically into suspend. As this can cause problems with headset, the responsible module can be deactivated. <br />
<br />
1. cp /etc/pulse/default.pa ~/.pulse/default.pa<br />
2. comment out the "load-module module-suspend-on-idle" line in ~/.pulse/default.pa<br />
3. pulseaudio -k && pulseaudio --start<br />
<br />
[http://robert.orzanna.de/2011/08/prevent-idle-suspend-with-bluetooth.html More information]<br />
<br />
===Automatically switch to Bluetooth or USB headset===<br />
Add the following to your /etc/pulse/default.pa:<br />
<br />
# automatically switch to newly-connected devices<br />
load-module module-switch-on-connect<br />
<br />
===Pulse overwrites ALSA settings===<br />
Pulseaudio usually overwrites the ALSA settings- for example set with alsamixer- at start up, even when the alsa daemon is loaded. Since there seems to be no other way to restrict this behaviour, a workaround is to restore the alsa settings again after pulseaudio had started. Add the following command to {{ic|.xinitrc}} {{ic|.bash_login}} or any other autostart file:<br />
<br />
restore_alsa() {<br />
while [ -z "`pidof pulseaudio`" ]; do<br />
sleep 0.5<br />
done<br />
alsactl -f /var/lib/alsa/asound.state restore <br />
}<br />
restore_alsa &<br />
<br />
===Prevent Pulse from restarting after being killed===<br />
Sometimes you may wish to temporarily disable Pulse. In order to do so you will have to prevent Pulse from restarting after being killed.<br />
<br />
$ echo autospawn=no > ~/.pulse/client.conf<br />
<br />
===Daemon startup failed===<br />
Try resetting PulseAudio. To do that:<br />
$ pulseaudio --kill<br />
$ killall pulseaudio<br />
$ killall -9 pulseaudio<br />
$ rm -rf ~/.pulse*<br />
$ rm -rf /tmp/pulse*<br />
<br />
Afterwards, start PulseAudio again.<br />
<br />
===padevchooser===<br />
If one cannot launch the PulseAudio Device Chooser, first (re)start the Avahi daemon as follows:<br />
$ rc.d restart avahi-daemon<br />
<br />
===Glitches, skips or crackling===<br />
The newer implementation of PulseAudio sound server uses a timer-based audio scheduling instead of the traditional interrupt-driven approach. <br />
<br />
Timer-based scheduling may expose issues in some ALSA drivers. On the other hand, other drivers might be glitchy without it on, so check to see what works on your system. <br />
<br />
To turn timer-based scheduling off, replace the line:<br />
load-module module-udev-detect <br />
in {{ic|/etc/pulse/default.pa}} by:<br />
load-module module-udev-detect tsched=0<br />
Then restart the PulseAudio server.<br />
<br />
Do the reverse to enable timer-based scheduling, if not already enabled by default.<br />
<br />
Please report any such cards to [http://pulseaudio.org/wiki/BrokenSoundDrivers PulseAudio Broken Sound Driver page]<br />
<br />
===Setting the default fragment number and buffer size in Pulseaudio===<br />
<br />
1. Finding out your audio device parameters<br />
<br />
Run the following Bash commands to find your sound card buffering settings:<br />
echo autospawn = no >> ~/.pulse/client.conf<br />
killall pulseaudio<br />
LANG=C timeout --foreground -k 10 -s kill 10 pulseaudio -vvvv 2>&1 | grep device.buffering -B 10<br />
sed -i '$d' ~/.pulse/client.conf<br />
<br />
For each sound card detected by Pulseaudio, you will see output similar to this:<br />
I: [pulseaudio] source.c: alsa.long_card_name = "HDA Intel at 0xfa200000 irq 46"<br />
I: [pulseaudio] source.c: alsa.driver_name = "snd_hda_intel"<br />
I: [pulseaudio] source.c: device.bus_path = "pci-0000:00:1b.0"<br />
I: [pulseaudio] source.c: sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"<br />
I: [pulseaudio] source.c: device.bus = "pci"<br />
I: [pulseaudio] source.c: device.vendor.id = "8086"<br />
I: [pulseaudio] source.c: device.vendor.name = "Intel Corporation"<br />
I: [pulseaudio] source.c: device.product.name = "82801I (ICH9 Family) HD Audio Controller"<br />
I: [pulseaudio] source.c: device.form_factor = "internal"<br />
I: [pulseaudio] source.c: device.string = "front:0"<br />
I: [pulseaudio] source.c: device.buffering.buffer_size = "768000"<br />
I: [pulseaudio] source.c: device.buffering.fragment_size = "384000"<br />
<br />
Take note the buffer_size and fragment_size values for the relevant sound card.<br />
<br />
2. Calculate your fragment size in msecs and number of fragments<br />
<br />
Pulseaudio's default sampling rate and bit depth are set to 44100Hz @ 16 bits.<br />
<br />
With this configuration, the bit rate we need is 44100*16 = 705600 bits per second. That's 1411200 bps for stereo.<br />
<br />
Let's take a look at the parameters we've found in the previous step:<br />
<br />
device.buffering.buffer_size = "768000" => 768000/1411200 = 0.544217687075s = 544 msecs<br />
device.buffering.fragment_size = "384000" => 384000/1411200 = 0.272108843537s = 272 msecs<br />
<br />
3.Modify Pulseaudio's configuration file<br />
<br />
Edit the configuration file located at {{ic|/etc/pulse/daemon.conf}} using the editor of your choice.<br />
<br />
For example:<br />
sudo vi /etc/pulse/daemon.conf<br />
<br />
Locate & uncomment (remove leading semicolons) these lines:<br />
<br />
; default-fragments = X<br />
; default-fragment-size-msec = Y<br />
<br />
<br />
In the previous step, we calculated the fragment size parameter.<br />
The number of fragments is simply buffer_size/fragment_size, which in this case (544/272) is 2.<br />
<br />
Edit the lines to use your calculated settings:<br />
<br />
default-fragment-size-msec = 272<br />
default-fragments = 2<br />
<br />
Save the file.<br />
<br />
<br />
4.Restart the Pulseaudio daemon<br />
<br />
pulseaudio -k<br />
pulseaudio --start<br />
<br />
Source: [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 kwevej @ Linux Mint Forums]<br />
<br />
===Laggy sound===<br />
This issue is due to incorrect buffer sizes.<br />
Edit {{ic|/etc/pulse/daemon.conf}}<br />
<br />
Either disable any modifications (if any) to these entries, or, if issue still exists, uncomment and change them in the following way:<br />
default-fragments = 8<br />
default-fragment-size-msec = 5<br />
<br />
===Choppy, overdriven sound===<br />
Choppy sound in pulsaudio can result from wrong settings for the sample rate in {{Ic|/etc/pulse/daemon.conf}}. Try changing the line <br />
; default-sample-rate = 44100<br />
to <br />
default-sample-rate = 48000<br />
and restart the PulseAudio server.<br />
<br />
If one experiences choppy sound in applications using openAL, change the sample rate in /etc/openal/alsoft.conf:<br />
frequency = 48000<br />
<br />
Setting the PCM volume above 0dB can cause clipping of the audio signal. Running {{ic|alsamixer -c0}} will allow you to see if this is the problem and if so fix it.<br />
<br />
===Volume adjustment does not work properly===<br />
Check:<br />
{{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common}}<br />
<br />
If the volume does not appear to increment/decrement properly using {{ic|alsamixer}} or {{ic|amixer}}, it may be due to pulseaudio having a larger number of increments (65537 to be exact). Try using larger values when changing volume (e.g. {{ic|amixer set Master 655+}}).<br />
<br />
===Volume gets louder every time a new application is started===<br />
Per default, it seems as if changing the volume in an application sets the global system volume to that level instead of only affecting the respective application. Applications setting their volume on startup will therefore cause the system volume to "jump".<br />
<br />
Fix this by uncommenting the line<br />
flat-volumes = yes<br />
and changing it to:<br />
flat-volumes = no<br />
in<br />
/etc/pulse/daemon.conf<br />
and then restarting PulseAudio by executing<br />
pulseaudio --kill && pulseaudio --start<br />
<br />
When Pulse comes back after a few seconds, applications will not alter the global system volume anymore but have their own volume level again.<br />
<br />
{{Note|A previously installed and removed pulseaudio-equalizer may leave behind remnants of the setup in {{Ic|$HOME/.pulse/default.pa}} which can also cause maximized volume trouble. Comment that out as needed.}}<br />
<br />
===No mic on ThinkPad T400/T500/T420===<br />
Run<br />
alsamixer -c 0<br />
Maximize the volume of/unmute the "Internal Mic".<br />
<br />
Once you see the device with<br />
arecord -l<br />
you might still need to adjust the settings. The microphone and the audio jack are duplexed. Set the configuration of the internal audio in pavucontrol to ''Analog Stereo Duplex''.<br />
<br />
===No mic input on Acer Aspire One===<br />
Install pavucontrol, unlink the microphone channels and turn down the left one to 0.<br />
Reference: http://getsatisfaction.com/jolicloud/topics/deaf_internal_mic_on_acer_aspire_one#reply_2108048<br />
<br />
===Sound output is only mono on M-Audio Audiophile 2496 sound card===<br />
Add the following to /etc/pulseaudio/default.pa:<br />
load-module module-alsa-sink sink_name=delta_out device=hw:M2496 format=s24le channels=10 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7<br />
load-module module-alsa-source source_name=delta_in device=hw:M2496 format=s24le channels=12 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9<br />
set-default-sink delta_out<br />
set-default-source delta_in<br />
<br />
===Static Noise in Microphone Recording===<br />
If we are getting static noise in skype, gnome-sound-recorder, arecord, etc.'s recordings then the sound card samplerate is incorrect. That is why there is static noise in linux microphone recordings. To fix this We need to set sample-rate in /etc/pulse/daemon.conf for the sound hardware.<br />
<br />
====1. Determine soundcards in the system====<br />
This requires alsa-utils and related packages to be installed:<br />
$ arecord --list-devices<br />
<br />
output:<br />
**** List of CAPTURE Hardware Devices ****<br />
card 0: Intel [HDA Intel], device 0: ALC888 Analog [ALC888 Analog]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
card 0: Intel [HDA Intel], device 2: ALC888 Analog [ALC888 Analog]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
<br />
soundcard is hw:0,0<br />
<br />
====2. Determine sampling-rate of the sound card====<br />
arecord -f dat -r 60000 -D hw:0,0 -d 5 test.wav<br />
<br />
output:<br />
"Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 60000 Hz, Stereo<br />
Warning: rate is not accurate (requested = 60000Hz, '''got = 96000Hz''')<br />
please, try the plug plugin<br />
<br />
observe, the '''got = 96000Hz''', this is the max sample-rate of our card.<br />
<br />
====3. Setting the soundcard's sampling rate into pulse audio configuration====<br />
the default sample-rate in pulseaudio is<br />
grep "sample-rate" /etc/pulse/daemon.conf<br />
<br />
output:<br />
; default-sample-rate = 44100<br />
<br />
It is 44100 and is disabled. Let us set our sound card's settings into pulseaudio configuation file<br />
su -c "sed 's/; default-sample-rate = 44100/default-sample-rate = 96000/g' -i /etc/pulse/daemon.conf"<br />
<br />
Let us verify the changes to deamon.conf<br />
grep "sample-rate" /etc/pulse/daemon.conf <br />
output:<br />
default-sample-rate = 96000<br />
and it is done.<br />
<br />
====4. Restart pulseaudio to apply the new settings====<br />
pulseaudio --kill<br />
pulseaudio --start<br />
<br />
====5. Finally check by recording and playing it back====<br />
Let us record some voice using mic for say 10 seconds. Make sure the mic is not muted and all<br />
arecord -f cd -d 10 test-mic.wav<br />
<br />
After 10 seconds, let us play the recording...<br />
aplay test-mic.wav<br />
<br />
Now hopefully, there is no static noise in microphone recording anymore.<br />
<br />
=== My Bluetooth device is paired but does not play any sound ===<br />
[[Bluetooth#My_device_is_paired_but_no_sound_is_played_from_it|See the article in Bluetooth section]]<br />
<br />
Starting from PulseAudio 2.99 and bluez 4.101 you should '''avoid''' using Socket interface. Do NOT add <br />
[General]<br />
Enable=Socket<br />
to your /etc/bluetooth/audio.conf.<br />
If you face problems with A2DP and PA 2.99 make sure you have SBC library:<br />
pacman -S sbc <br />
<br />
=== Subwoofer stops working after end of every song ===<br />
Known issue: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/494099<br />
<br />
To fix this, must edit: {{ic|/etc/pulse/daemon.conf}} and enable {{ic|enable-lfe-remixing}} :<br />
{{hc|/etc/pulse/daemon.conf|<nowiki><br />
enable-lfe-remixing = yes<br />
</nowiki>}}<br />
<br />
=== Pulseaudio uses wrong microphone ===<br />
If Pulseaudio uses the wrong microphone, and changing the Input Device with Pavucontrol did not help, take a look at alsamixer. It seems that Pavucontrol does not always set the input source correctly.<br><br />
Run:<br />
<br />
$ alsamixer<br />
<br />
press F6 and choose your sound card, e.g. HDA Intel. Now press F5 to display all items. Try to find the item: {{ic|Input Source}}. With the up/down arrow keys you are able to change the input source. <br><br />
Now try if the correct microphone is used for recording.<br />
<br />
=== Choppy Sound with Analog Surround Sound Setup ===<br />
<br />
The low-frequency effects (LFE) channel is not remixed per default. To enable it the following needs to be set in {{ic|/etc/pulse/daemon.conf}} :<br />
{{hc|/etc/pulse/daemon.conf|<nowiki><br />
enable-lfe-remixing = yes<br />
</nowiki>}}<br />
<br />
==External links==<br />
*[http://www.pulseaudio.org/wiki/PerfectSetup http://www.pulseaudio.org/wiki/PerfectSetup] - A good guide to make your configuration perfect<br />
*[http://www.alsa-project.org/main/index.php/Asoundrc http://www.alsa-project.org/main/index.php/Asoundrc] - Alsa wiki on .asoundrc<br />
*[http://www.pulseaudio.org/ http://www.pulseaudio.org/] - PulseAudio official site<br />
*[http://www.pulseaudio.org/wiki/FAQ http://www.pulseaudio.org/wiki/FAQ] - PulseAudio FAQ</div>
Idupree
https://wiki.archlinux.org/index.php?title=Daemons_list&diff=232455
Daemons list
2012-10-29T20:56:16Z
<p>Idupree: add fluidsynth to the list</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Daemons and system services]]<br />
Here is a list of daemons. Note that any package can provide a daemon, so this list will never be complete. Please feel free to add any missing daemons here, in alphabetical order.<br />
For each daemon the name of the script (for [[rc.conf|initscripts]]) and of the service (for [[systemd]]) is given.<br />
{| border="1"<br />
!initscripts!!systemd!!Description<br />
|-<br />
|[[acpid]]||acpid.service||Delivers ACPI events.<br />
|-<br />
|[[Advanced Linux Sound Architecture|alsa]]||alsa-store.service<br />
alsa-restore.service<br />
||Advanced Linux Sound Architecture; provides device drivers for sound cards.<br />
|-<br />
|atd||atd.service||Run jobs queued for later execution.<br />
|-<br />
|[[Avahi|avahi-daemon]]||avahi-daemon.service||Allows programs to automatically find local network services.<br />
|-<br />
|[[Avahi|avahi-dnsconfd]]||avahi-dnsconfd.service||<br />
|-<br />
|[[Bitlbee|bitlbee]]||bitlbee.service||BitlBee IRC/IM gateway.<br />
|-<br />
|[[Chrony|chrony]]||chrony.service||Alternative NTP client/server designed for systems not online all the time.<br />
|-<br />
|[[ClamAV|clamav]]||clamd.service<br />
freshclamd.service<br />
||Antivirus.<br />
|-<br />
|[[CPU_Frequency_Scaling|cpupower]]||cpupower.service||Userspace tools for the kernel cpufreq subsystem<br />
|-<br />
|craftbukkit||''not yet implemented''||CraftBukkit Minecraft server<br />
|-<br />
|[[Cron|crond]]||cronie.service||Daemon to schedule and time events. The daemon name ''crond'' is used by at least two packages, {{Pkg|cronie}} and {{Pkg|dcron}}.<br />
|-<br />
|[[CUPS|cupsd]]||cupsd.service<br />
''or'' cups.service<br />
||Common UNIX Printing System daemon.<br />
|-<br />
|[[D-Bus|dbus]]||dbus.service||Message bus system for software communication.<br />
|-<br />
|[[Cron|dcron]]||dcron.service||Daemon to schedule and time events. The daemon name ''crond'' is used by at least two packages, {{Pkg|cronie}} and {{Pkg|dcron}}. {{Pkg|cronie}} is the default cron implementation for Arch.<br />
|-<br />
|[[Deluge|deluged]]||deluged.service||Cross-platform and full-featured BitTorrent client.<br />
|-<br />
|[[Deluge|deluge-web]]||deluge-web.service||Cross-platform and full-featured BitTorrent client web UI.<br />
|-<br />
|[[Dovecot|dovecot]]||dovecot.service||IMAP and POP3 server. <br />
|-<br />
|[[Dropbox|dropboxd]]||''not yet implemented''||Cross-platform file synchronisation with version control.<br />
|-<br />
|[[FAM|fam]]||''deprecated''||File Alteration Monitor. (deprecated)<br />
|-<br />
|fancontrol||fancontrol.service||Fan control daemon (part of lm_sensors)<br />
|-<br />
|[[Fbsplash|fbsplash]]||''not yet implemented''||Graphical boot splash screen for the user.<br />
|-<br />
|[[FluidSynth|fluidsynth]]||fluidsynth.service||Software synthesizer<br />
|-<br />
|ftpd||''not yet implemented''||Inetutils ftp daemon<br />
|-<br />
|[[GDM|gdm]]||gdm.service||Gnome Display Manager (Login Screen)<br />
|-<br />
|[[Git|git-daemon]]||git-daemon.socket||GIT daemon<br />
|-<br />
|[[Console Mouse Support|gpm]]||gpm.service||Console mouse support.<br />
|-<br />
|[[HAL|hal]]||''deprecated''||Hardware Abstraction Layer. (Deprecated)<br />
|-<br />
|hddtemp||hddtemp.service||Hard drive temperature monitor daemon<br />
|-<br />
|healthd||healthd.service||A daemon which can be used to alert you in the event of a hardware health monitoring alarm (part of lm_sensors).<br />
|-<br />
|-<br />
|iptables||iptables.service||Load firewall rules.<br />
|-<br />
|-<br />
|ip6tables||ip6tables.service||Load firewall rules for ipv6.<br />
|-<br />
|[[LAMP|httpd]]||httpd.service<br />
See [[Systemd/Services#apache2]] for manual configuration.<br />
||Apache HTTP Server (Web Server)<br />
|-<br />
|[[hwclock]]||||Not a daemon as such, but on shutdown, updates hwclock to compensate for drift. Only run this daemon if ntpd is not running as both daemons adjust the hardware clock.<br />
|-<br />
|irqbalance||''not yet implemented''||Irqbalance is the Linux utility tasked with making sure that interrupts from your hardware devices are handled in as efficient a manner as possible.<br />
|-<br />
|[[KDE|kdm]]||kdm.service||KDE Display Manager (Graphical Login)<br />
|-<br />
|krb5-kadmind||krb5-kadmind.service||Kerberos 5 administration server<br />
|-<br />
|krb5-kdc||krb5-kdc.service||Kerberos 5 KDC<br />
|-<br />
|krb5-kpropd||krb5-kpropd.service||Kerberos 5 propagation server<br />
|-<br />
|[[Laptop Mode Tools|laptop-mode]]||laptop-mode-tools.service||Laptop Power Saving Tools<br />
|-<br />
|[[lighttpd]]||lighttpd.service||Lighttpd HTTP Server (Web Server).<br />
|-<br />
|[[LXDE|lxdm]]||lxdm.service||LXDE Display Manager (Graphical Login)<br />
|-<br />
|mdadm||mdadm.service||MD Administration (Linux Software RAID).<br />
|-<br />
|[[Music Player Daemon|mpd]]||mpd.service||Music Player Daemon.<br />
|-<br />
|[[MySQL|mysqld]]||mysqld.service||MySQL database server.<br />
|-<br />
|[[MythTV|mythbackend]]||mythbackend.service||Backend for the MythTV digital video recording/home theater software.<br />
|-<br />
|[[BIND|named]]||named.service||The Berkeley Internet Name Daemon (BIND) DNS server.<br />
|-<br />
|netfs||''unused, handled automatically, see''<br />
remote-fs.target<br />
''to manually execute scripts''<br />
||Mounts network file systems.<br />
|-<br />
|[[Netcfg|net-auto-wired]]||net-auto-wired.service||Netcfg replacement for {{ic|network}} - connects to wired network<br />
|-<br />
|[[Netcfg|net-auto-wireless]]||net-auto-wireless.service||Netcfg replacement for {{ic|network}} - connects to wireless network<br />
|-<br />
|[[Netcfg|net-profiles]]||netcfg.service<br />
netcfg@<profile-name>.service<br />
||Netcfg replacement for {{ic|network}} - connects to profiles<br />
|-<br />
|[[Configuring_Network|network]]||''(dynamic Ethernet)'' dhcpcd@<interface>.service||To bring up the network connections.<br />
|-<br />
|[[NetworkManager|networkmanager]]||NetworkManager.service<br />
NetworkManager-wait-online.service<br />
||Replaces {{ic|network}}, and provides configuration and detection for automatic network connections.<br />
|-<br />
|[[Nginx|nginx]]||nginx.service||Nginx HTTP Server and IMAP/POP3 proxy server (Web Server)<br />
|-<br />
|nscd||nscd.service||Name service cache daemon<br />
|-<br />
|[[Network Time Protocol daemon|ntpd]]||ntpd.service||Network Time Protocol daemon (client and server).<br />
|-<br />
|[[Ntop|Ntop]]||ntop.service||Ntop is a network traffic probe based on libcap.<br />
|-<br />
|[[OpenNTPD|openntpd]]||openntpd.service||alternate Network Time Protocol daemon (client and server).<br />
|-<br />
|osspd||osspd.service||OSS Userspace Bridge.<br />
|-<br />
|[[OpenVPN|openvpn]]||openvpn@<profile-name>.service||One for each vpn conf file saved like /etc/openvpn/<profile-name>.conf<br />
|-<br />
|[[Pdnsd|pdnsd]]||pdnsd.service||Proxy DNS server with permanent caching.<br />
|-<br />
|[[Nginx#1st_Method_.22New.22_.28as_of_PHP_5.3.3.29|php-fpm]]||php-fpm.service||FastCGI Process Manager for PHP<br />
|-<br />
|[[PostgreSQL|postgresql]]||postgresql.service||PostgreSQL database server.<br />
|-<br />
|[[Postfix|postfix]]||postfix.service||<br />
|-<br />
|[[powernowd]]||''not yet implemented''||To adjust speed of CPU depending on system load. See also [[CPU Frequency Scaling]]<br />
|-<br />
|[[Prosody|prosody]]||prosody.service||XMPP server.<br />
|-<br />
|ppp||''not yet implemented''||A daemon which implements the Point-to-Point Protocol for dial-up networking.<br />
|-<br />
|[[preload]]||preload.service||Makes applications run faster by prefetching binaries and shared objects.<br />
|-<br />
|[[psd]]||psd.service||Manages your browser's profile in tmpfs and periodically sync it back to your physical disk.<br />
|-<br />
|pure-ftpd||''not yet implemented''||FTP server.<br />
|-<br />
|[[readahead]]||systemd-readahead-collect.service<br />
systemd-readahead-done.service<br />
<br />
systemd-readahead-drop.service<br />
<br />
systemd-readahead-replay.service<br />
||Readahead for faster boot<br />
|-<br />
||rfkill||rfkill.service||(Un)block radio devices. (.service does not seem to provide equivalent functionality.)<br />
|-<br />
|[[Rsync|rsyncd]]||rsyncd.service||Rsync daemon.<br />
|-<br />
|[[Rsyslog|rsyslogd]]||rsyslog.service||The latest version of a system logger.<br />
|-<br />
|[[samba]]||smbd.service<br />
nmbd.service<br />
<br />
winbindd.service<br />
||File and print services for Microsoft Windows clients.<br />
|-<br />
|[[USB_Scanner_Support|saned]]||saned@.service||To share the scanner system over network.<br />
|-<br />
|sensord||sensord.service||Sensor information logging daemon (part of lm_sensors)<br />
|-<br />
|[[Lm sensors|sensors]]||lm_sensors.service||Hardware (temperature, fans etc) monitoring.<br />
|-<br />
|[[SLiM|slim]]||slim.service||Simple Login Manager<br />
|-<br />
|[[SMART|smartd]]||smartd.service||Self-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T) Hard Disk Monitoring<br />
|-<br />
|[[Samba#smbnetfs|smbnetfs]]||smbnetfs.service||To automatically mount Samba/Microsoft network shares.<br />
|-<br />
|snmpd||''not yet implemented''||A suite of applications used to implement SNMP<br />
|-<br />
|soundmodem||''not yet implemented''||Multiplatform Soundcard Packet Radio Modem<br />
|-<br />
|[[SOHO Postfix|spamd]]||spamassassin.service|| e-mail spam filtering service.<br />
|-<br />
|[[Secure Shell|sshd]]||sshd.service<br />
sshd@.service<br />
<br />
sshdgenkeys.service<br />
||OpenSSH (secure shell) daemon.<br />
|-<br />
|stbd||''deprecated''||This daemon was previously necessary for gnome-system-tools. However, as of gnome-tools 2.28, it is no longer needed.<br />
|-<br />
|svnserve||svnserve.service||Subversion server<br />
|-<br />
|syslogd||''deprecated''||This was the older and basic system logger.<br />
|-<br />
|[[syslog-ng]]||syslog-ng.service||System logger next generation.<br />
|-<br />
|[[Timidity|timidity++]]||''not yet implemented''||Software synthesizer for MIDI.<br />
|-<br />
|[[Tor|tor]]||tor.service||Onion routing for anonymous communication.<br />
|-<br />
|[[Transmission|transmissiond]]||transmission.service||Bit Torrent Daemon.<br />
|-<br />
|[[Ufw|ufw]]||ufw.service||Uncomplicated FireWall.<br />
|-<br />
|[[VirtualBox|vboxservice]]||vboxservice.service||VirtualBox Guest Service<br />
|-<br />
|[[Very Secure FTP Daemon|vsftpd]]||vsftpd.service<br />
vsftpd@.service<br />
<br />
vsftpd-ssl.service<br />
||FTP server.<br />
|-<br />
|[[wicd]]||wicd.service||Combine with dbus to replace {{ic|network}}, a lightweight alternative to NetworkManager.<br />
|-<br />
|[[x11vnc]]||''not yet implemented''||VNC remote desktop daemon <br />
|-<br />
|}</div>
Idupree
https://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=162853
Solid state drive
2011-09-29T19:36:26Z
<p>Idupree: /* Encrypted partition */ News of dm-crypt supporting TRIM. I'm not trying to add usage details until the software (linux 3.1 and maybe cryptsetup) is actually released.</p>
<hr />
<div>[[Category: Storage (English)]]<br />
{{i18n|Solid State Drives}}<br />
{{Article summary start}}<br />
{{Article summary text|This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principals and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as MacOS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.}}<br />
{{Article summary heading|Related Articles}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using both Windows and Mac OS X.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - No decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - Approx. 100x faster than an HDD. For example, 0.1 ms (100 ns) vs. 12-20 ms (12,000-20,000 ns) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - Fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (dollars per GB, vs. pennies per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size are not autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes are not amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell does not lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection is not universally well implemented, meaning freed space is not always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and Testing SSD TRIM Support Under Linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you do not know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you do not care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions are not aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk (gptfdisk package) from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the GPT partitioned SSD as a boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1 MiB partition with the partition type as BIOS boot or bios_grub partition (gdisk type code EF02) for booting from the disk using [[GRUB2]]. For [[Syslinux]], you do not need to create a separate 1 MiB bios_grub partition, but you need to have separate /boot partition and enable '''Legacy BIOS Bootable partition''' attribute for that partition (using gdisk). See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk in BIOS systems! You will need to use the depreciated MBR method described below for dual-boot in BIOS systems! This limitation does not apply if you boot in UEFI mode and using Windows Vista (64bits) or 7 (64bits). For 32-bit Windows Vista and 7, and 32 and 64-bit Windows XP, you need to use MBR partitioning and boot in BIOS mode only.}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, do not forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gptfdisk package:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content will not be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they are working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here]. August 2011 news: support will be in Linux 3.1, and involves a userspace dm-crypt update as well [http://superuser.com/questions/302710/trim-support-via-dm-crypt-device-mapper#318847])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here]{{Linkrot|2011|09|04}} for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably does not apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: {{Bug|22605}}<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [[Firefox Ramdisk]] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso]{{Linkrot|2011|09|04}} advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[Solid_State_Drives#Compiling in /dev/shm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that do not handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for Linux (i686 and x86_64) on their forum [http://www.ocztechnology.com/ssd_tools/ here].</div>
Idupree
https://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=100345
Mkinitcpio
2010-03-16T20:20:49Z
<p>Idupree: /* HOOKS */ add another clarification. Although I've the feeling that "hooks" is overloaded to mean two different things :-/</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|mkinitcpio}} {{DISPLAYTITLE:mkinitcpio}}<br />
{{Article summary start}}<br />
{{Article summary text|A detailed guide to the Arch initramfs creation utility.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''mkinitcpio''' is the next generation of initramfs creation.<br />
<br />
From [[Wikipedia:initrd]]:<br />
<br />
:''The '''initial ramdisk''', ['''initramfs'''], or '''initrd''' is a temporary file system commonly used in the [[boot process]] of the Linux kernel. It is typically used for making preparations before the real root file system can be mounted.''<br />
<br />
== Overview ==<br />
<br />
mkinitcpio is a Bash script used to create an initial ramdisk environment. From the [http://projects.archlinux.org/mkinitcpio.git/tree/mkinitcpio.5.txt mkinitcpio man page]:<br />
<br />
:''The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init. This makes it possible to have, for example, encrypted root filesystems and root filesystems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features.''<br />
<br />
Traditionally, the kernel was responsible for all hardware detection and initialization tasks early in the [[boot process]] before mounting the root filesystem and passing control to {{Codeline|init}}. However, as technology advances, these tasks have become increasingly complex. <br />
<br />
Nowadays, the root filesystem may be on a wide range of hardware, from SCSI to SATA to USB drives, controlled by a variety of drive controllers from different manufacturers. Additionally, the root filesystem may be encrypted or compressed; within a software RAID array or a logical volume group. The simple way to handle that complexity is to pass management into userspace: an initial ramdisk. <br />
<br />
See also: [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ /dev/brain0 &raquo; Blog Archive &raquo; Early Userspace in Arch Linux].<br />
<br />
mkinitcpio is a modular tool for building an init ramfs cpio image, offering many advantages over alternative methods, including:<br />
<br />
* The use of '''busybox''' to provide a small and lightweight base for early userspace (prior to version 0.6, [http://www.archlinux.org/news/486/ '''klibc'''] was used instead).<br />
* Support for '''[[udev]]''' for hardware autodetection at runtime, thus preventing the loading of unnecessary modules.<br />
* Being an extendable hook-based init script, custom hooks can easily be included in [[pacman]] packages.<br />
* Support for '''lvm2''', '''dm-crypt''' for both legacy and LUKS volumes, '''raid''', '''mdadm''', and '''swsusp''' and '''suspend2''' for resuming and booting from USB mass storage devices.<br />
* The ability to allow many features to be configured from the kernel command line without needing to rebuild the image.<br />
* Support for the inclusion of the image in a kernel, thus making a self-contained kernel image possible.<br />
<br />
mkinitcpio has been developed by '''phrakture''' and '''tpowa''' with some help from the community.<br />
<br />
== Installation ==<br />
<br />
The {{Package Official|mkinitcpio}} package is available in the [core] repository, and is installed by default as a member of the '''base''' group:<br />
# pacman -S mkinitcpio<br />
<br />
Users may wish to install the latest development version of mkinitcpio from Git:<br />
$ git clone git://projects.archlinux.org/mkinitcpio.git<br />
<br />
== Image creation and activation ==<br />
<br />
By default, the mkinitcpio script generates two images after kernel installation or upgrades: {{Filename|/boot/kernel26.img}} and {{Filename|/boot/kernel26-fallback.img}}. The ''fallback'' image utilizes the same configuration file as the ''default'' image, except the '''autodetect''' hook is skipped during creation, thus including a full range of modules. The '''autodetect''' hook detects required modules and tailors the image for specific hardware, shrinking the initramfs. <br />
<br />
Users may create any number of initramfs images with a variety of different configurations. The desired image must be specified for the bootloader, often in its configuration file ({{Filename|/boot/grub/menu.lst}} for [[GRUB]] users). After changes are made to the configuration file, the image must be regenerated. For the stock Arch Linux kernel, {{Package Official|kernel26}}, this is accomplished with the command:<br />
<br />
# mkinitcpio -p kernel26<br />
<br />
The {{Codeline|-p}} switch specifies a ''preset'' to utilize; most kernel packages provide a related mkinitcpio preset file, found in {{Filename|/etc/mkinitcpio.d}} (e.g. {{Filename|/etc/mkinitcpio.d/kernel26.preset}} for <tt>kernel26</tt>). A preset is a predefined definition of how to create an initramfs image instead of specifying the configuration file and output file every time.<br />
<br />
{{Warning|{{Filename|preset}} files are used to automatically regenerate the initramfs after a kernel update; be careful when editing them.}}<br />
<br />
Users can manually create an image using an alternate configuration file:<br />
<br />
# mkinitcpio -c /etc/mkinitcpio-custom.conf -g /boot/kernel26-custom.img<br />
<br />
This will generate the initramfs image for the currently running kernel and save it at {{Filename|/boot/kernel26-custom.img}}. <br />
<br />
If creating an image for a kernel other than the one currently running, add the kernel version to the command line:<br />
<br />
# mkinitcpio -g /boot/kernel26.img -k 2.6.16-ARCH<br />
<br />
== Configuration ==<br />
<br />
The primary configuration file for '''mkinitcpio''' is {{Filename|/etc/mkinitcpio.conf}}. Additionally, preset definitions are provided by kernel packages in the {{Filename|/etc/mkinitcpio.d}} directory (e.g. {{Filename|/etc/mkinitcpio.d/kernel26.preset}}).<br />
<br />
{{Warning|'''lvm2''', '''raid''', '''mdadm''', and '''encrypt''' are '''NOT''' enabled by default. Please read this section carefully for instructions if these hooks are required.}}<br />
<br />
{{Note|Users with multiple hardware disk controllers that use the same node names but different kernel modules (e.g. two SCSI/SATA or two IDE controllers) should ensure the correct order of modules is specified in {{Filename|/etc/mkinitcpio.conf}}. Otherwise, the root device location may change between boots, resulting in kernel panics.<br />
<br />
A more elegant alternative is to use [[persistent block device naming]] to ensure that the right devices are mounted.}}<br />
<br />
Users can modify five variables within the configuration file:<br />
<br />
; {{Codeline|MODULES}}: Kernel modules to be loaded before any boot hooks are run. <br />
; {{Codeline|BINARIES}}: Additional binaries to be included in the initramfs image.<br />
; {{Codeline|FILES}}: Additional files to be included in the intramfs image.<br />
; {{Codeline|HOOKS}}: Hooks are scripts that execute in the initial ramdisk.<br />
; {{Codeline|COMPRESSION}}: Used to compress the initramfs image.<br />
<br />
=== HOOKS ===<br />
<br />
A hook is a script that executes at ''mkinitcpio'' time in the initial ramdisk. Hooks are listed in order of execution, and control the modules and scripts added to the image. Some of them add a script from {{Filename|/lib/initcpio/hooks}} to the initramfs to be run at boot time.<br />
<br />
Hooks are found within the {{Filename|/lib/initcpio/install}} directory; for a list of available hooks:<br />
<br />
$ ls -1 /lib/initcpio/install<br />
<br />
Use mkinitcpio's {{Codeline|-H}} option to output help for a specific hook. For example, to display information about the '''base''' hook:<br />
<br />
$ mkinitcpio -H base<br />
<br />
The default configuration will work for most users with a standard setup:<br />
<br />
HOOKS="base udev autodetect pata scsi sata filesystems"<br />
<br />
If using the image on more than one machine, remove the '''autodetect''' hook, which tailors the image to the build machine:<br />
<br />
HOOKS="base udev pata scsi sata filesystems"<br />
<br />
For support for encrypted volumes on LVM2 volume groups:<br />
<br />
HOOKS="base udev autodetect pata scsi sata lvm2 encrypt filesystems"<br />
<br />
A table of common hooks and their function follows. Note that this table is not complete, as packages can provide custom hooks. <br />
<br />
{| border="1" <br />
|+ '''Common hooks'''<br />
|-<br />
! Hook || Installation || Runtime<br />
|-<br />
| '''base''' || Sets up all initial directories and installs base utilities and libraries. Always add this hook unless you know what you are doing. || --<br />
|-<br />
| '''udev''' || Adds udev to your image || Udev will be used to create your root device node and detect the needed modules for your root device. As it simplifies things, using the udev hook is recommended.<br />
|-<br />
| '''autodetect''' || Shrinks your initramfs to a smaller size by autodetecting your needed modules. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full. || --<br />
|-<br />
| '''ide''' || Adds legacy IDE modules to the image. You may choose to use this if your root device is on an IDE disk. Also use the '''autodetect''' hook if you want to minimize your image size || Loads legacy IDE modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''pata''' || Adds the new libata/PATA IDE modules to the image. Use this if your root device is on a IDE disk. Also use the '''autodetect''' hook if you want to minimize your image size || Loads IDE modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below). PATA is the kernel's new IDE driver. PATA utilizes SCSI emulation and will change {{Filename|/dev/hd''x''}} to {{Filename|/dev/sd''x''}}. [http://archlinux.org/news/272/ More information].<br />
|-<br />
| '''sata''' || Adds serial ATA modules to the image. Use this if your root device is on a SATA disk. Also use the '''autodetect''' hook if you want to minimize your image size. || Loads SATA modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''scsi''' || Adds SCSI modules to the image. Use this if your root device is on a SCSI disk. Also use the '''autodetect''' hook if you want to minimize your image size. || Loads SCSI modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''usb''' || Adds USB modules to the image. Use this if your root device is on a USB mass storage device or if your USB mass storage device needs to be accessed otherwise (checked, mounted, etc.) at boot time. || Loads USB modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''usbinput''' || Adds USB HID modules to the image. Use this if you have an USB keyboard and need it in early userspace (either for entering encryption passphrases or for failsafe mode). || Loads USB HID modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''fw''' || Adds FireWire modules to the image. Use this if your root device is on a FW mass storage device. || Loads FW modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''net''' || Adds the necessary modules for a network device. For PCMCIA net devices please add the '''pcmcia''' hook too. || Loads network modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below). See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''pcmcia''' || Adds the necessary modules for PCMCIA devices. You need to have {{Package Official|pcmciautils}} installed to use this. || Loads pcmcia modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''[[DSDT|dsdt]]''' || Loads a custom ACPI DSDT file during boot. Place your custom DSDT file for inclusion at {{Filename|/lib/initcpio/custom.dsdt}} || The custom DSDT file is automatically used by the kernel if it is present in initramfs.<br />
|-<br />
| '''filesystems''' || This includes necessary filesystem modules into your image. This hook is '''required''' unless you specify your filesystem modules in MODULES. || This will detect the filesystem type at runtime, load the module and pass it to kinit. (Will NOT detect '''reiser4''', which must be added to modules list.)<br />
|-<br />
| '''lvm2''' || Adds the device mapper kernel module and the {{Codeline|lvm}} tool to the image. You need to have the {{Package Official|lvm2}} package installed to use this. || Enables all LVM2 volume groups. This is necessary if you have your root filesystem on LVM.<br />
|-<br />
| '''raid''' || Adds the modules and {{Codeline|mdassamble}} for a software RAID setup. This hook has been superseded by the '''mdadm''' hook. You need to have {{Package Official|mdadm}} installed to use this. || Loads the necessary modules for software raid devices, and assembles the raid devices when run. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''mdadm''' || This hook supersedes the above '''raid''' hook. It supports assembling the arrays from {{Filename|/etc/mdadm.conf}}, or autodetection during boot. || Loads the necessary modules for software raid devices, and assembles the raid devices when run. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''encrypt''' || Adds the '''dm-crypt''' kernel module and the {{Codeline|cryptsetup}} tool to the image. You need to have the {{Package Official|cryptsetup}} package installed to use this. || Detects and unlocks an encrypted root partition. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''resume''' || -- || This tries to resume from the "suspend to disk" state. Works with both ''swsusp'' and ''[[suspend2]]''. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''firmware''' || Adds {{Filename|/lib/firmware}} files. || Loads firmware. You will need the '''udev''' hook to get firmware loaded. <br />
|-<br />
| '''keymap''' || Adds keymap and consolefonts from [[rc.conf]]. || Loads the specified keymap and consolefont from {{Filename|rc.conf}} during early userspace.<br />
|}<br />
<br />
=== MODULES ===<br />
<br />
The MODULES array is used to specify modules to load before anything else is done. To accelerate the boot process, users may opt to disable the '''udev''' hook and list required modules here instead:<br />
<br />
MODULES="piix ide_disk reiserfs"<br />
<br />
[...]<br />
<br />
HOOKS="base autodetect ide filesystems"<br />
<br />
{{Note|If using '''reiser4''', it ''must'' be added to the modules list.}}<br />
<br />
{{Box YELLOW|TODO:|Find out which modules fail on modern kernels.}}<br />
Known modules that are not autoloaded during boot process (status stock kernel 2.6.18):<br />
<br />
<tt>scsi_transport_sas, ultrastor, qlogicfas, eata, BusLogic, pas16, wd7000, sym53c416, g_NCR5380_mmio, fdomain, u14-34f, dtc initio, in2000, imm, t128, aha1542, aha152x, atp870u, g_NCR5380, NCR53c406a, qlogicfas408, megaraid_mm, advansys</tt><br />
<br />
If one of the above modules are required for the root device, consider explicitly adding it to {{Filename|/etc/mkinitcpio.conf}} to avoid kernel panics.<br />
<br />
=== BINARIES and FILES ===<br />
<br />
These options allow users to add files to the image. Both BINARIES and FILES are added before hooks are run, and may be used to override files used or provided by a hook. BINARIES are dependency-parsed, meaning any required libraries will also be added. FILES are added ''as-is''. For example:<br />
<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
<br />
BINARIES="/usr/bin/cal"<br />
<br />
== Runtime customization ==<br />
<br />
Runtime configuration options can be passed to {{Codeline|init}} and certain hooks via the kernel command line. Kernel command line parameters are often supplied by the bootloader. For example, a typical Arch Linux [[GRUB]] entry:<br />
<br />
{{File<br />
|name=/boot/grub/menu.lst<br />
|content=<nowiki><br />
...<br />
<br />
# (0) Arch Linux<br />
title Arch Linux [/boot/vmlinuz26]<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
...<br />
</nowiki>}}<br />
<br />
In this case, {{Codeline|<nowiki>root=/dev/sda3</nowiki>}} and {{Codeline|ro}} are kernel command line parameters. The options discussed below can be appended to the kernel command line to alter default behavior. See [[Arch Boot Process]] for more information.<br />
<br />
=== init ===<br />
<br />
''The following options alter the default behavior of {{Codeline|init}} in the initramfs environment. See {{Filename|/lib/initcpio/init}} for details.''<br />
<br />
; {{Codeline|break}}: If {{Codeline|<nowiki>break=y</nowiki>}} is specified, init pauses early in the boot process (after loading modules) and launches an interactive shell which can be used for troubleshooting purposes. (Normal boot continues after logout.)<br />
<br />
; {{Codeline|disablehooks}}: Disable hooks at runtime by adding {{Codeline|<nowiki>disablehooks=hook1{,hook2,...}</nowiki>}}. For example: <pre>disablehooks=resume</pre><br />
<br />
; {{Codeline|disablemodules}}: Blacklist modules at runtime by adding {{Codeline|<nowiki>disablemodules=mod1{,mod2,...}</nowiki>}}. For example: <pre>disablemodules=ata_piix</pre><br />
<br />
; {{Codeline|earlymodules}}: Alter the order in which modules are loaded by specifying modules to load early via {{Codeline|<nowiki>earlymodules=mod1{,mod2,...}</nowiki>}}. (This may be used, for example, to ensure the correct ordering of multiple network interfaces.)<br />
<br />
; {{Codeline|rootdelay}}: Pause for ten seconds before mounting the root file system by appending {{Codeline|rootdelay}}. (This may be used, for example, if booting from a USB hard drive that takes longer to initialize.)<br />
<br />
=== Using raid ===<br />
<br />
First add the 'mdadm' hook to the HOOKS list and any required raid modules to the MODULES list in '''/etc/mkinitcpio.conf'''.<br />
<br />
'''Kernel Parameters: '''<br />
Using the 'mdadm' hook, you no longer need to configure your RAID array in the GRUB parameters. The 'mdadm' hook will either use your /etc/mdadm.conf file, or automatically detect the arrays during the init phase of boot.<br />
<br />
=== Using net ===<br />
<br />
'''Kernel Parameters:''' <br />
<br />
'''ip=''' <br />
<br />
An interface spec can be either short form, which is just the name of<br />
an interface (eth0 or whatever), or long form. The long form consists<br />
of up to seven elements, separated by colons:<br />
<br />
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf><br />
nfsaddrs= is an alias to ip= and can be used too.<br />
<br />
''Parameter explanation:''<br />
<client-ip> IP address of the client. If empty, the address will<br />
either be determined by RARP/BOOTP/DHCP. What protocol<br />
is used de- pends on the <autoconf> parameter. If this<br />
parameter is not empty, autoconf will be used.<br />
<br />
<server-ip> IP address of the NFS server. If RARP is used to<br />
determine the client address and this parameter is NOT<br />
empty only replies from the specified server are<br />
accepted. To use different RARP and NFS server,<br />
specify your RARP server here (or leave it blank), and<br />
specify your NFS server in the `nfsroot' parameter<br />
(see above). If this entry is blank the address of the<br />
server is used which answered the RARP/BOOTP/DHCP<br />
request.<br />
<br />
<gw-ip> IP address of a gateway if the server is on a different<br />
subnet. If this entry is empty no gateway is used and the<br />
server is assumed to be on the local network, unless a<br />
value has been received by BOOTP/DHCP.<br />
<br />
<netmask> Netmask for local network interface. If this is empty,<br />
the netmask is derived from the client IP address assuming<br />
classful addressing, unless overridden in BOOTP/DHCP reply.<br />
<br />
<hostname> Name of the client. If empty, the client IP address is<br />
used in ASCII notation, or the value received by<br />
BOOTP/DHCP.<br />
<br />
<device> Name of network device to use. If this is empty, all<br />
devices are used for RARP/BOOTP/DHCP requests, and the<br />
first one we receive a reply on is configured. If you<br />
have only one device, you can safely leave this blank.<br />
<br />
<autoconf> Method to use for autoconfiguration. If this is either<br />
'rarp', 'bootp', or 'dhcp' the specified protocol is<br />
used. If the value is 'both', 'all' or empty, all<br />
protocols are used. 'off', 'static' or 'none' means<br />
no autoconfiguration.<br />
''Examples:''<br />
ip=127.0.0.1:::::lo:none --> Enable the loopback interface.<br />
ip=192.168.1.1:::::eth2:none --> Enable static eth2 interface.<br />
ip=:::::eth0:dhcp --> Enable dhcp protocol for eth0 configuration.<br />
'''nfsroot='''<br />
<br />
If the 'nfsroot' parameter is NOT given on the command line, the default<br />
"/tftpboot/%s" will be used.<br />
<br />
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]<br />
<br />
''Parameter explanation:''<br />
<br />
<server-ip> Specifies the IP address of the NFS server. If this field<br />
is not given, the default address as determined by the<br />
`ip' variable (see below) is used. One use of this<br />
parameter is for example to allow using different servers<br />
for RARP and NFS. Usually you can leave this blank.<br />
<br />
<root-dir> Name of the directory on the server to mount as root. If<br />
there is a "%s" token in the string, the token will be<br />
replaced by the ASCII-representation of the client's IP<br />
address.<br />
<br />
<nfs-options> Standard NFS options. All options are separated by commas.<br />
If the options field is not given, the following defaults<br />
will be used:<br />
port = as given by server portmap daemon<br />
rsize = 1024<br />
wsize = 1024<br />
timeo = 7<br />
retrans = 3<br />
acregmin = 3<br />
acregmax = 60<br />
acdirmin = 30<br />
acdirmax = 60<br />
flags = hard, nointr, noposix, cto, ac<br />
<br />
'''root=/dev/nfs'''<br />
If you don't use nfsroot= parameter you need to set root=/dev/nfs <br />
to boot from a nfs root by autoconfiguration.<br />
<br />
=== Using lvm ===<br />
<br />
If your root device is on lvm, you have to add the '''lvm2''' hook. You have to pass your root device on the kernel command line in the format<br />
<br />
root=/dev/mapper/<volume group name>-<logical volume name><br />
<br />
for example<br />
<br />
root=/dev/mapper/myvg-root<br />
<br />
=== Using encrypted root ===<br />
<br />
If your root volume is encrypted, you need to add the '''encrypt''' hook. Then specify your root device on the kernel command line, just as if it was unencrypted.<br />
<br />
For an encrypted partition on an sata or scsi disk:<br />
root=/dev/sda5<br />
<br />
For an encrypted lvm volume:<br />
root=/dev/mapper/myvg-root<br />
<br />
The root device will be automatically changed to ''/dev/mapper/root''.<br />
<br />
==== Using LUKS volumes ====<br />
<br />
If you use LUKS for hard disk encryption, the init script will detect the encryption automatically if the '''encrypt''' hook is enabled. It will then ask for a passphrase and try to unlock the volume.<br />
<br />
If this fails try to add you filesystem-module to the module list in /etc/mkinitcpio.conf if it's not compiled into your kernel.<br />
<br />
==== Using a key-file ====<br />
<br />
You can use a keyfile to encrypt your root-fs. Use the following format:<br />
<br />
cryptkey=device:fs-type:path<br />
<br />
Device is the device-file representing the device your key is stored on (e.g. /dev/sda1), fs-type is the filesystemtype of this device (e.g. ext3) and path is the path to the keyfile inside the fs of this device.<br />
<br />
==== Using legacy cryptsetup volumes ====<br />
<br />
If you are using a legacy cryptsetup volume, you have to specify all cryptsetup options necessary to unlock it on the kernel command line. The option format is<br />
<br />
crypto=hash:cipher:keysize:offset:skip<br />
<br />
representing cryptsetup's --hash, --cipher, --keysize, --offset and --skip options. If you omit an option, cryptsetup's default value is used, so you can just specify<br />
<br />
crypto=::::<br />
<br />
if you created your volume with the default settings.<br />
<br />
'''NOTE:''' For technical reasons, it is not possible to verify the correctness of your passphrase with legacy cryptsetup volumes. If you typed it wrong, mounting will simply fail. It is recommended that you use LUKS instead.<br />
<br />
==== Using loop-aes volumes ====<br />
<br />
'''mkinitcpio''' does not support loop-aes yet.<br />
<br />
== Troubleshooting ==<br />
<br />
=== mkinitcpio hangs on 'autodetect' during kernel upgrade ===<br />
This [http://bugs.archlinux.org/task/10061 '''bug'''] sometimes causes mkinitcpio to hang when upgrading the kernel. It has been noted that certain usb devices and pata hard drives/chipsets may irritate the issue, but the actual cause is currently unknown (2010-03-01). The best known method to circumvent this bug is to edit '/etc/mkinitcpio.conf' and remove 'autodetect' from the HOOKS parameter. Once removed, force reinstall the kernel with 'pacman -Sf kernel26', and mkinitcpio should process cleanly.<br />
<br />
Reboot the system, and then add 'autodetect' back to the HOOKS parameter, and force reinstall the kernel again to complete this workaround. While running on the new kernel, 'autodetect' seems to process successfully.<br />
<br />
NOTE: Be very careful modifying 'etc/mkinitcpio.conf'. Review the procedures BEFORE modifying, and make a backup. Some systems may need another hook for pata/ide, or sata if the respective hook is not yet present. If mkinitcpio fails during a kernel upgrade, and the issue is not resolved before a reboot is executed, this will most likely result in a kernel panic/nonfunctioning system!<br />
<br />
=== Extracting the image ===<br />
<br />
If you are curious about what is inside the initrd image you can extract it and poke at the files inside of it. <br />
<br />
The initrd image is a '''cpio''' archive, generated by the <tt>gen_init_cpio</tt> command, optionally compressed with one the 3 compression schemes understood by the kernel: namely '''gzip''' or '''bzip2''' or '''lzma'''. Only kernels later than 2.6.30 undertand bzip2 and lzma compression.<br />
<br />
<tt>bsdtar</tt> is powerful enough to autodetect the compression used and to extract to the current directory.<br />
<br />
You can list the files in the image with:<br />
$ bsdtar -t -f /boot/kernel26.img<br />
<br />
And to extract them all in the current directory:<br />
$ bsdtar -x -f /boot/kernel26.img</div>
Idupree
https://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=100343
Mkinitcpio
2010-03-16T20:13:19Z
<p>Idupree: /* HOOKS */ clarify (though it could be worded better by someone more familiar with the architecture of mkinitcpio)</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|mkinitcpio}} {{DISPLAYTITLE:mkinitcpio}}<br />
{{Article summary start}}<br />
{{Article summary text|A detailed guide to the Arch initramfs creation utility.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''mkinitcpio''' is the next generation of initramfs creation.<br />
<br />
From [[Wikipedia:initrd]]:<br />
<br />
:''The '''initial ramdisk''', ['''initramfs'''], or '''initrd''' is a temporary file system commonly used in the [[boot process]] of the Linux kernel. It is typically used for making preparations before the real root file system can be mounted.''<br />
<br />
== Overview ==<br />
<br />
mkinitcpio is a Bash script used to create an initial ramdisk environment. From the [http://projects.archlinux.org/mkinitcpio.git/tree/mkinitcpio.5.txt mkinitcpio man page]:<br />
<br />
:''The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init. This makes it possible to have, for example, encrypted root filesystems and root filesystems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features.''<br />
<br />
Traditionally, the kernel was responsible for all hardware detection and initialization tasks early in the [[boot process]] before mounting the root filesystem and passing control to {{Codeline|init}}. However, as technology advances, these tasks have become increasingly complex. <br />
<br />
Nowadays, the root filesystem may be on a wide range of hardware, from SCSI to SATA to USB drives, controlled by a variety of drive controllers from different manufacturers. Additionally, the root filesystem may be encrypted or compressed; within a software RAID array or a logical volume group. The simple way to handle that complexity is to pass management into userspace: an initial ramdisk. <br />
<br />
See also: [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ /dev/brain0 &raquo; Blog Archive &raquo; Early Userspace in Arch Linux].<br />
<br />
mkinitcpio is a modular tool for building an init ramfs cpio image, offering many advantages over alternative methods, including:<br />
<br />
* The use of '''busybox''' to provide a small and lightweight base for early userspace (prior to version 0.6, [http://www.archlinux.org/news/486/ '''klibc'''] was used instead).<br />
* Support for '''[[udev]]''' for hardware autodetection at runtime, thus preventing the loading of unnecessary modules.<br />
* Being an extendable hook-based init script, custom hooks can easily be included in [[pacman]] packages.<br />
* Support for '''lvm2''', '''dm-crypt''' for both legacy and LUKS volumes, '''raid''', '''mdadm''', and '''swsusp''' and '''suspend2''' for resuming and booting from USB mass storage devices.<br />
* The ability to allow many features to be configured from the kernel command line without needing to rebuild the image.<br />
* Support for the inclusion of the image in a kernel, thus making a self-contained kernel image possible.<br />
<br />
mkinitcpio has been developed by '''phrakture''' and '''tpowa''' with some help from the community.<br />
<br />
== Installation ==<br />
<br />
The {{Package Official|mkinitcpio}} package is available in the [core] repository, and is installed by default as a member of the '''base''' group:<br />
# pacman -S mkinitcpio<br />
<br />
Users may wish to install the latest development version of mkinitcpio from Git:<br />
$ git clone git://projects.archlinux.org/mkinitcpio.git<br />
<br />
== Image creation and activation ==<br />
<br />
By default, the mkinitcpio script generates two images after kernel installation or upgrades: {{Filename|/boot/kernel26.img}} and {{Filename|/boot/kernel26-fallback.img}}. The ''fallback'' image utilizes the same configuration file as the ''default'' image, except the '''autodetect''' hook is skipped during creation, thus including a full range of modules. The '''autodetect''' hook detects required modules and tailors the image for specific hardware, shrinking the initramfs. <br />
<br />
Users may create any number of initramfs images with a variety of different configurations. The desired image must be specified for the bootloader, often in its configuration file ({{Filename|/boot/grub/menu.lst}} for [[GRUB]] users). After changes are made to the configuration file, the image must be regenerated. For the stock Arch Linux kernel, {{Package Official|kernel26}}, this is accomplished with the command:<br />
<br />
# mkinitcpio -p kernel26<br />
<br />
The {{Codeline|-p}} switch specifies a ''preset'' to utilize; most kernel packages provide a related mkinitcpio preset file, found in {{Filename|/etc/mkinitcpio.d}} (e.g. {{Filename|/etc/mkinitcpio.d/kernel26.preset}} for <tt>kernel26</tt>). A preset is a predefined definition of how to create an initramfs image instead of specifying the configuration file and output file every time.<br />
<br />
{{Warning|{{Filename|preset}} files are used to automatically regenerate the initramfs after a kernel update; be careful when editing them.}}<br />
<br />
Users can manually create an image using an alternate configuration file:<br />
<br />
# mkinitcpio -c /etc/mkinitcpio-custom.conf -g /boot/kernel26-custom.img<br />
<br />
This will generate the initramfs image for the currently running kernel and save it at {{Filename|/boot/kernel26-custom.img}}. <br />
<br />
If creating an image for a kernel other than the one currently running, add the kernel version to the command line:<br />
<br />
# mkinitcpio -g /boot/kernel26.img -k 2.6.16-ARCH<br />
<br />
== Configuration ==<br />
<br />
The primary configuration file for '''mkinitcpio''' is {{Filename|/etc/mkinitcpio.conf}}. Additionally, preset definitions are provided by kernel packages in the {{Filename|/etc/mkinitcpio.d}} directory (e.g. {{Filename|/etc/mkinitcpio.d/kernel26.preset}}).<br />
<br />
{{Warning|'''lvm2''', '''raid''', '''mdadm''', and '''encrypt''' are '''NOT''' enabled by default. Please read this section carefully for instructions if these hooks are required.}}<br />
<br />
{{Note|Users with multiple hardware disk controllers that use the same node names but different kernel modules (e.g. two SCSI/SATA or two IDE controllers) should ensure the correct order of modules is specified in {{Filename|/etc/mkinitcpio.conf}}. Otherwise, the root device location may change between boots, resulting in kernel panics.<br />
<br />
A more elegant alternative is to use [[persistent block device naming]] to ensure that the right devices are mounted.}}<br />
<br />
Users can modify five variables within the configuration file:<br />
<br />
; {{Codeline|MODULES}}: Kernel modules to be loaded before any boot hooks are run. <br />
; {{Codeline|BINARIES}}: Additional binaries to be included in the initramfs image.<br />
; {{Codeline|FILES}}: Additional files to be included in the intramfs image.<br />
; {{Codeline|HOOKS}}: Hooks are scripts that execute in the initial ramdisk.<br />
; {{Codeline|COMPRESSION}}: Used to compress the initramfs image.<br />
<br />
=== HOOKS ===<br />
<br />
A hook is a script that executes at ''mkinitcpio'' time in the initial ramdisk. Hooks are listed in order of execution, and control the modules and scripts added to the image. <br />
<br />
Hooks are found within the {{Filename|/lib/initcpio/install}} directory; for a list of available hooks:<br />
<br />
$ ls -1 /lib/initcpio/install<br />
<br />
Use mkinitcpio's {{Codeline|-H}} option to output help for a specific hook. For example, to display information about the '''base''' hook:<br />
<br />
$ mkinitcpio -H base<br />
<br />
The default configuration will work for most users with a standard setup:<br />
<br />
HOOKS="base udev autodetect pata scsi sata filesystems"<br />
<br />
If using the image on more than one machine, remove the '''autodetect''' hook, which tailors the image to the build machine:<br />
<br />
HOOKS="base udev pata scsi sata filesystems"<br />
<br />
For support for encrypted volumes on LVM2 volume groups:<br />
<br />
HOOKS="base udev autodetect pata scsi sata lvm2 encrypt filesystems"<br />
<br />
A table of common hooks and their function follows. Note that this table is not complete, as packages can provide custom hooks. <br />
<br />
{| border="1" <br />
|+ '''Common hooks'''<br />
|-<br />
! Hook || Installation || Runtime<br />
|-<br />
| '''base''' || Sets up all initial directories and installs base utilities and libraries. Always add this hook unless you know what you are doing. || --<br />
|-<br />
| '''udev''' || Adds udev to your image || Udev will be used to create your root device node and detect the needed modules for your root device. As it simplifies things, using the udev hook is recommended.<br />
|-<br />
| '''autodetect''' || Shrinks your initramfs to a smaller size by autodetecting your needed modules. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full. || --<br />
|-<br />
| '''ide''' || Adds legacy IDE modules to the image. You may choose to use this if your root device is on an IDE disk. Also use the '''autodetect''' hook if you want to minimize your image size || Loads legacy IDE modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''pata''' || Adds the new libata/PATA IDE modules to the image. Use this if your root device is on a IDE disk. Also use the '''autodetect''' hook if you want to minimize your image size || Loads IDE modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below). PATA is the kernel's new IDE driver. PATA utilizes SCSI emulation and will change {{Filename|/dev/hd''x''}} to {{Filename|/dev/sd''x''}}. [http://archlinux.org/news/272/ More information].<br />
|-<br />
| '''sata''' || Adds serial ATA modules to the image. Use this if your root device is on a SATA disk. Also use the '''autodetect''' hook if you want to minimize your image size. || Loads SATA modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''scsi''' || Adds SCSI modules to the image. Use this if your root device is on a SCSI disk. Also use the '''autodetect''' hook if you want to minimize your image size. || Loads SCSI modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''usb''' || Adds USB modules to the image. Use this if your root device is on a USB mass storage device or if your USB mass storage device needs to be accessed otherwise (checked, mounted, etc.) at boot time. || Loads USB modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''usbinput''' || Adds USB HID modules to the image. Use this if you have an USB keyboard and need it in early userspace (either for entering encryption passphrases or for failsafe mode). || Loads USB HID modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''fw''' || Adds FireWire modules to the image. Use this if your root device is on a FW mass storage device. || Loads FW modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''net''' || Adds the necessary modules for a network device. For PCMCIA net devices please add the '''pcmcia''' hook too. || Loads network modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below). See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''pcmcia''' || Adds the necessary modules for PCMCIA devices. You need to have {{Package Official|pcmciautils}} installed to use this. || Loads pcmcia modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''[[DSDT|dsdt]]''' || Loads a custom ACPI DSDT file during boot. Place your custom DSDT file for inclusion at {{Filename|/lib/initcpio/custom.dsdt}} || The custom DSDT file is automatically used by the kernel if it is present in initramfs.<br />
|-<br />
| '''filesystems''' || This includes necessary filesystem modules into your image. This hook is '''required''' unless you specify your filesystem modules in MODULES. || This will detect the filesystem type at runtime, load the module and pass it to kinit. (Will NOT detect '''reiser4''', which must be added to modules list.)<br />
|-<br />
| '''lvm2''' || Adds the device mapper kernel module and the {{Codeline|lvm}} tool to the image. You need to have the {{Package Official|lvm2}} package installed to use this. || Enables all LVM2 volume groups. This is necessary if you have your root filesystem on LVM.<br />
|-<br />
| '''raid''' || Adds the modules and {{Codeline|mdassamble}} for a software RAID setup. This hook has been superseded by the '''mdadm''' hook. You need to have {{Package Official|mdadm}} installed to use this. || Loads the necessary modules for software raid devices, and assembles the raid devices when run. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''mdadm''' || This hook supersedes the above '''raid''' hook. It supports assembling the arrays from {{Filename|/etc/mdadm.conf}}, or autodetection during boot. || Loads the necessary modules for software raid devices, and assembles the raid devices when run. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''encrypt''' || Adds the '''dm-crypt''' kernel module and the {{Codeline|cryptsetup}} tool to the image. You need to have the {{Package Official|cryptsetup}} package installed to use this. || Detects and unlocks an encrypted root partition. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''resume''' || -- || This tries to resume from the "suspend to disk" state. Works with both ''swsusp'' and ''[[suspend2]]''. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''firmware''' || Adds {{Filename|/lib/firmware}} files. || Loads firmware. You will need the '''udev''' hook to get firmware loaded. <br />
|-<br />
| '''keymap''' || Adds keymap and consolefonts from [[rc.conf]]. || Loads the specified keymap and consolefont from {{Filename|rc.conf}} during early userspace.<br />
|}<br />
<br />
=== MODULES ===<br />
<br />
The MODULES array is used to specify modules to load before anything else is done. To accelerate the boot process, users may opt to disable the '''udev''' hook and list required modules here instead:<br />
<br />
MODULES="piix ide_disk reiserfs"<br />
<br />
[...]<br />
<br />
HOOKS="base autodetect ide filesystems"<br />
<br />
{{Note|If using '''reiser4''', it ''must'' be added to the modules list.}}<br />
<br />
{{Box YELLOW|TODO:|Find out which modules fail on modern kernels.}}<br />
Known modules that are not autoloaded during boot process (status stock kernel 2.6.18):<br />
<br />
<tt>scsi_transport_sas, ultrastor, qlogicfas, eata, BusLogic, pas16, wd7000, sym53c416, g_NCR5380_mmio, fdomain, u14-34f, dtc initio, in2000, imm, t128, aha1542, aha152x, atp870u, g_NCR5380, NCR53c406a, qlogicfas408, megaraid_mm, advansys</tt><br />
<br />
If one of the above modules are required for the root device, consider explicitly adding it to {{Filename|/etc/mkinitcpio.conf}} to avoid kernel panics.<br />
<br />
=== BINARIES and FILES ===<br />
<br />
These options allow users to add files to the image. Both BINARIES and FILES are added before hooks are run, and may be used to override files used or provided by a hook. BINARIES are dependency-parsed, meaning any required libraries will also be added. FILES are added ''as-is''. For example:<br />
<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
<br />
BINARIES="/usr/bin/cal"<br />
<br />
== Runtime customization ==<br />
<br />
Runtime configuration options can be passed to {{Codeline|init}} and certain hooks via the kernel command line. Kernel command line parameters are often supplied by the bootloader. For example, a typical Arch Linux [[GRUB]] entry:<br />
<br />
{{File<br />
|name=/boot/grub/menu.lst<br />
|content=<nowiki><br />
...<br />
<br />
# (0) Arch Linux<br />
title Arch Linux [/boot/vmlinuz26]<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
...<br />
</nowiki>}}<br />
<br />
In this case, {{Codeline|<nowiki>root=/dev/sda3</nowiki>}} and {{Codeline|ro}} are kernel command line parameters. The options discussed below can be appended to the kernel command line to alter default behavior. See [[Arch Boot Process]] for more information.<br />
<br />
=== init ===<br />
<br />
''The following options alter the default behavior of {{Codeline|init}} in the initramfs environment. See {{Filename|/lib/initcpio/init}} for details.''<br />
<br />
; {{Codeline|break}}: If {{Codeline|<nowiki>break=y</nowiki>}} is specified, init pauses early in the boot process (after loading modules) and launches an interactive shell which can be used for troubleshooting purposes. (Normal boot continues after logout.)<br />
<br />
; {{Codeline|disablehooks}}: Disable hooks at runtime by adding {{Codeline|<nowiki>disablehooks=hook1{,hook2,...}</nowiki>}}. For example: <pre>disablehooks=resume</pre><br />
<br />
; {{Codeline|disablemodules}}: Blacklist modules at runtime by adding {{Codeline|<nowiki>disablemodules=mod1{,mod2,...}</nowiki>}}. For example: <pre>disablemodules=ata_piix</pre><br />
<br />
; {{Codeline|earlymodules}}: Alter the order in which modules are loaded by specifying modules to load early via {{Codeline|<nowiki>earlymodules=mod1{,mod2,...}</nowiki>}}. (This may be used, for example, to ensure the correct ordering of multiple network interfaces.)<br />
<br />
; {{Codeline|rootdelay}}: Pause for ten seconds before mounting the root file system by appending {{Codeline|rootdelay}}. (This may be used, for example, if booting from a USB hard drive that takes longer to initialize.)<br />
<br />
=== Using raid ===<br />
<br />
First add the 'mdadm' hook to the HOOKS list and any required raid modules to the MODULES list in '''/etc/mkinitcpio.conf'''.<br />
<br />
'''Kernel Parameters: '''<br />
Using the 'mdadm' hook, you no longer need to configure your RAID array in the GRUB parameters. The 'mdadm' hook will either use your /etc/mdadm.conf file, or automatically detect the arrays during the init phase of boot.<br />
<br />
=== Using net ===<br />
<br />
'''Kernel Parameters:''' <br />
<br />
'''ip=''' <br />
<br />
An interface spec can be either short form, which is just the name of<br />
an interface (eth0 or whatever), or long form. The long form consists<br />
of up to seven elements, separated by colons:<br />
<br />
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf><br />
nfsaddrs= is an alias to ip= and can be used too.<br />
<br />
''Parameter explanation:''<br />
<client-ip> IP address of the client. If empty, the address will<br />
either be determined by RARP/BOOTP/DHCP. What protocol<br />
is used de- pends on the <autoconf> parameter. If this<br />
parameter is not empty, autoconf will be used.<br />
<br />
<server-ip> IP address of the NFS server. If RARP is used to<br />
determine the client address and this parameter is NOT<br />
empty only replies from the specified server are<br />
accepted. To use different RARP and NFS server,<br />
specify your RARP server here (or leave it blank), and<br />
specify your NFS server in the `nfsroot' parameter<br />
(see above). If this entry is blank the address of the<br />
server is used which answered the RARP/BOOTP/DHCP<br />
request.<br />
<br />
<gw-ip> IP address of a gateway if the server is on a different<br />
subnet. If this entry is empty no gateway is used and the<br />
server is assumed to be on the local network, unless a<br />
value has been received by BOOTP/DHCP.<br />
<br />
<netmask> Netmask for local network interface. If this is empty,<br />
the netmask is derived from the client IP address assuming<br />
classful addressing, unless overridden in BOOTP/DHCP reply.<br />
<br />
<hostname> Name of the client. If empty, the client IP address is<br />
used in ASCII notation, or the value received by<br />
BOOTP/DHCP.<br />
<br />
<device> Name of network device to use. If this is empty, all<br />
devices are used for RARP/BOOTP/DHCP requests, and the<br />
first one we receive a reply on is configured. If you<br />
have only one device, you can safely leave this blank.<br />
<br />
<autoconf> Method to use for autoconfiguration. If this is either<br />
'rarp', 'bootp', or 'dhcp' the specified protocol is<br />
used. If the value is 'both', 'all' or empty, all<br />
protocols are used. 'off', 'static' or 'none' means<br />
no autoconfiguration.<br />
''Examples:''<br />
ip=127.0.0.1:::::lo:none --> Enable the loopback interface.<br />
ip=192.168.1.1:::::eth2:none --> Enable static eth2 interface.<br />
ip=:::::eth0:dhcp --> Enable dhcp protocol for eth0 configuration.<br />
'''nfsroot='''<br />
<br />
If the 'nfsroot' parameter is NOT given on the command line, the default<br />
"/tftpboot/%s" will be used.<br />
<br />
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]<br />
<br />
''Parameter explanation:''<br />
<br />
<server-ip> Specifies the IP address of the NFS server. If this field<br />
is not given, the default address as determined by the<br />
`ip' variable (see below) is used. One use of this<br />
parameter is for example to allow using different servers<br />
for RARP and NFS. Usually you can leave this blank.<br />
<br />
<root-dir> Name of the directory on the server to mount as root. If<br />
there is a "%s" token in the string, the token will be<br />
replaced by the ASCII-representation of the client's IP<br />
address.<br />
<br />
<nfs-options> Standard NFS options. All options are separated by commas.<br />
If the options field is not given, the following defaults<br />
will be used:<br />
port = as given by server portmap daemon<br />
rsize = 1024<br />
wsize = 1024<br />
timeo = 7<br />
retrans = 3<br />
acregmin = 3<br />
acregmax = 60<br />
acdirmin = 30<br />
acdirmax = 60<br />
flags = hard, nointr, noposix, cto, ac<br />
<br />
'''root=/dev/nfs'''<br />
If you don't use nfsroot= parameter you need to set root=/dev/nfs <br />
to boot from a nfs root by autoconfiguration.<br />
<br />
=== Using lvm ===<br />
<br />
If your root device is on lvm, you have to add the '''lvm2''' hook. You have to pass your root device on the kernel command line in the format<br />
<br />
root=/dev/mapper/<volume group name>-<logical volume name><br />
<br />
for example<br />
<br />
root=/dev/mapper/myvg-root<br />
<br />
=== Using encrypted root ===<br />
<br />
If your root volume is encrypted, you need to add the '''encrypt''' hook. Then specify your root device on the kernel command line, just as if it was unencrypted.<br />
<br />
For an encrypted partition on an sata or scsi disk:<br />
root=/dev/sda5<br />
<br />
For an encrypted lvm volume:<br />
root=/dev/mapper/myvg-root<br />
<br />
The root device will be automatically changed to ''/dev/mapper/root''.<br />
<br />
==== Using LUKS volumes ====<br />
<br />
If you use LUKS for hard disk encryption, the init script will detect the encryption automatically if the '''encrypt''' hook is enabled. It will then ask for a passphrase and try to unlock the volume.<br />
<br />
If this fails try to add you filesystem-module to the module list in /etc/mkinitcpio.conf if it's not compiled into your kernel.<br />
<br />
==== Using a key-file ====<br />
<br />
You can use a keyfile to encrypt your root-fs. Use the following format:<br />
<br />
cryptkey=device:fs-type:path<br />
<br />
Device is the device-file representing the device your key is stored on (e.g. /dev/sda1), fs-type is the filesystemtype of this device (e.g. ext3) and path is the path to the keyfile inside the fs of this device.<br />
<br />
==== Using legacy cryptsetup volumes ====<br />
<br />
If you are using a legacy cryptsetup volume, you have to specify all cryptsetup options necessary to unlock it on the kernel command line. The option format is<br />
<br />
crypto=hash:cipher:keysize:offset:skip<br />
<br />
representing cryptsetup's --hash, --cipher, --keysize, --offset and --skip options. If you omit an option, cryptsetup's default value is used, so you can just specify<br />
<br />
crypto=::::<br />
<br />
if you created your volume with the default settings.<br />
<br />
'''NOTE:''' For technical reasons, it is not possible to verify the correctness of your passphrase with legacy cryptsetup volumes. If you typed it wrong, mounting will simply fail. It is recommended that you use LUKS instead.<br />
<br />
==== Using loop-aes volumes ====<br />
<br />
'''mkinitcpio''' does not support loop-aes yet.<br />
<br />
== Troubleshooting ==<br />
<br />
=== mkinitcpio hangs on 'autodetect' during kernel upgrade ===<br />
This [http://bugs.archlinux.org/task/10061 '''bug'''] sometimes causes mkinitcpio to hang when upgrading the kernel. It has been noted that certain usb devices and pata hard drives/chipsets may irritate the issue, but the actual cause is currently unknown (2010-03-01). The best known method to circumvent this bug is to edit '/etc/mkinitcpio.conf' and remove 'autodetect' from the HOOKS parameter. Once removed, force reinstall the kernel with 'pacman -Sf kernel26', and mkinitcpio should process cleanly.<br />
<br />
Reboot the system, and then add 'autodetect' back to the HOOKS parameter, and force reinstall the kernel again to complete this workaround. While running on the new kernel, 'autodetect' seems to process successfully.<br />
<br />
NOTE: Be very careful modifying 'etc/mkinitcpio.conf'. Review the procedures BEFORE modifying, and make a backup. Some systems may need another hook for pata/ide, or sata if the respective hook is not yet present. If mkinitcpio fails during a kernel upgrade, and the issue is not resolved before a reboot is executed, this will most likely result in a kernel panic/nonfunctioning system!<br />
<br />
=== Extracting the image ===<br />
<br />
If you are curious about what is inside the initrd image you can extract it and poke at the files inside of it. <br />
<br />
The initrd image is a '''cpio''' archive, generated by the <tt>gen_init_cpio</tt> command, optionally compressed with one the 3 compression schemes understood by the kernel: namely '''gzip''' or '''bzip2''' or '''lzma'''. Only kernels later than 2.6.30 undertand bzip2 and lzma compression.<br />
<br />
<tt>bsdtar</tt> is powerful enough to autodetect the compression used and to extract to the current directory.<br />
<br />
You can list the files in the image with:<br />
$ bsdtar -t -f /boot/kernel26.img<br />
<br />
And to extract them all in the current directory:<br />
$ bsdtar -x -f /boot/kernel26.img</div>
Idupree
https://wiki.archlinux.org/index.php?title=Amarok&diff=100106
Amarok
2010-03-15T02:05:40Z
<p>Idupree: /* Installation */ give the date of the recommendation (things can change fast in the open-source world!)</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|Provides a brief overview of the quintessential KDE music player.}}<br />
{{Article summary heading|Available in languages}}<br />
{{i18n entry|English|Amarok 2}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|Amarok 1.4}}<br />
{{Article summary end}}<br />
<br />
[http://amarok.kde.org/ Amarok] is a music player and organizer for Linux with an intuitive [[Qt]] interface that integrates very well with [[KDE]]. <br />
<br />
For a similar GTK-based music organizer, you might try [[Exaile]] (written in python) or [http://gmusicbrowser.org/ Gmusicbrowser] (written in perl).<br />
<br />
<br />
Amarok 2 has not yet and will not implement all features from [[Amarok 1.4]][http://amarok.kde.org/blog/archives/809-Missing-features-in-Amarok-2.html], so if you are not satisfied with the new version and would rather have the old one back, refer to that article.<br />
<br />
==Installation==<br />
The developers of Amarok currently (as of November 2009) recommend using {{Package Official|phonon-xine}} over the more buggy [[GStreamer]] backend[http://forum.kde.org/viewtopic.php?f=115&t=83610]:<br />
# pacman -S amarok phonon-xine<br />
<br />
Users of [[KDEmod]] will want the KDEmod Amarok build.<br />
<br />
==Customization==<br />
===Integration with Gnome===<br />
See [[Uniform Look for QT and GTK Applications]] for visual integration of the main GUI.<br />
<br />
===Scripts and applets===<br />
New scripts and applets can be found either directly from within Amarok or at [http://kde-apps.org/content/search.php kde-apps.org].<br />
<br />
===Moodbar===<br />
The moodbar is a feature which turn your standard progress slider bar into a progress slider bar coloured depending on the mood of your track, to activate this feature you need to get moodbar building it from the AUR or with yaourt according to your preferences. Then go settings -> configure amarok and check "Show moodbar in progress slider".<br />
<br />
Please note that as of february 19th amarok 2 does NOT generate moodfiles, you can either try to follow this tutorial [http://amarok.kde.org/wiki/Moodbar] to create them yourself or get amarok1 from AUR and let it generate all the .mood files for you. For the amarok1 solution go to settings -> configure amarok, and in the general tab check the "use moods" and "store moods data files with music" boxes.<br />
<br />
==SHOUTcast==<br />
For reasons which have not been adequately explained Amarok developers have removed the SHOUTcast Internet radio features from version 2.1.90 onwards. See the [http://wiki.archlinux.org/index.php/Talk:Amarok_2#Shoutcast discussion page], the forum [http://forum.kde.org/viewtopic.php?f=116&t=83718 here] and the thread starting [http://mail.kde.org/pipermail/amarok/2009-November/009696.html here].<br />
<br />
[[Amarok 1.4]] and [[VLC]] continue to support the SHOUTcast Internet radio station index and streaming as before.<br />
<br />
See also: [http://amarok.kde.org/wiki/FAQ#How_can_I_use_Amarok_to_stream_to_my_own_radio_station.3F How can I use Amarok to stream to my own radio station?], which recommends [http://www.onlymeok.nildram.co.uk/server.html Internet DJ Console], available in the AUR ({{Package AUR|idjc}}).</div>
Idupree
https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=99954
Dm-crypt
2010-03-13T03:58:35Z
<p>Idupree: /* Caveats */ A first attempt at describing the pitfalls of only encrypting (home / certain parts of your disk).</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why Encryption? ==<br />
Encryption is useful for two (related) reasons. Firstly, it prevents anyone with physical access to your computer, and your hard drive in particular, from getting the data from it (unless they have your passphrase/key). Secondly, it allows you to wipe the data on your hard drive with far more confidence in the event of you selling or discarding your drive.<br />
<br />
Basically, it supplements the access control mechanisms of the operating system (like file permissions) by making it harder to bypass the operating system by inserting a boot CD, for example. Encrypting the root partition prevents anyone from using this method to insert viruses or trojans onto your computer.<br />
<br />
Note that we're not encrypting the boot partition - the bootloader needs to read that one!<br />
<br />
'''ATTENTION: Having encrypted partitions does not protect you from all possible attacks. The encryption is only as good as your key management, and there are other ways to break into computers while they are running. Read the CAVEATS section below!'''<br />
<br />
== Why LUKS for dm-crypt? ==<br />
There are either 3 or 4 rival disk encryption standards in Linux, depending on how you count them.<br />
<br />
The old cryptoloop is deprecated: it's old, insecure and unreliable.<br />
<br />
A much better version, loop-AES (http://loop-aes.sourceforge.net/), was created but, due to politics, never became favorable with the kernel developers. It's far more secure than either cryptoloop or straight device-mapper encryptions (and probably faster than any of the other 3 options), but is not user-friendly. It also requires non-standard kernel support, which ARCH's kernel26 doesn't have.<br />
<br />
The standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]) is another choice.<br />
<br />
[http://code.google.com/p/cryptsetup/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://code.google.com/p/cryptsetup/ LUKS home page] if you're interested), it stores all the needed setup information on the disk itself. All you need then is the password, which can be in a separate file if you like. The Linux implementation uses dm-crypt and it can have up to eight different passwords, which can be changed or revoked easily. It is also supported by mkinitcpio in ARCH linux, which is nice.<br />
<br />
== Caveats ==<br />
<br />
=== Security (encryption) ===<br />
Disk encryption is not the be-all and end-all of security. Why not? Well, for a start, it won't prevent people from hacking into a running computer (either over the network or at a console) if there is a security hole to exploited (and there invariably is). There are a dozen and one things you can (and should) do to secure your computer against this type of attack, but they are all outside the scope of this document.<br />
<br />
What's more, even in situations this type of encryption is useful for (physical access to storage media), it isn't worth a thing if someone has your key. In other words, if someone finds out or guesses your passphrase, or gets access to your external key file if you're using one, they can unlock the encryption on the hard drive in exactly the same way that you can.<br />
<br />
What does this mean for you? Well, if you use an external key file, keep the device it is on '''SAFE'''. Attach it to your keyring or whatever. If you use a passphrase, '''make it hard to guess'''. There are [http://www.google.co.uk/search?q=create+secure+password hundreds of documents] all over the internet telling you how to come up with a secure passphrase; we're not going to go over it here. Note, however, that we use the term "passphrase": '''it doesn't have to be a single word'''.<br />
<br />
=== Security (encrypted home) ===<br />
<br />
If you install mlocate, it will scan all your currently mounted filesystems regularly, in updatedb. Then it will write the list of filenames to /var/lib/mlocate/mlocate.db, which is in the (less-encrypted) root or /var partition. There might be other packages similar to mlocate. Thus an attacker will have a list of all your filenames, including the ones you illegally downloaded or perhaps you named a file after your secret lover (or your chat client did, somewhere under ~/.chat-client/...). Thus your security would be reduced to the level of [[System_Encryption_with_eCryptfs|eCryptfs]]. If you're interested in encryption, think twice before sabotaging its potential.<br />
<br />
Likewise, it is essential to have all swap be encrypted and /tmp to either be tmpfs or also an encrypted partition; otherwise it is all too easy for information to leak and you not even to realize it is leaking unencrypted onto the disk.<br />
<br />
== Getting started ==<br />
If you're not starting from an unused hard drive, '''BACK UP YOUR DATA!''' I cannot stress this enough. Ideally, you should be doing this regularly anyway, and it's particularly important with an encrypted hard drive. But beware: if you have unencrypted backups, is there any point in having an encrypted hard drive? Think about where you store your backups.<br />
<br />
'''Note:''' if you want to have encrypted swap, read the section below about Encrypted Swap and decide how you want to set it up ''before'' you start the rest of this HOWTO.<br />
<br />
Since Arch Linux 2009.08 the Arch installer provides a comfortable and easy way to configure dm_crypt (also in combination with [[LVM]]).<br />
Of course you can also do all the work manually.<br />
In either case it's recommended to overwrite the disk to wipe out former unencrypted content.<br />
<br />
== Preparation ==<br />
=== Overwriting ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite this data. Contrary to popular believe overwriting several times or using random data as source serves no purpose. Data won't be recoverable after being overwritten by zeros. [http://www.springerlink.com/content/408263ql11460147/]<br />
<br />
To overwrite your disk with zeros you can use<br />
# dd if=/dev/zero of=/dev/sda bs=1M<br />
<br />
If you want to check for bad blocks while writing you can use badblocks. <br />
The <tt>badblocks</tt> command will check your disk for bad blocks while writing random data. The pseudorandom algorithm used by this command is faster (although "less random") than <tt>/dev/urandom</tt>, so it can be useful for large disks. [[frandom]] is a fast random generator you might want to use for large disk.<br />
<br />
# badblocks -c 10240 -w -t random -s -v /dev/sda<br />
This will test blocks in groups of 10240 (i.e. 10MB) at a time, writing over them with random data and showing progress as it goes.<br />
<br />
However it should be noted that the pseudo random data generated by badblocks does not serve any other purpose than slowing down the wiping of your drive.<br />
<br />
It is advantageous to subsequently fill the disk from a cryptographically-secure random number generator such as /dev/urandom, so that attackers who get access to your disk (the only people that disk-encryption defends against) cannot tell which blocks of the disk have yet been filled with encrypted data. If they get this information, it both tells them directly something about how much you've used your disk, and also might make the encryption easier to crack, (learning which parts of the disk are used might potentially help them guess which filesystem is inside, and maybe even what size files you've got...). Yes, /dev/urandom takes hours to generate enough data to fill up a modern hard disk, but you only have to do it once.<br />
<br />
== Arch Linux Installer (>2009.08) ==<br />
Since Arch Linux 2009.08 the installer supports dm_crypt and LVM (and combination of both) out of the box.<br />
<br />
Just run the installer as usual, i.e. follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]].<br />
When you reach the "Prepare Hard Drive(s)" don't use "Auto-Prepare" but set up your partitions manually.<br />
Beware that you '''have to''' create a separate unencrypted <tt>/boot</tt> partition, or GRUB/LILO has no chance to load the operating system afterwards.<br />
The most important step towards an encrypted system is done in the "Manually Configure ..." step.<br />
<br />
=== Configuring filesystems and mountpoints ===<br />
At first select the device corresponding to your unencrypted <tt>/boot</tt> partition, choose e.g. ext2 as filesystem and select <tt>/boot</tt> as the mountpoint.<br />
For all other partitions you created and which you want to be encrypted select dm_crypt in the filesystem dialog.<br />
You should enter a label for the encrypted device, e.g. 'sda2crypt', or simply 'root'.<br />
<br />
Here is an example listing how it may look like:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt<br />
/dev/sda3 raw->dm_crypt;yes;no_mountpoint;no_opts;sda3crypt<br />
/dev/mapper/sda2crypt dm_crypt->ext3;yes;/;no_opts;no_label;no_params<br />
/dev/mapper/sda3crypt dm_crypt->ext3;yes;/home;no_opts;no_label;no_params<br />
<br />
'''Note''': you can also put a LVM inside the dm_crypt partition, or vice versa a dm_crypt partition inside a LVM volume. See [[#Encrypting a LVM setup|Encrypting a LVM setup]] for details.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
That's it with the dm_crypt specific part for so far. Select your desired packages and install the system.<br />
The installer should perform all steps necessary for configuring the boot and mount process of your new system.<br />
You can check the configuration afterwards and compare them to the one in the section about manual configuration.<br />
Especially the HOOKS section in <tt>mkinitcpio.conf</tt> is important for an encrypted root partition.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
<br />
== Manually configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Partitioning ===<br />
At first set up your partitions as you want. Make sure you have a separate partition for /boot. If you think about it, this is absolutely necessary. If your /boot partition is encrypted, then your bootloader would not be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following - indicative - partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
/dev/sda5 -> /tmp # especially useful if you don't want to encrypt the entire root (/) partition<br />
<br />
=== Loading kernel modules ===<br />
'''Note:''' this article will use XTS-AES as encryption algorithm because it was standardized as IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices and it is quite secure, however the XTS mode is still flagged as "experimental" in the Linux kernel, so if you want something less secure but more proven, you should go with the CBC-ESSIV mode. The XTS mode is supported by Linux 2.6.24 upwards (ISO of Arch 2008.06 upwards).<br />
<br />
'''Note:''' The XTS mode uses two keys of the same size, therefore available sizes (using XTS-AES) are 256 (128 * 2), 384 (192 * 2) and 512 (256 * 2).<br />
<br />
Load the dm-crypt and the optimized AES module:<br />
# modprobe dm-crypt<br />
# modprobe aes-i586<br />
<br />
'''Note:''' x86_64 users can also try the "aes-x86_64" optimized module instead of "aes-i586".<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda4 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda4 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,4,5<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda4 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda4</tt> or <tt>/dev/sda5</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
'''Note:''' With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.<br />
<br />
'''Note:''' You might also want to replace /var/tmp/ with a symbolic link to /tmp.<br />
<br />
'''Note:''' If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.<br />
<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
'''Note:''' Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). If it is a ''swap'' or ''any other partition'', all is taken care by ''rc.sysinit'' and ''/etc/crypttab'' file'''<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keyboard' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
'''Note''' if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
'''Note:''' eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.<br />
<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda4 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
'''Note:''' Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
'''Note:''' Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work. If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
<span style="color:red">''Warning: don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure''</span><br><br><br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device><br />
* as stated in discussion: the -h parameter to specify hash function is (in this case) ignored, also the default hash - ripemd - is not recommended (citation needed). use aes-xts-plain:whirlpool , or aes-xts-sha256 instead. <br />
* check result with # cryptsetup luksDump /dev/<device>(sda3)<br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (due to journaling filesystems etc this is also not 100% secure)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption together with LVM. We are not going to cover the process of setting up LVM here as there is already a guide for that ([[Installing_with_Software_RAID_or_LVM]]).<br />
<br />
The best method and easier method to follow for a laptop is to set up the LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda4 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "lvm2" hook in /etc/mkinitcpio.conf '''before''' the "encrypt" hook. And you will have to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
In <tt>/etc/mkinitcpio.conf</tt> add ''lvm2'' '''before''' ''encrypt'' in the HOOKS variable.<br />
<br />
That's it for the LVM&dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2 encrypt'' before ''filesystems.<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root</div>
Idupree
https://wiki.archlinux.org/index.php?title=User_talk:Iphitus&diff=99234
User talk:Iphitus
2010-03-07T04:55:59Z
<p>Idupree: /* netcfg red warning box */ more misc. Network pages?</p>
<hr />
<div>Hi. What about [[Additional Network Config Examples]] and [[Network Scripts]], do you want to merge those with [[Network Profiles]] or scrap them altogether?<br />
:--[[User:Byte|byte]] 13:38, 14 December 2008 (EST)<br />
<br />
==Supplementary netcfg documentation==<br />
I've been trying to update and improve the [[Network Profiles]] wiki article as of late, and think a complete dictionary of valid profile options would be beneficial. I notice such a dictionary exists in the netcfg Git repo (http://projects.archlinux.org/netcfg.git/tree/docs/ethernet and http://projects.archlinux.org/netcfg.git/tree/docs/wireless), but these files are not included with the package.<br />
<br />
# are they current?<br />
# do you mind if they are copied and included on this wiki?<br />
<br />
Cheers,<br />
<br />
-- [[User:Pointone|pointone]] 14:14, 3 March 2010 (EST)<br />
<br />
== netcfg red warning box ==<br />
<br />
I see you added on the netcfg page a warning box at the beginning, which confused me, in revision<br />
http://wiki.archlinux.org/index.php?title=Network_Profiles&diff=97290&oldid=97289<br />
<br />
Since I see nothing explanatory in the commit log, could you comment on my suggestion about it? at http://wiki.archlinux.org/index.php/Talk:Network_Profiles#confusing_warning_message<br />
<br />
Thanks!<br />
[[User:Idupree|Idupree]] 18:54, 6 March 2010 (EST)<br />
<br />
<br />
'''Also! :-)'''<br />
<br />
the [[Network Scripts]] page looks like a 2 year old version of this, and [[Network Profiles development]] (sounded to me from the title like it was about developing the netcfg implementation but) looks like it's maybe a sandbox you use for updates to the [[Network Profiles]] page. Should they be marked as outdated/unofficial or deleted/moved? Luckily nothing important links to them, but they have sort-of-official-sounding names and the search box quickly found them...</div>
Idupree
https://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=99231
Network configuration/Wireless
2010-03-07T04:36:39Z
<p>Idupree: /* Management methods */ make sure no one uses WEP thinking that its encryption will protect them! WEP has many many flaws. also fix typo</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <tt>lspci | grep -i net</tt> from the command line.<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has an good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line.<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no other means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng====<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver support PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S rt2x00-rt71w-fw</pre><br />
<pre>pacman -S rt2x00-rt61-fw</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi====<br />
Package: '''madwifi'''<br />
<br />
The module is called <tt>ath_pci</tt>. The newer module, ath5k, will eventually phase out ath_pci (or for newer Atheros hardware, [[#ath9k|ath9k]] is the new, official, superior driver, see below).<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. Support seems alright as of 2.6.32 (see [http://linuxwireless.org/en/users/Drivers/ath9k/bugs#Minimal_kernel_requirements details on linuxwireless.org]). (In the unlikely event that you have stability issues that trouble you, you could try using the [http://wireless.kernel.org/en/users/Download compat-wireless] package.<br />
An [https://lists.ath9k.org/mailman/listinfo/ath9k-devel ath9k mailing list] exists for support and development related discussions.)<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
Install the appropriate firmware package for your chipset:<br />
# pacman -S iwlwifi-3945-ucode<br />
or:<br />
# pacman -S iwlwifi-4965-ucode<br />
or:<br />
# pacman -S iwlwifi-5000-ucode<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
To manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/options. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!snd_pcsp !eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://www.prism54.org/ this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== BCM43XX ====<br />
<br />
Broadcom wireless hardware that have the 43xx series chipsets no longer have to use ndiswrapper on kernel versions 2.6.17 and above. The Broadcom driver has been updated since the BCM43XX verion and most users they will want to use the [[#b43]] driver.<br />
<br />
#Run <pre>iwconfig</pre> or <pre>hwd -s</pre> to determine that you have an appropriate card. Example: <pre>Network : Broadcom Corp.|BCM94306 802.11g NIC module: unknown</pre> For a list of supported devices, see [http://bcm43xx.berlios.de/?go=devices this].<br />
#Run <pre>pacman -S b43-fwcutter</pre> to install the firmware cutter application.<br />
#Download the Windows driver file for your card from which to extract the firmware.<br />
#If you download the driver from Dell's website, you must run in on a Windows machine or under WINE (it is a .exe file that extracts itself to C:\Dell\[driver numbers]). Or you may try [http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o], [http://freewebs.com/ronserver/bcm43xx.tar.gz] or [http://xeve.de/down/wl_apsta.o]. You will not need it after the next step, so location where it is saved is not important.<br />
#Run <pre>bcm43xx-fwcutter -w /lib/firmware /home/&lt;user&gt;/Desktop/wl_apsta.o</pre> You may have to create /lib/firmware first.<br />
#Restart, and configure your device as normal. You may want to add bcm43xx into the modules section of your rc.conf file. Good luck!<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the Broadcom 43xx firmware:<br />
<br />
yaourt -S b43-firmware # or for newer cards<br />
yaourt -S b43-firmware-newest # or for older cards<br />
yaourt -S b43-firmware-legacy<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 4312 cards. See the [[Broadcom_BCM4312|Broadcom 4312 wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
If <code>iwlist scan</code> displays <code>Interface does not support scanning</code> then you probably forgot to install the firmware.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || || cnetworkmanager (AUR)<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure -- but crackable in a matter of minutes, so it's hardly more secure than an unencrypted connection) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome network-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
1. ''(Optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
2. ''(Optional, may be required)'' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
3. Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
4. Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Using yaourt:<br />
# yaourt -S newlan<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>
Idupree
https://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=99230
Network configuration/Wireless
2010-03-07T04:29:45Z
<p>Idupree: /* ath9k */ I used ath9k since Ubuntu 8.10; since mid-2009 it seems quite stable (not perfect, but way better than madwifi, and sometimes even works better just mainline than adding compat-wireless)</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <tt>lspci | grep -i net</tt> from the command line.<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has an good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line.<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no other means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng====<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver support PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S rt2x00-rt71w-fw</pre><br />
<pre>pacman -S rt2x00-rt61-fw</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi====<br />
Package: '''madwifi'''<br />
<br />
The module is called <tt>ath_pci</tt>. The newer module, ath5k, will eventually phase out ath_pci (or for newer Atheros hardware, [[#ath9k|ath9k]] is the new, official, superior driver, see below).<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. Support seems alright as of 2.6.32 (see [http://linuxwireless.org/en/users/Drivers/ath9k/bugs#Minimal_kernel_requirements details on linuxwireless.org]). (In the unlikely event that you have stability issues that trouble you, you could try using the [http://wireless.kernel.org/en/users/Download compat-wireless] package.<br />
An [https://lists.ath9k.org/mailman/listinfo/ath9k-devel ath9k mailing list] exists for support and development related discussions.)<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
Install the appropriate firmware package for your chipset:<br />
# pacman -S iwlwifi-3945-ucode<br />
or:<br />
# pacman -S iwlwifi-4965-ucode<br />
or:<br />
# pacman -S iwlwifi-5000-ucode<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
To manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/options. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!snd_pcsp !eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://www.prism54.org/ this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== BCM43XX ====<br />
<br />
Broadcom wireless hardware that have the 43xx series chipsets no longer have to use ndiswrapper on kernel versions 2.6.17 and above. The Broadcom driver has been updated since the BCM43XX verion and most users they will want to use the [[#b43]] driver.<br />
<br />
#Run <pre>iwconfig</pre> or <pre>hwd -s</pre> to determine that you have an appropriate card. Example: <pre>Network : Broadcom Corp.|BCM94306 802.11g NIC module: unknown</pre> For a list of supported devices, see [http://bcm43xx.berlios.de/?go=devices this].<br />
#Run <pre>pacman -S b43-fwcutter</pre> to install the firmware cutter application.<br />
#Download the Windows driver file for your card from which to extract the firmware.<br />
#If you download the driver from Dell's website, you must run in on a Windows machine or under WINE (it is a .exe file that extracts itself to C:\Dell\[driver numbers]). Or you may try [http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o], [http://freewebs.com/ronserver/bcm43xx.tar.gz] or [http://xeve.de/down/wl_apsta.o]. You will not need it after the next step, so location where it is saved is not important.<br />
#Run <pre>bcm43xx-fwcutter -w /lib/firmware /home/&lt;user&gt;/Desktop/wl_apsta.o</pre> You may have to create /lib/firmware first.<br />
#Restart, and configure your device as normal. You may want to add bcm43xx into the modules section of your rc.conf file. Good luck!<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the Broadcom 43xx firmware:<br />
<br />
yaourt -S b43-firmware # or for newer cards<br />
yaourt -S b43-firmware-newest # or for older cards<br />
yaourt -S b43-firmware-legacy<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 4312 cards. See the [[Broadcom_BCM4312|Broadcom 4312 wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
If <code>iwlist scan</code> displays <code>Interface does not support scanning</code> then you probably forgot to install the firmware.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || || cnetworkmanager (AUR)<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome networ-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
1. ''(Optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
2. ''(Optional, may be required)'' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
3. Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
4. Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Using yaourt:<br />
# yaourt -S newlan<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>
Idupree
https://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=99229
Network configuration/Wireless
2010-03-07T04:16:39Z
<p>Idupree: /* ath9k */ find out when a "have not propagated yet" statement was made. http://wiki.archlinux.org/index.php?title=Wireless_Setup&diff=59196&oldid=59192</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <tt>lspci | grep -i net</tt> from the command line.<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has an good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line.<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no other means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng====<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver support PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S rt2x00-rt71w-fw</pre><br />
<pre>pacman -S rt2x00-rt61-fw</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi====<br />
Package: '''madwifi'''<br />
<br />
The module is called <tt>ath_pci</tt>. The newer module, ath5k, will eventually phase out ath_pci (or for newer Atheros hardware, [[#ath9k|ath9k]] is the new, official, superior driver, see below).<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. But it has undergone some heavy development, and the changes have not propagated to the mainline kernel tree yet (as of January 2009).<br />
The best solution would be to use the [http://wireless.kernel.org/en/users/Download compat-wireless] package for now.<br />
A [https://lists.ath9k.org/mailman/listinfo/ath9k-devel mailing list] exists for support and development related discussions.<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
Install the appropriate firmware package for your chipset:<br />
# pacman -S iwlwifi-3945-ucode<br />
or:<br />
# pacman -S iwlwifi-4965-ucode<br />
or:<br />
# pacman -S iwlwifi-5000-ucode<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
To manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/options. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!snd_pcsp !eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://www.prism54.org/ this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== BCM43XX ====<br />
<br />
Broadcom wireless hardware that have the 43xx series chipsets no longer have to use ndiswrapper on kernel versions 2.6.17 and above. The Broadcom driver has been updated since the BCM43XX verion and most users they will want to use the [[#b43]] driver.<br />
<br />
#Run <pre>iwconfig</pre> or <pre>hwd -s</pre> to determine that you have an appropriate card. Example: <pre>Network : Broadcom Corp.|BCM94306 802.11g NIC module: unknown</pre> For a list of supported devices, see [http://bcm43xx.berlios.de/?go=devices this].<br />
#Run <pre>pacman -S b43-fwcutter</pre> to install the firmware cutter application.<br />
#Download the Windows driver file for your card from which to extract the firmware.<br />
#If you download the driver from Dell's website, you must run in on a Windows machine or under WINE (it is a .exe file that extracts itself to C:\Dell\[driver numbers]). Or you may try [http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o], [http://freewebs.com/ronserver/bcm43xx.tar.gz] or [http://xeve.de/down/wl_apsta.o]. You will not need it after the next step, so location where it is saved is not important.<br />
#Run <pre>bcm43xx-fwcutter -w /lib/firmware /home/&lt;user&gt;/Desktop/wl_apsta.o</pre> You may have to create /lib/firmware first.<br />
#Restart, and configure your device as normal. You may want to add bcm43xx into the modules section of your rc.conf file. Good luck!<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the Broadcom 43xx firmware:<br />
<br />
yaourt -S b43-firmware # or for newer cards<br />
yaourt -S b43-firmware-newest # or for older cards<br />
yaourt -S b43-firmware-legacy<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 4312 cards. See the [[Broadcom_BCM4312|Broadcom 4312 wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
If <code>iwlist scan</code> displays <code>Interface does not support scanning</code> then you probably forgot to install the firmware.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || || cnetworkmanager (AUR)<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome networ-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
1. ''(Optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
2. ''(Optional, may be required)'' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
3. Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
4. Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Using yaourt:<br />
# yaourt -S newlan<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>
Idupree
https://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=99228
Network configuration/Wireless
2010-03-07T04:05:40Z
<p>Idupree: /* madwifi */ mention that for some hardware (such as mine!), it was ath9k and not ath5k that obsoleted madwifi.</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <tt>lspci | grep -i net</tt> from the command line.<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has an good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line.<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no other means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng====<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver support PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S rt2x00-rt71w-fw</pre><br />
<pre>pacman -S rt2x00-rt61-fw</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi====<br />
Package: '''madwifi'''<br />
<br />
The module is called <tt>ath_pci</tt>. The newer module, ath5k, will eventually phase out ath_pci (or for newer Atheros hardware, [[#ath9k|ath9k]] is the new, official, superior driver, see below).<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. But it has undergone some heavy development, and the changes have not propagated to the mainline kernel tree yet.<br />
The best solution would be to use the [http://wireless.kernel.org/en/users/Download compat-wireless] package for now.<br />
A [https://lists.ath9k.org/mailman/listinfo/ath9k-devel mailing list] exists for support and development related discussions.<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
Install the appropriate firmware package for your chipset:<br />
# pacman -S iwlwifi-3945-ucode<br />
or:<br />
# pacman -S iwlwifi-4965-ucode<br />
or:<br />
# pacman -S iwlwifi-5000-ucode<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
To manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/options. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!snd_pcsp !eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://www.prism54.org/ this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== BCM43XX ====<br />
<br />
Broadcom wireless hardware that have the 43xx series chipsets no longer have to use ndiswrapper on kernel versions 2.6.17 and above. The Broadcom driver has been updated since the BCM43XX verion and most users they will want to use the [[#b43]] driver.<br />
<br />
#Run <pre>iwconfig</pre> or <pre>hwd -s</pre> to determine that you have an appropriate card. Example: <pre>Network : Broadcom Corp.|BCM94306 802.11g NIC module: unknown</pre> For a list of supported devices, see [http://bcm43xx.berlios.de/?go=devices this].<br />
#Run <pre>pacman -S b43-fwcutter</pre> to install the firmware cutter application.<br />
#Download the Windows driver file for your card from which to extract the firmware.<br />
#If you download the driver from Dell's website, you must run in on a Windows machine or under WINE (it is a .exe file that extracts itself to C:\Dell\[driver numbers]). Or you may try [http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o], [http://freewebs.com/ronserver/bcm43xx.tar.gz] or [http://xeve.de/down/wl_apsta.o]. You will not need it after the next step, so location where it is saved is not important.<br />
#Run <pre>bcm43xx-fwcutter -w /lib/firmware /home/&lt;user&gt;/Desktop/wl_apsta.o</pre> You may have to create /lib/firmware first.<br />
#Restart, and configure your device as normal. You may want to add bcm43xx into the modules section of your rc.conf file. Good luck!<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the Broadcom 43xx firmware:<br />
<br />
yaourt -S b43-firmware # or for newer cards<br />
yaourt -S b43-firmware-newest # or for older cards<br />
yaourt -S b43-firmware-legacy<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 4312 cards. See the [[Broadcom_BCM4312|Broadcom 4312 wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
If <code>iwlist scan</code> displays <code>Interface does not support scanning</code> then you probably forgot to install the firmware.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || || cnetworkmanager (AUR)<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome networ-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
1. ''(Optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
2. ''(Optional, may be required)'' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
3. Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
4. Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Using yaourt:<br />
# yaourt -S newlan<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>
Idupree
https://wiki.archlinux.org/index.php?title=Netcfg&diff=99227
Netcfg
2010-03-07T03:44:03Z
<p>Idupree: /* FAQ */ replace "X" as metasyntactic variable because I got confused with the X-window-system at first (which, after all, is a "feature" that NetworkManager normally uses and core netcfg doesn't).</p>
<hr />
<div>[[Category:Networking (English)]]<br />
{{i18n|Network Profiles}}<br />
{{Moveto|netcfg|Talk:Network Profiles#Move to netcfg}}<br />
{{Article summary start}}<br />
{{Article summary text|An guide to installing and configuring netcfg &ndash; network configuration and profile scripts.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network}}<br />
{{Article summary wiki|Wireless Setup}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|netcfg network scripts repository|http://projects.archlinux.org/netcfg.git/}}<br />
{{Article summary end}}<br />
<br />
From the [http://projects.archlinux.org/netcfg.git/tree/man/netcfg.8 netcfg man page]:<br />
<br />
:'''''netcfg''' is used to configure and manage network connections via profiles. It has pluggable support for a range of connection types, such as wireless, ethernet, ppp. It is also capable of starting/stopping many to one connections, that is, multiple connections within the same profile, optionally with bonding.''<br />
<br />
netcfg is useful for users seeking a simple and robust means of managing multiple network configurations (e.g. laptop users). For systems connecting to a single network, the [[network]] daemon may be more appropriate.<br />
<br />
==Preparation==<br />
In the simplest cases, users must at least know the name of their network interface(s) (e.g. '''eth0''', '''wlan0'''). If configuring a static IP address, gateway and name server addresses must also be known.<br />
<br />
If connecting to a wireless network, have some basic information ready. For a wireless network this includes what type of security is used, the network name (SSID), and any password or encryption keys. Additionally, ensure the proper drivers and firmware are installed for the wireless device, as described in [[Wireless Setup]].<br />
<br />
==Installation==<br />
Ensure you have the latest version of netcfg installed. Older versions have more bugs and may not work well with the latest drivers. The {{Package Official|netcfg}} package is available in '''core''':<br />
<br />
# pacman -S netcfg<br />
<br />
As of version 2.5.x, optional dependencies include {{Package Official|wpa_actiond}} &ndash; required for automatic/roaming wireless connection &ndash; and {{Package Official|ifplugd}} &ndash; required for automatic ethernet configuration. ([http://www.archlinux.org/news/487/ More information].)<br />
<br />
# pacman -S wpa_actiond ifplugd<br />
<br />
==Configuration==<br />
Network profiles are stored in the {{Filename|/etc/network.d}} directory. To minimize the potential for errors, copy an example configuration from {{Filename|/etc/network.d/examples}} to {{Filename|/etc/network.d/mynetwork}}. The file name is the name of the network profile ("mynetwork" is used as an example throughout this article). The name is not a network setting and does not need to match the wireless network name (SSID).<br />
<br />
Depending on the connection type and security, use one of the following examples from {{Filename|/etc/network.d/examples}} as a base. Be wary of examples found on the Internet as they often contain deprecated options that may cause problems.<br />
<br />
{| border="1"<br />
! Connection type/security !! Example profile<br />
|-<br />
| Wireless; WEP hex key || {{Filename|wireless-wep}}<br />
|-<br />
| Wireless; WEP string key || {{Filename|wireless-wep-string-key}}<br />
|-<br />
| Wireless; WPA personal (passphrase) || {{Filename|wireless-wpa}}<br />
|-<br />
| Wireless; WPA enterprise || {{Filename|wireless-wpa-config}} (wpa_supplicant configuration is external) <br /> {{Filename|wireless-wpa-configsection}} (wpa_supplicant configuration stored as string)<br />
|-<br />
| Wired; DHCP || {{Filename|ethernet-dhcp}}<br />
|-<br />
| Wired; static IP || {{Filename|ethernet-static}}<br />
|-<br />
| Wired; iproute configuration || {{Filename|ethernet-iproute}}<br />
|}<br />
<br />
Next, modify the new configuration file, {{Filename|/etc/network.d/mynetwork}}:<br />
<br />
* Set {{Codeline|INTERFACE}} to the correct wireless or ethernet interface. This can be checked with {{Codeline|ifconfig}} and {{Codeline|iwconfig}}.<br />
* Ensure the {{Codeline|ESSID}} and {{Codeline|KEY}} (passphrase) are set correctly for wireless connections. Typos in these fields are common errors.<br />
** Note that WEP ''string'' keys (not ''hex'' keys) must be specified with a leading {{Codeline|s:}} (e.g. {{Codeline|<nowiki>KEY="s:somepasskey"</nowiki>}}).<br />
<br />
{{Note | Netcfg configurations are valid Bash scripts. Any configuration involving special characters such as $ or \ needs to be quoted correctly otherwise it will be interpreted by Bash. To avoid interpretation, use single quotes or backslash escape characters where appropriate. }}<br />
<br />
{{Note | Network information (e.g. wireless passkey) will be stored in plain text format, so users may want to change the permissions on the newly created profile (e.g. {{Codeline|chmod 0600 /etc/network.d/mynetwork}} to make it readable by root only).}}<br />
<br />
==Usage==<br />
To connect a profile:<br />
# netcfg mynetwork<br />
<br />
To disconnect a profile:<br />
# netcfg down <profile-name><br />
<br />
If successful, users can configure netcfg to connect automatically or during boot. If the connection fails, see [[#Troubleshooting]] for solutions and how to get help.<br />
<br />
For other functions, see:<br />
$ netcfg help<br />
<br />
==Connecting automatically==<br />
Several methods are available to users wanting to automatically connect network profiles (e.g. during boot or whilst roaming). Note that a network profile must be properly configured within the {{Filename|/etc/network.d}} directory ''first'' (see [[#Configuration]]).<br />
<br />
{{Tip|If enabling one of the following daemons and nothing is configured within the {{Codeline|INTERFACES}} array in {{Filename|rc.conf}}, you may remove the {{Codeline|network}} daemon from the {{Codeline|DAEMONS}} array. If you mount NFS shares during boot, ensure the {{Codeline|netfs}} daemon remains listed, though (otherwise the network will be dropped before unmounting shares during shutdown).}}<br />
<br />
===net-profiles===<br />
'''{{Codeline|net-profiles}} allows users to connect profiles during boot.'''<br />
<br />
To enable this feature, users must add {{Codeline|net-profiles}} to the {{Codeline|DAEMONS}} array in [[rc.conf]] and specify profiles to try in the {{Codeline|NETWORKS}} array:<br />
<br />
{{File<br />
|name=/etc/rc.conf<br />
|content=<nowiki><br />
NETWORKS=(mynetwork yournetwork)<br />
<br />
...<br />
<br />
DAEMONS=(... net-profiles ...)<br />
</nowiki>}}<br />
<br />
Alternatively, {{Codeline|net-profiles}} can be configured to display a menu &ndash; allowing users to choose a desired profile &ndash; by setting the contents of the {{Codeline|NETWORKS}} array to {{Codeline|menu}}:<br />
<br />
{{File<br />
|name=/etc/rc.conf<br />
|content=<nowiki><br />
NETWORKS=(menu)<br />
<br />
...<br />
<br />
DAEMONS=(... net-profiles ...)<br />
</nowiki>}}<br />
<br />
Additionally, the {{Package Official|dialog}} package is required.<br />
<br />
{{Tip|Access the menu at any time by running {{Codeline|netcfg-menu}} in a terminal.}}<br />
<br />
===net-auto-wireless===<br />
'''{{Codeline|net-auto-wireless}} allows users to automatically connect to wireless networks with proper roaming support.'''<br />
<br />
To enable this feature, users must add {{Codeline|net-auto-wireless}} to the {{Codeline|DAEMONS}} array in [[rc.conf]] and specify the desired wireless interface with the {{Codeline|WIRELESS_INTERFACE}} variable:<br />
<br />
{{File<br />
|name=/etc/rc.conf<br />
|content=<nowiki><br />
WIRELESS_INTERFACE="wlan0"<br />
<br />
...<br />
<br />
DAEMONS=(... net-auto-wireless ...)<br />
</nowiki>}}<br />
<br />
Additionally, the {{Package Official|wpa_actiond}} package is required.<br />
<br />
===net-auto-wired===<br />
'''{{Codeline|net-auto-wired}} allows users to automatically connect to wired networks.'''<br />
<br />
To enable this feature, users must add {{Codeline|net-auto-wired}} to the {{Codeline|DAEMONS}} array in [[rc.conf]] and specify the desired wired interface with the {{Codeline|WIRED_INTERFACE}} variable:<br />
<br />
{{File<br />
|name=/etc/rc.conf<br />
|content=<nowiki><br />
WIRED_INTERFACE="eth0"<br />
<br />
...<br />
<br />
DAEMONS=(... net-auto-wired ...)<br />
</nowiki>}}<br />
<br />
Additionally, the {{Package Official|ifplugd}} package is required.<br />
<br />
==Tips and tricks==<br />
<br />
===Passing arguments to iwconfig before connecting===<br />
Simply add the following to a profile:<br />
<br />
IWCONFIG="<arguments>"<br />
<br />
Where {{Codeline|<arguments>}} can be any valid {{Codeline|iwconfig}} argument. The script then runs {{Codeline|iwconfig $INTERFACE $IWCONFIG}}.<br />
<br />
For example, force the card to register to a specific access point given by MAC address:<br />
IWCONFIG="ap 12:34:56:78:90:12"<br />
<br />
This supersedes the {{Codeline|IWOPTS}} and {{Codeline|WEP_OPTS}} options which were incompletely implemented.<br />
<br />
===rfkill (enable/disable radio power)===<br />
netcfg can enable/disable radio for wireless cards equipped with software control of radio. For wireless cards with hardware switches, netcfg can detect disabled hardware switches and fail accordingly.<br />
<br />
To enable rfkill support, you need to specify what sort of switch the wireless interface has; hardware or software. This can be set within a profile or at the interface level ({{Filename|/etc/network.d/interfaces/$INTERFACE}}; see [[#Per-interface configuration]]). <br />
<br />
RFKILL=soft # can be either 'hard' or 'soft'<br />
<br />
For some kill switches the rfkill entry in {{Filename|/sys}} is not linked to the interface and the {{Codeline|RFKILL_NAME}} variable needs to be set to the contents of the matching {{Filename|/sys/class/rfkill/rfkill#/name}}.<br />
<br />
For example, on an Eee PC:<br />
<br />
RFKILL=soft<br />
RFKILL_NAME='eeepc-wlan'<br />
<br />
===Execute commands before/after interface up/down===<br />
If your interface requires special actions prior/after the establishment/closure of a connection, you may use the {{Codeline|PRE_UP}}, {{Codeline|POST_UP}}, {{Codeline|PRE_DOWN}}, and {{Codeline|POST_DOWN}} variables.<br />
<br />
For example, if you want to configure your wireless card to operate in ad-hoc mode but you can only change modes when the interface is down, you could use something like this:<br />
<br />
PRE_UP="ifconfig wlan0 down; iwconfig wlan0 mode ad-hoc"<br />
<br />
Or if you want to mount your network shares after a successful connection, you could use:<br />
<br />
POST_UP="sleep 5; mount /mnt/shares/nexus/utorrent 2>/dev/null"<br />
<br />
{{Note|If the commands specified in these properties return anything other than 0 (success), netcfg aborts the current operation. So if you want to mount a certain network share that might not be available at the time of connection (thus returning an error), you could create a separate Bash script with the mount commands and a {{Codeline|exit 0}} at the end. Alternatively you can add {{Codeline|<nowiki>|| true</nowiki>}} to the end of the command that may fail.}}<br />
<br />
===Per-interface configuration===<br />
Configuration options that apply to all profiles using an interface can be set using {{Filename|/etc/network.d/interfaces/$INTERFACE}}. For example:<br />
<br />
/etc/network.d/interfaces/wlan0<br />
<br />
This is useful for {{Codeline|wpa_supplicant}} options, rfkill switch support, pre/post up/down scripts and {{Codeline|net-auto-wireless}}. These options are loaded ''before'' profiles so that any profile-based options will take priority.<br />
<br />
{{Filename|/etc/network.d/interfaces/$INTERFACE}} may contain any valid profile option, though you are likely to use {{Codeline|PRE_UP}}/{{Codeline|DOWN}} and {{Codeline|POST_UP}}/{{Codeline|DOWN}} (described in the previous section) or one of the options listed below. Remember that these options are set for ''all'' profiles using the interface; you probably do not want to connect to your work VPN here, for instance, as it will try to connect on ''every'' wireless network!<br />
<br />
WPA_GROUP - Setting the group of the wpa_ctrl interface<br />
WPA_COUNTRY - Enforces local regulatory limitations and allows use of more channels<br />
WPA_DRIVER - Defaults to wext, may want nl80211 for mac80211 devices<br />
<br />
{{Note|{{Codeline|POST_UP}}/{{Codeline|POST_DOWN}} require the {{Package Official|wpa_actiond}} package.}}<br />
<br />
===Output hooks===<br />
netcfg has limited support to load hooks that handle output. By default it loads the {{Filename|arch}} hook which provides the familiar output that you see. A syslog logging hook is also included. These can be found at {{Filename|/usr/lib/network/hooks}}.<br />
<br />
===ArchAssitant (GUI)===<br />
<br />
A Qt-based netcfg front-end called ArchAssistant exists. It proposes to manage and connect/disconnect profiles from a systray icon. Automatic wireless detection is also available. This tool is particularly useful for laptop users.<br />
<br />
Links:<br />
<br />
* [http://aur.archlinux.org/packages.php?ID=15655 archassistant in the AUR] <br />
* [http://www.kde-apps.org/content/show.php/ArchAssistant?content=76760 archassistant on kde-apps.org] <br />
* archassistant package on archlinux.fr: [http://repo.archlinux.fr/i686/archassistant/ i686] and [http://repo.archlinux.fr/x86_64/archassistant/ x86_64]<br />
<br />
There is also a relatively new GUI for netcfg2 on qt-apps.org that does only network configuration. You can find it [http://www.qt-apps.org/content/show.php/netcfgGUI?content=99523 here].<br />
<br />
===wifi-select===<br />
<br />
There is a console tool for selecting wireless networks in "real-time" (in NetworkManager manner) called <tt>wifi-select</tt>. The tool is convenient for use in Internet cafés or other places you are visiting for the first (and maybe the last) time. With this tool, you do not need to create a profile for a new network, just type {{Codeline|sudo wifi-select wlan0}} and choose the network you need. <br />
<br />
The tool is currently packaged and available in [community] repository. To install:<br />
<br />
# pacman -S wifi-select<br />
<br />
<tt>wifi-select</tt> does the following:<br />
* parses <tt>iwlist scan</tt> results and presents list of networks along with its security settings (WPA/WEP/none) using <tt>dialog</tt><br />
* if user selects network with existing profile -- just use this profile to connect with <tt>netcfg</tt><br />
* if user selects a new network (for example, WiFi hotspot), <tt>wifi-select</tt> automatically generates new profile with corresponding <tt>$SECURITY</tt> and asks for the key (if needed). It uses DHCP as <tt>$IP</tt> by default<br />
* then, if connection succeeds, profile is saved for later usage<br />
* if connection fails, user is asked if he/she wants to keep generated profile for further usage (for example to change <tt>$IP</tt> to static or adjust some additional options)<br />
<br />
Links: <br />
<br />
* [http://bbs.archlinux.org/viewtopic.php?id=63973 Forum thread] related to development of <tt>wifi-select</tt><br />
* [http://aur.archlinux.org/packages.php?ID=23471 wifi-select in the AUR] <br />
* [http://hg.horna.org.ua/wifi-select/ wifi-select Mercurial repository]<br />
<br />
==Troubleshooting==<br />
<br />
===Debugging===<br />
To run netcfg with debugging output, set the {{Codeline|NETCFG_DEBUG}} environment variable to {{Codeline|"yes"}}, for example:<br />
<br />
# NETCFG_DEBUG="yes" netcfg <arguments><br />
<br />
===Network unavailable===<br />
This error is typically due to:<br />
* Out of range<br />
* Driver issue <br />
* Trying to connect to a hidden network<br />
<br />
If you know your network is hidden, set:<br />
SCAN=no <br />
<br />
===Wireless association failed===<br />
This error is typically due to:<br />
* Out of range/reception<br />
* Incorrect configuration<br />
* Invalid key<br />
* Driver problem<br />
<br />
If it is a range problem, increasing {{Codeline|TIMEOUT}} can help.<br />
<br />
===Unable to get IP address with DHCP===<br />
This error is typically due to:<br />
* Out of range/reception<br />
<br />
Try increasing {{Codeline|DHCP_TIMEOUT}}.<br />
<br />
===Not a valid connection, check spelling or look at examples===<br />
You must set {{Codeline|CONNECTION}} to one of the connection types listed in the {{Filename|/usr/lib/network/connections}} directory. Alternatively, use one of the provided configuration examples in {{Filename|/etc/network.d/examples}}.<br />
<br />
===Driver quirks===<br />
{{Note|You most likely do '''not''' need quirks; ensure your configuration is correct before considering them. Quirks are intended for a small range of drivers with unusual issues, many of them older versions. These are workarounds, not solutions.}}<br />
<br />
Some drivers behave oddly and need workarounds to connect. Quirks must be enabled manually. They are best determined by reading the forums, seeing what others have used, and, if that fails, trial and error. Quirks can be combined.<br />
<br />
; {{Codeline|prescan}}: Run {{Codeline|iwlist $INTERFACE scan}} before attempting to connect (broadcom)<br />
; {{Codeline|preessid}}: Run {{Codeline|iwconfig $INTERFACE essid $ESSID}} before attempting to connect (ipw3945 and Intel PRO/Wireless 4965AGN)<br />
; {{Codeline|wpaessid}}: Same as previous, run before starting {{Codeline|wpa_supplicant}}. Deprecated - use <pre>PRE_UP="iwconfig $INTERFACE essid $ESSID"</pre> instead. (ath9k)<br />
; {{Codeline|predown}}: Take interface down before association and then restore it after (madwifi)<br />
; {{Codeline|postsleep}}: Sleep one second before checking if the association was successful<br />
; {{Codeline|postscan}}: Run {{Codeline|iwlist scan}} after associating <br />
<br />
For example:<br />
QUIRKS=(prescan preessid)<br />
<br />
If you receive "Wireless network not found" or "Association failed" errors and have tried the above, try:<br />
SCAN=no<br />
<br />
===Ralink legacy drivers rt2500, rt2400 that use iwpriv===<br />
There is no plans to add WPA support to these drivers. rt2x00 is supported, however, and will replace these.<br />
<br />
If you must use them, create a shell script that runs the needed {{Codeline|iwpriv}} commands and put its path in {{Codeline|PRE_UP}}.<br />
<br />
===It still doesn't work, what do I do?===<br />
If this article did not help solve your problem, the next best place to ask for help is the forums or the mailing list. <br />
<br />
To be able to determine the problem, we need information. When you ask, provide the following output:<br />
* '''ALL OUTPUT FROM netcfg''' <br />
* '''ALL OUTPUT FROM netcfg''' <br />
* '''ALL OUTPUT FROM netcfg'''<br />
** This is absolutely crucial to be able determine what went wrong. The message might be short or non-existent, but it can mean a great deal. <br />
* '''{{Filename|/etc/network.d}} network profiles'''<br />
** This is also crucial as many problems are simple configuration issues. Feel free to censor your wireless key.<br />
* '''netcfg version'''<br />
* {{Codeline|lsmod}}<br />
* {{Codeline|iwconfig}}<br />
<br />
==FAQ==<br />
{{FAQ<br />
|question=Why doesn't netcfg do ''(some feature)''?<br />
|answer=netcfg doesn't need to; it connects to networks. netcfg is modular and re-usable; see {{Filename|/usr/lib/networks}} for reusable functions for custom scripts.}}<br />
<br />
{{FAQ<br />
|question=Why doesn't netcfg behave in ''this'' way?<br />
|answer=netcfg doesn't enforce any rules; it connects to networks. It doesn't impose any heuristics, like "disconnect from wireless if ethernet is connected". If you want behaviour like that, it should be simple to write a separate tool over netcfg. See the question above.}}<br />
<br />
{{FAQ<br />
|question=Do I still need ''(some thing)'' if I'm using netcfg?<br />
|answer=This question usually references {{Filename|/etc/hosts}} and the {{Codeline|HOSTNAME}} variable in {{Filename|/etc/rc.conf}}, which are both still required. You may remove {{Codeline|network}} from the {{Codeline|DAEMONS}} array if you've configured all your networks with netcfg, though.}}</div>
Idupree
https://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=99215
Enhance system stability
2010-03-07T00:29:07Z
<p>Idupree: /* Regularly Backup the Pacman Database */ improve link-to-redirect-to-section</p>
<hr />
<div>[[Category:HOWTOs (English)]][[Category:Package management (English)]]<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Display Manager|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Display Manager#inittab_method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Be careful with unofficial and less tested packages===<br />
<br />
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system.<br />
<br />
Use precaution when using packages from AUR. Most of the packages in AUR are supplied by user and thus might not have the same packaging standard as those in official repositories. Always check AUR package's PKGBUILD for any signs of mistake or malicious code before you build and install them.<br />
<br />
Be careful with AUR helpers such as [http://archlinux.fr/yaourt-en Yaourt] which highly simplify installation of AUR packages and could lead to user build and install package that have malformed PKGBUILD. Fortunately, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is not only highly recommended, but should be mandatory for every packages. <br />
<br />
Finally, it is extremely unwise to ever run any AUR helper utilities, such as yaourt, or the makepkg command as root user.<br />
<br />
Only use 3rd party repository if absolutely necessary or if you know what you're doing. Always use 3rd party repository from a trusted source.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, ensure that your system is up-to-date by doing pacman -Syu.<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, bzr, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is an alternative Arch kernel package based upon Linux kernel 2.6.27 and is available in the core repository. This particular kernel version enjoys long term support from upstream, including security fixes and some feature backports. Additionally, this package includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending upon which bootloader is used, to make this kernel available as a boot-time option.<br />
<br />
==Generic Best Practices==<br />
<br />
===Use the package manager to install software===<br />
The package manager (in Arch: [[pacman]]) does a much better job than you at keeping track of files. If you install things manually you ''will'', sooner or later forget what you did, where you installed to, install conflicting stuff, install to wrong locations etc. <br />
<br />
From a stability standpoint you should try to avoid unsupported package and custom software, but if you really need such things making a package is better than manually compiling and installing. <br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages using yaourt -Syu --aur.<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Arch being a rolling release distribution, it can be dangerous to refresh pacman databases without doing a full system upgrade immediately after. Avoid using ''pacman -Sy Package-Name'' to install a package, but always use ''pacman -S Package-Name'' instead. And upgrade your system regularly with ''pacman -Syu''.<br />
<br />
Avoid using the '''-f''' option with pacman, ESPECIALLY in commands such as ''pacman -Syuf'' involving more than one package. The --force option ignores file-conflict and can even cause file loss when files are relocated between different packages! In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desperate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Use the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script] to move all but the last previously installed package versions in the pacman cache archives, to the home directory.<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[Pacman_Tips#Restore_pacman.27s_local_database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /etc, /home, /srv, and /var Directories===<br />
<br />
Since /etc, /home, /srv and /var directories contain important system files and configs, it is advisable to keep backup of these folders on a regular interval. The following is a simple guide line on how to go about it.<br />
<br />
* '''/etc:''' Backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
<br />
* '''/home:''' At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
* '''/srv:''' Server installations should have the /srv directory regularly backed up. <br />
<br />
* '''/var:''' Additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.</div>
Idupree
https://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=99214
Enhance system stability
2010-03-07T00:18:00Z
<p>Idupree: /* Avoid Development Packages */ add the remaining well-known RCS to the list (bzr. e.g. gwibber-bzr, http://aur.archlinux.org/packages.php?ID=18820)</p>
<hr />
<div>[[Category:HOWTOs (English)]][[Category:Package management (English)]]<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Display Manager|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Display Manager#inittab_method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Be careful with unofficial and less tested packages===<br />
<br />
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system.<br />
<br />
Use precaution when using packages from AUR. Most of the packages in AUR are supplied by user and thus might not have the same packaging standard as those in official repositories. Always check AUR package's PKGBUILD for any signs of mistake or malicious code before you build and install them.<br />
<br />
Be careful with AUR helpers such as [http://archlinux.fr/yaourt-en Yaourt] which highly simplify installation of AUR packages and could lead to user build and install package that have malformed PKGBUILD. Fortunately, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is not only highly recommended, but should be mandatory for every packages. <br />
<br />
Finally, it is extremely unwise to ever run any AUR helper utilities, such as yaourt, or the makepkg command as root user.<br />
<br />
Only use 3rd party repository if absolutely necessary or if you know what you're doing. Always use 3rd party repository from a trusted source.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, ensure that your system is up-to-date by doing pacman -Syu.<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, bzr, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is an alternative Arch kernel package based upon Linux kernel 2.6.27 and is available in the core repository. This particular kernel version enjoys long term support from upstream, including security fixes and some feature backports. Additionally, this package includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending upon which bootloader is used, to make this kernel available as a boot-time option.<br />
<br />
==Generic Best Practices==<br />
<br />
===Use the package manager to install software===<br />
The package manager (in Arch: [[pacman]]) does a much better job than you at keeping track of files. If you install things manually you ''will'', sooner or later forget what you did, where you installed to, install conflicting stuff, install to wrong locations etc. <br />
<br />
From a stability standpoint you should try to avoid unsupported package and custom software, but if you really need such things making a package is better than manually compiling and installing. <br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages using yaourt -Syu --aur.<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Arch being a rolling release distribution, it can be dangerous to refresh pacman databases without doing a full system upgrade immediately after. Avoid using ''pacman -Sy Package-Name'' to install a package, but always use ''pacman -S Package-Name'' instead. And upgrade your system regularly with ''pacman -Syu''.<br />
<br />
Avoid using the '''-f''' option with pacman, ESPECIALLY in commands such as ''pacman -Syuf'' involving more than one package. The --force option ignores file-conflict and can even cause file loss when files are relocated between different packages! In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desperate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Use the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script] to move all but the last previously installed package versions in the pacman cache archives, to the home directory.<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /etc, /home, /srv, and /var Directories===<br />
<br />
Since /etc, /home, /srv and /var directories contain important system files and configs, it is advisable to keep backup of these folders on a regular interval. The following is a simple guide line on how to go about it.<br />
<br />
* '''/etc:''' Backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
<br />
* '''/home:''' At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
* '''/srv:''' Server installations should have the /srv directory regularly backed up. <br />
<br />
* '''/var:''' Additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.</div>
Idupree
https://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=99213
Enhance system stability
2010-03-07T00:15:34Z
<p>Idupree: /* Use Recommended Configurations */ fix cross-page section link</p>
<hr />
<div>[[Category:HOWTOs (English)]][[Category:Package management (English)]]<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Display Manager|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Display Manager#inittab_method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Be careful with unofficial and less tested packages===<br />
<br />
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system.<br />
<br />
Use precaution when using packages from AUR. Most of the packages in AUR are supplied by user and thus might not have the same packaging standard as those in official repositories. Always check AUR package's PKGBUILD for any signs of mistake or malicious code before you build and install them.<br />
<br />
Be careful with AUR helpers such as [http://archlinux.fr/yaourt-en Yaourt] which highly simplify installation of AUR packages and could lead to user build and install package that have malformed PKGBUILD. Fortunately, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is not only highly recommended, but should be mandatory for every packages. <br />
<br />
Finally, it is extremely unwise to ever run any AUR helper utilities, such as yaourt, or the makepkg command as root user.<br />
<br />
Only use 3rd party repository if absolutely necessary or if you know what you're doing. Always use 3rd party repository from a trusted source.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, ensure that your system is up-to-date by doing pacman -Syu.<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is an alternative Arch kernel package based upon Linux kernel 2.6.27 and is available in the core repository. This particular kernel version enjoys long term support from upstream, including security fixes and some feature backports. Additionally, this package includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending upon which bootloader is used, to make this kernel available as a boot-time option.<br />
<br />
==Generic Best Practices==<br />
<br />
===Use the package manager to install software===<br />
The package manager (in Arch: [[pacman]]) does a much better job than you at keeping track of files. If you install things manually you ''will'', sooner or later forget what you did, where you installed to, install conflicting stuff, install to wrong locations etc. <br />
<br />
From a stability standpoint you should try to avoid unsupported package and custom software, but if you really need such things making a package is better than manually compiling and installing. <br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages using yaourt -Syu --aur.<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Arch being a rolling release distribution, it can be dangerous to refresh pacman databases without doing a full system upgrade immediately after. Avoid using ''pacman -Sy Package-Name'' to install a package, but always use ''pacman -S Package-Name'' instead. And upgrade your system regularly with ''pacman -Syu''.<br />
<br />
Avoid using the '''-f''' option with pacman, ESPECIALLY in commands such as ''pacman -Syuf'' involving more than one package. The --force option ignores file-conflict and can even cause file loss when files are relocated between different packages! In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desperate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Use the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script] to move all but the last previously installed package versions in the pacman cache archives, to the home directory.<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /etc, /home, /srv, and /var Directories===<br />
<br />
Since /etc, /home, /srv and /var directories contain important system files and configs, it is advisable to keep backup of these folders on a regular interval. The following is a simple guide line on how to go about it.<br />
<br />
* '''/etc:''' Backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
<br />
* '''/home:''' At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
* '''/srv:''' Server installations should have the /srv directory regularly backed up. <br />
<br />
* '''/var:''' Additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.</div>
Idupree
https://wiki.archlinux.org/index.php?title=User_talk:Iphitus&diff=99212
User talk:Iphitus
2010-03-06T23:54:38Z
<p>Idupree: /* netcfg red warning box */ new section</p>
<hr />
<div>Hi. What about [[Additional Network Config Examples]] and [[Network Scripts]], do you want to merge those with [[Network Profiles]] or scrap them altogether?<br />
:--[[User:Byte|byte]] 13:38, 14 December 2008 (EST)<br />
<br />
==Supplementary netcfg documentation==<br />
I've been trying to update and improve the [[Network Profiles]] wiki article as of late, and think a complete dictionary of valid profile options would be beneficial. I notice such a dictionary exists in the netcfg Git repo (http://projects.archlinux.org/netcfg.git/tree/docs/ethernet and http://projects.archlinux.org/netcfg.git/tree/docs/wireless), but these files are not included with the package.<br />
<br />
# are they current?<br />
# do you mind if they are copied and included on this wiki?<br />
<br />
Cheers,<br />
<br />
-- [[User:Pointone|pointone]] 14:14, 3 March 2010 (EST)<br />
<br />
== netcfg red warning box ==<br />
<br />
I see you added on the netcfg page a warning box at the beginning, which confused me, in revision<br />
http://wiki.archlinux.org/index.php?title=Network_Profiles&diff=97290&oldid=97289<br />
<br />
Since I see nothing explanatory in the commit log, could you comment on my suggestion about it? at http://wiki.archlinux.org/index.php/Talk:Network_Profiles#confusing_warning_message<br />
<br />
Thanks!<br />
[[User:Idupree|Idupree]] 18:54, 6 March 2010 (EST)</div>
Idupree
https://wiki.archlinux.org/index.php?title=Talk:Netcfg&diff=99209
Talk:Netcfg
2010-03-06T23:34:35Z
<p>Idupree: /* Move to netcfg */</p>
<hr />
<div>== DHCLIENT ==<br />
<br />
DHCLIENT=no<br />
This will tell netcfg to use dhcpcd instead of dhclient<br />
<br />
I is correct? Without setting DHCLIENT, IP="dhcp" in my profile launches dhcpcd. [[User:Mykhal|Mykhal]] 17:28, 22 May 2009 (EDT)<br />
<br />
:This appears to refer to an older revision. See [http://projects.archlinux.org/netcfg.git/commit/?id=75b7abe2727a9ce7e72721a5c79f070d6126b6b3 this commit: "Restore dhcpcd as default dhcp client"]. I've removed the offending line from the article.<br />
<br />
:-- [[User:Pointone|pointone]] 14:51, 24 February 2010 (EST)<br />
<br />
== Move to [[netcfg]] ==<br />
<br />
Are there any objections to renaming this article "netcfg"? I think this would be much clearer. -- [[User:Pointone|pointone]] 12:19, 23 February 2010 (EST)<br />
<br />
+1 [[User:Daenyth|Daenyth]] 17:46, 25 February 2010 (EST)<br />
<br />
+1 [[User:Proofrific|Proofrific]] 22:17, 5 March 2010 (EST)<br />
<br />
+1 [[User:Idupree|Idupree]] 18:19, 6 March 2010 (EST)<br />
:If we do this, we should also move [[Network_Profiles_development]] to Netcfg_development; also check [[Network_Profiles_with_3G_card]]; also do we need to be concerned about the "Network Profiles (Some other language)" pages? [[User:Idupree|Idupree]] 18:34, 6 March 2010 (EST)<br />
<br />
== confusing warning message ==<br />
<br />
The page begins<br />
{{Box RED||'''This document refers to netcfg 2.5.x''' &ndash; please upgrade to the latest version of netcfg.}}<br />
which sounds to me like the page itself is outdated and needs to be updated to describe a netcfg 2.6 or so (which doesn't exist actually) -- especially because I remembered an announcement on archlinux.org saying there was a netcfg update (it was to 2.5.2).<br />
<br />
Is it needed? Can it be, say, green instead of "SOMETHING IS WRONG" red? What if it just said the fact, "This document refers to netcfg 2.5.x"? Or add "; using older versions is unsupported."<br />
<br />
[[User:Idupree|Idupree]] 18:24, 6 March 2010 (EST)</div>
Idupree
https://wiki.archlinux.org/index.php?title=Talk:Netcfg&diff=99208
Talk:Netcfg
2010-03-06T23:24:47Z
<p>Idupree: /* confusing warning message */ new section</p>
<hr />
<div>== DHCLIENT ==<br />
<br />
DHCLIENT=no<br />
This will tell netcfg to use dhcpcd instead of dhclient<br />
<br />
I is correct? Without setting DHCLIENT, IP="dhcp" in my profile launches dhcpcd. [[User:Mykhal|Mykhal]] 17:28, 22 May 2009 (EDT)<br />
<br />
:This appears to refer to an older revision. See [http://projects.archlinux.org/netcfg.git/commit/?id=75b7abe2727a9ce7e72721a5c79f070d6126b6b3 this commit: "Restore dhcpcd as default dhcp client"]. I've removed the offending line from the article.<br />
<br />
:-- [[User:Pointone|pointone]] 14:51, 24 February 2010 (EST)<br />
<br />
== Move to [[netcfg]] ==<br />
<br />
Are there any objections to renaming this article "netcfg"? I think this would be much clearer. -- [[User:Pointone|pointone]] 12:19, 23 February 2010 (EST)<br />
<br />
+1 [[User:Daenyth|Daenyth]] 17:46, 25 February 2010 (EST)<br />
<br />
+1 [[User:Proofrific|Proofrific]] 22:17, 5 March 2010 (EST)<br />
<br />
+1 [[User:Idupree|Idupree]] 18:19, 6 March 2010 (EST)<br />
<br />
== confusing warning message ==<br />
<br />
The page begins<br />
{{Box RED||'''This document refers to netcfg 2.5.x''' &ndash; please upgrade to the latest version of netcfg.}}<br />
which sounds to me like the page itself is outdated and needs to be updated to describe a netcfg 2.6 or so (which doesn't exist actually) -- especially because I remembered an announcement on archlinux.org saying there was a netcfg update (it was to 2.5.2).<br />
<br />
Is it needed? Can it be, say, green instead of "SOMETHING IS WRONG" red? What if it just said the fact, "This document refers to netcfg 2.5.x"? Or add "; using older versions is unsupported."<br />
<br />
[[User:Idupree|Idupree]] 18:24, 6 March 2010 (EST)</div>
Idupree
https://wiki.archlinux.org/index.php?title=Talk:Netcfg&diff=99207
Talk:Netcfg
2010-03-06T23:19:16Z
<p>Idupree: /* Move to netcfg */ yes let's.</p>
<hr />
<div>== DHCLIENT ==<br />
<br />
DHCLIENT=no<br />
This will tell netcfg to use dhcpcd instead of dhclient<br />
<br />
I is correct? Without setting DHCLIENT, IP="dhcp" in my profile launches dhcpcd. [[User:Mykhal|Mykhal]] 17:28, 22 May 2009 (EDT)<br />
<br />
:This appears to refer to an older revision. See [http://projects.archlinux.org/netcfg.git/commit/?id=75b7abe2727a9ce7e72721a5c79f070d6126b6b3 this commit: "Restore dhcpcd as default dhcp client"]. I've removed the offending line from the article.<br />
<br />
:-- [[User:Pointone|pointone]] 14:51, 24 February 2010 (EST)<br />
<br />
== Move to [[netcfg]] ==<br />
<br />
Are there any objections to renaming this article "netcfg"? I think this would be much clearer. -- [[User:Pointone|pointone]] 12:19, 23 February 2010 (EST)<br />
<br />
+1 [[User:Daenyth|Daenyth]] 17:46, 25 February 2010 (EST)<br />
<br />
+1 [[User:Proofrific|Proofrific]] 22:17, 5 March 2010 (EST)<br />
<br />
+1 [[User:Idupree|Idupree]] 18:19, 6 March 2010 (EST)</div>
Idupree
https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=98919
Dm-crypt
2010-03-04T03:55:57Z
<p>Idupree: /* Overwriting */ advocate for /dev/urandom -- I hope what I said is self-evident/convincing enough! See my comment on the talk page, also</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why Encryption? ==<br />
Encryption is useful for two (related) reasons. Firstly, it prevents anyone with physical access to your computer, and your hard drive in particular, from getting the data from it (unless they have your passphrase/key). Secondly, it allows you to wipe the data on your hard drive with far more confidence in the event of you selling or discarding your drive.<br />
<br />
Basically, it supplements the access control mechanisms of the operating system (like file permissions) by making it harder to bypass the operating system by inserting a boot CD, for example. Encrypting the root partition prevents anyone from using this method to insert viruses or trojans onto your computer.<br />
<br />
Note that we're not encrypting the boot partition - the bootloader needs to read that one!<br />
<br />
'''ATTENTION: Having encrypted partitions does not protect you from all possible attacks. The encryption is only as good as your key management, and there are other ways to break into computers while they are running. Read the CAVEATS section below!'''<br />
<br />
== Why LUKS for dm-crypt? ==<br />
There are either 3 or 4 rival disk encryption standards in Linux, depending on how you count them.<br />
<br />
The old cryptoloop is deprecated: it's old, insecure and unreliable.<br />
<br />
A much better version, loop-AES (http://loop-aes.sourceforge.net/), was created but, due to politics, never became favorable with the kernel developers. It's far more secure than either cryptoloop or straight device-mapper encryptions (and probably faster than any of the other 3 options), but is not user-friendly. It also requires non-standard kernel support, which ARCH's kernel26 doesn't have.<br />
<br />
The standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]) is another choice.<br />
<br />
[http://code.google.com/p/cryptsetup/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://code.google.com/p/cryptsetup/ LUKS home page] if you're interested), it stores all the needed setup information on the disk itself. All you need then is the password, which can be in a separate file if you like. The Linux implementation uses dm-crypt and it can have up to eight different passwords, which can be changed or revoked easily. It is also supported by mkinitcpio in ARCH linux, which is nice.<br />
<br />
== Caveats ==<br />
<br />
=== Security (encryption) ===<br />
Disk encryption is not the be-all and end-all of security. Why not? Well, for a start, it won't prevent people from hacking into a running computer (either over the network or at a console) if there is a security hole to exploited (and there invariably is). There are a dozen and one things you can (and should) do to secure your computer against this type of attack, but they are all outside the scope of this document.<br />
<br />
What's more, even in situations this type of encryption is useful for (physical access to storage media), it isn't worth a thing if someone has your key. In other words, if someone finds out or guesses your passphrase, or gets access to your external key file if you're using one, they can unlock the encryption on the hard drive in exactly the same way that you can.<br />
<br />
What does this mean for you? Well, if you use an external key file, keep the device it is on '''SAFE'''. Attach it to your keyring or whatever. If you use a passphrase, '''make it hard to guess'''. There are [http://www.google.co.uk/search?q=create+secure+password hundreds of documents] all over the internet telling you how to come up with a secure passphrase; we're not going to go over it here. Note, however, that we use the term "passphrase": '''it doesn't have to be a single word'''.<br />
<br />
== Getting started ==<br />
If you're not starting from an unused hard drive, '''BACK UP YOUR DATA!''' I cannot stress this enough. Ideally, you should be doing this regularly anyway, and it's particularly important with an encrypted hard drive. But beware: if you have unencrypted backups, is there any point in having an encrypted hard drive? Think about where you store your backups.<br />
<br />
'''Note:''' if you want to have encrypted swap, read the section below about Encrypted Swap and decide how you want to set it up ''before'' you start the rest of this HOWTO.<br />
<br />
Since Arch Linux 2009.08 the Arch installer provides a comfortable and easy way to configure dm_crypt (also in combination with [[LVM]]).<br />
Of course you can also do all the work manually.<br />
In either case it's recommended to overwrite the disk to wipe out former unencrypted content.<br />
<br />
== Preparation ==<br />
=== Overwriting ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite this data. Contrary to popular believe overwriting several times or using random data as source serves no purpose. Data won't be recoverable after being overwritten by zeros. [http://www.springerlink.com/content/408263ql11460147/]<br />
<br />
To overwrite your disk with zeros you can use<br />
# dd if=/dev/zero of=/dev/sda bs=1M<br />
<br />
If you want to check for bad blocks while writing you can use badblocks. <br />
The <tt>badblocks</tt> command will check your disk for bad blocks while writing random data. The pseudorandom algorithm used by this command is faster (although "less random") than <tt>/dev/urandom</tt>, so it can be useful for large disks. [[frandom]] is a fast random generator you might want to use for large disk.<br />
<br />
# badblocks -c 10240 -w -t random -s -v /dev/sda<br />
This will test blocks in groups of 10240 (i.e. 10MB) at a time, writing over them with random data and showing progress as it goes.<br />
<br />
However it should be noted that the pseudo random data generated by badblocks does not serve any other purpose than slowing down the wiping of your drive.<br />
<br />
It is advantageous to subsequently fill the disk from a cryptographically-secure random number generator such as /dev/urandom, so that attackers who get access to your disk (the only people that disk-encryption defends against) cannot tell which blocks of the disk have yet been filled with encrypted data. If they get this information, it both tells them directly something about how much you've used your disk, and also might make the encryption easier to crack, (learning which parts of the disk are used might potentially help them guess which filesystem is inside, and maybe even what size files you've got...). Yes, /dev/urandom takes hours to generate enough data to fill up a modern hard disk, but you only have to do it once.<br />
<br />
== Arch Linux Installer (>2009.08) ==<br />
Since Arch Linux 2009.08 the installer supports dm_crypt and LVM (and combination of both) out of the box.<br />
<br />
Just run the installer as usual, i.e. follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]].<br />
When you reach the "Prepare Hard Drive(s)" don't use "Auto-Prepare" but set up your partitions manually.<br />
Beware that you '''have to''' create a separate unencrypted <tt>/boot</tt> partition, or GRUB/LILO has no chance to load the operating system afterwards.<br />
The most important step towards an encrypted system is done in the "Manually Configure ..." step.<br />
<br />
=== Configuring filesystems and mountpoints ===<br />
At first select the device corresponding to your unencrypted <tt>/boot</tt> partition, choose e.g. ext2 as filesystem and select <tt>/boot</tt> as the mountpoint.<br />
For all other partitions you created and which you want to be encrypted select dm_crypt in the filesystem dialog.<br />
You should enter a label for the encrypted device, e.g. 'sda2crypt', or simply 'root'.<br />
<br />
Here is an example listing how it may look like:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt<br />
/dev/sda3 raw->dm_crypt;yes;no_mountpoint;no_opts;sda3crypt<br />
/dev/mapper/sda2crypt dm_crypt->ext3;yes;/;no_opts;no_label;no_params<br />
/dev/mapper/sda3crypt dm_crypt->ext3;yes;/home;no_opts;no_label;no_params<br />
<br />
'''Note''': you can also put a LVM inside the dm_crypt partition, or vice versa a dm_crypt partition inside a LVM volume. See [[#Encrypting a LVM setup|Encrypting a LVM setup]] for details.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
That's it with the dm_crypt specific part for so far. Select your desired packages and install the system.<br />
The installer should perform all steps necessary for configuring the boot and mount process of your new system.<br />
You can check the configuration afterwards and compare them to the one in the section about manual configuration.<br />
Especially the HOOKS section in <tt>mkinitcpio.conf</tt> is important for an encrypted root partition.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
<br />
== Manually configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Partitioning ===<br />
At first set up your partitions as you want. Make sure you have a separate partition for /boot. If you think about it, this is absolutely necessary. If your /boot partition is encrypted, then your bootloader would not be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following - indicative - partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
/dev/sda5 -> /tmp # especially useful if you don't want to encrypt the entire root (/) partition<br />
<br />
=== Loading kernel modules ===<br />
'''Note:''' this article will use XTS-AES as encryption algorithm because it was standardized as IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices and it is quite secure, however the XTS mode is still flagged as "experimental" in the Linux kernel, so if you want something less secure but more proven, you should go with the CBC-ESSIV mode. The XTS mode is supported by Linux 2.6.24 upwards (ISO of Arch 2008.06 upwards).<br />
<br />
'''Note:''' The XTS mode uses two keys of the same size, therefore available sizes (using XTS-AES) are 256 (128 * 2), 384 (192 * 2) and 512 (256 * 2).<br />
<br />
Load the dm-crypt and the optimized AES module:<br />
# modprobe dm-crypt<br />
# modprobe aes-i586<br />
<br />
'''Note:''' x86_64 users can also try the "aes-x86_64" optimized module instead of "aes-i586".<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda4 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda4 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,4,5<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda4 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda4</tt> or <tt>/dev/sda5</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
'''Note:''' With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.<br />
<br />
'''Note:''' You might also want to replace /var/tmp/ with a symbolic link to /tmp.<br />
<br />
'''Note:''' If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.<br />
<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
'''Note:''' Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). If it is a ''swap'' or ''any other partition'', all is taken care by ''rc.sysinit'' and ''/etc/crypttab'' file'''<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keyboard' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
'''Note''' if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
'''Note:''' eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.<br />
<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda4 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
'''Note:''' Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
'''Note:''' Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, unless it has a LUKS header, then it simply won't work. If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
<span style="color:red">''Warning: don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure''</span><br><br><br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device><br />
* as stated in discussion: the -h parameter to specify hash function is (in this case) ignored, also the default hash - ripemd - is not recommended (citation needed). use aes-xts-plain:whirlpool , or aes-xts-sha256 instead. <br />
* check result with # cryptsetup luksDump /dev/<device>(sda3)<br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (due to journaling filesystems etc this is also not 100% secure)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption together with LVM. We are not going to cover the process of setting up LVM here as there is already a guide for that ([[Installing_with_Software_RAID_or_LVM]]).<br />
<br />
The best method and easier method to follow for a laptop is to set up the LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda4 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "lvm2" hook in /etc/mkinitcpio.conf '''before''' the "encrypt" hook. And you will have to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
In <tt>/etc/mkinitcpio.conf</tt> add ''lvm2'' '''before''' ''encrypt'' in the HOOKS variable.<br />
<br />
That's it for the LVM&dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2 encrypt'' before ''filesystems.<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root</div>
Idupree
https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt&diff=98918
Talk:Dm-crypt
2010-03-04T03:45:25Z
<p>Idupree: /* on the bashing of /dev/urandom */ new section</p>
<hr />
<div>I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?<br />
<br />
Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit?<br />
<br />
[[User:WhiteMagic|WhiteMagic]] 12:56, 24 May 2007 (EDT)<br />
<br />
== Suspend to disk instructions are insecure ==<br />
<br />
They cause the swap encryption key to be picked up by mkinitcpio and stored on the unencrypted /boot partition, thus rendering the encryption useless. Better still, the suspend image contains the keys for any other encrypted partitions that were currently open too...<br />
<br />
Unless someone thinks otherwise, I'm going to remove the stuff about key files and replace it with a warning not to do that. I think the approach using a password should be secure, and it's somewhat workable (at least in my setup with uresume): we can place the 'openswap' and 'uresume' hooks ''before'' 'encrypt' and rely on the above-mentioned keys in the suspend image to magically have the root unlocked once the resume is complete. Downside is typing two passwords during a normal boot - it's a quick fix for the current instructions at any rate.<br />
<br />
There are a few other options, but probably the tidiest strategy would be to put root and swap (and anything else) on an encrypted LVM PV, then the 'encrypt' hook can unlock everything in one go. I guess that makes a mess if the VG contain other PVs which need decrypting too, but that's probably not an issue at least for laptop users. I've not tried this though.<br />
<br />
Of course, ideally there'd be support for multiple volumes (preferably with a single password prompt) in the 'encrypt' hook.<br />
<br />
--[[User:Jmawebb|Jmawebb]] 19:44, 27 February 2010 (EST)<br />
<br />
== Encrypted Swap ==<br />
<br />
http://bbs.archlinux.org/viewtopic.php?id=26097 - this is I think, better solution for encrypted swap.<br />
<br />
:Probably the SWAP keyword, which can be used in /etc/crypttab, should be mentioned. --[[User:Gothmog.todi|gothmog.todi]] 12:47, 24 July 2007 (EDT)<br />
::I've added a paragraph about the SWAP keyword some while ago. Does anybody see a reason to keep the information about setting up random swap encryption manually? I can't think about a use case where it should be preferred to the automatic one. -- [[User:Gothmog.todi|gothmog.todi]] 15:16, 5 February 2008 (EST)<br />
<br />
== Luks and suspend2 ==<br />
<br />
Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does:<br />
resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap<br />
I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation.<br />
<br />
== Setting up LUKS ==<br />
<br />
cryptsetup -c aes-lrw-benbi -h sha256 -y -s 384 luksFormat /dev/sda3<br />
<br />
I'm quite sure that the '-h' here is ignored by luksFormat. Somebody knows about this?<br />
<br />
-- [[User:Gothmog.todi|gothmog.todi]] 14:57, 31 January 2008 (EST)<br />
:I tested it and luksFormat does ignore it, so I removed it. -- [[User:Gothmog.todi|gothmog.todi]] 17:27, 3 February 2008 (EST)<br />
<br />
== Misc ==<br />
<br />
Look: http://wiki.archlinux.org/index.php/User_talk:Gothmog.todi#LUKS<br />
<br />
Summary: we could insert a short explanation so every user can chose between a "LRW mode" swap partition or a "CBC-ESSIV mode" swap partition. [[User:Ekerazha|ekerazha]] 07:11, 3 February 2008 (EST)<br />
: Improved the "note" (I hope) ;-) [[User:Ekerazha|ekerazha]] 12:28, 3 February 2008 (EST)<br />
:: Thank you, it's better now. I added a shot info about suspend2disk in connection with encrypted swap. -- [[User:Gothmog.todi|gothmog.todi]] 17:26, 3 February 2008 (EST)<br />
::: I've added other info because with "uswsusp" you can also encrypt the suspend image, so it should also encrypt the "kernel space" key we used for dm-crypt before storing it to the lrw ciphered volume. [[User:Ekerazha|ekerazha]] 09:30, 4 February 2008 (EST)<br />
<br />
==Merge proposal==<br />
<br />
As you can see, I tried to merge 4 articles that covered the same (or very similar) subject into this one. There was wrong/redundant informations between the various pages. -- [[User:Ekerazha|ekerazha]] 18:36, 3 February 2008 (EST)<br />
: There's still a very redundant page (this one: [[Disk encryption]]) but the user "[[User:Post|Post]]" believes to own it (see [[User_talk:Ekerazha]]) so I can't merge/redirect that page... and I have no desire to lose my time with him. -- [[User:Ekerazha|ekerazha]] 19:12, 3 February 2008 (EST)<br />
::Sure, your page contains more topics (USB stick and loopback), but the overall quality still sucks.<br />
<br />
::[[User:Post|Post]] 19:28, 3 February 2008 (EST)<br />
::: You still don't understand this ISN'T "my" page: many users contributed to this page. However, "YOUR" page, compared to this, is *very* superficial, just look at the notes with deeper explanations we have here. If you have improvements (but I doubt it, considering the low level of your arguments), you can contribute to this page instead of keeping a redundant page because you like to own a wiki page. -- [[User:Ekerazha|ekerazha]] 19:36, 3 February 2008 (EST)<br />
::::Owning a wiki page is 1337.<br />
<br />
::::[[User:Post|Post]] 19:55, 3 February 2008 (EST)<br />
<br />
Now really, could you both please try to behave a little bit more like grown-ups? A wiki is supposed to be a place of '''objective''' information and discussion, you know. I don't know if you are aware how this normally works, so I'm going to explain it: I added merge-tags on both pages (as it probably should have be done from the beginning). And now a discussion should be started whether or not the pages should be merged. -- [[User:Gothmog.todi|gothmog.todi]] 04:32, 4 February 2008 (EST)<br />
<br />
So, [[Disk_encryption]] does indeed seem rather redundant to me. [[User:Post|Post]], could you may try to explain why you think there is a need for it as an independent article? -- [[User:Gothmog.todi|gothmog.todi]] 04:37, 4 February 2008 (EST)<br />
<br />
The current situation is: 3 pages already merged here, 2 proposed merges ([[Disk_encryption]] and [[RAID_Encryption_LVM]]). This article doesn't talk about the LVM setup, [[RAID_Encryption_LVM]] mainly talks about the LVM setup (not only however), [[Disk_encryption]] (the page "property of [[User:Post|Post]]") talks about both LVM and non-LVM setups but in a very superficial way. These pages should be definitely merged together in order to avoid redundant informations. Gothmog.todi seems to agree to me about the redundancy of [[Disk_encryption]]. -- [[User:Ekerazha|ekerazha]] 07:23, 4 February 2008 (EST)<br />
:You should at first clean up this page before merging all other pages with it and making it the Ultimate Guide to Encryption. It contains some really weird/obsolete stuff, like loading modules (it is done automatically), generating a keyfile with head (lawl), setting up swap via /etc/rc.local, giving "-y" option to cryptsetup, etc. Of course, I could fix these things, but there is one thing I cannot fix - that someone who simply wants to set up encryption will need to read all this crap and waste his time (like I was back then when I was setting up encrypted partitions for the first time).<br />
<br />
:[[User:Post|Post]] 14:05, 4 February 2008 (EST)<br />
<br />
:: You say loading modules is done automatically... partially it could be true (I didn't write that paragraph), however on x86_64 what module is used? As I've written inside a "note", x86_64 can *also* use an optimized version of the AES module: you can't settle everything "automatically" and "your" page doesn't explain there are 2 different modules. And what's wrong with giving "-y" to cryptsetup? The page you have written is a strictly "step by step" guide for people who don't understand what is doing. Why do you use "cbc-essiv" instead of "lrw" for the swap partition? Who knows... of course, that page is shorter and "step by step" but because of this, it is really really superficial (and still redundant). This is why I think it should be definitely merged. -- [[User:Ekerazha|ekerazha]] 06:26, 5 February 2008 (EST)<br />
<br />
::I don't think that the additional information given in this article is crap. (But it does need some love) I rather see it as important for someone using encryption to fully understand what he is doing. Sure, for someone who just needs a quick step-by-step it's burdensome to filter out the needed commands. Maybe some kind of "short version" of the setup would help here? (I remember that something like this was in an early version of [[Disk_encryption]]) What do you think of this? I would prefer it to an extra article, which would likely lead to inconsistency between it and this one. -- [[User:Gothmog.todi|gothmog.todi]] 14:43, 5 February 2008 (EST)<br />
<br />
About [[RAID_Encryption_LVM]]: I really don't see much reason to keep this separate. It's rather out-of-date and would need some serious revisions. And the difference compared to the normal cyrpto setup is not really big: it could easily be put in a subsection here, with a link to the article about LVM/raid setup ([[Installing_with_Software_RAID_or_LVM]]. This one is out-dated as well, but thats another topic) -- [[User:Gothmog.todi|gothmog.todi]] 15:08, 5 February 2008 (EST)<br />
: I agree. However I don't use LVM (I prefer UnionFS for my needs), so I don't have the "background" to merge that part. Could you do this? -- [[User:Ekerazha|ekerazha]] 15:45, 5 February 2008 (EST)<br />
::I merged it, but it still needs some cleanup. -- [[User:Gothmog.todi|gothmog.todi]] 08:13, 6 February 2008 (EST)<br />
I merged mine. ^^<br />
<br />
[[User:Post|Post]] 18:51, 5 February 2008 (EST)<br />
<br />
Well... now some cleanup is needed: maybe we could begin removing the "rc.local" way of setting up the swap partition (the other one is more elegant). [[User:Ekerazha|ekerazha]] 06:25, 6 February 2008 (EST)<br />
:Yeah, I already proposed that in another section of this page ;-) ([[Talk:System_Encryption_with_LUKS_for_dm-crypt#Encrypted_Swap|#Encrypted_Swap]]) Lets go for it. -- [[User:Gothmog.todi|gothmog.todi]] 07:11, 6 February 2008 (EST)<br />
::I removed the rc.local way, and adapted the automatic one, it may still need some work to fit in. -- [[User:Gothmog.todi|gothmog.todi]] 08:15, 6 February 2008 (EST)<br />
:"-y" option to cryptsetup (at least when using LUKS) is unnecessary, since LUKS asks to confirm the password by default. Two methods for generating a key are given (head/tail and dd). The former is just... weird. And why the key size given in the latter is 2K? No explanations given. And does someone use Arch64? It needs to be tested whether the aes_x86_64 module is loaded automatically. Well, and it's not supposed to be step-by-step, but sections 5-8 ARE step-by-step. This page really needs to get improved.<br />
:[[User:Post|Post]] 10:52, 6 February 2008 (EST)<br />
:: Inside "man cryptsetup" it's not documented that -y doesn't affect luks (it IS documented that it ACCEPTS -y, while it's documented that -h doesn't affect luksFormat), is there another guy that could confirm this (I'll try by myself asap). About the key generation, cleanup the unuseful stuff if you want... I didn't write that part so I can't say why it is that way. I use Arch64 and I didn't test what it loads by default, however reading the source code and some web pages, it seems like it uses the unoptimized "aes.ko" module (not "aes-i586.ko" and not "aes_x86_64.ko"), but I wait for confirmations. -- [[User:Ekerazha|ekerazha]] 12:30, 6 February 2008 (EST)<br />
<br />
And, if your root partition is on lvm, change USELVM in /etc/rc.conf to yes.<br />
:What THIS has to do with the root partition? The root partition needs to be already mounted in order to read /etc/rc.conf. Isn't this for scanning for other (non-root) volumes?<br />
<br />
:[[User:Post|Post]] 11:04, 6 February 2008 (EST)<br />
::Yes, you are right. Thank you, I changed it. -- [[User:Gothmog.todi|gothmog.todi]] 13:56, 6 February 2008 (EST)<br />
<br />
== New cipher mode ==<br />
Kernel 2.6.24 supports "aes-xts-plain" (instead of "cbc" or "lrw"). Waiting for kernel 2.6.24 to reach [core] (and new CD version), stay tuned :-) [[User:Ekerazha|ekerazha]] 09:00, 6 February 2008 (EST)<br />
:Sounds cool.<br />
<br />
:If you can't wait you can get a livecd that has a 2.6.24 kernel (such as the daily builds of ubuntu http://cdimage.ubuntu.com/daily-live/current/). It worked for me. [[User:inthemedium|inthemedium]] 10:14, 6 February 2008 (EST)<br />
:'''Question:''' xts-plain VS xts-benbi http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2585 [[User:Ekerazha|ekerazha]] 09:13, 13 April 2008 (EDT)<br />
:: -plain is the good one (specs: http://grouper.ieee.org/groups/1619/email/pdf00086.pdf ) [[User:Ekerazha|ekerazha]] 13:00, 16 April 2008 (EDT)<br />
<br />
== Badblocks insecure ==<br />
I wrote this down at the Gentoo wiki. Since I've been getting into Arch I thought I would share...<br /><br />
Here's an example<br /><br />
<br />
If you write to a device with the command...<br /><br />
''<nowiki>/sbin/badblocks -c 10240 -s -w -t random -v /dev/loop0</nowiki>''<br /><br />
... or somthing similar as recommended in many places.<br /><br />
<br />
Then...<br /><br />
''xxd /dev/loop0''<br /><br />
---SNIP---<br />
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
002e810: 1a18 a663 0b58 0e53 054f b72f 8058 d7a1 ...c.X.S.O./.X..<br />
002e820: a4f8 b5a5 c74e 0bf9 a11e 447b 6edd 5888 .....N....D{n.X.<br />
002e830: f5fe ec00 56fa 535c 490b 8bc9 6363 6b07 ....V.S\I...cck.<br />
002e840: 5b20 ac22 6eb7 1c0f d560 8a43 3de2 cc32 [ ."n....`.C=..2<br />
002e850: e0b8 3236 b286 92fc 911e c5f4 8130 fbdc ..26.........0..<br />
002e860: 50a7 ffbe 5f1b cd34 7b57 78b8 3944 ea19 P..._..4{Wx.9D..<br />
002e870: fc1c 50ae a2e2 aa33 0070 2781 a022 5ef1 ..P....3.p'.."^.<br />
002e880: ca5d af29 787d 5df3 d4d5 ab0e 1995 2715 .].)x}].......'.<br />
002e890: b177 c454 5a6e 875a deaf dc7f d13a 709b .w.TZn.Z.....:p.<br />
---SNIP---<br />
<br />
Then... looking for the data at 0x002e800...<br /><br />
''xxd /dev/loop0 | grep "214c 2113 01ce 9965 3253 134a da50 99dd"''<br /><br />
You'll get<br /><br />
---SNIP---<br />
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
0a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
142e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
1e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
282e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
322e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
3c2e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
462e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
502e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
5a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
642e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
6e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd !L!....e2S.J.P..<br />
---SNIP---<br />
Tell me if I'm wrong, but that kinda seems to defeat the purpose of randomizing the HDD<br />
<br />
== Proposed update of the section 'Storing the key between MBR and 1st partition' ==<br />
<br />
{| style="background-color: #f3f9ff; margin: 1em 2.5% 0 2.5%; padding: 3px 3px; border: 1px solid #aaa;"<br />
|-<br />
|'''Background'''<br />
<br />
I tried to setup automatic mount of my luks encrypted /home using a keyfile stored between MBR and first partition header of my USB key following this wiki page and realized that it didn't work out because the howto is incomplete. I had to manually go through the encrypt hook to figure out what it does. To save other users this tiresome work that cost me hours until all finally worked out the way I wanted it I propose to update the mentioned section in the following way. Suggestions welcome. Maybe it should be noted in the parent section that /etc/crypttab conflicts with using the howto presented here.<br />
|}<br />
<br />
Add the temporary keyfile we created before with cryptsetup:<br />
cryptsetup luksAddKey /dev/hda3 secretkey<br />
<br />
That should return you output like this:<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
Next you'll have to write the key directly between MBR and first partition.<br />
<br />
WARNING: you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey:<br />
shred --remove --zero secretkey<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048 cryptdevice=/dev/hda4:home<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be (if you use skip=16 in the 'dd' command above to protect the bootloader)<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048 cryptdevice=/dev/hda4:home<br />
Format for the cryptdevice option:<br />
cryptdevice=BLOCKDEVICE:MAPPING_TARGET<br />
The encrypted block device BLOCKDEVICE will then be mapped to /dev/mapper/MAPPING_TARGET<br />
<br />
'''Note:''' You will _not_ need to have ''/etc/crypttab'' setup for this device then (but maybe you want to use it for other encrypted devices where you want to enter the passphrase manually or e.g. use a keyfile stored on this afterwards decrypted partition)! But don't forget to activate the ''encrypt'' hook in ''/etc/mkinitcpio.conf'' (_before_ the ''filesystems'' hook)<br />
<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup of volume header ==<br />
<br />
I think that its important to backup headers of your volumes. This should be mentioned in the wiki imo.<br />
<br />
== LVM2 and LUKS ==<br />
<br />
I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device.<br />
<br />
And you have to add the "encrypt" hook ''before'' the "lvm2" hook, because you need to make the decrypted device available before LVM2 imports volume groupe and makes logical volumes available.<br />
<br />
Yet this chapter tends to tell the other way round. Is my English so bad ?<br />
<br />
I agree.. I find this entire wiki article unnecessarily complicated .. this link for an LVM on top of an encrypted partition is MUCH!!! easier to follow, and for a laptop would be better. [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
<br />
== Prepare hard drive ==<br />
The actual text is:<br />
<br />
Skip the Partitioning and Auto-Prepare business and go straight to "Set Filesystem Mountpoints". When asked for your / (root) partition, do NOT select /dev/sda3 as you normally would. Select /dev/mapper/root instead. Similarly, use /dev/mapper/home instead of /dev/sda4 as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition. Make sure you mount /dev/sda1 as the /boot partition or else the installer will not properly set up the bootloader. <br />
<br />
but the archlinux installer says:<br />
[code]<br />
/dev/sda1<br />
/dev/sda2<br />
/dev/mapper/root<br />
/dev/mapper/lvm-home<br />
/dev/mapper/lvm-root<br />
/dev/mapper/lvm-swap<br />
/dev/mapper/lvm-tmp<br />
[/code]<br />
When asked for / (root) partition: is it /dev/mapper/root or /dev/mapper/lvm-root. I suppose it is the first one because the second one does not match.<br />
<br />
== on the bashing of /dev/urandom ==<br />
<br />
I don't take an opinion on whether old overwritten data can be read.<br />
<br />
However, there is an unrelated reason to fill a LUKS partition from /dev/urandom before LUKS-initializing it (and after checking for bad blocks if you wanted to do that).<br />
<br />
It makes it harder for people trying to read your disk and find out what's on it. If you filled it with zeroes, for example, then they would be able to tell which portions of the partition had been written to since you initialized it.<br />
<br />
compate gentoo docs, http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Filling_the_disk_with_random_data<br />
<br />
[[User:Idupree|Idupree]] 22:45, 3 March 2010 (EST)</div>
Idupree
https://wiki.archlinux.org/index.php?title=Mac&diff=98708
Mac
2010-03-02T21:12:01Z
<p>Idupree: /* iSight */ isight-firmware-tools : not just for extracting. (So that is why my existing isight.fw didn't work yet! So help others realize too. My technical detail could be edited away if you want to</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
Installing Arch Linux on a MacBook is quite similar to installing it on any other computer. However, due to the specific hardware configuration on a MacBook, there are a few deviations and special considerations which warrant a separate guide. For more background information, please see the [[Official Arch Linux Install Guide]], [[Beginners Guide]], [[Beginners Guide Appendix]], and [[Post Installation Tips]]. This guide should also work for the MacBook Pros 5 series, and apply to both the 32 and 64 bits versions. If you have a Macbook5,2 (Polycarbonate, Non-Unibody) and are having additional issues, please see [[Macbook5,2]] for additional help.<br />
{{Article summary start}}<br />
{{Article summary text|Details the installation and configuration of Arch Linux on Apple's MacBook and MacBook Pro lines of notebooks.}}<br />
{{Article summary heading|Languages}}<br />
{{i18n_entry|English|:MacBook (English)}}<br />
{{i18n_entry|Italiano|:MacBook (Italiano)}}<br />
{{Article summary heading| Related articles}}<br />
{{Article summary wiki|Official Arch Linux Install Guide}}<br />
{{Article summary wiki|Beginners Guide}}<br />
{{Article summary wiki|Beginners Guide Appendix}}<br />
{{Article summary wiki|Post Installation Tips}}<br />
{{Article summary end}}<br />
== Overview ==<br />
<br />
Specifically, the procedure for installing Arch Linux on a MacBook is:<br />
<br />
# '''[[#Installation of Mac OS X and Firmware Update | Install Mac OS X]]''': Regardless of the desired end-configuration, it helps to start from a clean install of OS X.<br />
# '''[[#Installation of Mac OS X and Firmware Update | Firmware Update]]''': This should help reduce errors and provide newer features for the hardware.<br />
# '''[[#Partition | Partition]]''': This step either resizes or deletes the OS X partition and creates partitions for Arch Linux.<br />
# '''[[#Installation | Install Arch Linux]]''': The actual installation procedure.<br />
# '''[[#Post-Install Configuration | Post-Install Configuration]]''': MacBook specific configuration.<br />
<br />
{{ Tip | rEFIt is a popular bootloader for EFI-firmware computers (including Macs). It can be installed at any time during the installation. For instructions, please see [[MacBook#rEFIt|rEFIt]]. }}<br />
<br />
==Installation of Mac OS X and Firmware Update==<br />
<br />
[http://www.apple.com Apple] already has excellent instructions for installing Mac OS X. Follow their instructions. Finally, once OS X is installed, go to:<br />
<br />
Apple Menu --> Software Update<br />
<br />
And update all software. Once this has run, you will need to reboot your computer. Do this, and then run '''Software Update''' again to check to make sure that all updates have been installed.<br />
<br />
{{Note | Sometimes '''Software Update''' may not pick up all the firmware updates available for your computer. However, you can try to search this upgrades directly into the Apple's Support site.}}<br />
<br />
If you are not going to have Mac OS X installed, you need to make a backup of the file:<br />
/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS/AppleUSBVideoSupport<br />
<br />
You will need this file later for iSight functionality.<br />
<br />
==Partition==<br />
<br />
The next step in the installation is to re-partition the hard drive. If Mac OS X was installed using the typical procedure, then your drive should have a GPT format and the following two partitions:<br />
<br />
* '''EFI partition''': a 200 MB partition at the beginning of the disk.It is often read as '''msdos''' or '''FAT''' by some partitioning tools and usually labelled ''#1''<br />
* '''Mac OS X partition''': the ''(HFS+)'' partition that should take up all of the remaining disk space. Usually labelled ''#2''.<br />
<br />
How to partition depends on how many operating systems you want install. The following options will be proposed here:<br />
<br />
* [[#Arch Linux Only | Arch Linux Only]] for single boot.<br />
* [[#Mac OS X with Arch Linux | Mac OS X with Arch Linux]] for dual boot.<br />
<br />
If you don't know which option to pick, we recommend the dual boot so you can still return to Mac OS X whenever you want.<br />
<br />
===Arch Linux Only===<br />
<br />
This situation is the easiest to deal with. Mostly, partitioning is the same as any other hardware that Arch Linux can be installed on. The only special consideration is the MacBook firmware boot sound. To ensure that this sound is off: '''mute''' the volume in Mac OS X before continuing further. The MacBook firmware relies on the value in Mac OS X, if available. Note that if you choose to get rid of the OsX partition, there is no easy way to update your machine firmware.<br />
<br />
Then partition with '''parted'''. The simplest way is to change the partition table to '''msdos''' and then partition as normal. If you decide to use the GPT format, GRUB will not be able to recognize the partitioning scheme.<br />
<br />
{{Note | to partition with '''parted''', just boot the Arch Linux core install disk and run '''parted''' from the root account before using the install program.}}<br />
<br />
Once you have finished this part, please move on to [[#Installation | Installation]] section.<br />
<br />
===Mac OS X with Arch Linux===<br />
<br />
The easiest way to partition your hard drive, so that Mac OS X and Arch Linux will co-exist, is to use partitioning tools in Mac OS X and then finish with Arch Linux tools.<br />
<br />
{{Warning | It is highly recommended that this only be attempted after a clean install of Mac OS X. Using these methods on a pre-existing system may have undesired results.}}<br />
<br />
'''Procedure''':<br />
* In Mac OS X, run '''Disk Utility''' (located in /Applications/Utilities)<br />
<br />
* Select the drive to be partitioned in the left-hand column (not the partitions!). Click on the '''partition''' tab on the right.<br />
<br />
* Select the volume to be resized in the '''volume scheme.'''<br />
<br />
* Decide how much space you wish to have for your Mac OS X partition, and how much for Arch Linux. Remember that a typical installation of Mac OS X requires around 15-20 GiB, depending on the number of software applications and files.<br />
<br />
* Finally, type the new (smaller) size for the MacOS partition in the size box and click '''apply'''. This will create a new partition out of the empty space.<br />
<br />
{{Note | if you wish to have a shared partition between Mac OS X and Arch Linux, then additional steps will need to happen here. Please see [[#Shared Partition|Shared Partition]].}}<br />
<br />
* If the above completed successfully, then you can continue. If not, then you may need to fix your partitions from within Mac OS X first.<br />
<br />
* Boot the Arch install CD and run '''parted'''<br />
# parted<br />
<br />
* Delete the empty space partition and partition the space as you would for any other installation. Note that MBR is limited to 4 primary partitions (including the efi partition). That leaves 2 primary partitions for arch. One strategy is to have a system and home partition, and use a swap file (I haven't tried to use logical partitions). Another is to dedicate one partition to a shared partition (see below).<br />
<br />
* At this point, if you are dual booting, you should reboot your computer and have rEFIt fix the partition tables on your hard drive. (If you don't do this, you may have to reinstall GRUB later on in order to have your Mac recognize the Linux partition.) When you are into the rEFIt menu, select '''update partition table''', then press Y.<br />
# reboot<br />
<br />
* Done! Please continue to [[MacBook#Installation | installation]]<br />
<br />
===Mac OS X, Windows XP, & Arch Linux Triple boot===<br />
<br />
This may not work for everyone but it worked for me. I'm on a Macbook from late 2009.<br />
<br />
The easiest way to partition your hard drive, so that all these operating systems can co-exist, is to use disk utility in Mac OS X, use the formatter on windows XP install CP, and then finish with Arch Linux tools.<br />
<br />
{{Warning | It is highly recommended that this only be attempted after a clean install of Mac OS X. Using these methods on a pre-existing system may have undesired results. At least back your stuff up with timemachine or clonezilla before you begin.}}<br />
<br />
'''Procedure''':<br />
* In Mac OS X, run '''Disk Utility''' (located in /Applications/Utilities)<br />
<br />
* Select the drive to be partitioned in the left-hand column (not the partitions!). Click on the '''partition''' tab on the right.<br />
<br />
* Select the volume to be resized in the '''volume scheme.'''<br />
<br />
* Decide how much space you wish to have for your Mac OS X partition, how much fo XP, and how much for Arch Linux. Remember that a typical installation of Mac OS X requires around 15-20 GiB, and XP about the same, depending on the number of software applications and files. I went for something like OSX 200Gb, XP 25Gb, Arch 25Gb.<br />
<br />
* Put your decisions into action by pressing the + button and adding the new partitions, Label them as you like and make sure that your XP partition is the last one on the disk and is formatted for FAT32. It's probably best to have Arch formatted in HFS format as to not confuse you later, it will be reformatted anyway.<br />
<br />
So in linux terms your partitions will be something like:<br><br />
<br><br />
<br>sda (disk)<br />
<br>sda1 (Mac boot partition - you can't see this one in OSX)<br />
<br>sda2 (OSX install in HFS+)<br />
<br>sda3 (Arch install temporarly in HFS)<br />
<br>sda4 (XP install in FAT32)<br />
<br />
* Finally, click '''apply'''. This will create a new partition out of the empty space.<br />
<br />
{{Note | Using this method you may not be able to have a shared partition between Mac OS X and Arch Linux, this is because the mac will only allow for 4 active partitions. You will however be albe to mount a HFS partion in Arch for one workaround. There are other workarounds possible also.}}<br />
<br />
* If the above completed successfully, then you can continue. If not, then you may need to fix your partitions from within Mac OS X first.<br />
<br />
* You won't be needing boot camp this way, the program rEFIt is much more flexable (though not as flexabe as Grub). Download and install rEFIt [[http://refit.sourceforge.net/]]<br />
<br />
* Go into a terminal in OSX and perform the following, this will enable the rEFIt boot manager. <br />
<pre><br />
cd /efi/refit<br />
./enable.sh<br />
</pre><br />
<br />
* Reboot to check the rEFIt is working, it should appear on boot. When it comes up go to the rEFIt partiton manager and agree to the changes.<br />
<br />
* Put your XP install CD and boot it with rEFIt - You may have to reboot a few times till it's recognised by the boot loader. Install XP and once it's installed use the OSX install CD to get your drivers running nicely in XP.<br />
** Note: when installing XP make sure you select your XP partition and format it again inside the XP installer. If you don't reformat it won't work.<br />
<br />
* Boot the Arch install CD, log in as root and run /arch/setup<br />
<br />
* Follow the install as normal but note that you will have to tell that arch installer to mount sda3 as the root partiton and format it as ext3, there'll be no /boot and not swap partition so ignore those warnings.<br />
<br />
* At this point, if you are dual booting, you should reboot your computer and have rEFIt fix the partition tables on your hard drive. (If you don't do this, you may have to reinstall GRUB later on in order to have your Mac recognize the Linux partition.) When you are into the rEFIt menu, select '''update partition table''', then press Y.<br />
# reboot<br />
<br />
* Done! Please continue to [[MacBook#Installation | installation]]<br />
<br />
<br />
<br />
<br />
<br />
==Installation==<br />
{{ Note | This section is only required if you want to have Mac OS X installed along with Arch Linux. If not, follow the steps in the official install guide, then skip to [[MacBook#Post-Install Configuration | post install]].}}<br />
<br />
* Boot from the Arch Linux install CD. Type '''arch''' at the boot prompt or '''arch vga=773''' if you prefer a higher console resolution.<br />
<br />
boot: arch vga=773<br />
<br />
{{Note | some MacBook users report strange keyboard output such as long delays and character doubling. If this is your situation, boot with follows options.}}<br />
<br />
boot: arch noapic irqpoll acpi=force<br />
<br />
* Log in as '''root'''<br />
<br />
* Run the Arch installer:<br />
<br />
/arch/setup<br />
<br />
* Proceed through the installation as described in the [[Official Arch Linux Install Guide]] '''except''' in the following areas:<br />
** In the [[Official Arch Linux Install Guide#Prepare Hard Drive | prepare hard drive]] stage do only the [[Official Arch Linux Install Guide#Manually configure block devices, filesystems and mountpoints | set filesystem mountpoints]] step, taking care to assign the correct partitions.<br />
** In the [[Official Arch Linux Install Guide#Install Bootloader | install boot loader]] stage, edit the menu.lst file and add '''reboot=pci''' to the end of the '''kernel''' lines, for example: <pre style="margin: .5em 0; padding: .5em 1em">kernel /vmlinuz26 root=/dev/sda5 ro reboot=pci</pre> This will allow your MacBook to reboot correctly from Arch.<br />
** Also in the [[Official Arch Linux Install Guide#Install Bootloader | install boot loader]] stage, install GRUB on whatever partition that <tt>/boot</tt> is on. {{Warning | Do not install GRUB onto ''/dev/sda'' !!! Doing so is likely to lead to an unstable post-environment.}}<br />
** In the [[Official Arch Linux Install Guide#Configure System | configure system]] stage, edit /etc/mkinitcpio.conf and add the '''usbinput''' hook to the '''HOOKS''' line somewhere after the '''autodetect''' hook. This will load the drivers for your keyboard in case you need to use it before Arch boots (e.g. entering a [[LUKS]] password or using the troubleshooting shell).<br />
<br />
* When the install process is complete, reboot your computer.<br />
# reboot<br />
<br />
* Hold down the eject key as your MacBook starts, this should eject the Arch Linux install disk.<br />
<br />
==Post-Install Configuration==<br />
<br />
{{ Tip | MacBooks require some extra software from [[AUR]]. You may wish to install this software speedly; then you should install [[Yaourt]].}}<br />
<br />
{{ Tip | this software and its configuration require Root Privileges. To speed up this procedure i hint you to install [[Sudo]].}}<br />
<br />
{{ Tip | follow one section at time.}}<br />
<br />
=== Xorg ===<br />
<br />
Install and configure Xorg by following the [[Xorg]] article.<br />
<br />
==== Video ====<br />
<br />
Different MacBook's models have different graphic cards.<br />
<br />
To see which graphic card do you have type:<br />
<br />
# lspci | grep VGA<br />
<br />
If it returns a string with '''intel''' you need '''xf86-video-intel''' driver. You can install it typing<br />
<br />
# pacman -S xf86-video-intel<br />
<br />
If it returns '''nvidia'''<br />
<br />
# pacman -S nvidia<br />
<br />
Otherwise if it returns '''ATI'''<br />
<br />
# yaourt catalyst<br />
<br />
At least, '''intel''' users don't need any other work; instead others users need a basic '''xorg.conf''' file where you can specify the right driver to use.<br />
<br />
To configure it read those pages [[ATI]] or [[NVIDIA]].<br />
<br />
==== Touchpad ====<br />
<br />
The touchpad should have basic functionality by default.<br />
<br />
To configure advanced functions, see [[Touchpad Synaptics]] and [[Xorg input hotplugging]].<br />
<br />
==== Keyboard ====<br />
<br />
MacBook keyboard works by default. Only the '''eject''' key isn't recognized properly.<br />
<br />
To enable it you can map with right application like '''xbindkeys''' or through DE preferences; but another very good way, that we recommend, is to install '''pommed''' from [[AUR]].<br />
<br />
To install and configure '''pommed''' is easy:<br />
<br />
# yaourt pommed<br />
<br />
to install it, after<br />
<br />
Edit the '''/etc/pommed.conf''' according to your hardware on MacBook, building<br />
it from '''/etc/pommed.conf.mac''' or '''/etc/pommed.conf.ppc''' example files.<br />
<br />
Note that you can also run it without a configuration file, the defaults may work for you. Then<br />
<br />
Put '''pommed''' at the end in your '''DAEMONS''' array in your '''/etc/rc.conf'''<br />
<br />
finally reboot your pc.<br />
<br />
{{ Tip | if you are using Gnome or KDE you can easily configure ''3rd level functionality'', ''multimedia key'', etc. in Keyboard Preferences.}}<br />
<br />
{{ Note | see the [[Xorg input hotplugging]] page for other configuration information.}}<br />
<br />
=== Wifi ===<br />
<br />
Different MacBook models have different wireless cards.<br />
<br />
You can easily check what card do your MacBook have by:<br />
<br />
# lspci | grep Network<br />
<br />
* if you have an Atheros all should works-out-of-the-box.<br />
<br />
* instead if you have a Broadcom follow the [[Broadcom BCM4312]] page.<br />
<br />
* new macbooks may have a BCM453, if so then read the following <br />
[[http://www.broadcom.com/docs/linux_sta/README.txt]] and install the following [[http://www.broadcom.com/support/802.11/linux_sta.php]]<br />
<br />
<br />
=== Power management ===<br />
<br />
Suspend (the kernel suspend) should work out of the box (I had a problem in which the machine would "suspend immediately after resume" in certain conditions when suspending by closing the lid. This was solved by de-selecting the option "event_when_closed_battery" in gconf-editor &rarr; gnome-power-manager &rarr; actions).<br />
<br />
Hibernate should work if you have a swap partition. If you opted for a swap file because of the MBR limitation to 4 primary partitions, you can still get hibernate functionality by following these instructions (this is mostly taken from http://ubuntuforums.org/showthread.php?t=1042946):<br />
<br />
* Create a swapfile (here 2G = bs*count):<br />
sudo dd if=/dev/zero of=/swapfile bs=1024 count=2M<br />
It is recommended, but not necessary, to create the swapfile on a newly created partition, so that fragmentation is minimum.<br />
# chmod 600 swapfile <br />
# mkswap swapfile <br />
mkswap: swapfile: warning: don't erase bootbits sectors<br />
on whole disk. Use -f to force.<br />
Setting up swapspace version 1, size = 2097148 KiB<br />
no label, UUID=6bf46166-4f9e-433a-aac1-91cb3f5cf8ba<br />
# <br />
Note that we won't use this UUID later.<br />
* Add the swapfile in fstab:<br />
/swapfile none swap sw 0 0<br />
* Determine the UUID of partition on which the swapfile is (/sbin/blkid is provided by util-linux-ng)<br />
# blkid -g<br />
# blkid<br />
/dev/sda4: UUID="388014d3-1d18-4ca0-980e-ef2f9fdebde4" TYPE="ext3" <br />
388014d3-1d18-4ca0-980e-ef2f9fdebde4 is the number we're looking for.<br />
* Determine the physical offset of the swapfile:<br />
$ sudo filefrag -v /swapfile | head<br />
Filesystem type is: ef53<br />
Filesystem cylinder groups is approximately 132<br />
File size of /swapfile is 2147483648 (524288 blocks, blocksize 4096)<br />
ext logical physical expected length flags<br />
0 0 24576 12 merged<br />
1 12 24589 24587 1024 merged<br />
2 1036 25615 25612 1024 merged<br />
3 2060 26640 26638 1024 merged<br />
4 3084 27665 27663 1024 merged<br />
5 4108 28690 28688 1024 merged<br />
$ <br />
Here, 24576 is the number we want.<br />
* Edit /boot/grub/menu.lst and add:<br />
resume=/dev/disk/by-uuid/388014d3-1d18-4ca0-980e-ef2f9fdebde4 resume_offset=24576<br />
to your kernel stanza options (or use the kopt method as in the post). Note that the "resume=UUID=" actually didn't work for me. I had to use the /dev/disk/by-uuid syntax.<br />
* Nothing to do with update-grub nor mkinitcpio.<br />
* Reboot once<br />
* Try to hibernate<br />
<br />
=== Sound ===<br />
{{ Tip | MBP 5.5: since kernel 2.6.32 this works out of the box - just unmute the front speakers and store the sound level }}<br />
<br />
First of all follow [[ALSA]] wiki page, then if something doesn't work correctly, continue reading this part.<br />
<br />
Edit your '''/etc/modprobe.d/50-sound.conf''' or '''/etc/modprobe.d/modprobe.conf''' appending this line:<br />
<br />
options snd_hda_intel model=intel-mac-auto<br />
<br />
This should automatically specify the codec in your MacBook. Alternatively, for MacBookPro5,X, you can use:<br />
<br />
options snd_hda_intel model=mb5<br />
<br />
(note that the jack output is controlled with "HP").<br />
<br />
If you have an iMac8,1, you should instead use<br />
<br />
options snd-hda-intel model=mbp3 position_fix=2<br />
<br />
{{ Note | you can try to specify other options, agree with in your hardware. All other possible settings are listed in Kernel Documentation, avaible online:<br />
<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/ALSA-Configuration.txt ALSA-Configuration.txt]<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio.txt HD-Audio.txt]<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio-Models.txt HD-Audio-Models.txt].}}<br />
<br />
Then, reboot.<br />
<br />
=== Bluetooth ===<br />
<br />
See the article on [[Bluetooth]] to install and configure all software needed.<br />
<br />
Then if Bluetooth doesn't work out-of-the-box, you should edit your '''/etc/conf.d/bluetooth''' to enable '''hid2hci''' by uncommenting related line as follows:<br />
<br />
HID2HCI_ENABLE="true"<br />
<br />
Then restart your bluetooth daemon or simply reboot your pc.<br />
<br />
{{ Tip | for advanced bluetooth information see [[Bluetooth]] page.}}<br />
<br />
=== iSight ===<br />
<br />
{{ Note | linux kernel from 2.6.26 includes the '''Linux UVC driver''' natively. You will not need to download the driver sources manually unless you want to test a newer version or help with development. iSight should work out of the box for these kernel versions and up.}}<br />
<br />
iSight webcams require the Apple's proprietary firmware that can't be redistributed because proprietary. Then we must extract it from MacOS and load it Arch.<br />
<br />
Tools to extract firmware is available at [http://bersace03.free.fr/ift/ http://bersace03.free.fr/ift/] but we can found it on AUR [http://aur.archlinux.org/packages.php?ID=23525 isight-firmware-tools]. The AUR package also includes a udev rule and ELF binary that are necessary, even once you have extracted the firmware file into /lib/firmware/isight.fw, for the file to be loaded every time you boot your computer (namely /etc/udev/rules.d/isight.rules which uses /usr/lib/udev/ift-load).<br />
<br />
Instructions:<br />
<br />
First you need to get the firmware out of a particular file located on your OS X install. It is located in '''/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS/AppleUSBVideoSupport'''.<br />
<br />
To get it, mounts the MacOSX drive with:<br />
<br />
# sudo mkdir /media/MacOSX<br />
# sudo mount -t hfsplus /dev/sda2 /media/MacOSX<br />
<br />
Then install the firmware extractor and let it do the work for you<br />
<br />
# yaourt isight-firmware-tools<br />
<br />
and click OK to accept the default path (/media/MacOSX/System...).<br />
<br />
When it's done check that the firmware has been found:<br />
<br />
# ls /lib/firmware/isight.fw<br />
<br />
Once that is done, you need to completely SHUTDOWN your Mac and start it back up again (because this clears the hardware state of the camera).<br />
<br />
{{ Tip | to save very much time in the future, you just need to place the '''isight.fw''' file you saved in '''/lib/firmware/''' and then shutdown and reboot as instructed above.}}<br />
<br />
Finally you can load the '''uvcvideo''' module or add it at the end of MODULES() array into your '''/etc/rc.conf''' if you want it to load at boot.<br />
<br />
Everything should works.<br />
<br />
To test it there are many software:<br />
<br />
* MPlayer<br />
<br />
# mplayer tv:// -tv driver=v4l2:width=1280:height=1024:device=/dev/video0 -fps 20<br />
<br />
* Cheese<br />
* Skype<br />
* Ekiga<br />
<br />
A simple solution to take snapshots is:<br />
<br />
# mplayer tv:// -vf screenshot<br />
<br />
and the pressing the s key to take a snapshot. Files are of the format shot\d\d\d\d.png and are reported in the standard output.<br />
<br />
=== Temperature Sensors ===<br />
<br />
For reading temperature just install and configure '''lm_sensors'''.<br />
See [[Lm sensors]] page.<br />
<br />
=== Color Profile ===<br />
<br />
We can use color profiles from Mac OS.<br />
<br />
First install '''xcalib''' from AUR:<br />
<br />
# yaourt xcalib<br />
<br />
Second copy pre-saved color profiles placed in '''/Library/ColorSync/Profiles/Displays/''' on Mac OS partition to '''~/colorprofiles/''' for example.<br />
<br />
There are color profile files agree with in MacBook models; select the right one:<br />
<br />
* '''Color LCD-4271800.icc''' for MacBook Pro with CoreDuo CPU<br />
* '''Color LCD-4271880.icc''' for MacBook with Core2Duo<br />
* '''Color LCD-4271780.icc''' for MacBook (not Pro) based on CoreDuo or Core2Duo.<br />
<br />
{{ Tip | also Mac OS allows to save current color profile from '''Displays -> Color''' section of the '''Mac OS System Preferences''', in this case file is saved to '''/Users/<username>/Library/ColorSync/Profiles'''.}}<br />
<br />
Finally you can activate it by running<br />
<br />
# xcalib ~/colorprofile.icc<br />
<br />
{{ Warning | previous command set the color profile only for the current session; this mean that you must run it every time you login in your system. For automating it you can execute the command by '''Autostart Application''', concording with your DE.}}<br />
<br />
{{ Note | see '''xcalib''' man pages for further information.}}<br />
<br />
=== Apple Remote ===<br />
<br />
First, to correctly install and configure the '''lirc''' software that control IR see [[Lirc]] wiki.<br />
<br />
Then make LIRC use '''/dev/usb/hiddev0''' (or '''/dev/hiddev0''') by editing '''/etc/conf.d/lircd'''. Here is how mine look:<br />
<br />
#<br />
# Parameters for lirc daemon<br />
#<br />
LIRC_DEVICE="/dev/usb/hiddev0"<br />
LIRC_DRIVER="macmini"<br />
LIRC_EXTRAOPTS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
<br />
Use '''irrecord''' (available when installing lirc) to create a config file matching your remote control signals (alternatively, you can try to use the lircd.conf below):<br />
<br />
sudo irrecord -d /dev/usb/hiddev0 -H macmini output_conf_file<br />
<br />
Start '''lircd''' and use '''irw''' to check if it works.<br />
<br />
Example of an '''/etc/lirc/lircd.conf''':<br />
<br />
begin remote<br />
<br />
name lircd.conf.macbook<br />
bits 8<br />
eps 30<br />
aeps 100<br />
<br />
one 0 0<br />
zero 0 0<br />
pre_data_bits 24<br />
pre_data 0x87EEFD<br />
gap 211994<br />
toggle_bit_mask 0x87EEFD01<br />
<br />
begin codes<br />
Repeat 0x01<br />
Menu 0x03<br />
Play 0x05<br />
Prev 0x09<br />
Next 0x06<br />
Up 0x0A<br />
Down 0x0C<br />
end codes<br />
<br />
end remote<br />
<br />
===Hfs Partition Sharing===<br />
<br />
First, we have to list our partitions. Use<br />
<br />
fdisk -l /dev/sda<br />
<br />
example output:<br />
<br />
# fdisk -l /dev/sda<br />
Device Boot Start End Blocks Id Type<br />
/dev/sda1 1 26 204819 ee GPT<br />
/dev/sda2 26 13602 109051903+ af Unknown<br />
/dev/sda3 * 13602 14478 7031250 83 Linux<br />
/dev/sda4 14478 14594 932832+ 82 Linux swap / Solaris<br />
<br />
As we see, the "Unknown" partition is our OS X partition, which is located in <code>/dev/sda2</code>.<br />
<br />
Create a "mac" folder in /media:<br />
<br />
sudo mkdir /media/mac<br />
<br />
Add at the end of ''/etc/fstab'' this line:<br />
<br />
/dev/sda2 /media/mac hfsplus rw,exec,auto,users 0 0<br />
<br />
Mount it :<br />
<br />
mount /media/mac<br />
<br />
and check it:<br />
<br />
ls /media/mac<br />
<br />
===Home Sharing===<br />
<br />
'''''UID Synchronization'''''<br />
<br />
====In OS X====<br />
<br />
{{Note | it is strongly recommended that UID/GID manipulation be done immediately after a new user account is created, in OS X as well as in Arch Linux. If you installed OS X from scratch, then this operation is guaranteed to work after logging into your account for the first time.}}<br />
<br />
=====Step 1: Change UID and GID(s)=====<br />
<br />
'''''Pre-Leopard'''''<br />
<br />
# Open '''NetInfo Manager''' located in the ''/Applications/Utilities'' folder.<br />
<br />
# If not done for you already, enable access to user account transactions by clicking on the closed lock at the bottom of the window, and entering your account password, or root password if you have created a root account.<br />
<br />
# Navigate to ''/users/<new user name>'' where <new user name> is the name of the account that will have read/write access to the folder that will be shared with the primary user in Arch.<br />
<br />
# Change the '''UID''' value to 1000 (the value used by default for first user created in Arch).<br />
<br />
# Also change the '''GID''' value to 1000 (the value used by default for user account creation in Arch).<br />
<br />
# Navigate to ''/groups/<new user name>'', automatically saving the changes you have made so far.<br />
<br />
{{Note | if you get an error message that the transaction is not allowed, log out and log back in.}}<br />
<br />
'''''Leopard'''''<br />
<br />
In Leopard, the '''NetInfo Manager''' application is not present. A different set of steps is required for UID synchronization:<br />
<br />
# Open '''System Preferences'''.<br />
<br />
# Click on '''Accounts'''.<br />
<br />
# Unlock the pane if not already done so.<br />
<br />
# Right-click on the desired user and select '''Advanced Options'''.<br />
<br />
# Write down the value of the '''User ID''' field, you'll need it later on. Change both the UID and GID to match the UID and GID of the account wished to be shared with in Arch (1000 by default for the first user created in Arch).<br />
<br />
=====Step 2: Change "Home" Permissions=====<br />
<br />
# Open up '''Terminal''' in the ''/Applications/Utilities'' folder.<br />
<br />
# Enter the following command to reclaim the permission settings of your home folder, replacing <your user name>, <your user group> and <your old UID> with the user name whose UID and GID values you just changed, the group name whose GID value you just changed and the old UID number, respectively.<br />
<br />
find /User/<your user name> -user <your old UID> -exec chown <your user name>:<your user group><br />
<br />
====In Arch====<br />
<br />
To synchronize your UID in Arch Linux, you are advised to perform this operation ''while creating a new user account''.<br />
It is therefore recommended that you do this as soon as you install Arch Linux.<br />
<br />
Now you must substitute Arch's home with Mac OS's home, by modify entries of the famous ''/etc/fstab'' file.<br />
<br />
==rEFIt==<br />
<br />
Now install rEFIt if you have not done so already.<br />
<br />
{{Note | this is not a requirement. It only gives you a menu to choose between OS X and Arch Linux upon every boot.}}<br />
<br />
In OS X, download the ".dmg" from -> [http://refit.sourceforge.net/ Refit Homepage] and install it.<br />
<br />
{{Note | if you have already partitioned your hard disk in preparation for the Arch installation, rEFIt may not be enabled by default. You will have to run the "enable.sh" script installed in /efi/refit/.}}<br />
<br />
Open up '''Terminal''' and enter:<br />
<br />
cd /efi/refit; ./enable.sh<br />
<br />
== See also ==<br />
<br />
* http://www.netsoc.tcd.ie/~theorie/interblag/2010/01/30/installing-arch-linux-on-a-mac-pro/</div>
Idupree