https://wiki.archlinux.org/api.php?action=feedcontributions&user=Watermel0n&feedformat=atomArchWiki - User contributions [en]2024-03-28T21:45:28ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=VirtualBox&diff=126126VirtualBox2010-12-27T10:50:54Z<p>Watermel0n: fixed the article for the new Virtuabox 4.0</p>
<hr />
<div>[[Category:Emulators (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|VirtualBox}}<br />
<br />
[http://www.virtualbox.org VirtualBox] is a virtual pc emulator like vmware. It has many of the features vmware has, as well as some of its own. It is in constant development and new features are implemented all the time. eg. version 2.2 introduced OpenGL 3D acceleration support for Linux and Solaris guests. It has a nice GUI interface (Qt and/or SDL) or command line tools for managing virtual machines. Headless operation is also supported. Running iTunes under VirtualBox is the only way (currently) to sync iPod Touch/iPhone firmware 3.0+.<br />
<br />
==Editions==<br />
Virtualbox is available under the GPL, but there is an extension module released under the custom PUEL (Personal Use And Evaluation License) available.<br />
<br />
===VirtualBox (GPL)===<br />
This is the baseic Virtualbox, released under the GPL. It can be found in the community repository. It lacks some features such as USB 2.0 device support and the built-in RDP server. <br />
<br />
===VirtualBox Oracle VM VirtualBox Extension Pack (PUEL)===<br />
This extension pack is free for personal use. You can download it from the AUR ([http://aur.archlinux.org/packages.php?ID=44761 AUR: virtualbox-ext-oracle]). The PUEL extension offers the following advantages:<br />
<br />
*'''Remote Display Protocol (RDP) Server''' - a complete RDP server on top of the virtual hardware, allowing users to connect to a virtual machine remotely using any RDP compatible client<br />
<br />
*'''USB 2.0 support''' - this adds USB 2.0 support. The GPL version just supports USB 1.1<br />
<br />
*'''PXE boot for Intel cards'''<br />
<br />
==Installation==<br />
<br />
===Install VirtualBox===<br />
<br />
VirtualBox (OSE) is available from the community repository:<br />
# pacman -Syu virtualbox<br />
<br />
Once installed, a desktop entry can be located in ''Applications &rarr; System Tools &rarr; Oracle VM VirtualBox''<br />
<br />
Now, add the desired username to the '''vboxusers''' group:<br />
# gpasswd -a USERNAME vboxusers<br />
<br />
{{Note | You must logout/login in order for this change to take effect.}}<br />
<br />
To build '''vboxdrv''' module, run as root:<br />
# /etc/rc.d/vboxdrv setup<br />
<br />
Lastly, edit {{Filename|/etc/rc.conf}} as root and add '''vboxdrv''' to the MODULES array in order to load the VirtualBox drivers at startup. For example:<br />
MODULES=(loop '''vboxdrv''' fuse ...)<br />
<br />
To load the module manually, run the following in a terminal as root: <br />
# modprobe vboxdrv<br />
<br />
===Install Oracle VM VirtualBox Extension Pack (PUEL)===<br />
The Oracle VM VirtualBox Extension Pack is available from the [http://aur.archlinux.org/packages.php?ID=44761 AUR: virtualbox-ext-oracle].<br />
<br />
Use an AUR Helper or makepkg it yourself.<br />
<br />
====Install required QT libraries====<br />
Currently, VirtualBox relies on QT4 for its graphical interface. If you require a GUI, ensure you have QT4 installed:<br />
# pacman -S qt<br />
<br />
==Configuration==<br />
After having installed VirtualBox on your system and added yourself to the vboxusers group, you can start configuring your system in order to make all the features of VirtualBox available. Create a new virtual machine using the wizard provided by the GUI and then click settings in order to edit the virtual machine settings.<br />
<br />
===Keyboard and mouse between the host and the guest===<br />
*To capture the keyboard and mouse, click the mouse inside the Virtual Machine display.<br />
*To uncapture, press the right Ctrl key, alone.<br />
<br />
To get seamless mouse integration between host and guest, you need to install the Virtualbox additions into the guest.<br />
<br />
Also, mouse pointer integration does not work out of the box. To fix it, make sure you have the following sections in your guest's {{Filename|xorg.conf}}:<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "vboxmouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "X.org Configured"<br />
Screen 0 "Screen0" 0 0<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
<br />
When generating your {{Filename|xorg.conf}} with {{Codeline|"X -configure"}}, you will end up with an InputDevice section that uses the {{Codeline|mouse}} driver. After installing the Guest Additions, you should replace {{Codeline|mouse}} with {{Codeline|vboxmouse}} and then restart X or reboot your VM.<br />
<br />
===Getting network in the guest machine to work===<br />
First, get network working in the guest machine. Click the network tab. The not attached option means you will have "Network cable unplugged" or similar error in the guest computer.<br />
<br />
====Using NAT network====<br />
This is the simplest way to get network. Select NAT network and it should be ready to use. Then, the guest operating system can be automatically configured by using DHCP.<br />
<br />
The NAT IP address on the first card is 10.0.2.0, 10.0.3.0 on the second and so on.<br />
<br />
Also in VirtualBox 2.2.0+ NAT network DHCP clients will not configure your nameserver (DNS server for windows guests) you will have to manually configure the nameserver(DNS server)<br />
<br />
====Using host interface networking (the VirtualBox way)====<br />
Since VirtuaBox 2.1.0 it has a native support for host interface networking. Just add '''vboxnetflt''' to your MODULES section in {{Filename|[[rc.conf]]}} and choose ''Host Interface Networking'' (or ''Bridged adapter'' in [http://forums.virtualbox.org/viewtopic.php?f=1&t=16447 2.2]) in the virtual machine configuration.<br />
<br />
'''Note''': DHCP broadcasting does not seem to work properly under this way. Set up your guest networking with static IP assignment.<br />
<br />
====Using host interface networking (the Arch way)====<br />
You are going to just edit these files and reboot:<br />
<br />
* {{Filename|/etc/conf.d/bridges}}<br />
* {{Filename|/etc/rc.conf}}<br />
* {{Filename|/etc/vbox/interfaces}}<br />
<br />
Edit:<br />
'''{{Filename|/etc/conf.d/bridges}}'''<br />
bridge_br0="eth0 vbox0" # Put any interfaces you need.<br />
BRIDGE_INTERFACES=(br0)<br />
<br />
'''{{Filename|/etc/rc.conf}}'''<br />
<br />
First add the bridge module to your MODULES line<br />
MODULES=( <your other modules> '''bridge''')<br />
<br />
Then, in your NETWORKING section, make the following changes:<br />
eth0="eth0 up"<br />
br0="dhcp" # Maybe you have some static configuration; change to fit<br />
INTERFACES=(eth0 br0)<br />
<br />
'''Note''' by gpan:<br />
<br />
'''{{Filename|/etc/rc.conf}}'''<br />
<br />
First add the vboxdrv (and vboxnetflt in case of 2.1.0 version) module to your MODULES line:<br />
MODULES=( <your other modules> vboxdrv vboxnetflt )<br />
<br />
'''Note''' by vit:<br />
<br />
'''{{Filename|/etc/rc.conf}}'''<br />
<br />
In my case it did not work untill adding vboxnetadp to modules.<br />
<br />
Next, you should edit your {{Filename|/etc/udev/rules.d/60-vboxdrv.rules}} and type:<br />
KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="vboxusers", MODE="0660"<br />
<br />
Save it and exit.<br />
<br />
Then open terminal and type:<br />
# pacman -S bridge-utils uml_utilities<br />
<br />
Create a new bridge with this command:<br />
# brctl addbr br0<br />
<br />
'''{{Filename|/etc/vbox/interfaces}}'''<br />
<br />
(You can set up more interfaces if you want. Sky is the limit!):<br />
vbox0 your_user br0 # Be sure that your user is in the vboxusers group.<br />
<br />
Reboot.<br />
<br />
{{Note | Remember to set up your virtual machine with proper network configuration. (Attach a "Bridged Adapter" and choose "br0") }}<br />
{{Note | If you have any issue, make sure that you have the bridge-utils package installed and vboxnet daemon loaded.}}<br />
<br />
====Using host interface networking (generic)====<br />
This way is a bit harder, but it allows you to see the VirtualMachine as a "real" computer on your local network. You need to get bridge-utils <br />
<br />
# pacman -S bridge-utils uml_utilities<br />
<br />
'''Note''' by Sp1d3rmxn:<br />
:You also need to have the TUN module loaded... in {{Filename|[[rc.conf]]}} add {{Codeline|"tun"}} (without the quotes) to your MODULES section. For testing this out right now without rebooting you can load the module from the command line by {{Codeline|"modprobe tun"}}.<br />
:<br />
:Then you MUST set these permissions otherwise you will never get VBox to init the interface. The command is {{Codeline|"chmod 666 /dev/net/tun"}} (without the quotes).<br />
<br />
:Now proceed with the rest as it is written below.<br />
<br />
'''Note'''<br />
:As said by Sp1d3rmxn, set these permissions, but, instead of using the command, set them in {{Filename|/etc/udev/rules.d/60-vboxdrv.rules}}, which will apply them on boot:<br />
KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="vboxusers", MODE="0660"<br />
KERNEL=="tun", OWNER="root", GROUP="vboxusers", MODE="0660"<br />
<br />
<br />
'''1.''' Create a new bridge with this command:<br />
# brctl addbr br0<br />
<br />
'''2.''' If you are not using DHCP, run ifconfig and note down the network configuration of your existing network interface (e.g. eth0), which will need to be copied to the bridge.<br />
<br />
{{Note|You will need this settings so make sure you do not lose them.}}<br />
<br />
'''3.''' Switch your physical network adapter to "promiscuous" mode so that it will accept Ethernet frames for MAC addresses other than its own (replace {{Codeline|eth0}} with your network interface):<br />
# ifconfig eth0 0.0.0.0 promisc <br />
<br />
{{Note | You will lose network connectivity on eth0 at this point.}}<br />
<br />
'''4.''' Add your network adapter to the bridge:<br />
# brctl addif br0 eth0<br />
<br />
'''5.''' Transfer the network configuration previously used with your physical ethernet adapter to the new bridge. If you are using DHCP, this should work:<br />
# dhclient br0<br />
<br />
'''Note''' by Sp1d3rmxn:<br />
:Use {{Codeline|"dhcpcd -t 30 -h yourhostname br0 &"}} instead of the above<br />
<br />
Otherwise, run {{Codeline|"ifconfig br0 x.x.x.x netmask x.x.x.x"}} and use the values that you noted down previously.<br />
<br />
'''6.''' To create a permanent host interface called vbox0 (all host interfaces created in this way must be called vbox followed by a number) and add it to the network bridge created above, use the following command:<br />
VBoxAddIF vbox0 vboxuser br0<br />
<br />
Replace {{Codeline|vboxuser}} with the name of the user who is supposed to be able to use the new interface.<br />
<br />
{{Note | VboxAddIF is located in /opt/VirtualBox-VERSION OF VIRTUALBOX/VBoxAddIF}}<br />
<br />
Alternatively, you can [http://mychael.gotdns.com/blog/2007/05/31/virtualbox-bridging/ setup VirtualBox networking] through your {{Filename|/etc/rc.conf}} to enable a bridged connection.<br />
<br />
====Using host interface networking with a wireless device====<br />
Bridging as described above will not work with a wireless device. Using [http://aur.archlinux.org/packages.php?ID=16356 parprouted] however it can be accomplished.<br />
<br />
# Install parprouted and iproute<br />
# {{Codeline|# ln -s /usr/sbin/ip /sbin/ip}}<br />
# Make sure IP fowarding is enabled: {{Codeline|# sysctl net.ipv4.ip_forward&#61;1}}, and/or edit {{Filename|/etc/sysctl.conf}}.<br />
# {{Codeline|# VBoxTunctl -b -u <user>}}, to create the tap device<br />
# {{Codeline|# ip link set tap0 up; ip addr add 192.168.0.X/24 dev tap0}}, needs to be a manually set IP on the same network your wireless device is.<br />
# {{Codeline|# parprouted wlan0 tap0}}<br />
<br />
===Getting USB to work in the guest machine===<br />
(Only available in the PUEL edition)<br />
<br />
{{Note|As of VirtualBox>2.2.4 this is no longer necessary to mount a usb filesystem.}}<br />
<br />
First in order to make USB available for use to the virtual machine you must add this line to your {{Filename|/etc/fstab}}:<br />
none /proc/bus/usb usbfs auto,busgid=108,busmode=0775,devgid=108,devmode=0664 0 0<br />
<br />
Then tell mount to reread {{Filename|/etc/fstab}}:<br />
# mount -a<br />
<br />
{{Codeline|108}} is is the id of the group which should be allowed to access USB-devices. Change it to the id of your vboxusers group. You can get the id by running:<br />
$ grep vboxusers /etc/group<br />
<br />
Restart Virtualbox and click the USB tab in the settings of the virtual machine and select which devices are available to your pc on boot. If you wish your virtual machine to use device that you have just plugged in (assuming the virtual machine has booted already), go to the VirtualMachine screen go to ''Devices &rarr; USB Devices'' and select the device you wish to plug in the virtual PC.<br />
<br />
'''Note''' by bjimba:<br />
<br />
Recent versions of VirtualBox, as noted above, do not require usbfs, however you will need the HAL daemon running if you do not use usbfs. See the [[HAL]] wiki page for details.<br />
<br />
===Installing Guest Additions===<br />
The Guest Additions make the shared folders feature available, as well as better video (3D available in version 2.1+) and mouse drivers. You will have mouse integration, thus no need to release the mouse after using it in the guest and one can also enable a bidirectional clipboard.<br />
<br />
{{Note | The instructions immediately below are for an Archlinux guest on an Archlinux host.}}<br />
<br />
After you booted the virtual machine, go to menu ''Devices &rarr; Install Guest Additions...'' Once you have clicked it, VirtualBox loads an ISO into the current CD-ROM, so you will not see anything happen yet.<br />
<br />
You will require gcc and make if you do not already have them so install them typing the following as root:<br />
# pacman -S gcc make <br />
<br />
If you are running arch in VirtualBox install the kernel headers<br />
# pacman -S kernel26-headers<br />
<br />
Then do the following as root:<br />
# mount /media/cdrom<br />
On some systems it might be necessary to mount the cdrom like so:<br />
# mount /dev/cdrom /media/cd<br />
for i686 systems (32 bit):<br />
# sh /media/cdrom/VBoxLinuxAdditions-x86.run<br />
for x86-64 systems (64 bit):<br />
# sh /media/cdrom/VBoxLinuxAdditions-amd64.run<br />
<br />
It will build and install the kernel modules, install the Xorg drivers and create init scripts. It will most probably print out errors about init scripts and run levels and what not. Ignore them. You will find {{Filename|rc.vboxadd}} in /etc/rc.d which will load them on demand. To have the Guest Additions loaded at boot time, just add those to the DAEMONS array in {{Filename|/etc/rc.conf}} eg.:<br />
DAEMONS=(syslog-ng network netfs crond alsa '''rc.vboxadd''')<br />
<br />
Another option is to install one of these packages:<br />
# pacman -S virtualbox-additions<br />
or<br />
# pacman -S virtualbox-ose-additions<br />
<br />
You will then have an ISO to mount as a loop device. Remember to load the loop kernel module before:<br />
# modprobe loop<br />
# mount /usr/lib/virtualbox/additions/VBoxGuestAdditions.iso /media/cdrom -o loop<br />
<br />
Then execute {{Filename|VBoxLinuxAdditions.run}} as before. Before adding {{Filename|rc.vboxadd}} to DAEMONS check {{Filename|/etc/rc.local}} for commands to load the vboxadd daemons put by the installation script.<br />
<br />
'''Using full resolution of the host system in the guest'''<br />
<br />
Set the resolution of your guest in the grub boot script {{Filename|/boot/grub/menu.lst}}, i.e. add the correct vga code to the kernel command line.<br />
For a resolution of 1280x1024, this would e.g. look like<br />
# kernel /vmlinuz26 root=/dev/disk/by-uuid/7bdc5dee-8fb0-4260-bc43-60ac6e4e4a54 ro vga=795<br />
Add the resolution to {{Filename|/etc/X11/xorg.conf}}, e.g.<br />
<pre><br />
Section "Screen"<br />
...<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24<br />
Modes "1280x1024" "1024x768"<br />
EndSubSection<br />
...<br />
EndSection<br />
</pre><br />
<br />
'''Windows Guests'''<br />
<br />
After installing Windows (XP etc.) on your virtual machine, simply select ''Devices &rarr; Install Guest Additions...''<br />
<br />
This will mount the iso image and windows should then automatically launch the guest additions installer. Follow the instructions to the end.<br />
<br />
===Sharing folders between the host and the guest===<br />
In the settings of the virtual machine go to shared folders tab and add the folders you want to share.<br />
<br />
*NOTE: You need to install Guest Additions in order to use this feature.<br />
In a Linux host, ''Devices &rarr; Install Guest Additions''<br />
Yes (when asked to download the CD image)<br />
Mount (when asked to register and mount)<br />
<br />
In a Linux host, create one or more folders for sharing files, then set the shared folders via the virtualbox menu (guest window).<br />
<br />
In a Windows guest, starting with VirtualBox 1.5.0, shared folders are browseable and are therefore visible in Windows Explorer. Open Windows Explorer and look for it under ''My Networking Places &rarr; Entire Network &rarr; VirtualBox Shared Folders''.<br />
<br />
Launch the windows explorer (run explorer command) to browse the network places -> expand with the (+) sign : entire network &rarr; VirtualBox shared folders &rarr; '''\\Vboxsvr''' &rarr; then you can now expand all your configured shared folders here, and set up shortcuts for linux folders in the guest filesystem. You can alternatively use the "Add network place wizard", and browse to "VBoxsvr".<br />
<br />
Alternatively, on the Windows command line, you can also use the following:<br />
net use x: \\VBOXSVR\sharename<br />
<br />
While {{Codeline|VBOXSVR}} is a fixed name, replace {{Codeline|x:}} with the drive letter that you want to use for the share, and sharename with the share name specified with VBoxManage.<br />
<br />
In a Windows guest, to improve loading and saving files (e.g. MS Office) by VirtualBox Shared Folders edit ''c:\windows\system32\drivers\etc\hosts'' as below:<br />
127.0.0.1 localhost vboxsvr<br />
<br />
In a Linux guest, use the following command:<br />
# mount -t vboxsf [-o OPTIONS] sharename mountpoint<br />
(Notes: sharename is optional or same as selected in the VirtualBox-Dialog , mountpoint of the shared directory in the hosts filesystem)<br />
<br />
Replace {{Codeline|sharename}} with the share name specified with VBoxManage, and mountpoint with the path where you want the share to be mounted (e.g. /mnt/share). The usual mount rules apply, that is, create this directory first if it does not exist yet.<br />
<br />
Beyond the standard options supplied by the mount command, the following are available:<br />
iocharset=CHARSET<br />
to set the character set used for I/O operations (utf8 by default) and<br />
convertcp=CHARSET<br />
to specify the character set used for the shared folder name (utf8 by default).<br />
<br />
===Getting audio to work in the guest machine===<br />
<br />
In the machine settings, go to the audio tab and select the correct driver according to your sound system (ALSA, OSS or PulseAudio).<br />
<br />
===Setting up the RAM and Video Memory for the virtual PC===<br />
<br />
You can change the default values by going to ''Settings &rarr; General''.<br />
<br />
===Setting up CD-ROM for the Virtual PC===<br />
<br />
You can change the default values by going to ''Settings &rarr; CD/DVD-ROM''.<br />
<br />
Check mount CD/DVD drive and select one of the following options.<br />
<br />
'''Note:''' If no CD-ROM drive is detected, make sure the HAL daemon is running. To start it, run the following command as root:<br />
# /etc/rc.d/hal start<br />
<br />
<br />
===Enabling D3D acceleration in Windows guests===<br />
Recent versions of Virtualbox have support for accelerating OpenGL inside guests. This can be enabled with a simple checkbox in the machine's settings, right below where video ram is set, and installing the Virtualbox guest additions. However, most Windows games use Direct3D (part of DirectX), not OpenGL, and are thus not helped by this method. However, it is possible to gain accelerated Direct3D in your Windows guests by borrowing the d3d libraries from Wine, which translate d3d calls into OpenGL, which is then accelerated. <br />
<br />
After enabling OpenGL acceleration as described above, go to http://www.nongnu.org/wined3d/ in your Windows guest and grab the "Latest version (Installer):". Reboot the guest into safe mode (press F8 before the Windows screen appears but after the Virtualbox screen disappears), and install wined3d, accepting the defaults during the install. (You may check the box for DirectX 10 support if you like, dont touch anything else.) Reboot back to normal mode and you should have accelerated Direct3D. <br />
<br />
{{Note | This hack may or may not work for some games depending on what hardware checks they make and what parts of D3D they use.}}<br />
{{Note | This has only been tried on Windows XP and Windows 7 RC guests AFAIK, and does not work on the Windows 7 guest. If you have experience with this on a different windows version, please add that data here.}}<br />
<br />
==Start VirtualBox==<br />
To start Virtualbox, run the following command in a terminal:<br />
$ VirtualBox<br />
<br />
Or in KDE/GNOME menu, select: Applications --> System --> Virtual Machine (Oracle VM VirtualBox)<br />
<br />
==Virtualized OS Setup==<br />
Virtualbox needs to be setup to virtualize another operating system.<br />
<br />
===Test a LiveCD/DVD===<br />
Click the 'New' button to create a new virtual environment. Name it appropriately and select Operating System type and version. Select base memory size (note: most operating systems will need at least 512MB to function properly). Create a new hard disk image (a hard disk image is a file that will contain the operating system's filesystem and files).<br />
<br />
When the new image has been created, click 'Settings', then CD/DVD-ROM, check 'Mount CD/DVD Drive' then select an ISO image.<br />
<br />
==Maintenance==<br />
<br />
===Rebuild the vboxdrv Module===<br />
Note that any time your kernel version changes (due to an upgrade, recompile, etc.) you must also rebuild the VirtualBox kernel modules.<br />
<br />
Ensure that ''kernel26-headers'' is still installed, and run the following command:<br />
# /etc/rc.d/vboxdrv setup<br />
This will build the VirtualBox kernel modules for the ''currently running kernel''; if you have just upgraded your kernel package, reboot before trying to rebuild your kernel modules.<br />
<br />
After rebuilding the module, do not forget to load it with<br />
# modprobe vboxdrv<br />
<br />
''vboxdrv'' and ''vboxnetflt'' should be in the MODULES=() section of your /etc/rc.conf<br />
<br />
If you are using an old virtualbox_bin package built from AUR, run:<br />
# vbox_build_module<br />
<br />
If you need to rebuild the Virtual Box Additions in a guest installation of Arch Linux, use this command:<br />
# /etc/rc.d/rc.vboxadd setup<br />
<br />
===Compact a Disk Image===<br />
See [http://my.opera.com/locksley90/blog/2008/06/01/how-to-compact-a-virtualbox-virtual-disk-image-vdi How to compact a VirtualBox virtual disk image (VDI)]<br />
<br />
===Increase the size of a virtual hard drive for a Windows guest===<br />
WARNING: ONLY TESTED WITH XP GUEST!<br />
<br />
If you find that you are running out of space due to the small hard drive size you selected when created your VM, you can take the following steps:<br />
<br />
Create a new vdi in ~/.VirtualBox/HardDisks by running:<br />
# cd ~/.VirtualBox/HardDisks<br />
# VBoxManage createhd -filename new.vdi --size 10000 --remember<br />
<br />
where size is in mb, in this example 10000MB ~= 10GB, and new.vdi is name of new hard drive to be created.<br />
<br />
Next the old vdi needs to be cloned to the new vdi, this may take some time so wait while it occurs:<br />
# VBoxManage clonehd old.vdi new.vdi --existing<br />
<br />
Detach old harddrive and attach new hard drive, replace VMName with whatever you called your VM:<br />
# VBoxManage modifyvm VMName --hda none<br />
# VBoxManage modifyvm VMName --hda new.vdi<br />
<br />
Boot the VM, run Partition Wizard 5 to resize the partition on the fly, and reboot.<br />
<br />
Remove old vdi from VirtualBox and delete<br />
# VBoxManage closemedium disk old.vdi<br />
# rm old.vdi<br />
<br />
===Windows Xp and Nokia phones===<br />
To get working Windows XP and Nokia phones with Pc Suite mode, Virtualbox needs two simple steps:<br />
<br />
'''1.''' Add a rule to udev with {{Filename|/etc/udev/rules.d/40-permissions.rules}}:<br />
LABEL="usb_serial_start"<br />
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", \<br />
GROUP="usbfs", MODE="0660", GROUP="dialout"<br />
LABEL="usb_serial_end"<br />
<br />
'''2.''' Create the group usbfs and add its user to it<br />
$ sudo groupadd usbfs<br />
$ sudo usermod -a -G usbfs $USER<br />
<br />
After a logout, connect a Nokia phone with PC Suite mode and start Windows XP to test new rule.<br />
<br />
==Migrating From Another VM==<br />
The <code>qemu-img</code> program can be used to convert images from one format to another, or add compression or encryption to an image. <br />
# pacman -S qemu<br />
<br />
===Converting from QEMU images===<br />
To convert a QEMU image for use with VirtualBox, first convert it to ''raw'' format, then use VirtualBox's conversion utility to convert and compact it in its native format.<br />
$ qemu-img convert -O raw test.qcow2 test.raw<br />
$ VBoxManage modifyvdi /full/path/to/test.vdi compact<br />
or <br />
$ qemu-img convert -O raw test.qcow2 test.raw<br />
(of course you must have installed qemu package for that)<br />
$ VBoxManage convertfromraw /full/path/to/test.raw /full/path/to/test.vdi<br />
$ VBoxManage modifyvdi /full/path/to/test.vdi compact<br />
<br />
===Converting from VMware images ===<br />
Do <br />
$ VBoxManage clonehd source.vmdk target.vdi --format VDI<br />
<br />
This may not be needed anymore with recent virtualbox versions (to be confirmed)<br />
<br />
==Tips and Tricks==<br />
<br />
===Getting Web-cams and other USB devices to detect===<br />
Make sure you filter any devices that are not a keyboard or a mouse so they don't start up at boot and this insures that Windows will detect the device at start-up.<br />
<br />
===Sending a CTRL+ALT+F1 to the Guest===<br />
If your guest O/S is a Linux distro, and you want to open a new tty text shell or exit X via typing {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|F1}}, you can easily send this command to the guest O/S simply by hitting your 'Host Key' (usually the {{Keypress|Ctrl}} in the Right side of your keyboard) + {{Keypress|F1}} or {{Keypress|F2}}, etc.<br />
<br />
===Speeding up HDD Access for the Guest===<br />
Enabling the SATA(AHCI) controller within Virtualbox can speed up Host disk operations. This is available though Settings>Hard Disks in current versions of Virtual Box.<br />
<br />
===Starting VMs at System Boot on Headless Servers===<br />
Add this line to /etc/rc.local<br />
exec /bin/su PREFERRED_USER -l -c "/bin/bash --login -c \"VBoxHeadless -startvm {UUID}\" >/dev/null 2>&1" &<br />
Where PREFERRED_USER is the user profile that contains the VM definitions and .vdi files. This will start the VM with a RDP server running on port 3389.<br />
To determine the available VMs for a user:<br />
su PREFERRED_USER -c "VBoxManage list vms"<br />
To suspend the VM:<br />
su PREFERRED_USER -c "VBoxManage controlvm {UUID} savestate"<br />
<br />
===Accessing Server on VM from Host===<br />
To access apache on a VM from the Host machine ONLY, simply execute the following lines on the Host:<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/pcnet/0/LUN#0/Config/Apache/HostPort" 8888<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/pcnet/0/LUN#0/Config/Apache/GuestPort" 80<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/pcnet/0/LUN#0/Config/Apache/Protocol" TCP<br />
Where 8888 is the port the host should listen on and 80 is the port the VM will send Apache's signal on. <br />
To use a port lower than 1024 on the host machine changes need to be made to the firewall on the host machine. This can also be set up to work with SSH, etc.. by changing "Apache" to whatever service and using different ports. <br />
<br />
Note: "pcnet" refers to the network card of the VM. If you use an Intel card in your VM settings change "pcnet" to "e1000"<br />
<br />
*from [http://mydebian.blogdns.org/?p=111 ]<br />
<br />
It might also be necessary to allow connections from the outside to the server in your VM. E.g. if the guest OS is Arch, you may want to add the line <br />
httpd: ALL<br />
to your /etc/hosts.allow file.<br />
<br />
===Daemon Tools===<br />
While VirtualBox can mount ISO images without a problem, there are some image formats which cannot reliably be converted to ISO. For instance, ccd2iso ignores .ccd and .sub files, which can give disk images with broken files. cdemu, fuseiso, and MagicISO will do the same. In this case there is no choice but to use Daemon Tools inside VirtualBox.<br />
<br />
Recent Daemon Tools versions won't install, so use this old one: [http://www.disc-tools.com/download/daemon347+hashcalc]<br />
<br />
===Using VirtualBox on a USB key===<br />
When using VirtualBox on a USB key, for example to start an installed machine with an ISO image, you will manually have to create VDMKs from the existing drives. However, once the new VMDKs are saved and you move on to another machine, you may experience problems launching an appropriate machine again. To get rid of this issue, you can use the following script to launch VirtualBox. This script will clean up and unregister old VMDK files and it will create new, proper VMDKs for you:<br />
<pre><br />
#!/bin/bash<br />
<br />
# Erase old VMDK entries<br />
rm ~/.VirtualBox/*.vmdk<br />
<br />
# Clean up VBox-Registry<br />
sed -i '/sd/d' ~/.VirtualBox/VirtualBox.xml<br />
<br />
# Remove old harddisks from existing machines<br />
find ~/.VirtualBox/Machines -name \*.xml | while read file; do<br />
line=`grep -e "type\=\"HardDisk\"" -n $file | cut -d ':' -f 1`<br />
if [ -n "$line" ]; then<br />
sed -i ${line}d $file<br />
sed -i ${line}d $file<br />
sed -i ${line}d $file<br />
fi<br />
sed -i "/rg/d" $file<br />
done<br />
<br />
# Delete prev-files created by VirtualBox<br />
find ~/.VirtualBox/Machines -name \*-prev -exec rm '{}' \;<br />
<br />
# Recreate VMDKs<br />
ls -l /dev/disk/by-uuid | cut -d ' ' -f 9,11 | while read ln; do<br />
if [ -n "$ln" ]; then<br />
uuid=`echo "$ln" | cut -d ' ' -f 1`<br />
device=`echo "$ln" | cut -d ' ' -f 2 | cut -d '/' -f 3 | cut -b 1-3`<br />
<br />
# determine whether drive is mounted already<br />
checkstr1=`mount | grep $uuid`<br />
checkstr2=`mount | grep $device`<br />
checkstr3=`ls ~/.VirtualBox/*.vmdk | grep $device`<br />
if [[ -z "$checkstr1" && -z "$checkstr2" && -z "$checkstr3" ]]; then<br />
VBoxManage internalcommands createrawvmdk -filename ~/.VirtualBox/$device.vmdk -rawdisk /dev/$device -register<br />
fi<br />
fi<br />
done<br />
<br />
# Start VirtualBox<br />
VirtualBox<br />
</pre><br />
Note that your user has to be added to the "disk" group to create VMDKs out of existing drives.<br />
<br />
===phpVirtualBox===<br />
An open source, AJAX implementation of the VirtualBox user interface written in PHP. As a modern web interface, it allows you to access and control remote VirtualBox instances. Much of its verbage and some of its code is based on the (inactive) vboxweb project. It allows the used to remotely, graphically, administer their virtual machines without having to log in to their headless VirtualBox servers.<br />
<br />
This requires the PUEL edition for VirtualBox.<br />
<br />
An installation guide is available here:<br />
http://code.google.com/p/phpvirtualbox/wiki/Installation<br />
<br />
Arch Linux users should uncomment these 2 extensions in ''/etc/php/php.ini''<br />
extension=json.so<br />
extension=soap.so<br />
<br />
==Running Arch Linux as a guest==<br />
To install guest additions with support for Xorg follow these steps:<br />
{{Note|Guest additions from Virtualbox 3.2.8 do not support Xorg 1.9. Refer to [http://www.virtualbox.org/ticket/7306 Virtualbox ticket #7306] for an updated iso.}}<br />
<br />
{{Note| There is a new Version of guest additions available [http://www.virtualbox.org/download/testcase/VBoxGuestAdditions_3.2.9-66155.iso here].<br />
*Go to Virtualbox folder <br />
*Delete the vboxguestadditions.iso<br />
*Copy vboxguestadditions_3.2.9*.iso to your virtualbox folder and rename it to vboxguestadditions.iso<br />
*sudo mount /dev/cdrom /media/cd<br />
*sudo sh /media/cd/VBoxLinuxAdditions-amd64/i686.run <br />
Enjoy the guest additions.<br />
}}<br />
<br />
{{Note|Run the following steps as root}}<br />
* install entire xorg group: (is everything actually required?) <br />
* install dependencies needed to build the guest additions: <pre># pacman -S kernel26-headers gcc make</pre><br />
* mount and install VirtualBox guest additions<br />
{{Note|If X didn't work after you finished '''following steps''' , you may install virtualbox-ose-additions-modules from community repo instead of guest additions from it's ISO. <br />
<pre><br />
# pacman -S virtualbox-ose-additions<br />
# pacman -S virtualbox-ose-additions-modules<br />
# pacman -S xf86-input-evdev xf86-input-{mouse,keyboard}<br />
</pre><br />
then go ahead.<br />
}}<br />
* create <tt>/etc/X11/xorg.conf</tt> with the following contents:<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "vboxmouse"<br />
Option "Device" "/dev/vboxguest"<br />
Option "CorePointer" "yes"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "vboxvideo"<br />
EndSection<br />
* add <tt>hal</tt> to <tt>DAEMONS</tt> in <tt>rc.conf</tt> (not needed if you use X.org Server >= 1.8)<br />
{{Note|It is not required to add rc.vboxadd to DAEMONS because it is added to /etc/rc.local automatically}}<br />
{{Note|Run the following steps while logged into your user account}}<br />
* add <tt>/usr/bin/VBoxClient-all &</tt> to the top of <tt>~/.xinitrc</tt> (even if <tt>~/.xinitrc</tt> does not exist)<br />
<br />
{{Note|If you upgrade the kernel in the Virtual Machine you will need to re-install the Guest Additions in order for some features to work properly.}}<br />
<br />
If you need to rebuild the Virtual Box Additions in a guest installation of Arch Linux, use this command:<br />
# /etc/rc.d/rc.vboxadd setup<br />
<br />
===Copy and paste is not working in Arch guests!===<br />
You forgot to start VBoxclient-all. See above.<br />
<br />
===Enabling OpenGL acceleration in Arch Linux guests===<br />
Due to a bug in the VirtualBox guest addition setup scripts (as of VBox 3.1.2), simply ticking the "3D acceleration" checkbox in the virtual machine settings and installing the guest additions won't enable 3D acceleration for OpenGL applications under X for Arch Linux guests (and possibly others). In order to still get OpenGL acceleration, a bit of manual intervention is necessary after installing the guest additions. <br />
As root, run:<br />
ln -s /usr/lib/VBoxOGL.so /usr/lib/xorg/modules/dri/vboxvideo_dri.so<br />
ln -s /usr/lib/xorg/modules/dri /usr/lib/dri<br />
Also make sure the user starting X in the guest is in the '''video''' group.<br />
<br />
{{Note | Don't compare before-after performance using glxgears! You may get a lot less FPS due to now-working vsync support. Compare performance using a real, heavy 3D application (like a game).}}<br />
<br />
<br />
==External Links==<br />
* [http://www.virtualbox.org/manual/UserManual.html VirtualBox User Manual]</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=ASUS_Eee_PC_1005P&diff=112612ASUS Eee PC 1005P2010-07-24T22:53:26Z<p>Watermel0n: removed some myths</p>
<hr />
<div>[[Category:ASUS (English)]]<br />
{| style="float:right; border: 1px solid #000;" <br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|- <br />
| Video || style="color:green" | '''Working''' || i915<br />
|- <br />
| Ethernet || style="color:green" | '''Working''' || atl1c<br />
|-<br />
| Wireless || style="color:green" | '''Working''' || ath9k<br />
|-<br />
| Audio || style="color:green" | '''Working''' || snd_hda_intel<br />
|-<br />
| Camera || style="color:green" | '''Working''' || uvcvideo <br />
|-<br />
| Card Reader || style="color:yellow" | '''???''' || <br />
|-<br />
| Function Keys || style="color:yellow" | '''Some working''' || <br />
|}<br />
<br />
This article describes both the 1005P and the 1005PE, since the only difference of the 1005PE is wlan n and a bigger harddrive.<br />
<br />
=Installation=<br />
#[[Install_from_USB_stick|Installing from USB]]: according to the article on [[Putting_installation_media_on_a_USB_key|installing from USB]], the standard ISO images can be used for this (beginning with release 2010.05).<br />
#[[Install_Arch_from_network_(via_PXE)|Installing via PXE]] works well. It requires another computer to use as PXE host, and some configuration.<br />
<br />
=Kernel=<br />
Append acpi_osi=Linux to your /boot/grub/menu.lst to set the EeePC ACPI Interfaces to "Linux-Mode". Then the current kernel (as of writing 2.6.34) will autoload the eeepc_laptop module and everything works perfectly.<br />
<br />
=Xorg=<br />
==Video Driver==<br />
Install '''xf86-video-intel'''.<br />
<br />
==Device Autodetection==<br />
Everything works out of the box. xf86-input-evdev gets installed automatically with the xorg package. The current Xorg doesn't depend on HAL anymore, it uses dbus directly.<br />
<br />
==DPI setting==<br />
A good comfortable setting would be 96dpi or 75dpi if you like your fonts really small. An easy way to set your DPI would be to add this to the end of '''/etc/X11/xinit/xserverrc''':<br />
<br />
exec /usr/bin/X -nolisten tcp -dpi 96<br />
<br />
('''-nolisten''' is also a good idea for reducing unneeded system activity)<br />
<br />
==Graphic Performance==<br />
The default graphic performance is the best you can currently get. It is not needed to add "optimizations" like "AccelMethod" "exa" to your xorg.conf, because these will get ignored by the current version of the intel drivers anyway.<br />
The only thing you can add is XvMC Hardware decoding support, which allows your intel graphics adaptor to decode MPEG2 video material. To do this and set XvMC, here's a minimal xorg.conf:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "intel"<br />
Option "XvMC" "on"<br />
EndSection<br />
<br />
More is not needed in your xorg.conf, since Xorg uses input hotplugging.<br />
<br />
To let X know where the XvMC library is, run:<br />
<br />
# echo /usr/lib/libIntelXvMC.so > /etc/X11/XvMCConfig<br />
<br />
==Touchpad==<br />
<br />
Install '''xf86-input-synaptics'''. To enable Two Finger Scrolling and to disable Edge Scrolling, add this to your /etc/X11/xorg.conf.d/10-synaptics.conf inside the InputClass Section:<br />
<br />
Option "VertTwoFingerScroll" "true"<br />
Option "HorizTwoFingerScroll" "true"<br />
Option "EmulateTwoFingerMinZ" "10"<br />
Option "EmualteTwoFingerMinW" "7"<br />
Option "VertEdgeScroll" "false"<br />
Option "HorizEdgeScroll" "false"<br />
<br />
==xrandr==<br />
For a nice GUI tool, you can try '''lxrandr'''.<br />
<br />
Switch to external monitor (VGA port):<br />
xrandr --output LVDS1 --off --output VGA1 --auto<br />
<br />
Switch back to eeepc's LCD: <br />
xrandr --output LVDS1 --auto --output VGA1 --off<br />
<br />
=Powersaving and ACPI=<br />
Your best bet is to disable all hardware you don't intend to use (to access the BIOS settings, press F2 after rebooting).<br />
<br />
==laptop-mode-tools==<br />
Laptop mode is an easy way to setup most of the availiable power saving options, which include spinning down the hard drive and adjusting the power saving modes of the harddrive and CPU, as well as autosuspending the USB-ports, setting screen brightness, configuring the eee's own 'Super Hybrid Engine', etc.<br />
<br />
===Setup===<br />
# pacman -S laptop-mode-tools<br />
<br />
The main configuration file is '''/etc/laptop-mode/laptop-mode.conf''', plus there are several separate configuration files in '''/etc/laptop-mode/conf.d/''' for the various power saving modules managed by laptop-mode-tools. The files are well commented, so it should be easy to set everything up as needed. (For more information, see [[Laptop Mode Tools]])<br />
<br />
To make the daemon start at boot, add '''laptop-mode''' to the '''DAEMONS''' array in '''/etc/rc.conf'''.<br />
<br />
===LCD brightness===<br />
The relevant config file is '''/etc/laptop-mode/conf.d/lcd-brightness.conf'''. Brightness values are between 0 (darkest) and 15 (brightest). An example of usable settings:<br />
<br />
BATT_BRIGHTNESS_COMMAND="echo 1"<br />
LM_AC_BRIGHTNESS_COMMAND="echo 15"<br />
NOLM_AC_BRIGHTNESS_COMMAND="echo 15"<br />
BRIGHTNESS_OUTPUT="/sys/class/backlight/acpi_video0/brightness"<br />
<br />
===CPU frequency===<br />
The CPU frequency is controlled through the file '''/etc/laptop-mode/conf.d/cpufreq.conf'''. The available frequency options can be found out by running:<br />
<br />
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies<br />
<br />
This functionality requires the package '''cpufrequtils'''. The package also provides a daemon which can be used on its own, in which case '''/etc/conf.d/cpufreq''' should be edited to contain the desired options, and added to '''DAEMONS''' in '''/etc/rc.conf'''. If handling frequency scaling through '''laptop-mode-tools''', the cpufreq daemon should not be loaded, and its config file options can remain commented out, since the settings will come from '''/etc/laptop-mode/conf.d/cpufreq.conf'''.<br />
<br />
Either way, cpufreq requires the kernel module '''acpi-cpufreq'''. If you're not using laptop-mode-tools, you will also need some 'governors' ('''cpufreq_ondemand''' seems to be loaded by default, but there is also '''cpufreq_powersave'''). To load them at startup, add these modules to the '''MODULES''' array in '''/etc/rc.conf'''.<br />
<br />
===SHE===<br />
The eeepc's 'Super Hybrid Engine' has a significant effect on powersaving. This underclocks the FSB for powersave/overclocks for performance and can be controlled via the file '''/sys/devices/platform/eeepc/cpufv''' which is provided by the module '''eeepc_laptop'''.<br />
You can manage this with laptop-mode-tools. The relevant config file is '''/etc/laptop-mode/conf.d/eee-superhe.conf'''.<br />
<br />
===USB suspend===<br />
Config file: '''/etc/laptop-mode/conf.d/usb-autosuspend.conf'''<br />
Tip: make use of the option to disable the suspending of some USB hardware (eg. 3g modems) by using lsusb to get the ID and then insert it in the configuration file.<br />
<br />
==Hotkeys==<br />
Some work out of the box (see [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Hotkeys]] for more).<br />
<br />
=Hardware Info=<br />
'''lspci''' says:<br />
<br />
00:00.0 Host bridge: Intel Corporation Pineview DMI Bridge<br />
00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:02.1 Display controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)<br />
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)<br />
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)<br />
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)<br />
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)<br />
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)<br />
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)<br />
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)<br />
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)<br />
00:1f.0 ISA bridge: Intel Corporation Tigerpoint LPC Controller (rev 02)<br />
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 02)<br />
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)<br />
01:00.0 Ethernet controller: Atheros Communications Atheros AR8132 / L1c Gigabit Ethernet Adapter (rev c0)<br />
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=ASUS_Eee_PC_1005P&diff=112598ASUS Eee PC 1005P2010-07-24T14:49:46Z<p>Watermel0n: added synaptics conf</p>
<hr />
<div>[[Category:ASUS (English)]]<br />
{| style="float:right; border: 1px solid #000;" <br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|- <br />
| Video || style="color:green" | '''Working''' || i915<br />
|- <br />
| Ethernet || style="color:green" | '''Working''' || atl1c<br />
|-<br />
| Wireless || style="color:green" | '''Working''' || ath9k<br />
|-<br />
| Audio || style="color:green" | '''Working''' || snd_hda_intel<br />
|-<br />
| Camera || style="color:green" | '''Working''' || uvcvideo <br />
|-<br />
| Card Reader || style="color:yellow" | '''???''' || <br />
|-<br />
| Function Keys || style="color:yellow" | '''Some working''' || <br />
|}<br />
<br />
This article describes both the 1005P and the 1005PE, since the only difference of the 1005PE is wlan n and a bigger harddrive.<br />
<br />
=Installation=<br />
#[[Install_from_USB_stick|Installing from USB]]: according to the article on [[Putting_installation_media_on_a_USB_key|installing from USB]], the standard ISO images can be used for this (beginning with release 2010.05).<br />
#[[Install_Arch_from_network_(via_PXE)|Installing via PXE]] works well. It requires another computer to use as PXE host, and some configuration.<br />
<br />
=Kernel=<br />
Append acpi_osi=Linux to your /boot/grub/menu.lst to set the EeePC ACPI Interfaces to "Linux-Mode". Then the current kernel (as of writing 2.6.34) will autoload the eeepc_laptop module and everything works perfectly.<br />
<br />
=Xorg=<br />
==Video Driver==<br />
Install '''xf86-video-intel'''.<br />
<br />
==Device Autodetection==<br />
Everything works out of the box. xf86-input-evdev gets installed automatically with the xorg package. The current Xorg doesn't depend on HAL anymore, it uses dbus directly.<br />
<br />
==DPI setting==<br />
A good comfortable setting would be 96dpi or 75dpi if you like your fonts really small. An easy way to set your DPI would be to add this to the end of '''/etc/X11/xinit/xserverrc''':<br />
<br />
exec /usr/bin/X -nolisten tcp -dpi 96<br />
<br />
('''-nolisten''' is also a good idea for reducing unneeded system activity)<br />
<br />
==Graphic Performance==<br />
See [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Graphic_Performance]] and [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Display_settings]].<br />
The short story is that it might be useful to add the following to the '''Device''' section of /etc/X11/xorg.conf:<br />
<br />
Driver "intel"<br />
Option "AccelMethod" "exa" <br />
Option "MigrationHeuristic" "greedy"<br />
Option "FramebufferCompression" "on"<br />
Option "Tiling" "on"<br />
Option "XvMC" "on"<br />
<br />
To let X know where the XvMC library is, run:<br />
<br />
# echo /usr/lib/libIntelXvMC.so > /etc/X11/XvMCConfig<br />
<br />
==Touchpad==<br />
<br />
Install '''xf86-input-synaptics'''. To enable Two Finger Scrolling and to disable Edge Scrolling, add this to your /etc/X11/xorg.conf.d/10-synaptics.conf inside the InputClass Section:<br />
<br />
Option "VertTwoFingerScroll" "true"<br />
Option "HorizTwoFingerScroll" "true"<br />
Option "EmulateTwoFingerMinZ" "10"<br />
Option "EmualteTwoFingerMinW" "7"<br />
Option "VertEdgeScroll" "false"<br />
Option "HorizEdgeScroll" "false"<br />
<br />
==xrandr==<br />
For a nice GUI tool, you can try '''lxrandr'''.<br />
<br />
Switch to external monitor (VGA port):<br />
xrandr --output LVDS1 --off --output VGA1 --auto<br />
<br />
Switch back to eeepc's LCD: <br />
xrandr --output LVDS1 --auto --output VGA1 --off<br />
<br />
=Powersaving and ACPI=<br />
Your best bet is to disable all hardware you don't intend to use (to access the BIOS settings, press F2 after rebooting).<br />
<br />
==laptop-mode-tools==<br />
Laptop mode is an easy way to setup most of the availiable power saving options, which include spinning down the hard drive and adjusting the power saving modes of the harddrive and CPU, as well as autosuspending the USB-ports, setting screen brightness, configuring the eee's own 'Super Hybrid Engine', etc.<br />
<br />
===Setup===<br />
# pacman -S laptop-mode-tools<br />
<br />
The main configuration file is '''/etc/laptop-mode/laptop-mode.conf''', plus there are several separate configuration files in '''/etc/laptop-mode/conf.d/''' for the various power saving modules managed by laptop-mode-tools. The files are well commented, so it should be easy to set everything up as needed. (For more information, see [[Laptop Mode Tools]])<br />
<br />
To make the daemon start at boot, add '''laptop-mode''' to the '''DAEMONS''' array in '''/etc/rc.conf'''.<br />
<br />
===LCD brightness===<br />
The relevant config file is '''/etc/laptop-mode/conf.d/lcd-brightness.conf'''. Brightness values are between 0 (darkest) and 15 (brightest). An example of usable settings:<br />
<br />
BATT_BRIGHTNESS_COMMAND="echo 1"<br />
LM_AC_BRIGHTNESS_COMMAND="echo 15"<br />
NOLM_AC_BRIGHTNESS_COMMAND="echo 15"<br />
BRIGHTNESS_OUTPUT="/sys/class/backlight/acpi_video0/brightness"<br />
<br />
===CPU frequency===<br />
The CPU frequency is controlled through the file '''/etc/laptop-mode/conf.d/cpufreq.conf'''. The available frequency options can be found out by running:<br />
<br />
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies<br />
<br />
This functionality requires the package '''cpufrequtils'''. The package also provides a daemon which can be used on its own, in which case '''/etc/conf.d/cpufreq''' should be edited to contain the desired options, and added to '''DAEMONS''' in '''/etc/rc.conf'''. If handling frequency scaling through '''laptop-mode-tools''', the cpufreq daemon should not be loaded, and its config file options can remain commented out, since the settings will come from '''/etc/laptop-mode/conf.d/cpufreq.conf'''.<br />
<br />
Either way, cpufreq requires the kernel module '''acpi-cpufreq''' and some 'governors' ('''cpufreq_ondemand''' seems to be loaded by default, but there is also '''cpufreq_powersave'''). To load them at startup, add these modules to the '''MODULES''' array in '''/etc/rc.conf'''.<br />
<br />
===SHE===<br />
The eeepc's 'Super Hybrid Engine' has a significant effect on powersaving. This underclocks the FSB for powersave/overclocks for performance and can be controlled via the file '''/sys/devices/platform/eeepc/cpufv''' which is provided by the module '''eeepc_laptop'''.<br />
The relevant config file is '''/etc/laptop-mode/conf.d/eee-superhe.conf'''.<br />
<br />
As of writing this (kernel 2.6.33), the module eeepc_laptop doesn't work as expected, see [[#Issues|Issues]].<br />
<br />
===USB suspend===<br />
Config file: '''/etc/laptop-mode/conf.d/usb-autosuspend.conf'''<br />
Tip: make use of the option to disable the suspending of some USB hardware (eg. 3g modems) by using lsusb to get the ID and then insert it in the configuration file.<br />
<br />
==Hotkeys==<br />
Some work out of the box (see [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Hotkeys]] for more).<br />
<br />
=Hardware Info=<br />
'''lspci''' says:<br />
<br />
00:00.0 Host bridge: Intel Corporation Pineview DMI Bridge<br />
00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:02.1 Display controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)<br />
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)<br />
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)<br />
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)<br />
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)<br />
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)<br />
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)<br />
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)<br />
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)<br />
00:1f.0 ISA bridge: Intel Corporation Tigerpoint LPC Controller (rev 02)<br />
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 02)<br />
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)<br />
01:00.0 Ethernet controller: Atheros Communications Atheros AR8132 / L1c Gigabit Ethernet Adapter (rev c0)<br />
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=ASUS_Eee_PC_1005P&diff=112597ASUS Eee PC 1005P2010-07-24T14:35:54Z<p>Watermel0n: Fixed some things. Will fix more later</p>
<hr />
<div>[[Category:ASUS (English)]]<br />
{| style="float:right; border: 1px solid #000;" <br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|- <br />
| Video || style="color:green" | '''Working''' || i915<br />
|- <br />
| Ethernet || style="color:green" | '''Working''' || atl1c<br />
|-<br />
| Wireless || style="color:green" | '''Working''' || ath9k<br />
|-<br />
| Audio || style="color:green" | '''Working''' || snd_hda_intel<br />
|-<br />
| Camera || style="color:green" | '''Working''' || uvcvideo <br />
|-<br />
| Card Reader || style="color:yellow" | '''???''' || <br />
|-<br />
| Function Keys || style="color:yellow" | '''Some working''' || <br />
|}<br />
<br />
This article describes both the 1005P and the 1005PE, since the only difference of the 1005PE is wlan n and a bigger harddrive.<br />
<br />
=Installation=<br />
#[[Install_from_USB_stick|Installing from USB]]: according to the article on [[Putting_installation_media_on_a_USB_key|installing from USB]], the standard ISO images can be used for this (beginning with release 2010.05).<br />
#[[Install_Arch_from_network_(via_PXE)|Installing via PXE]] works well. It requires another computer to use as PXE host, and some configuration.<br />
<br />
=Kernel=<br />
Append acpi_osi=Linux to your /boot/grub/menu.lst to set the EeePC ACPI Interfaces to "Linux-Mode". Then the current kernel (as of writing 2.6.34) will autoload the eeepc_laptop module and everything works perfectly.<br />
<br />
=Xorg=<br />
==Video Driver==<br />
Install '''xf86-video-intel'''.<br />
<br />
==Device Autodetection==<br />
Everything works out of the box. xf86-input-evdev gets installed automatically with the xorg package. The current Xorg doesn't depend on HAL anymore, it uses dbus directly.<br />
<br />
==DPI setting==<br />
A good comfortable setting would be 96dpi or 75dpi if you like your fonts really small. An easy way to set your DPI would be to add this to the end of '''/etc/X11/xinit/xserverrc''':<br />
<br />
exec /usr/bin/X -nolisten tcp -dpi 96<br />
<br />
('''-nolisten''' is also a good idea for reducing unneeded system activity)<br />
<br />
==Graphic Performance==<br />
See [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Graphic_Performance]] and [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Display_settings]].<br />
The short story is that it might be useful to add the following to the '''Device''' section of /etc/X11/xorg.conf:<br />
<br />
Driver "intel"<br />
Option "AccelMethod" "exa" <br />
Option "MigrationHeuristic" "greedy"<br />
Option "FramebufferCompression" "on"<br />
Option "Tiling" "on"<br />
Option "XvMC" "on"<br />
<br />
To let X know where the XvMC library is, run:<br />
<br />
# echo /usr/lib/libIntelXvMC.so > /etc/X11/XvMCConfig<br />
<br />
==Touchpad==<br />
<br />
It works (driver: '''xf86-input-synaptics'''). For additional stuff, see [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Touchpad]].<br />
<br />
==xrandr==<br />
For a nice GUI tool, you can try '''lxrandr'''.<br />
<br />
Switch to external monitor (VGA port):<br />
xrandr --output LVDS1 --off --output VGA1 --auto<br />
<br />
Switch back to eeepc's LCD: <br />
xrandr --output LVDS1 --auto --output VGA1 --off<br />
<br />
=Powersaving and ACPI=<br />
Your best bet is to disable all hardware you don't intend to use (to access the BIOS settings, press F2 after rebooting).<br />
<br />
==laptop-mode-tools==<br />
Laptop mode is an easy way to setup most of the availiable power saving options, which include spinning down the hard drive and adjusting the power saving modes of the harddrive and CPU, as well as autosuspending the USB-ports, setting screen brightness, configuring the eee's own 'Super Hybrid Engine', etc.<br />
<br />
===Setup===<br />
# pacman -S laptop-mode-tools<br />
<br />
The main configuration file is '''/etc/laptop-mode/laptop-mode.conf''', plus there are several separate configuration files in '''/etc/laptop-mode/conf.d/''' for the various power saving modules managed by laptop-mode-tools. The files are well commented, so it should be easy to set everything up as needed. (For more information, see [[Laptop Mode Tools]])<br />
<br />
To make the daemon start at boot, add '''laptop-mode''' to the '''DAEMONS''' array in '''/etc/rc.conf'''.<br />
<br />
===LCD brightness===<br />
The relevant config file is '''/etc/laptop-mode/conf.d/lcd-brightness.conf'''. Brightness values are between 0 (darkest) and 15 (brightest). An example of usable settings:<br />
<br />
BATT_BRIGHTNESS_COMMAND="echo 1"<br />
LM_AC_BRIGHTNESS_COMMAND="echo 15"<br />
NOLM_AC_BRIGHTNESS_COMMAND="echo 15"<br />
BRIGHTNESS_OUTPUT="/sys/class/backlight/acpi_video0/brightness"<br />
<br />
===CPU frequency===<br />
The CPU frequency is controlled through the file '''/etc/laptop-mode/conf.d/cpufreq.conf'''. The available frequency options can be found out by running:<br />
<br />
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies<br />
<br />
This functionality requires the package '''cpufrequtils'''. The package also provides a daemon which can be used on its own, in which case '''/etc/conf.d/cpufreq''' should be edited to contain the desired options, and added to '''DAEMONS''' in '''/etc/rc.conf'''. If handling frequency scaling through '''laptop-mode-tools''', the cpufreq daemon should not be loaded, and its config file options can remain commented out, since the settings will come from '''/etc/laptop-mode/conf.d/cpufreq.conf'''.<br />
<br />
Either way, cpufreq requires the kernel module '''acpi-cpufreq''' and some 'governors' ('''cpufreq_ondemand''' seems to be loaded by default, but there is also '''cpufreq_powersave'''). To load them at startup, add these modules to the '''MODULES''' array in '''/etc/rc.conf'''.<br />
<br />
===SHE===<br />
The eeepc's 'Super Hybrid Engine' has a significant effect on powersaving. This underclocks the FSB for powersave/overclocks for performance and can be controlled via the file '''/sys/devices/platform/eeepc/cpufv''' which is provided by the module '''eeepc_laptop'''.<br />
The relevant config file is '''/etc/laptop-mode/conf.d/eee-superhe.conf'''.<br />
<br />
As of writing this (kernel 2.6.33), the module eeepc_laptop doesn't work as expected, see [[#Issues|Issues]].<br />
<br />
===USB suspend===<br />
Config file: '''/etc/laptop-mode/conf.d/usb-autosuspend.conf'''<br />
Tip: make use of the option to disable the suspending of some USB hardware (eg. 3g modems) by using lsusb to get the ID and then insert it in the configuration file.<br />
<br />
==Hotkeys==<br />
Some work out of the box (see [[http://wiki.archlinux.org/index.php/Asus_Eee_PC_1005HA#Hotkeys]] for more).<br />
<br />
=Hardware Info=<br />
'''lspci''' says:<br />
<br />
00:00.0 Host bridge: Intel Corporation Pineview DMI Bridge<br />
00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:02.1 Display controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)<br />
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)<br />
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)<br />
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)<br />
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)<br />
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)<br />
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)<br />
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)<br />
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)<br />
00:1f.0 ISA bridge: Intel Corporation Tigerpoint LPC Controller (rev 02)<br />
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 02)<br />
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)<br />
01:00.0 Ethernet controller: Atheros Communications Atheros AR8132 / L1c Gigabit Ethernet Adapter (rev c0)<br />
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=Talk:ASUS_Eee_PC_1005P&diff=107877Talk:ASUS Eee PC 1005P2010-06-03T14:17:06Z<p>Watermel0n: Created page with 'Hello. I own an Asus Eee PC 1005PE, which is basically the same as the 1005P, except that it has a bigger Harddrive and WLAN 802.11n Thanks to this and the other Eee wiki pages, …'</p>
<hr />
<div>Hello. I own an Asus Eee PC 1005PE, which is basically the same as the 1005P, except that it has a bigger Harddrive and WLAN 802.11n<br />
Thanks to this and the other Eee wiki pages, I could set up my Eee PC correvtly, but I have a question.<br />
<br />
When I run glxgears, I only get around 60 FPS (300 frames per 5.0s). What results do you get? Because I think it could be possible that my graphics adaptor isn't set up correctly, and therefore everything is rendered on the CPU.</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=ASUS_Eee_PC&diff=107876ASUS Eee PC2010-06-03T14:11:13Z<p>Watermel0n: </p>
<hr />
<div>[[Category:ASUS (English)]]<br />
This should be the page to gather all information on installing and running arch on the Asus Eee. <br />
Why? Because the 'old' page is a bit confusing/outdated, wrongly named (makes finding it in a search hard) and the title limits it to just the install precedure.<br />
<br />
The 'old' page should be cleaned up and merged into this page, and any future information should also go on this page. If no one that actualy owns an Eee want to do it, then I (Mr.Elendig) can do it, but it will take some time.<br />
<br />
Until this page actualy get some contents, go to [[Installing Arch Linux on the Asus EEE PC]].<br />
<br />
= Eee 700 Series and 900=<br />
This should be filled with the majority of the content from [[Installing Arch Linux on the Asus EEE PC]].<br />
<br />
=== Installation ===<br />
Installation can be achieved from an external cdrom drive, or from a usb stick configured as described in [[Install from USB stick]]<br />
<br />
The wireless module (ath5k) is now part of the stock kernel. The stock kernel performs very well on the eeepc. You do not need to install any extra packages from AUR for wireless or install any special kernel.<br />
<br />
During installation make sure you add the following packages in addition to the base packages for wireless to work.<br />
<br />
wireless_tools<br />
netcfg<br />
<br />
Thats all you now need for a working eee.<br />
<br />
=== If you do want an optimized Pentium-M kernel ===<br />
toofishes created a repository for the Eee. You can find some basic packages like a Pentium-M optimized kernel. Add<br />
[eee]<br />
Server = http://code.toofishes.net/packages/eee<br />
to your {{Filename|/etc/pacman.conf}} to use the repository.<br />
<br />
Simply use pacman to install the package you need. Install the packages with this command:<br />
# pacman -S kernel-eee<br />
<br />
Then, add the following to {{Filename|/boot/grub/menu.lst}}; note that no initrd is needed:<br />
# (2) Arch Linux<br />
title Arch Linux EEE kernel<br />
root (hd0,0)<br />
kernel /boot/vmlinuzeee root=/dev/sda1 ro<br />
<br />
Restart and select Arch Linux EEE kernel from the grub boot menu.<br />
<br />
===Xorg===<br />
Xorg works without an xorg.conf on the eeepc fine with the new hotplugging system.<br />
<br />
# pacman -S xorg xf86-input-keyboard xf86-input-synaptics xf86-video-intel<br />
<br />
start hal<br />
<br />
# /etc/rc.d/hal start<br />
<br />
and add hal to the daemons line of your /etc/rc.conf file<br />
<br />
===Sound===<br />
If sound does not work in a new installation add the following line to {{Filename|/etc/modprobe.conf}}<br />
options snd-hda-intel model=3stack-dig<br />
<br />
= Eee 900A =<br />
<br />
The 900A is a 900 with a Intel Atom CPU and new hardware (the most is like in 901), you can get help in [[Asus Eee PC 900A]].<br />
<br />
= Eee 901, 904, and 1000(H) =<br />
The 901, 904, and 1000(H) all seem to share much-of, if not all the same hardware. The steps for setting up Arch Linux are as follows.<br />
NB. There is a separate wiki page as well dedicated to the [[Asus_Eee_PC_901|901]].<br />
<br />
== Setting up the Network ==<br />
Two PKGBUILD files are available in the AUR to help you get your network interfaces up and running. The first is delcake's "atl1e" drivers for your wired ethernet, and the second is jbooth's "eeert2860" drivers for wireless.<br />
<br />
=== atl1e ===<br />
delcake's PKGBUILD is located [http://aur.archlinux.org/packages.php?ID=18663 here] in the AUR.<br />
Note that in order to build this package, you will need to get the unrar and unzip packages from the mirror of you choice, as well as the LinuxDrivers.zip source code linked on the AUR page unless you did your wireless drivers first.<br />
<br />
#Transfer the PKGBUILD to your Eee PC. Get the source files too if you don't have internet yet.<br />
#Install the unrar and unzip packages if you don't already have them.<br />
#Issue a 'makepkg' command at the location of the PKGBUILD.<br />
<br />
If all goes well, a .pkg.tar.gz file that starts with the name atl1e will have been created in the same folder.<br />
<br />
As root, run 'pacman -U <package name>.pkg.tar.gz' to install your newly created module.<br />
In order to detect it, run both 'depmod -a' and 'modprobe atl1e' as root in that order.<br />
<br />
At this point, you should be able to issue an 'ifconfig -a' command and see your brand new eth0 device staring back at you. Don't forget to add atl1e to your modules list in /etc/rc.conf to automatically load your ethernet module during boot.<br />
<br />
* '''WARNING:''' You will need to recompile this module any time you do a kernel upgrade, so hang on to that PKGBUILD and zip file.<br />
<br />
=== eeert2860 ===<br />
jbooth's PKGBUILD is located [http://aur.archlinux.org/packages.php?ID=18705 here] in the AUR.<br />
Note that in order to build this package, you will need to get the wireless_tools package from the mirror of your choice, as well as Ralink's drivers listed under the sources section unless you did your wired drivers first.<br />
<br />
#Transfer the PKGBUILD to your Eee PC. Get the source files too if you don't have internet yet.<br />
#Install the wireless_tools package if you don't already have it.<br />
#Issue a 'makepkg' command at the location of the PKGBUILD.<br />
<br />
Hopefully, the makepkg command went through without a hitch, and a .pkg.tar.gz file will have been created in the same folder.<br />
<br />
As root, run 'pacman -U <package name>.pkg.tar.gz' to install your newly created module.<br />
In order to detect it, run both 'depmod -a' and 'modprobe rt2860sta' as root in that order.<br />
<br />
Now you should see your ra0 wireless device in the output of 'ifconfig -a'. As root, run 'ifconfig ra0 up' to bring up the interface for configuration.<br />
<br />
*'''Still no ra0 device?''' Make sure that the WLAN device is enabled in your BIOS.<br />
<br />
* '''WARNING:''' You will need to recompile this module any time you do a kernel upgrade, so hang on to the PKGBUILD and .tar.bz2 file.<br />
<br />
==Eee 901 20G lsmod and lspci==<br />
'''<br />
Note :''' This section was moved from the 70x/900 page.<br />
<br />
The following are from a stock ASUS EeePC 901 20G Linux version:<br />
<br />
lsmod:<br />
<pre><br />
Module Size Used by<br />
acpi_cpufreq 5004 0 <br />
freq_table 1988 1 acpi_cpufreq<br />
usb_storage 22980 0 <br />
libusual 6352 1 usb_storage<br />
pciehp 31172 0 <br />
pci_hotplug 9672 1 pciehp<br />
ehci_hcd 25420 0 <br />
uhci_hcd 18636 0 <br />
usbhid 13444 0 <br />
usbcore 91992 6 usb_storage,libusual,ehci_hcd,uhci_hcd,usbhid<br />
snd_pcm_oss 33568 0 <br />
snd_mixer_oss 13056 1 snd_pcm_oss<br />
rt2860sta 468248 1 <br />
atl1e 26388 0 <br />
fuse 34516 0 <br />
asus_acpi 6560 0 <br />
button 5648 0 <br />
processor 19820 1 acpi_cpufreq<br />
battery 7940 0 <br />
ac 3524 0 <br />
autofs4 15876 0 <br />
sr_mod 13284 0 <br />
cdrom 30624 1 sr_mod<br />
snd_hda_intel 284112 0 <br />
snd_pcm 50696 2 snd_pcm_oss,snd_hda_intel<br />
snd_timer 15556 1 snd_pcm<br />
snd_page_alloc 6728 2 snd_hda_intel,snd_pcm<br />
snd_hwdep 6084 1 snd_hda_intel<br />
snd 34852 6 snd_pcm_oss,snd_mixer_oss,snd_hda_intel,snd_pcm,snd_timer,snd_hwdep<br />
soundcore 3744 1 snd<br />
genrtc 6028 0<br />
</pre><br />
<br />
lspci:<br />
<pre><br />
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)<br />
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)<br />
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)<br />
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)<br />
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)<br />
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)<br />
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)<br />
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)<br />
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)<br />
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)<br />
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)<br />
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)<br />
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)<br />
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)<br />
01:00.0 Network controller: RaLink RT2790 Wireless 802.11n PCIe<br />
03:00.0 Ethernet controller: Atheros Corp. L1e Gigabit Ethernet Adapter (rev b0)<br />
</pre><br />
<br />
= Eee 904HA =<br />
Visit the page dedicated to the [[Asus_Eee_PC_904HA|904HA]].<br />
<br />
= Eee 1000HA =<br />
[[Asus Eee PC 1000HA]]<br />
<br />
= Eee 1000HE =<br />
[[Asus Eee PC 1000HE]]<br />
<br />
= Eee 1001P =<br />
[[Asus Eee PC 1001p]]<br />
<br />
= Eee 1005HA =<br />
[[Asus Eee PC 1005HA]]<br />
<br />
= Eee 1005P(E) =<br />
[[Asus Eee PC 1005P]]</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=JDownloader&diff=106396JDownloader2010-05-15T10:37:39Z<p>Watermel0n: </p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
<br />
==Introduction==<br />
JDownloader is a Download Manager written in Java. JDownloader can download normal files, but also files from online file hosting services like Rapidshare.com.<br />
<br />
==Installation==<br />
<br />
===Requirements===<br />
For running JDownloader you need Java installed. I recommend OpenJDK, it works flawless with jDownloader.<br />
# pacman -S openjdk<br />
<br />
===Installing===<br />
You can use the [http://aur.archlinux.org/packages.php?ID=29288 jdownloader package] in the AUR.<br />
<br />
===Running===<br />
Use the command jdownloader to start JDownloader. When you just installed JDownloader from AUR, this will run the update tool to download some required files for JDownloader, else this will start JDownloader directly.<br />
<br />
==Configuration==<br />
When you first start JDownloader you can choose your preferred language and also your download directory. On the next window, JDownloader asks you if you want to install FlashGot, a Firefox extension. I recommend clicking on Cancel. If you want this extension, you can still download it through [http://addons.mozilla.org the official mozilla addons website].<br />
<br />
==Tips and tricks==<br />
===Making JDownloader faster===<br />
In its default configuration, JDownloader is very slow and uses a lot of resources. You can atleast make it a bit faster by applying the following changes in the Settings Tab.<br />
<br />
Choose General and then turn the logging level to OFF.<br />
<br />
Choose User Interface and then switch the style to Light(GTK). (If you're using GNOME).</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=Talk:Dm-crypt&diff=100083Talk:Dm-crypt2010-03-14T14:44:29Z<p>Watermel0n: </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 />
- This section is misleading. What the author meant was if you encrypt the contents of LVM partitions, THEN you have to move the lvm2 hook before the encrypt hook. I made a few small changes, so other newbies (like me) don't end up with an unbootable system.<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>Watermel0nhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=100082Dm-crypt2010-03-14T14:39:31Z<p>Watermel0n: made small changes, which might stop newbies like me running into a system which doesn't boot lol</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 if you chose to set up LVM on top of the encrypted partition. 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 if you set up LVM on top of the encrypted partition.<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>Watermel0nhttps://wiki.archlinux.org/index.php?title=JDownloader&diff=99515JDownloader2010-03-10T11:17:39Z<p>Watermel0n: </p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
<br />
==Introduction==<br />
JDownloader is a Download Manager written in Java. JDownloader can download normal files, but also files from online file hosting services like Rapidshare.com.<br />
<br />
==Installation==<br />
<br />
===Requirements===<br />
For running JDownloader you need Java installed. I recommend OpenJDK, it works flawless on Arch Linux.<br />
# pacman -S openjdk<br />
<br />
===Installing===<br />
JDownloader can be downloaded from the official website [http://jdownloader.org JDownloader.org]. On the navigation bar choose Download and then pick a Mirror for the Linux binary distribution.<br />
After unpacking the ZIP file, you can move the directory anywhere you want, a good destination might be ~/JDownloader/.<br />
<br />
===Adding a Menu item===<br />
Edit your menu and use the following command to start JDownloader:<br />
java -jar /path/to/JDownloader.jar<br />
<br />
==Running==<br />
To run JDownloader cd to the JDownloader directory and run<br />
$ java -jar JDownloader.jar<br />
Or click on your created menu item.<br />
<br />
==Configuration==<br />
When you first start JDownloader you can choose your preferred language and also your download directory. On the next window, JDownloader asks you if you want to install FlashGot, a Firefox extension. I recommend clicking on Cancel. If you want this extension, you can still download it through [http://addons.mozilla.org the official mozilla addons website].<br />
<br />
==Tips and tricks==<br />
===Making JDownloader faster===<br />
In its default configuration, JDownloader is very slow and uses a lot of resources. You can atleast make it a bit faster by applying the following changes in the Settings Tab.<br />
<br />
Choose General and then turn the logging level to OFF.<br />
<br />
Choose User Interface and then switch the style to Light(GTK). (If you're using GNOME).</div>Watermel0nhttps://wiki.archlinux.org/index.php?title=JDownloader&diff=99514JDownloader2010-03-10T09:57:55Z<p>Watermel0n: Created page with 'Category:Internet and Email (English) ==Introduction== JDownloader is a Download Manager written in Java. JDownloader can download normal files, but also files from online f…'</p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
<br />
==Introduction==<br />
JDownloader is a Download Manager written in Java. JDownloader can download normal files, but also files from online file hosting services like Rapidshare.com.<br />
<br />
==Installation==<br />
<br />
===Requirements===<br />
For running JDownloader you need Java installed. I recommend OpenJDK, it works flawless on Arch Linux.<br />
# pacman -S openjdk<br />
<br />
===Installing===<br />
JDownloader can be downloaded from the official website [http://jdownloader.org JDownloader.org]. On the navigation bar choose Download and then pick a Mirror for the Linux binary distribution.<br />
After unpacking the ZIP file, you can move the directory anywhere you want, a good destination might be ~/JDownloader/.<br />
<br />
===Adding a Menu item===<br />
Edit your menu and use the following command to start<br />
# java -jar /path/to/JDownloader.jar<br />
<br />
==Running==<br />
To run JDownloader cd to the JDownloader directory and run<br />
# java -jar JDownloader.jar<br />
Or click on your created menu item.<br />
<br />
==Configuration==<br />
When you first start JDownloader you can choose your preferred language and also your download directory. On the next window, JDownloader asks you if you want to install FlashGot, a Firefox extension. I recommend clicking on Cancel. If you want this extension, you can still download it through [http://addons.mozilla.org the official mozilla addons website].<br />
<br />
==Tips and tricks==<br />
===Making JDownloader faster===<br />
In its default configuration, JDownloader is very slow and uses a lot of resources. You can atleast make it a bit faster by applying the following changes in the Settings Tab.<br />
<br />
Choose General and then turn the logging level to OFF.<br />
<br />
Choose User Interface and then switch the style to Light(GTK). (If you're using GNOME).</div>Watermel0n