https://wiki.archlinux.org/api.php?action=feedcontributions&user=B&feedformat=atomArchWiki - User contributions [en]2024-03-28T23:26:26ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Msmtp&diff=164442Msmtp2011-10-07T14:14:21Z<p>B: Corrected location of systemwide configuration file</p>
<hr />
<div>{{DISPLAYTITLE:msmtp}}<br />
[[Category:Email Client (English)]]<br />
<br />
[http://msmtp.sourceforge.net/ msmtp] is a very simple and easy to use smtp client with excellent [[sendmail]] compatibility.<br />
<br />
An alternative lightweight MTA that also handles local mail is {{Package AUR|dma}}, available in the [[AUR]].<br />
<br />
==Installing==<br />
{{package Official|msmtp}} is in the ''extra'' repository.<br />
# pacman -S msmtp<br />
<br />
==Quick start==<br />
The following is an example of a msmtp configuration file for several accounts. If msmtp throws errors when using this file, search for double byte '\xc2\xa0' characters that may have been erroneously inserted.<br />
{{file|name=~/.msmtprc|content=<br />
# Accounts will inherit settings from this section<br />
defaults<br />
auth on<br />
tls on<br />
tls_trust_file /usr/share/ca-certificates/mozilla/Thawte_Premium_Server_CA.crt<br />
<br />
# A first gmail address<br />
account gmail<br />
host smtp.gmail.com<br />
port 587<br />
from username@gmail.com<br />
user username@gmail.com<br />
password password<br />
<br />
# A second gmail address<br />
account gmail2 : gmail<br />
from username2@gmail.com<br />
user username2@gmail.com<br />
password password2<br />
# It looks like Google's in the process of becoming its own certificate<br />
# authority. For some users, they seem to have switched to a "Google<br />
# Certificate Authority" certificate, which is rooted in Equifax.<br />
#tls_trust_file /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt<br />
<br />
<br />
# A freemail service<br />
account freemail<br />
host smtp.freemail.example<br />
from joe_smith@freemail.example<br />
user joe.smith<br />
password secret<br />
<br />
# A provider's service<br />
account provider<br />
host smtp.provider.example<br />
<br />
# Set a default account<br />
account default : gmail<br />
}}<br />
<br />
msmtp will refuse to start if ''user'' configuration file is readable and writeable to anyone else but the owner:<br />
$ chmod 600 ~/.msmtprc<br />
<br />
This does not apply to system configuration file (in Arch, this is /etc/msmtprc; copy the example over from /usr/share/doc/msmtp/ ).<br />
<br />
If your application uses "mail" (mailx) to send mail (e.g. smartd), specify msmtp:<br />
{{file|name=/etc/mail.rc|content=set sendmail=/usr/bin/msmtp}}<br />
<br />
==Test msmtp==<br />
The {{codeline|-a}} flag specifies the account to use as sender; {{codeline|<username>@domain.com}} is the recipient.<br />
<br />
Save (with the addresses you want to use)<br />
To: <username>@domain.com<br />
From: username@gmail.com<br />
Subject: A test<br />
<br />
Yadda, yadda, yadda.<br />
<br />
as, say, "test.mail".<br />
<br />
Then execute<br />
<br />
$ cat test.mail | msmtp -a default <username>@domain.com<br />
<br />
Do ''not'' merely use "echo 'Yadda, yadda, yadda.'" instead of "cat test.mail". This causes at least Gmail and Yahoo to deliver the mail incorrectly.<br />
<br />
==Miscellaneous==<br />
<br />
===Practical password management===<br />
The {{codeline|password}} directive may be omitted. In that case, if the account in question has {{codeline|auth}} set to a legitimate value other than {{codeline|off}}, invoking msmtp from an interactive shell will ask for the password before sending mail. msmtp will not prompt if it has been called by another type of application, such as [[Mutt]].<br />
<br />
If this is not desired, an alternative is to place passwords in {{filename|~/.netrc}}, a file that can act as a common pool for msmtp, [[OfflineIMAP]], and associated tools.<br />
<br />
===Using msmtp offline===<br />
{{note|The msmtp source distribution includes msmtpq and msmtpQ in the ./scripts directory, which are updated versions of the msmtpqueue bundle.}}<br />
<br />
Although msmtp is great, it requires that you be online to use it. This isn't ideal for people on laptops with intermittent connections to the Internet or dialup users. Several scripts have been written to remedy this fact, collectively called msmtpqueue.<br />
<br />
The scripts can be downloaded from [http://sourceforge.net/project/showfiles.php?group_id=86651&package_id=96024 SourceForge], the most recent of which is msmtpqueue-0.5.tar.gz.<br />
<br />
Once the scripts have been downloaded extract them using:<br />
$ tar xf msmtpqueue-0.5.tar.gz<br />
<br />
After that, copy the scripts to a convenient location on your computer ({{filename|/usr/local/bin}} is a good choice):<br />
$ cp msmtpqueue-0.5/*.sh /usr/local/bin/<br />
<br />
Finally, change your MUA to use msmtp-enqueue.sh instead of msmtp when sending e-mail. Queued messages will be stored in {{filename|~/.msmtpqueue}}.<br />
<br />
When you want to send any mail that you've created and queued up run:<br />
$ /usr/local/bin/msmtp-runqueue.sh<br />
<br />
Adding {{filename|/usr/local/bin}} to your PATH can save you some keystrokes if you're doing it manually. The README file that comes with the scripts has some handy information, reading it is recommended.<br />
<br />
===Vim syntax highlighting===<br />
The msmtp source distribution includes a {{filename|msmtprc}} highlighting script for [[Vim]]. Install it from {{filename|./scripts/vim/msmtp.vim}}.<br />
<br />
===Send mail with PHP using msmtp===<br />
Look for ''sendmail_path'' option in your {{filename|php.ini}} and edit like this:<br />
<pre><br />
sendmail_path = "/usr/bin/msmtp -C /path/to/your/config -t"<br />
</pre><br />
<br />
Note that you '''can not''' use a user configuration file (ie: one under ~/) if you plan on using msmtp as a sendmail replacement with php or something similar.<br />
In that case just create /etc/msmtprc, and remove your user configuration (or not if you plan on using it for something else). Also make sure it's readable by whatever you're using it with (php, django, etc...)<br />
<br />
From the msmtp manual: ''Accounts defined in the user configuration file override accounts from the system configuration file. The user configuration file must have no more permissions than user read/write''<br />
<br />
So it's impossible to have a conf file under ~/ and have it still be readable by the php user.<br />
<br />
To test it place this file in your php enabled server or using php-cli.<br />
<pre><br />
<?php<br />
mail("your@email.com", "Test email from PHP", "msmtp as sendmail for PHP");<br />
?><br />
</pre><br />
<br />
==Troubleshooting==<br />
<br />
===Issues with TLS===<br />
If you see the following message:<br />
msmtp: TLS certificate verification failed: the certificate hasn't got a known issuer<br />
it probably means your tls_trust_file is not right.<br />
<br />
Just follow the [http://msmtp.sourceforge.net/doc/msmtp.html#Transport-Layer-Security fine manual]. It explains you how to find out the server certificate issuer of a given smtp server. Then you can explore the {{filename|/usr/share/ca-certificates/}} directory to find out if by any chance, the certificate you need is there. If not, you will have to get the certificate on your own.<br />
<br />
If you are trying to send mail through GMail and are receiving this error, have a look at [http://www.mail-archive.com/msmtp-users@lists.sourceforge.net/msg00141.html this] thread or just use the second GMail example above.<br />
<br />
If you are completely desperate, but are 100% sure you are communicating with the right server, you can always temporarily disable the cert check:<br />
$ msmtp --tls-certcheck off</div>Bhttps://wiki.archlinux.org/index.php?title=Advanced_Format&diff=164405Advanced Format2011-10-07T02:31:53Z<p>B: HD204UI added reported sector sizes</p>
<hr />
<div>[[Category:Storage (English)]]<br />
{{i18n|Advanced Format}}<br />
==Introduction==<br />
The 'advanced format' feature reduces overhead by using 4 kilobyte sectors instead of the traditional 512 byte sectors. The old format gave a format efficiency of 87%. Advanced Format results in a format efficiency of 96% which increases space by up to 11%. The 4k sector is slated to become the next standard for HDDs by 2014.<br />
<br />
===More Detailed Explanation===<br />
The main idea behind using 4096-byte sectors is to increase the bit density on each track by reducing the number of gaps which hold Sync/DAM and ECC (Error Correction Code) information between data sectors. For eight 512-byte sectors, the track also holds eight sector gaps.<br />
<br />
By having one single sector of size 4096-byte (8 x 512-byte), the track holds only 1 sector gap for each data sector thus reducing an overhead for a need to support multiple Sync/DAM and ECC blocks and at the same time increasing bit density.<br />
<br />
Linux partitioning tools by default start each partition on sector 63 which leads to a bad performance in HDDs that use this 4K sector size due to misalignment to 4K sector from the beginning of the track.<br />
<br />
===External Links===<br />
*[http://www.anandtech.com/Show/Index/2888?cPage=2&all=False&sort=0&page=1 Western Digital’s Advanced Format: The 4K Sector Transition Begins]<br />
*[http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf White paper entitled "Advanced Format Technology."]<br />
*Failure to align one's HDD results in poor read/write performance. See [http://www.linuxconfig.org/linux-wd-ears-advanced-format this article] for specific examples.<br />
<br />
==Current HDD Models that Employ a 4k Sectors==<br />
As of June 2011, there are a limited number of HDDs that support "Advanced Format" or 4k sectors as shown below.<br />
<br />
All drives in this list have a physical sector size of 4096 bytes, but not all drives correctly report this to the OS. The actual value reported (via new fields in the ATA-8 spec) is shown in the table as the physical reported sector size. As this is the value partitioning tools use for alignment, it is important that it should be 4096 to avoid misalignment issues.<br />
<br />
The logical sector size is the sector size used for data transfer. This value multiplied by the number of LBA sectors on the disk gives the disk capacity. Thus a disk with 4096 byte logical sectors will have a lower maximum LBA for the same capacity compared to a drive with 512 byte sectors. Drives with 512 byte logical sectors offer better compatibility with legacy operating systems (roughly those released before 2009) however drives with 4096 byte logical sectors may offer marginally better performance (e.g. more read/write requests may fit into the NCQ buffer.)<br />
<br />
{|class="wikitable"<br />
!rowspan=2| Manufacturer !!rowspan=2| Model !!rowspan=2| Capacity !!colspan=2| Reported sector size (bytes)<br />
|-<br />
! Logical !! Physical<br />
|-<br />
|colspan=5| '''3.5"'''<br />
|-<br />
| Western Digital || WD30EZRSDTL || 3.0 TB<br />
|-<br />
| Western Digital || WD25EZRSDTL || 2.5 TB<br />
|-<br />
| Samsung || HD204UI || 2.0 TB || 512 || 512<br />
|-<br />
| Seagate || ST1000DL002 || 1.0 TB || 512 || 512<br />
|-<br />
| Seagate || ST2000DL003 || 2.0 TB || 512 || 512<br />
|-<br />
| Western Digital || WD20EARS || 2.0 TB || 512 || [http://community.wdc.com/t5/Desktop/4k-sector-drive-reporting-512-byte-sectors-to-OS-why/td-p/205060 512]<br />
|-<br />
| Western Digital || WD15EARS || 1.5 TB || 512 || [http://excess.org/article/2010/11/wd-hdd-lying-about-4k-sectors/ 4096]<br />
|-<br />
| Western Digital || WD10EARS || 1.0 TB<br />
|-<br />
| Western Digital || WD10EURS || 1.0 TB<br />
|-<br />
| Western Digital || WD8000AARS || 800.0 GB<br />
|-<br />
| Western Digital || WD6400AARS || 640.0 GB<br />
|-<br />
|colspan=5| '''2.5"'''<br />
|-<br />
| Western Digital || WD10TPVT || 1.0 TB<br />
|-<br />
| Western Digital || WD7500BPVT || 750.0 GB<br />
|-<br />
| Western Digital || WD7500KPVT || 750.0 GB<br />
|-<br />
| Western Digital || WD6400BPVT || 640.0 GB<br />
|-<br />
| Western Digital || WD5000BPVT || 500.0 GB<br />
|-<br />
| Western Digital || WD3200BPVT || 320.0 GB<br />
|-<br />
| Western Digital || WD2500BPVT || 250.0 GB || 512 || 4096<br />
|-<br />
| Western Digital || WD1600BPVT || 160.0 GB<br />
|}<br />
<br />
{{Note| Readers are encouraged to add to this table.}}<br />
<br />
==Aligning Partitions==<br />
===Check your partitions alignment===<br />
{{Note|This only works with [[MBR]], not [[GPT]].}}<br />
# fdisk -lu /dev/sda<br />
...<br />
# Device Boot Start End Blocks Id System<br />
# /dev/sda1 2048 46876671 23437312 7 HPFS/NTFS<br />
<br />
2048 (default since fdisk 2.17.2) means that your HDD is aligned correctly.<br />
Any other value divisible by 8 is good as well.<br />
<br />
===GPT (Recommended)===<br />
When using [[GPT]] partition tables, one need only use gdisk to create partitions which are aligned by default. For an example, see [[SSD#Detailed_Usage_Example]].<br />
<br />
===MBR (Not Recommended)===<br />
One can employ fdisk to align partitions to sector 2048 which will ensure that the partitions are aligned to the 4k sector. Interestingly, in sector mode, the default starting point is not 63 or 64 but 2048 in the current version of fdisk (2.17.2) so it is automatically taking care of the 4k sector size!<br />
<br />
# fdisk -c -u /dev/sda<br />
<br />
==Special Consideration for WD Green HDDs==<br />
<br />
FYI - this section has nothing to do with Advanced Format technology, but this is an appropriate location to share it with users. The WD20EARS (and other sizes include 1.0 and 1.5 TB driver in the series) will attempt to park the read heads once every 8 seconds FOR THE LIFE OF THE HDD which is just horrible! Use hdparm in {{Filename|/etc/rc.local}} to disable this 'feature' and likely add life to your hdd:<br />
<br />
# echo "hdparm -S 242 /dev/sdX" >> /etc/rc.local<br />
<br />
Alternatively, the following shell script can accomplish this automatically:<br />
#!/bin/sh<br />
for DISK in `fdisk -l | grep [12]000.4 | cut -c13-13`; do<br />
echo hdparm -S 242 /dev/sd$DISK >> /etc/rc.local<br />
done</div>Bhttps://wiki.archlinux.org/index.php?title=Openbox&diff=154592Openbox2011-08-31T06:48:21Z<p>B: /* SSH agent no longer starting */</p>
<hr />
<div>[[Category:Stacking WMs (English)]]<br />
{{i18n|Openbox}}<br />
<br />
Openbox is a lightweight and highly configurable window manager with extensive standards support. Its features are documented at the [http://openbox.org/ official website]. This article pertains to installing Openbox under Arch Linux.<br />
<br />
== Installation ==<br />
<br />
{{Package Official|openbox}} is available from the community repository:<br />
# pacman -S openbox<br />
<br />
After installation, you should copy the default configuration files {{Filename|rc.xml}}, {{Filename|menu.xml}}, {{Filename|autostart}}, and {{Filename|environment}} to {{Filename|~/.config/openbox}}:<br />
<br />
{{Note | Do this as a regular user, not as root.}}<br />
<br />
$ mkdir -p ~/.config/openbox<br />
$ cp /etc/xdg/openbox/{rc.xml,menu.xml,autostart,environment} ~/.config/openbox<br />
<br />
{{Filename|rc.xml}} is the main configuration file. It defines keyboard shortcuts, themes, virtual desktops, and more.<br />
<br />
{{Filename|menu.xml}} defines the content of the right-click menu. It defines launchers for applications and other shortcuts. See the [[#Menus]] section.<br />
<br />
{{Filename|autostart}} is read by openbox-session at startup. It contains the programs that are run at startup. It is typically used to set environment variables, launch panels/docks, set background image or execute other startup scripts. See the [http://openbox.org/wiki/Help:Autostart Openbox Wiki].<br />
<br />
{{Filename|environment}} is sourced by openbox-session at startup. It contains environment variables to be set in Openbox's context. Any variables you set here will be visible to Openbox itself and anything you start from its menus.<br />
<br />
== Upgrading to Openbox 3.5 ==<br />
<br />
If you are upgrading to Openbox 3.5 or later from an earlier release, be aware of these changes:<br />
<br />
* There is a new config file called {{Filename|environment}} that you should copy from /etc/xdg/openbox to ~/.config/openbox .<br />
* The config file previously called {{Filename|autostart.sh}} is now just called {{Filename|autostart}}. You should rename yours to remove the .sh from the end of the name.<br />
* Some of the configuration grammar in {{Filename|rc.xml}} has changed. While Openbox appears to understand the old options, it would be wise to compare your configuration to the one in /etc/xdg/openbox and look for changes that affect you.<br />
<br />
=== Troubleshooting 3.5 ===<br />
See the [[#Troubleshooting_Openbox_3.5|Troubleshooting Openbox 3.5]] section below.<br />
<br />
== Openbox as a stand-alone WM ==<br />
<br />
Openbox can be used as a stand-alone window manager (WM). This is usually simpler to install and configure than using Openbox with desktop environments. Running openbox alone may reduce your system's CPU and memory load.<br />
<br />
To run Openbox as a stand-alone window manager, append the following to '''{{Filename|~/.xinitrc}}''':<br />
exec openbox-session<br />
<br />
You may also start Openbox from the command shell (aka: text prompt) using '''xinit''':<br />
$ xinit /usr/bin/openbox-session<br />
<br />
If you used another window manager previously (such as Xfwm) and now Openbox will not start after logging out of X, try moving the autostart folder:<br />
mv ~/.config/autostart ~/.config/autostart-bak<br />
<br />
Using Consolekit, use this instead:<br />
exec ck-launch-session openbox-session<br />
<br />
If you also use '''polkit''' and '''D-Bus''' (e.g. for auto-mount drivers in Nautilus/Gnome) use:<br />
exec ck-launch-session dbus-launch openbox-session<br />
<br />
{{Note | [http://www.archlinux.org/packages/extra/any/pyxdg/ pyxdg] is required for Openbox's xdg-autostart}}<br />
{{Note | "dbus-launch" must be placed after "ck-launch-session" or you will experience mounting problems}}<br />
<br />
== Openbox as a WM for desktop environments ==<br />
<br />
Openbox can be used as a replacement window manager for full-fledged desktop environments. The method for deploying Openbox depends on the desktop environment.<br />
<br />
=== GNOME 2.24 and 2.26 ===<br />
Create {{Filename|/usr/share/applications/openbox.desktop}} with the following lines:<br />
[Desktop Entry]<br />
Type=Application<br />
Encoding=UTF-8<br />
Name=OpenBox<br />
Exec=openbox<br />
NoDisplay=true<br />
# name of loadable control center module<br />
X-GNOME-WMSettingsModule=openbox<br />
# name we put on the WM spec check window<br />
X-GNOME-WMName=OpenBox<br />
In gconf, set '''{{Codeline|/desktop/gnome/session/required_components/windowmanager}}''' to '''{{Codeline|openbox}}:'''<br />
$ gconftool-2 -s -t string /desktop/gnome/session/required_components/windowmanager openbox<br />
Finally, choose '''GNOME''' session from the GDM sessions menu.<br />
<br />
=== GNOME 2.26 Redux ===<br />
'''''If the previous guide for GNOME 2.24 fails:'''''<br />
<br />
If, when attempting to log into a "Gnome/Openbox" session -- and it consistently fails to start, try the following. This is one way of achieving your goal of using Openbox as the WM anytime you open a Gnome session:<br />
<br />
#Log into your Gnome-only session (it should still be using Metacity as its window manager).<br />
#Install Openbox if you have not done so already<br />
#Navigate your menus to ''System &rarr; Preferences &rarr; Startup Applications'' (possibly named 'Session' in older Gnome versions)<br />
#Open Startup Application, select '+ Add' and enter the text shown below. Omit the text after #.<br />
#Click the 'Add' button for the data entry window. Make sure the checkbox beside your new entry is selected.<br />
#Log out from your Gnome session and log back in<br />
#You should now be running openbox as your window manager.<br />
<br />
Name: Openbox Windox Manager # Can be changed<br />
Command: openbox --replace # Text should not be removed from this line, but possibly added to it<br />
Comment: Replaces metacity with openbox # Can be changed<br />
<br />
This creates a startup list entry which is executed by Gnome each time the user's session is started.<br />
<br />
=== GNOME 2.22 and prior ===<br />
# If you use GDM, select the "GNOME/Openbox" login option<br />
# If you use {{Codeline|startx}}, add {{Codeline|exec openbox-gnome-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-gnome-session<br />
<br />
=== KDE ===<br />
# If you use KDM, select the "KDE/Openbox" login option<br />
# If you use startx, add {{Codeline|exec openbox-kde-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-kde-session<br />
<br />
=== Xfce4 ===<br />
Log into a normal Xfce4 session. From your terminal, type:<br />
$ killall xfwm4 ; openbox & exit<br />
<br />
This kills xfwm4, runs Openbox, and closes the terminal. Log out, being sure to check the ''"Save session for future logins"'' box. On your next login, Xfce4 should use '''Openbox''' as its WM.<br />
<br />
To enable exiting from a session using ''xfce4-session,'' edit '''{{Filename|~/.config/openbox/menu.xml}}'''. If the file is not there, copy it from {{Filename|/etc/xdg/openbox/}}. Look for the following entry:<br />
<item label="Exit Openbox"><br />
<action name="Exit"><br />
<prompt>yes</prompt><br />
</action><br />
</item><br />
<br />
Change it to:<br />
<item label="Exit Openbox"><br />
<action name="Execute"><br />
<prompt>yes</prompt><br />
<command>xfce4-session-logout</command><br />
</action><br />
</item><br />
<br />
Otherwise, choosing "Exit" from the root-menu causes Openbox to terminate its execution, leaving you with no window manager.<br />
<br />
If you have a problem changing virtual desktops with the mouse wheel skipping over desktops, edit '''{{Filename|~/.config/openbox/rc.xml}}'''. Move the ''mouse binds with...'' actions "DesktopPrevious" and "DesktopNext" from context ''Desktop'' to the context ''Root''. (You may need to create a definition for the ''Root'' context as well.)<br />
<br />
When using the Openbox root-menu instead of Xfce's menu, you may exit the Xfdesktop with this terminal command:<br />
$ xfdesktop --quit<br />
Xfdesktop manages the wallpaper and desktop icons, requiring you to use other utilities such as ROX for these functions.<br />
<br />
(When terminating Xfdesktop, the above issue with the virtual desktops is no longer a problem.)<br />
<br />
== Openbox for multihead users ==<br />
<br />
While Openbox provides better than average multihead support on its own, a branch called [http://aur.archlinux.org/packages.php?ID=51460 Openbox Multihead] is now available in the AUR that gives multihead users per-monitor desktops. This model is not commonly found in floating window managers, but exists mainly in tiling window managers. It is explained well on the [http://xmonad.org/tour.html#workspace Xmonad web site]. Also, please see [https://github.com/BurntSushi/openbox-multihead/blob/multihead/README.MULTIHEAD README.MULTIHEAD] for a more comprehensive description of the new features and configuration options found in Openbox Multihead.<br />
<br />
Openbox Multihead will function like normal Openbox when only a single head is available.<br />
<br />
A downside to using Openbox Multihead is that it breaks the EWMH assumption that one and only one desktop is visible at any time. Thus, existing pagers will not work well with it. To remedy this, [http://aur.archlinux.org/packages.php?ID=51536 pager-multihead] can be found in the AUR that is compatible with Openbox Multihead. [http://imgur.com/a/cnZeq#y04nk Screenshots].<br />
<br />
Finally, a new version of [http://aur.archlinux.org/packages.php?ID=51626 pytyle] can also be found in the AUR that will work with Openbox Multihead.<br />
<br />
Both pytyle3 and pager-multihead will work without Openbox Multihead if only one monitor is active.<br />
<br />
== Configuration ==<br />
<br />
There are several options for configuring Openbox settings:<br />
<br />
=== Manual configuration ===<br />
To configure Openbox manually, edit the {{Filename|~/.config/openbox/rc.xml}} file with a text editor. The file has explanatory comments throughout. See the [http://openbox.org/wiki/Help:Configuration Help:Configuration openbox wiki] for more documentation on editing this file.<br />
<br />
=== ObConf ===<br />
[http://openbox.org/wiki/ObConf:About ObConf] is an Openbox configuration tool. It is used to set most common preferences such as themes, virtual desktops, window properties, and desktop margins. It can be installed with pacman:<br />
<br />
# pacman -S obconf<br />
<br />
ObConf cannot configure keyboard shortcuts and certain other features. For these features edit {{Filename|rc.xml}} manually. Alternatively, you can try {{Package AUR|obkey}} from the [[AUR]].<br />
<br />
=== Application customization ===<br />
<br />
Openbox allows per-application customizations. This lets you define rules for a given program. For example:<br />
* Start your web browser on a specific virtual desktop.<br />
* Open your terminal program with no window decorations (window chrome).<br />
* Make your bit-torrent client open at a given screen position.<br />
<br />
Per-application settings are defined in {{Filename|~/.config/openbox/rc.xml}}. Instructions are in the file's comments. More details are found in the [http://openbox.org/wiki/Help:Applications Help:Applications openbox wiki].<br />
<br />
== Menus ==<br />
<br />
The default Openbox menu includes a variety of menu items to get you started. Many of these items launch applications you do not want, have not installed yet, or never intend to install. You will surely want to customize '''{{Filename|menu.xml}}''' at some point. There are a number of ways to do so.<br />
<br />
=== Manual configuration of menus ===<br />
<br />
You can edit {{Filename|~/.config/openbox/menu.xml}} with a text editor. Many of the settings are self-explanatory. The article [http://openbox.org/wiki/Help:Menus Help:Menus] has extensive details.<br />
<br />
===Icons in menu===<br />
<br />
Since version 3.5.0 you can have icons next to your menu entries. To do that :<br />
# add <showIcons>yes</showIcons> in the <menu> section of the {{Filename|rc.xml}} file<br />
# edit the menu entries in {{Filename|menu.xml}} and add icons="<path>" like this :<br />
<menu id="apps-menu" label="SomeApp" icon="/home/user/.icons/application.png"><br />
<br />
then openbox --reconfigure or openbox --restart if you have troubles updating the menu :)<br />
<br />
=== MenuMaker ===<br />
<br />
[http://menumaker.sourceforge.net/ MenuMaker] creates XML menus for several window managers including Openbox. MenuMaker searchs your computer for executable programs and creates a menu file from the result. It can be configured to exclude certain application types (GNOME, KDE, etc) if you desire.<br />
# pacman -S menumaker # Install MenuMaker from the repository<br />
<br />
Once installed, generate a menu file (named {{Filename|menu.xml}}) by running the program.<br />
$ mmaker -v OpenBox3 # Will not overwrite an existing menu file.<br />
$ mmaker -vf OpenBox3 # Force option permits overwriting the menu file.<br />
$ mmaker --help # See the full set of options for MenuMaker.<br />
<br />
MenuMaker creates a comprehensive {{Filename|menu.xml}}. You may edit this file by hand or regenerate it after installing software.<br />
<br />
=== Obmenu ===<br />
<br />
Obmenu is a menu editor for Openbox. This GUI application is the best choice for those who dislike editing XML code. Obmenu is available in the community repository:<br />
# pacman -S obmenu<br />
<br />
Once installed, run {{Codeline|obmenu}} then add and remove applications as desired.<br />
<br />
=== openbox-menu ===<br />
<br />
Openbox-menu uses [http://sourceforge.net/projects/lxde/files/menu-cache/ menu-cache] from the LXDE Project to create dynamic menus for Openbox.<br />
<br />
Project homepage here:<br />
[http://mimasgpc.free.fr/openbox-menu_en.html http://mimasgpc.free.fr/openbox-menu_en.html]<br />
<br />
AUR Package here:<br />
[http://aur.archlinux.org/packages.php?ID=31605 http://aur.archlinux.org/packages.php?ID=31605]<br />
<br />
==== Obm-xdg ====<br />
<br />
<tt>obm-xdg</tt> is a command-line tool that comes with Obmenu. It generates a categorized sub-menu of installed GTK/GNOME applications.<br />
<br />
To use obm-xdg with other menus, add the following line to '''{{Filename|~/.config/openbox/menu.xml}}''':<br />
<menu execute="obm-xdg" id="xdg-menu" label="xdg"/><br />
<br />
Then add the following line under your 'root-menu' entry where you want to have the menu appear:<br />
<menu id="xdg-menu"/><br />
<br />
To use obm-xdg by itself create '''{{Filename|~/.config/openbox/menu.xml}}''' and add these lines:<br />
<openbox_menu><br />
<menu execute="obm-xdg" id="root-menu" label="apps"/><br />
</openbox_menu><br />
<br />
<br />
Then run {{Codeline|openbox --reconfigure}} to refresh the Openbox menu. You should now see a sub-menu labeled '''xdg''' in your menu.<br />
<br />
{{Note|If you do not have GNOME installed, you need to install package '''gnome-menus''' for obm-xdg.}}<br />
<br />
=== Python-based xdg menu script ===<br />
<br />
This script is found in Fedora's Openbox package. You have only to put the script somewhere and create a menu entry.<br />
<br />
Here is the head: [http://pkgs.fedoraproject.org/gitweb/?p=openbox.git;f=xdg-menu;hb=HEAD latest script]<br />
<br />
Download from above repository. Place the file into the directory you want.<br />
<br />
Open '''{{Filename|menu.xml}}''' with your text editor and add the following entry. Of course, you can modify the label as you see fit.<br />
<menu id="apps-menu" label="xdg-menu" execute="python2 <path>/xdg-menu"/><br />
<br />
Save the file and run '''{{Codeline|openbox --reconfigure}}'''.<br />
<br />
{{Note|If you do not have GNOME installed, you need to install package '''gnome-menus''' for xdg-menu.}}<br />
<br />
=== Openbox menu generator ===<br />
<br />
Residing in the AUR as [http://aur.archlinux.org/packages.php?ID=27300 obmenugen-bin,] Openbox menu generator creates the menu file from *.desktop files. Obmenugen provides a text file which filters (hides) menu items using basic regex.<br />
$ obmenugen # Create a menu file<br />
$ openbox --reconfigure # To see the menu you generated<br />
<br />
=== Pipe menus ===<br />
<br />
Like other window managers, Openbox allows for scripts to dynamically build menus (menus on-the-fly). Examples are system monitors, media player controls, or weather monitors. Pipe menu script examples are found in the [http://openbox.org/wiki/Openbox:Pipemenus Openbox:Pipemenus] page at Openbox's site.<br />
<br />
User ''Xyne'' created a pipe menu file browser and user ''brisbin33'' created a pipe menu for scanning and connecting to wireless hot spots (using netcfg). Forum posts for these utilities are here: [http://bbs.archlinux.org/viewtopic.php?id=77197&p=1 file browser] and here: [http://bbs.archlinux.org/viewtopic.php?id=78290 wifi].<br />
<br />
User ''jnguyen'' created a pipe menu for managing removable devices using Udisks. The forum post is here: [https://bbs.archlinux.org/viewtopic.php?id=114702 obdevicemenu].<br />
<br />
== Startup programs ==<br />
<br />
Openbox supports running programs at startup. This is provided by command '''openbox-session'''.<br />
<br />
=== Enabling autostart ===<br />
<br />
There are two ways to enable autostart:<br />
# When using startx or xinit to begin a session, edit {{Filename|~/.xinitrc}}. Change the line that executes '''''openbox''''' to '''openbox-session'''.<br />
# When using GDM or KDM, selecting an ''Openbox'' session automatically runs the autostart script.<br />
<br />
=== Autostart script ===<br />
<br />
Openbox executes a user startup script located at {{Filename|~/.config/openbox/autostart}}. This script is ''not'' created by default. In the absence of a user startup script, openbox executes the system startup script {{Filename|/etc/xdg/openbox/autostart}}. The system script does not run when the user script is present.<br />
<br />
To create a personal startup script, copy the system script to your settings directory {{Filename|~/.config/openbox/}} and append your commands. This ensures your environment is properly configured.<br />
<br />
Full instructions are available from the [http://openbox.org/wiki/Help:Autostart Help:Autostart] article at the Openbox site.<br />
<br />
{{Note|This file used to be called autostart.sh before OpenBox 3.5.0. If you are upgrading, be sure you rename your copy of the file to remove the .sh from the end, or it will stop being read.}}<br />
<br />
== Themes and appearance ==<br />
<br />
:{{Box YELLOW||The supplemental article '''[[Openbox_Themes_and_Apps|Openbox Themes and Apps]]''' has detailed information about changing Openbox's GUI.}}<br />
<br />
You probably installed a selection of Linux programs that were developed using different toolkits. Configuration settings for a given program may reside in an unexpected location.<br />
<br />
For example, the double-click setting used by [http://www.geany.org/ Geany] (an editor/IDE) is set within the file '''{{Filename|~/.gtkrc-2.0,}}''' not where you might expect in '''{{Filename|~/.config/openbox/rc.xml}}'''. Some visual aspects of Geany are set by .gtkrc-2.0 as well.<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Themes_and_appearance|Openbox Themes and Apps]] for visual theming information.<br />
<br />
=== Openbox themes ===<br />
<br />
Themes control the appearance of windows, titlebars, and buttons. They also control menu appearance and on-screen display (OSD). Additional themes are available from the standard repositories.<br />
# pacman -S openbox-themes<br />
<br />
=== Cursors, icons, wallpaper ===<br />
<br />
Please see [[Openbox_Themes_and_Apps#X11_Mouse_cursors|Openbox Themes and Apps]] for information on these GUI customizations.<br />
<br />
== Recommended programs ==<br />
:{{Box YELLOW||The supplemental wiki article '''[[Openbox_Themes_and_Apps#Recommended_programs|Openbox Themes and Apps]]''' has information on applications you may use with Openbox.<br>The article gives details about panels, trays, mixer controls, and other widgets used on a desktop interface.}}<br />
<br />
There is a list of [[Lightweight_Applications|Lightweight Applications]] in the wiki. Most of these work nicely with Openbox.<br />
<br />
=== Login managers ===<br />
<br />
[http://slim.berlios.de/ SLiM] is a graphical login manager. It works for standalone Openbox configurations. Refer to the [[SLiM]] wiki article for instructions.<br />
<br />
[http://qingy.sourceforge.net/ Qingy] is a light, highly-configurable graphical login manager. It supports login to either text console or X session. Qingy uses [http://www.directfb.org DirectFB]. Qingy does not start an X session unless you choose a session that uses X Windows. Read the Arch wiki article about [[Qingy|Qingy.]]<br />
<br />
=== Compositing the desktop view ===<br />
<br />
[[Xcompmgr]] is a compositing window manager capable of rendering drop shadows, fading, and window transparency for Openbox and other window managers.<br />
Note that xcompmgr is no longer being developed. Any problems are unlikely to be fixed. (For example, Xcompmgr has shown a problem with ''tint2 0.9'': systray icons have a tendency to become corrupted.)<br />
<br />
[[Cairo Compmgr]] is a versatile compositing window manager that uses [http://en.wikipedia.org/wiki/Cairo_(software) Cairo] for rendering. It is usually the better choice.<br />
<br />
=== Panels, trays, pagers ===<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Panels, trays, pagers|Openbox Themes and Apps]] to learn about these GUI embellishments for Openbox.<br />
<br />
=== File managers ===<br />
<br />
Three popular lightweight file managers are:<br />
* [[Thunar]]. Thunar supports auto-mount features and other plugins. <br />
# pacman -S thunar<br />
* [http://rox.sourceforge.net ROX] (ROX provides desktop icons)<br />
# pacman -S rox<br />
* [http://pcmanfm.sourceforge.net PCManFM]<br />
# pacman -S pcmanfm # PcManFM package also provides desktop icons.<br />
# pacman -S ntfs-3g # Allows PCManFM to access NTFS drives.<br />
<br />
More information is found at [[Openbox_Themes_and_Apps#File_managers|Openbox Themes and Apps]]. The supplemental article has further information about application launchers such as [http://sourceforge.net/projects/gmrun gmrun], clipboard managers, volume mixers, and more.<br />
<br />
== Tips and tricks ==<br />
<br />
=== File associations ===<br />
Because Openbox and the applications you use with it are not well-integrated you might run into the issues with your browser. Your browser may not know which program it is supposed to use for certain types of files.<br />
<br />
A package in the AUR called [http://aur.archlinux.org/packages.php?ID=23170 gnome-defaults-list] contains a list of file-types and programs specific to the Gnome desktop. The list is installed to {{Filename|/etc/gnome/defaults.list.}}<br />
<br />
Open this file with your text-editor. Now you can replace a given application with the name of the program of your choosing. For example, totem <=> vlc or eog <=> mirage. Save the file to {{Filename|~/.local/share/applications/defaults.list}}.<br />
<br />
Another way of setting file associations is to install package ''perl-file-mimeinfo'' from the repository and invoke '''mimeopen''' like this:<br />
mimeopen -d /path/to/file<br />
You are asked which application to use when opening /path/to/file:<br />
Please choose a default application for files of type text/plain<br />
1) notepad (wine-extension-txt)<br />
2) Leafpad (leafpad)<br />
3) OpenOffice.org Writer (writer)<br />
4) gVim (gvim)<br />
5) Other...<br />
Your answer becomes the default handler for that type of file. Mimeopen is installed as {{Filename|/usr/bin/perlbin/vendor/mimetype}}.<br />
<br />
=== Copy and paste ===<br />
<br />
From a terminal '''Ctrl+Insert''' for copy and '''Shift+Insert''' for paste.<br />
<br />
Also '''Ctrl+Shift+C''' for copy and '''mouse middle-click''' for paste (in terminals).<br />
<br />
Other applications most likely use the conventional keyboard shortcuts for copy and paste.<br />
<br />
=== Window transparency ===<br />
<br />
The program transset-df (virtually the same as ''transset'') is installed with pacman -S transset-df. With transset-df you can enable window-transparency on-the-fly.<br />
<br />
For instance by placing the following in {{Filename|~/.config/openbox/rc.xml}} you can have your mouse adjust window transparency by scrolling while hovering over the title bar (it is in the <mouse> section):<br />
<br />
<context name="Titlebar"><br />
. . .<br />
<mousebind button="Up" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --inc </execute><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --dec </execute><br />
</action><br />
</mousebind><br />
. . .<br />
</context><br />
It appears to work only when no additional actions are defined within the action group.<br />
<br />
=== Xprop values for applications ===<br />
If you use per-application settings frequently, you might find this bash alias handy:<br />
<br />
alias xp='xprop | grep "WM_WINDOW_ROLE\|WM_CLASS" && echo "WM_CLASS(STRING) = \"NAME\", \"CLASS\""'<br />
<br />
To use, run '''{{Codeline|xp}}''' and click on the running program that you would like to define with per-app settings. The result displays only the info that Openbox requires, namely the WM_WINDOW_ROLE and WM_CLASS (name and class) values:<br />
<br />
[thayer@dublin:~] $ xp<br />
WM_WINDOW_ROLE(STRING) = "roster"<br />
WM_CLASS(STRING) = "gajim.py", "Gajim.py"<br />
WM_CLASS(STRING) = "NAME", "CLASS"<br />
<br />
==== Xprop for Firefox ====<br />
<br />
For whatever reason, Firefox and like-minded equivalents ignore application rules (e.g. <desktop>) unless {{Codeline|class&#61;"Firefox*"}} is used. This applies irrespective of whatever values xprop may report for the program's WM_CLASS.<br />
<br />
=== Linking the menu to a button ===<br />
<br />
Some people want to link the Openbox menu (or any menu) to an object. This is useful for creating a panel button to pop up a menu. Although Openbox does not provide this, a program called '''xdotool''' simulates a keypress. Openbox can be configured to bind that keypress to the ''ShowMenu'' action.<br />
<br />
Package [http://aur.archlinux.org/packages.php?do_Details=1&ID=14789&O=0&L=0&C=0&K=xdotool&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd xdotool] is available in the AUR. After installing ''xdotool'', add the following to the <keyboard> section of your '''{{Filename|rc.xml}}''':<br />
<keybind key="A-C-q"><br />
<action name="ShowMenu"><br />
<menu>root-menu</menu><br />
</action><br />
</keybind><br />
Restart/reconfigure Openbox. The following command summons a menu at your cursor position. The command may given as-is, linked to an object, or placed in a script.<br />
$ xdotool key ctrl+alt+q<br />
<br />
Of course, change the key shortcut to your liking. Here is a snippet from a '''tint2''' (a taskbar-like panel) configuration file which pops up a menu when the clock area is clicked. Each key combination is set to open a menu within openbox's '''{{Filename|rc.xml}}''' configuration file. The right‑click menu is different from the left‑click menu:<br />
clock_rclick_command = xdotool key --clearmodifiers "ctrl+XF86PowerOff"<br />
clock_lclick_command = xdotool key --clearmodifiers "alt+XF86PowerOff"<br />
<br />
=== Urxvt in the background ===<br />
<br />
With Openbox, running a terminal as desktop background is easy. You will not need '''devilspie''' here.<br />
<br />
First you must enable transparency, open your {{Filename|.Xdefaults}} file (if it does not exist yet, create it in your home folder).<br />
URxvt*transparent:true<br />
URxvt*scrollBar:false<br />
URxvt*geometry:124x24 #I do not use the whole screen, if you want a full screen term do not bother with this and see below.<br />
URxvt*borderLess:true<br />
URxvt*foreground:Black #Font color. My wallpaper is White, you may wish to change this to White.<br />
<br />
Then edit your {{Filename|.config/openbox/rc.xml}} file:<br />
<application name="URxvt"><br />
<decor>no</decor><br />
<focus>yes</focus><br />
<position><br />
<x>center</x><br />
<y>20</y><br />
</position><br />
<layer>below</layer><br />
<desktop>all</desktop><br />
<maximized>true</maximized> #Only if you want a full size terminal.<br />
</application><br />
<br />
The ''magic'' comes from the {{Codeline|<layer>below</layer>}} line, which place the application under all others. Here Urxvt is displayed on all desktops, change it to your convenience.<br />
<br />
Note: Instead of using <application name="URxvt">, you can use another name ("URxvt-bg" for example), and use the -name option when starting uxrvt. That way, only the urxvt terminals which you choose to name URxvt-bg would be captured and modified by the application rule in rc.xml. For example: urxvt -name URxvt-bg (case sensitive)<br />
<br />
====ToggleShowDesktop exception====<br />
<br />
Above method still minimizes Urxvt when using the ToggleShowDesktop command. A method for avoiding this is explained in this [https://bbs.archlinux.org/viewtopic.php?pid=865844#p865844 forum post]. This involves editing Urxvt's source code.<br />
<br />
=== Keyboard volume control ===<br />
<br />
If you use ALSA for sound, you can use the amixer program to adjust the volume of sound. You can use Openbox's keybindings to act like multimedia keys. (Alternatively, you can probably find out the names of your real multimedia keys and map them.) For example, in the <keyboard> section of rc.xml:<br />
<br />
<keybind key="W-Up"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+</command><br />
</action><br />
</keybind><br />
<br />
This binds Windows key + Up arrow to increase your master ALSA volume by 5%. Corresponding binding for volume down:<br />
<br />
<keybind key="W-Down"><br />
<action name="Execute"><br />
<command>amixer set Master 5%-</command><br />
</action><br />
</keybind><br />
<br />
As another example you can also use the XF86Audio keybindings:<br />
<br />
<keybind key="XF86AudioRaiseVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+ unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioLowerVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%- unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioMute"><br />
<action name="Execute"><br />
<command>amixer set Master toggle</command><br />
</action><br />
</keybind><br />
<br />
The above example should work for the majority of multimedia keyboards. It should enable to raise, lower and mute the Master control of your audio device by using the respective multimedia keyboard keys. Notice also that in this example:<br />
<br />
* The "Mute" key should unmute the Master control if it is already in mute mode.<br />
* The "Raise" and "Lower" keys should unmute the Master control if it is in mute mode.<br />
<br />
== Troubleshooting Openbox 3.5 ==<br />
=== X server crashes ===<br />
Problems have been detected after upgrade to ver. 3.5, that the X server might crash in attempt to start openbox, ending with similar error message:<br />
(metacity:25137): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process \<br />
was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit \<br />
status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request \<br />
the exit status, or don't set the SIGCHLD action.<br />
xinit: connection to X server lost<br />
waiting for X server to shut down<br />
In this particular case, some problem with metacity package has been identified as the cause of the X server crash issue. Removal of metacity & compiz-decorator-gtk packages solved the problem. Though, later was found, that even a simple reinstall of packages might have helped, as there is no problem after new installation of previously removed packages.<br />
<br />
Also, plenty of similar cases have been found on the Internet, that not only metacity package might be causing the X server to crash.<br />
Thus, whatever else instead of metacity you get in the error output message, try to reinstall it (or remove if necessary) in an attempt to get rid of this X server crash.<br />
<br />
=== Autostarting unwanted applications in 3.5 ===<br />
Unwanted applications do start with your Openbox session, though they are not listed in your ~/.config/openbox/autostart script?<br />
<br />
Check the ~/.config/autostart/ directory, it might contain the residues from your previously used desktop environment (Gnome, KDE, etc.), and remove unwanted files.<br />
<br />
=== SSH agent no longer starting ===<br />
Whereas Openbox 3.4.x allowed launching an SSH agent from $XDG_CONFIG_HOME/openbox/autostart{,.sh}, with 3.5 that no longer seems to work. You need to put your code in $XDG_CONFIG_HOME/openbox/environment, e.g.:<br />
<br />
<pre><br />
SSHAGENT="/usr/bin/ssh-agent"<br />
SSHAGENTARGS="-s"<br />
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then<br />
eval `$SSHAGENT $SSHAGENTARGS`<br />
trap "kill $SSH_AGENT_PID" 0<br />
fi<br />
</pre><br />
<br />
=== Openbox not registering with D-Bus ===<br />
Just like with SSH agent, lots of people used to have D-Bus code in $XDG_CONFIG_HOME/openbox/autostart{,.sh} - which no longer works (e.g. Thunar doesn't see any removable devices anymore).<br />
<br />
The fix is to move the code to $XDG_CONFIG_HOME/openbox/environment:<br />
<pre><br />
if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then<br />
eval `dbus-launch --sh-syntax --exit-with-session`<br />
fi<br />
</pre><br />
<br />
Alternatively you can call openbox-session with dbus-launch in e.g. ~/.xinitrc.<br />
<br />
== Resources ==<br />
<br />
* [http://openbox.org/ Openbox Website] &ndash; The official website<br />
* [http://planetob.openmonkey.com/ Planet Openbox] &ndash; Openbox news portal<br />
* [http://www.box-look.org/ Box-Look.org] &ndash; A good resource for themes and related artwork<br />
* [https://bbs.archlinux.org/viewtopic.php?id=93126 Openbox Hacks and Configs Thread] @ Arch Linux Forums<br />
* [https://bbs.archlinux.org/viewtopic.php?id=45692 Openbox Screenshots Thread] @ Arch Linux Forums<br />
* [http://snott.net/linux/using-gnome3-with-openbox/ Installation and configuration tutorial] Using gnome3 with Openbox<br />
<!-- vim: set ft=Wikipedia: --></div>Bhttps://wiki.archlinux.org/index.php?title=Openbox&diff=154591Openbox2011-08-31T06:47:34Z<p>B: Added D-Bus troubleshooting entry</p>
<hr />
<div>[[Category:Stacking WMs (English)]]<br />
{{i18n|Openbox}}<br />
<br />
Openbox is a lightweight and highly configurable window manager with extensive standards support. Its features are documented at the [http://openbox.org/ official website]. This article pertains to installing Openbox under Arch Linux.<br />
<br />
== Installation ==<br />
<br />
{{Package Official|openbox}} is available from the community repository:<br />
# pacman -S openbox<br />
<br />
After installation, you should copy the default configuration files {{Filename|rc.xml}}, {{Filename|menu.xml}}, {{Filename|autostart}}, and {{Filename|environment}} to {{Filename|~/.config/openbox}}:<br />
<br />
{{Note | Do this as a regular user, not as root.}}<br />
<br />
$ mkdir -p ~/.config/openbox<br />
$ cp /etc/xdg/openbox/{rc.xml,menu.xml,autostart,environment} ~/.config/openbox<br />
<br />
{{Filename|rc.xml}} is the main configuration file. It defines keyboard shortcuts, themes, virtual desktops, and more.<br />
<br />
{{Filename|menu.xml}} defines the content of the right-click menu. It defines launchers for applications and other shortcuts. See the [[#Menus]] section.<br />
<br />
{{Filename|autostart}} is read by openbox-session at startup. It contains the programs that are run at startup. It is typically used to set environment variables, launch panels/docks, set background image or execute other startup scripts. See the [http://openbox.org/wiki/Help:Autostart Openbox Wiki].<br />
<br />
{{Filename|environment}} is sourced by openbox-session at startup. It contains environment variables to be set in Openbox's context. Any variables you set here will be visible to Openbox itself and anything you start from its menus.<br />
<br />
== Upgrading to Openbox 3.5 ==<br />
<br />
If you are upgrading to Openbox 3.5 or later from an earlier release, be aware of these changes:<br />
<br />
* There is a new config file called {{Filename|environment}} that you should copy from /etc/xdg/openbox to ~/.config/openbox .<br />
* The config file previously called {{Filename|autostart.sh}} is now just called {{Filename|autostart}}. You should rename yours to remove the .sh from the end of the name.<br />
* Some of the configuration grammar in {{Filename|rc.xml}} has changed. While Openbox appears to understand the old options, it would be wise to compare your configuration to the one in /etc/xdg/openbox and look for changes that affect you.<br />
<br />
=== Troubleshooting 3.5 ===<br />
See the [[#Troubleshooting_Openbox_3.5|Troubleshooting Openbox 3.5]] section below.<br />
<br />
== Openbox as a stand-alone WM ==<br />
<br />
Openbox can be used as a stand-alone window manager (WM). This is usually simpler to install and configure than using Openbox with desktop environments. Running openbox alone may reduce your system's CPU and memory load.<br />
<br />
To run Openbox as a stand-alone window manager, append the following to '''{{Filename|~/.xinitrc}}''':<br />
exec openbox-session<br />
<br />
You may also start Openbox from the command shell (aka: text prompt) using '''xinit''':<br />
$ xinit /usr/bin/openbox-session<br />
<br />
If you used another window manager previously (such as Xfwm) and now Openbox will not start after logging out of X, try moving the autostart folder:<br />
mv ~/.config/autostart ~/.config/autostart-bak<br />
<br />
Using Consolekit, use this instead:<br />
exec ck-launch-session openbox-session<br />
<br />
If you also use '''polkit''' and '''D-Bus''' (e.g. for auto-mount drivers in Nautilus/Gnome) use:<br />
exec ck-launch-session dbus-launch openbox-session<br />
<br />
{{Note | [http://www.archlinux.org/packages/extra/any/pyxdg/ pyxdg] is required for Openbox's xdg-autostart}}<br />
{{Note | "dbus-launch" must be placed after "ck-launch-session" or you will experience mounting problems}}<br />
<br />
== Openbox as a WM for desktop environments ==<br />
<br />
Openbox can be used as a replacement window manager for full-fledged desktop environments. The method for deploying Openbox depends on the desktop environment.<br />
<br />
=== GNOME 2.24 and 2.26 ===<br />
Create {{Filename|/usr/share/applications/openbox.desktop}} with the following lines:<br />
[Desktop Entry]<br />
Type=Application<br />
Encoding=UTF-8<br />
Name=OpenBox<br />
Exec=openbox<br />
NoDisplay=true<br />
# name of loadable control center module<br />
X-GNOME-WMSettingsModule=openbox<br />
# name we put on the WM spec check window<br />
X-GNOME-WMName=OpenBox<br />
In gconf, set '''{{Codeline|/desktop/gnome/session/required_components/windowmanager}}''' to '''{{Codeline|openbox}}:'''<br />
$ gconftool-2 -s -t string /desktop/gnome/session/required_components/windowmanager openbox<br />
Finally, choose '''GNOME''' session from the GDM sessions menu.<br />
<br />
=== GNOME 2.26 Redux ===<br />
'''''If the previous guide for GNOME 2.24 fails:'''''<br />
<br />
If, when attempting to log into a "Gnome/Openbox" session -- and it consistently fails to start, try the following. This is one way of achieving your goal of using Openbox as the WM anytime you open a Gnome session:<br />
<br />
#Log into your Gnome-only session (it should still be using Metacity as its window manager).<br />
#Install Openbox if you have not done so already<br />
#Navigate your menus to ''System &rarr; Preferences &rarr; Startup Applications'' (possibly named 'Session' in older Gnome versions)<br />
#Open Startup Application, select '+ Add' and enter the text shown below. Omit the text after #.<br />
#Click the 'Add' button for the data entry window. Make sure the checkbox beside your new entry is selected.<br />
#Log out from your Gnome session and log back in<br />
#You should now be running openbox as your window manager.<br />
<br />
Name: Openbox Windox Manager # Can be changed<br />
Command: openbox --replace # Text should not be removed from this line, but possibly added to it<br />
Comment: Replaces metacity with openbox # Can be changed<br />
<br />
This creates a startup list entry which is executed by Gnome each time the user's session is started.<br />
<br />
=== GNOME 2.22 and prior ===<br />
# If you use GDM, select the "GNOME/Openbox" login option<br />
# If you use {{Codeline|startx}}, add {{Codeline|exec openbox-gnome-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-gnome-session<br />
<br />
=== KDE ===<br />
# If you use KDM, select the "KDE/Openbox" login option<br />
# If you use startx, add {{Codeline|exec openbox-kde-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-kde-session<br />
<br />
=== Xfce4 ===<br />
Log into a normal Xfce4 session. From your terminal, type:<br />
$ killall xfwm4 ; openbox & exit<br />
<br />
This kills xfwm4, runs Openbox, and closes the terminal. Log out, being sure to check the ''"Save session for future logins"'' box. On your next login, Xfce4 should use '''Openbox''' as its WM.<br />
<br />
To enable exiting from a session using ''xfce4-session,'' edit '''{{Filename|~/.config/openbox/menu.xml}}'''. If the file is not there, copy it from {{Filename|/etc/xdg/openbox/}}. Look for the following entry:<br />
<item label="Exit Openbox"><br />
<action name="Exit"><br />
<prompt>yes</prompt><br />
</action><br />
</item><br />
<br />
Change it to:<br />
<item label="Exit Openbox"><br />
<action name="Execute"><br />
<prompt>yes</prompt><br />
<command>xfce4-session-logout</command><br />
</action><br />
</item><br />
<br />
Otherwise, choosing "Exit" from the root-menu causes Openbox to terminate its execution, leaving you with no window manager.<br />
<br />
If you have a problem changing virtual desktops with the mouse wheel skipping over desktops, edit '''{{Filename|~/.config/openbox/rc.xml}}'''. Move the ''mouse binds with...'' actions "DesktopPrevious" and "DesktopNext" from context ''Desktop'' to the context ''Root''. (You may need to create a definition for the ''Root'' context as well.)<br />
<br />
When using the Openbox root-menu instead of Xfce's menu, you may exit the Xfdesktop with this terminal command:<br />
$ xfdesktop --quit<br />
Xfdesktop manages the wallpaper and desktop icons, requiring you to use other utilities such as ROX for these functions.<br />
<br />
(When terminating Xfdesktop, the above issue with the virtual desktops is no longer a problem.)<br />
<br />
== Openbox for multihead users ==<br />
<br />
While Openbox provides better than average multihead support on its own, a branch called [http://aur.archlinux.org/packages.php?ID=51460 Openbox Multihead] is now available in the AUR that gives multihead users per-monitor desktops. This model is not commonly found in floating window managers, but exists mainly in tiling window managers. It is explained well on the [http://xmonad.org/tour.html#workspace Xmonad web site]. Also, please see [https://github.com/BurntSushi/openbox-multihead/blob/multihead/README.MULTIHEAD README.MULTIHEAD] for a more comprehensive description of the new features and configuration options found in Openbox Multihead.<br />
<br />
Openbox Multihead will function like normal Openbox when only a single head is available.<br />
<br />
A downside to using Openbox Multihead is that it breaks the EWMH assumption that one and only one desktop is visible at any time. Thus, existing pagers will not work well with it. To remedy this, [http://aur.archlinux.org/packages.php?ID=51536 pager-multihead] can be found in the AUR that is compatible with Openbox Multihead. [http://imgur.com/a/cnZeq#y04nk Screenshots].<br />
<br />
Finally, a new version of [http://aur.archlinux.org/packages.php?ID=51626 pytyle] can also be found in the AUR that will work with Openbox Multihead.<br />
<br />
Both pytyle3 and pager-multihead will work without Openbox Multihead if only one monitor is active.<br />
<br />
== Configuration ==<br />
<br />
There are several options for configuring Openbox settings:<br />
<br />
=== Manual configuration ===<br />
To configure Openbox manually, edit the {{Filename|~/.config/openbox/rc.xml}} file with a text editor. The file has explanatory comments throughout. See the [http://openbox.org/wiki/Help:Configuration Help:Configuration openbox wiki] for more documentation on editing this file.<br />
<br />
=== ObConf ===<br />
[http://openbox.org/wiki/ObConf:About ObConf] is an Openbox configuration tool. It is used to set most common preferences such as themes, virtual desktops, window properties, and desktop margins. It can be installed with pacman:<br />
<br />
# pacman -S obconf<br />
<br />
ObConf cannot configure keyboard shortcuts and certain other features. For these features edit {{Filename|rc.xml}} manually. Alternatively, you can try {{Package AUR|obkey}} from the [[AUR]].<br />
<br />
=== Application customization ===<br />
<br />
Openbox allows per-application customizations. This lets you define rules for a given program. For example:<br />
* Start your web browser on a specific virtual desktop.<br />
* Open your terminal program with no window decorations (window chrome).<br />
* Make your bit-torrent client open at a given screen position.<br />
<br />
Per-application settings are defined in {{Filename|~/.config/openbox/rc.xml}}. Instructions are in the file's comments. More details are found in the [http://openbox.org/wiki/Help:Applications Help:Applications openbox wiki].<br />
<br />
== Menus ==<br />
<br />
The default Openbox menu includes a variety of menu items to get you started. Many of these items launch applications you do not want, have not installed yet, or never intend to install. You will surely want to customize '''{{Filename|menu.xml}}''' at some point. There are a number of ways to do so.<br />
<br />
=== Manual configuration of menus ===<br />
<br />
You can edit {{Filename|~/.config/openbox/menu.xml}} with a text editor. Many of the settings are self-explanatory. The article [http://openbox.org/wiki/Help:Menus Help:Menus] has extensive details.<br />
<br />
===Icons in menu===<br />
<br />
Since version 3.5.0 you can have icons next to your menu entries. To do that :<br />
# add <showIcons>yes</showIcons> in the <menu> section of the {{Filename|rc.xml}} file<br />
# edit the menu entries in {{Filename|menu.xml}} and add icons="<path>" like this :<br />
<menu id="apps-menu" label="SomeApp" icon="/home/user/.icons/application.png"><br />
<br />
then openbox --reconfigure or openbox --restart if you have troubles updating the menu :)<br />
<br />
=== MenuMaker ===<br />
<br />
[http://menumaker.sourceforge.net/ MenuMaker] creates XML menus for several window managers including Openbox. MenuMaker searchs your computer for executable programs and creates a menu file from the result. It can be configured to exclude certain application types (GNOME, KDE, etc) if you desire.<br />
# pacman -S menumaker # Install MenuMaker from the repository<br />
<br />
Once installed, generate a menu file (named {{Filename|menu.xml}}) by running the program.<br />
$ mmaker -v OpenBox3 # Will not overwrite an existing menu file.<br />
$ mmaker -vf OpenBox3 # Force option permits overwriting the menu file.<br />
$ mmaker --help # See the full set of options for MenuMaker.<br />
<br />
MenuMaker creates a comprehensive {{Filename|menu.xml}}. You may edit this file by hand or regenerate it after installing software.<br />
<br />
=== Obmenu ===<br />
<br />
Obmenu is a menu editor for Openbox. This GUI application is the best choice for those who dislike editing XML code. Obmenu is available in the community repository:<br />
# pacman -S obmenu<br />
<br />
Once installed, run {{Codeline|obmenu}} then add and remove applications as desired.<br />
<br />
=== openbox-menu ===<br />
<br />
Openbox-menu uses [http://sourceforge.net/projects/lxde/files/menu-cache/ menu-cache] from the LXDE Project to create dynamic menus for Openbox.<br />
<br />
Project homepage here:<br />
[http://mimasgpc.free.fr/openbox-menu_en.html http://mimasgpc.free.fr/openbox-menu_en.html]<br />
<br />
AUR Package here:<br />
[http://aur.archlinux.org/packages.php?ID=31605 http://aur.archlinux.org/packages.php?ID=31605]<br />
<br />
==== Obm-xdg ====<br />
<br />
<tt>obm-xdg</tt> is a command-line tool that comes with Obmenu. It generates a categorized sub-menu of installed GTK/GNOME applications.<br />
<br />
To use obm-xdg with other menus, add the following line to '''{{Filename|~/.config/openbox/menu.xml}}''':<br />
<menu execute="obm-xdg" id="xdg-menu" label="xdg"/><br />
<br />
Then add the following line under your 'root-menu' entry where you want to have the menu appear:<br />
<menu id="xdg-menu"/><br />
<br />
To use obm-xdg by itself create '''{{Filename|~/.config/openbox/menu.xml}}''' and add these lines:<br />
<openbox_menu><br />
<menu execute="obm-xdg" id="root-menu" label="apps"/><br />
</openbox_menu><br />
<br />
<br />
Then run {{Codeline|openbox --reconfigure}} to refresh the Openbox menu. You should now see a sub-menu labeled '''xdg''' in your menu.<br />
<br />
{{Note|If you do not have GNOME installed, you need to install package '''gnome-menus''' for obm-xdg.}}<br />
<br />
=== Python-based xdg menu script ===<br />
<br />
This script is found in Fedora's Openbox package. You have only to put the script somewhere and create a menu entry.<br />
<br />
Here is the head: [http://pkgs.fedoraproject.org/gitweb/?p=openbox.git;f=xdg-menu;hb=HEAD latest script]<br />
<br />
Download from above repository. Place the file into the directory you want.<br />
<br />
Open '''{{Filename|menu.xml}}''' with your text editor and add the following entry. Of course, you can modify the label as you see fit.<br />
<menu id="apps-menu" label="xdg-menu" execute="python2 <path>/xdg-menu"/><br />
<br />
Save the file and run '''{{Codeline|openbox --reconfigure}}'''.<br />
<br />
{{Note|If you do not have GNOME installed, you need to install package '''gnome-menus''' for xdg-menu.}}<br />
<br />
=== Openbox menu generator ===<br />
<br />
Residing in the AUR as [http://aur.archlinux.org/packages.php?ID=27300 obmenugen-bin,] Openbox menu generator creates the menu file from *.desktop files. Obmenugen provides a text file which filters (hides) menu items using basic regex.<br />
$ obmenugen # Create a menu file<br />
$ openbox --reconfigure # To see the menu you generated<br />
<br />
=== Pipe menus ===<br />
<br />
Like other window managers, Openbox allows for scripts to dynamically build menus (menus on-the-fly). Examples are system monitors, media player controls, or weather monitors. Pipe menu script examples are found in the [http://openbox.org/wiki/Openbox:Pipemenus Openbox:Pipemenus] page at Openbox's site.<br />
<br />
User ''Xyne'' created a pipe menu file browser and user ''brisbin33'' created a pipe menu for scanning and connecting to wireless hot spots (using netcfg). Forum posts for these utilities are here: [http://bbs.archlinux.org/viewtopic.php?id=77197&p=1 file browser] and here: [http://bbs.archlinux.org/viewtopic.php?id=78290 wifi].<br />
<br />
User ''jnguyen'' created a pipe menu for managing removable devices using Udisks. The forum post is here: [https://bbs.archlinux.org/viewtopic.php?id=114702 obdevicemenu].<br />
<br />
== Startup programs ==<br />
<br />
Openbox supports running programs at startup. This is provided by command '''openbox-session'''.<br />
<br />
=== Enabling autostart ===<br />
<br />
There are two ways to enable autostart:<br />
# When using startx or xinit to begin a session, edit {{Filename|~/.xinitrc}}. Change the line that executes '''''openbox''''' to '''openbox-session'''.<br />
# When using GDM or KDM, selecting an ''Openbox'' session automatically runs the autostart script.<br />
<br />
=== Autostart script ===<br />
<br />
Openbox executes a user startup script located at {{Filename|~/.config/openbox/autostart}}. This script is ''not'' created by default. In the absence of a user startup script, openbox executes the system startup script {{Filename|/etc/xdg/openbox/autostart}}. The system script does not run when the user script is present.<br />
<br />
To create a personal startup script, copy the system script to your settings directory {{Filename|~/.config/openbox/}} and append your commands. This ensures your environment is properly configured.<br />
<br />
Full instructions are available from the [http://openbox.org/wiki/Help:Autostart Help:Autostart] article at the Openbox site.<br />
<br />
{{Note|This file used to be called autostart.sh before OpenBox 3.5.0. If you are upgrading, be sure you rename your copy of the file to remove the .sh from the end, or it will stop being read.}}<br />
<br />
== Themes and appearance ==<br />
<br />
:{{Box YELLOW||The supplemental article '''[[Openbox_Themes_and_Apps|Openbox Themes and Apps]]''' has detailed information about changing Openbox's GUI.}}<br />
<br />
You probably installed a selection of Linux programs that were developed using different toolkits. Configuration settings for a given program may reside in an unexpected location.<br />
<br />
For example, the double-click setting used by [http://www.geany.org/ Geany] (an editor/IDE) is set within the file '''{{Filename|~/.gtkrc-2.0,}}''' not where you might expect in '''{{Filename|~/.config/openbox/rc.xml}}'''. Some visual aspects of Geany are set by .gtkrc-2.0 as well.<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Themes_and_appearance|Openbox Themes and Apps]] for visual theming information.<br />
<br />
=== Openbox themes ===<br />
<br />
Themes control the appearance of windows, titlebars, and buttons. They also control menu appearance and on-screen display (OSD). Additional themes are available from the standard repositories.<br />
# pacman -S openbox-themes<br />
<br />
=== Cursors, icons, wallpaper ===<br />
<br />
Please see [[Openbox_Themes_and_Apps#X11_Mouse_cursors|Openbox Themes and Apps]] for information on these GUI customizations.<br />
<br />
== Recommended programs ==<br />
:{{Box YELLOW||The supplemental wiki article '''[[Openbox_Themes_and_Apps#Recommended_programs|Openbox Themes and Apps]]''' has information on applications you may use with Openbox.<br>The article gives details about panels, trays, mixer controls, and other widgets used on a desktop interface.}}<br />
<br />
There is a list of [[Lightweight_Applications|Lightweight Applications]] in the wiki. Most of these work nicely with Openbox.<br />
<br />
=== Login managers ===<br />
<br />
[http://slim.berlios.de/ SLiM] is a graphical login manager. It works for standalone Openbox configurations. Refer to the [[SLiM]] wiki article for instructions.<br />
<br />
[http://qingy.sourceforge.net/ Qingy] is a light, highly-configurable graphical login manager. It supports login to either text console or X session. Qingy uses [http://www.directfb.org DirectFB]. Qingy does not start an X session unless you choose a session that uses X Windows. Read the Arch wiki article about [[Qingy|Qingy.]]<br />
<br />
=== Compositing the desktop view ===<br />
<br />
[[Xcompmgr]] is a compositing window manager capable of rendering drop shadows, fading, and window transparency for Openbox and other window managers.<br />
Note that xcompmgr is no longer being developed. Any problems are unlikely to be fixed. (For example, Xcompmgr has shown a problem with ''tint2 0.9'': systray icons have a tendency to become corrupted.)<br />
<br />
[[Cairo Compmgr]] is a versatile compositing window manager that uses [http://en.wikipedia.org/wiki/Cairo_(software) Cairo] for rendering. It is usually the better choice.<br />
<br />
=== Panels, trays, pagers ===<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Panels, trays, pagers|Openbox Themes and Apps]] to learn about these GUI embellishments for Openbox.<br />
<br />
=== File managers ===<br />
<br />
Three popular lightweight file managers are:<br />
* [[Thunar]]. Thunar supports auto-mount features and other plugins. <br />
# pacman -S thunar<br />
* [http://rox.sourceforge.net ROX] (ROX provides desktop icons)<br />
# pacman -S rox<br />
* [http://pcmanfm.sourceforge.net PCManFM]<br />
# pacman -S pcmanfm # PcManFM package also provides desktop icons.<br />
# pacman -S ntfs-3g # Allows PCManFM to access NTFS drives.<br />
<br />
More information is found at [[Openbox_Themes_and_Apps#File_managers|Openbox Themes and Apps]]. The supplemental article has further information about application launchers such as [http://sourceforge.net/projects/gmrun gmrun], clipboard managers, volume mixers, and more.<br />
<br />
== Tips and tricks ==<br />
<br />
=== File associations ===<br />
Because Openbox and the applications you use with it are not well-integrated you might run into the issues with your browser. Your browser may not know which program it is supposed to use for certain types of files.<br />
<br />
A package in the AUR called [http://aur.archlinux.org/packages.php?ID=23170 gnome-defaults-list] contains a list of file-types and programs specific to the Gnome desktop. The list is installed to {{Filename|/etc/gnome/defaults.list.}}<br />
<br />
Open this file with your text-editor. Now you can replace a given application with the name of the program of your choosing. For example, totem <=> vlc or eog <=> mirage. Save the file to {{Filename|~/.local/share/applications/defaults.list}}.<br />
<br />
Another way of setting file associations is to install package ''perl-file-mimeinfo'' from the repository and invoke '''mimeopen''' like this:<br />
mimeopen -d /path/to/file<br />
You are asked which application to use when opening /path/to/file:<br />
Please choose a default application for files of type text/plain<br />
1) notepad (wine-extension-txt)<br />
2) Leafpad (leafpad)<br />
3) OpenOffice.org Writer (writer)<br />
4) gVim (gvim)<br />
5) Other...<br />
Your answer becomes the default handler for that type of file. Mimeopen is installed as {{Filename|/usr/bin/perlbin/vendor/mimetype}}.<br />
<br />
=== Copy and paste ===<br />
<br />
From a terminal '''Ctrl+Insert''' for copy and '''Shift+Insert''' for paste.<br />
<br />
Also '''Ctrl+Shift+C''' for copy and '''mouse middle-click''' for paste (in terminals).<br />
<br />
Other applications most likely use the conventional keyboard shortcuts for copy and paste.<br />
<br />
=== Window transparency ===<br />
<br />
The program transset-df (virtually the same as ''transset'') is installed with pacman -S transset-df. With transset-df you can enable window-transparency on-the-fly.<br />
<br />
For instance by placing the following in {{Filename|~/.config/openbox/rc.xml}} you can have your mouse adjust window transparency by scrolling while hovering over the title bar (it is in the <mouse> section):<br />
<br />
<context name="Titlebar"><br />
. . .<br />
<mousebind button="Up" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --inc </execute><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --dec </execute><br />
</action><br />
</mousebind><br />
. . .<br />
</context><br />
It appears to work only when no additional actions are defined within the action group.<br />
<br />
=== Xprop values for applications ===<br />
If you use per-application settings frequently, you might find this bash alias handy:<br />
<br />
alias xp='xprop | grep "WM_WINDOW_ROLE\|WM_CLASS" && echo "WM_CLASS(STRING) = \"NAME\", \"CLASS\""'<br />
<br />
To use, run '''{{Codeline|xp}}''' and click on the running program that you would like to define with per-app settings. The result displays only the info that Openbox requires, namely the WM_WINDOW_ROLE and WM_CLASS (name and class) values:<br />
<br />
[thayer@dublin:~] $ xp<br />
WM_WINDOW_ROLE(STRING) = "roster"<br />
WM_CLASS(STRING) = "gajim.py", "Gajim.py"<br />
WM_CLASS(STRING) = "NAME", "CLASS"<br />
<br />
==== Xprop for Firefox ====<br />
<br />
For whatever reason, Firefox and like-minded equivalents ignore application rules (e.g. <desktop>) unless {{Codeline|class&#61;"Firefox*"}} is used. This applies irrespective of whatever values xprop may report for the program's WM_CLASS.<br />
<br />
=== Linking the menu to a button ===<br />
<br />
Some people want to link the Openbox menu (or any menu) to an object. This is useful for creating a panel button to pop up a menu. Although Openbox does not provide this, a program called '''xdotool''' simulates a keypress. Openbox can be configured to bind that keypress to the ''ShowMenu'' action.<br />
<br />
Package [http://aur.archlinux.org/packages.php?do_Details=1&ID=14789&O=0&L=0&C=0&K=xdotool&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd xdotool] is available in the AUR. After installing ''xdotool'', add the following to the <keyboard> section of your '''{{Filename|rc.xml}}''':<br />
<keybind key="A-C-q"><br />
<action name="ShowMenu"><br />
<menu>root-menu</menu><br />
</action><br />
</keybind><br />
Restart/reconfigure Openbox. The following command summons a menu at your cursor position. The command may given as-is, linked to an object, or placed in a script.<br />
$ xdotool key ctrl+alt+q<br />
<br />
Of course, change the key shortcut to your liking. Here is a snippet from a '''tint2''' (a taskbar-like panel) configuration file which pops up a menu when the clock area is clicked. Each key combination is set to open a menu within openbox's '''{{Filename|rc.xml}}''' configuration file. The right‑click menu is different from the left‑click menu:<br />
clock_rclick_command = xdotool key --clearmodifiers "ctrl+XF86PowerOff"<br />
clock_lclick_command = xdotool key --clearmodifiers "alt+XF86PowerOff"<br />
<br />
=== Urxvt in the background ===<br />
<br />
With Openbox, running a terminal as desktop background is easy. You will not need '''devilspie''' here.<br />
<br />
First you must enable transparency, open your {{Filename|.Xdefaults}} file (if it does not exist yet, create it in your home folder).<br />
URxvt*transparent:true<br />
URxvt*scrollBar:false<br />
URxvt*geometry:124x24 #I do not use the whole screen, if you want a full screen term do not bother with this and see below.<br />
URxvt*borderLess:true<br />
URxvt*foreground:Black #Font color. My wallpaper is White, you may wish to change this to White.<br />
<br />
Then edit your {{Filename|.config/openbox/rc.xml}} file:<br />
<application name="URxvt"><br />
<decor>no</decor><br />
<focus>yes</focus><br />
<position><br />
<x>center</x><br />
<y>20</y><br />
</position><br />
<layer>below</layer><br />
<desktop>all</desktop><br />
<maximized>true</maximized> #Only if you want a full size terminal.<br />
</application><br />
<br />
The ''magic'' comes from the {{Codeline|<layer>below</layer>}} line, which place the application under all others. Here Urxvt is displayed on all desktops, change it to your convenience.<br />
<br />
Note: Instead of using <application name="URxvt">, you can use another name ("URxvt-bg" for example), and use the -name option when starting uxrvt. That way, only the urxvt terminals which you choose to name URxvt-bg would be captured and modified by the application rule in rc.xml. For example: urxvt -name URxvt-bg (case sensitive)<br />
<br />
====ToggleShowDesktop exception====<br />
<br />
Above method still minimizes Urxvt when using the ToggleShowDesktop command. A method for avoiding this is explained in this [https://bbs.archlinux.org/viewtopic.php?pid=865844#p865844 forum post]. This involves editing Urxvt's source code.<br />
<br />
=== Keyboard volume control ===<br />
<br />
If you use ALSA for sound, you can use the amixer program to adjust the volume of sound. You can use Openbox's keybindings to act like multimedia keys. (Alternatively, you can probably find out the names of your real multimedia keys and map them.) For example, in the <keyboard> section of rc.xml:<br />
<br />
<keybind key="W-Up"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+</command><br />
</action><br />
</keybind><br />
<br />
This binds Windows key + Up arrow to increase your master ALSA volume by 5%. Corresponding binding for volume down:<br />
<br />
<keybind key="W-Down"><br />
<action name="Execute"><br />
<command>amixer set Master 5%-</command><br />
</action><br />
</keybind><br />
<br />
As another example you can also use the XF86Audio keybindings:<br />
<br />
<keybind key="XF86AudioRaiseVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+ unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioLowerVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%- unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioMute"><br />
<action name="Execute"><br />
<command>amixer set Master toggle</command><br />
</action><br />
</keybind><br />
<br />
The above example should work for the majority of multimedia keyboards. It should enable to raise, lower and mute the Master control of your audio device by using the respective multimedia keyboard keys. Notice also that in this example:<br />
<br />
* The "Mute" key should unmute the Master control if it is already in mute mode.<br />
* The "Raise" and "Lower" keys should unmute the Master control if it is in mute mode.<br />
<br />
== Troubleshooting Openbox 3.5 ==<br />
=== X server crashes ===<br />
Problems have been detected after upgrade to ver. 3.5, that the X server might crash in attempt to start openbox, ending with similar error message:<br />
(metacity:25137): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process \<br />
was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit \<br />
status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request \<br />
the exit status, or don't set the SIGCHLD action.<br />
xinit: connection to X server lost<br />
waiting for X server to shut down<br />
In this particular case, some problem with metacity package has been identified as the cause of the X server crash issue. Removal of metacity & compiz-decorator-gtk packages solved the problem. Though, later was found, that even a simple reinstall of packages might have helped, as there is no problem after new installation of previously removed packages.<br />
<br />
Also, plenty of similar cases have been found on the Internet, that not only metacity package might be causing the X server to crash.<br />
Thus, whatever else instead of metacity you get in the error output message, try to reinstall it (or remove if necessary) in an attempt to get rid of this X server crash.<br />
<br />
=== Autostarting unwanted applications in 3.5 ===<br />
Unwanted applications do start with your Openbox session, though they are not listed in your ~/.config/openbox/autostart script?<br />
<br />
Check the ~/.config/autostart/ directory, it might contain the residues from your previously used desktop environment (Gnome, KDE, etc.), and remove unwanted files.<br />
<br />
=== SSH agent no longer starting ===<br />
Whereas Openbox 3.4.x allowed launching an SSH agent from autostart.sh, with 3.5 that no longer seems to work. You need to put your code in $XDG_CONFIG_HOME/openbox/environment, e.g.:<br />
<br />
<pre><br />
SSHAGENT="/usr/bin/ssh-agent"<br />
SSHAGENTARGS="-s"<br />
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then<br />
eval `$SSHAGENT $SSHAGENTARGS`<br />
trap "kill $SSH_AGENT_PID" 0<br />
fi<br />
</pre><br />
<br />
=== Openbox not registering with D-Bus ===<br />
Just like with SSH agent, lots of people used to have D-Bus code in $XDG_CONFIG_HOME/openbox/autostart{,.sh} - which no longer works (e.g. Thunar doesn't see any removable devices anymore).<br />
<br />
The fix is to move the code to $XDG_CONFIG_HOME/openbox/environment:<br />
<pre><br />
if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then<br />
eval `dbus-launch --sh-syntax --exit-with-session`<br />
fi<br />
</pre><br />
<br />
Alternatively you can call openbox-session with dbus-launch in e.g. ~/.xinitrc.<br />
<br />
== Resources ==<br />
<br />
* [http://openbox.org/ Openbox Website] &ndash; The official website<br />
* [http://planetob.openmonkey.com/ Planet Openbox] &ndash; Openbox news portal<br />
* [http://www.box-look.org/ Box-Look.org] &ndash; A good resource for themes and related artwork<br />
* [https://bbs.archlinux.org/viewtopic.php?id=93126 Openbox Hacks and Configs Thread] @ Arch Linux Forums<br />
* [https://bbs.archlinux.org/viewtopic.php?id=45692 Openbox Screenshots Thread] @ Arch Linux Forums<br />
* [http://snott.net/linux/using-gnome3-with-openbox/ Installation and configuration tutorial] Using gnome3 with Openbox<br />
<!-- vim: set ft=Wikipedia: --></div>Bhttps://wiki.archlinux.org/index.php?title=Openbox&diff=152650Openbox2011-08-20T00:09:49Z<p>B: Added 3.5 troubleshooting item about SSH agent</p>
<hr />
<div>[[Category:Stacking WMs (English)]]<br />
{{i18n|Openbox}}<br />
<br />
Openbox is a lightweight and highly configurable window manager with extensive standards support. Its features are documented at the [http://openbox.org/ official website]. This article pertains to installing Openbox under Arch Linux.<br />
<br />
== Installation ==<br />
<br />
{{Package Official|openbox}} is available from the community repository:<br />
# pacman -S openbox<br />
<br />
After installation, you should copy the default configuration files {{Filename|rc.xml}}, {{Filename|menu.xml}}, {{Filename|autostart}}, and {{Filename|environment}} to {{Filename|~/.config/openbox}}:<br />
<br />
{{Note | Do this as a regular user, not as root.}}<br />
<br />
$ mkdir -p ~/.config/openbox<br />
$ cp /etc/xdg/openbox/{rc.xml,menu.xml,autostart,environment} ~/.config/openbox<br />
<br />
{{Filename|rc.xml}} is the main configuration file. It defines keyboard shortcuts, themes, virtual desktops, and more.<br />
<br />
{{Filename|menu.xml}} defines the content of the right-click menu. It defines launchers for applications and other shortcuts. See the [[#Menus]] section.<br />
<br />
{{Filename|autostart}} is read by openbox-session at startup. It contains the programs that are run at startup. It is typically used to set environment variables, launch panels/docks, set background image or execute other startup scripts. See the [http://openbox.org/wiki/Help:Autostart Openbox Wiki].<br />
<br />
{{Filename|environment}} is sourced by openbox-session at startup. It contains environment variables to be set in Openbox's context. Any variables you set here will be visible to Openbox itself and anything you start from its menus.<br />
<br />
== Upgrading to Openbox 3.5 ==<br />
<br />
If you are upgrading to Openbox 3.5 or later from an earlier release, be aware of these changes:<br />
<br />
* There is a new config file called {{Filename|environment}} that you should copy from /etc/xdg/openbox to ~/.config/openbox .<br />
* The config file previously called {{Filename|autostart.sh}} is now just called {{Filename|autostart}}. You should rename yours to remove the .sh from the end of the name.<br />
* Some of the configuration grammar in {{Filename|rc.xml}} has changed. While Openbox appears to understand the old options, it would be wise to compare your configuration to the one in /etc/xdg/openbox and look for changes that affect you.<br />
<br />
=== Troubleshooting 3.5 ===<br />
See the [[#Troubleshooting_Openbox_3.5|Troubleshooting Openbox 3.5]] section below.<br />
<br />
== Openbox as a stand-alone WM ==<br />
<br />
Openbox can be used as a stand-alone window manager (WM). This is usually simpler to install and configure than using Openbox with desktop environments. Running openbox alone may reduce your system's CPU and memory load.<br />
<br />
To run Openbox as a stand-alone window manager, append the following to '''{{Filename|~/.xinitrc}}''':<br />
exec openbox-session<br />
<br />
You may also start Openbox from the command shell (aka: text prompt) using '''xinit''':<br />
$ xinit /usr/bin/openbox-session<br />
<br />
If you used another window manager previously (such as Xfwm) and now Openbox won't start after logging out of X, try moving the autostart folder:<br />
mv ~/.config/autostart ~/.config/autostart-bak<br />
<br />
Using Consolekit, use this instead:<br />
exec ck-launch-session openbox-session<br />
<br />
If you also use '''polkit''' and '''D-Bus''' (e.g. for auto-mount drivers in Nautilus/Gnome) use:<br />
exec ck-launch-session dbus-launch openbox-session<br />
<br />
{{Note | [http://www.archlinux.org/packages/extra/any/pyxdg/ pyxdg] is required for Openbox's xdg-autostart}}<br />
{{Note | "dbus-launch" must be placed after "ck-launch-session" or you will experience mounting problems}}<br />
<br />
== Openbox as a WM for desktop environments ==<br />
<br />
Openbox can be used as a replacement window manager for full-fledged desktop environments. The method for deploying Openbox depends on the desktop environment.<br />
<br />
=== GNOME 2.24 and 2.26 ===<br />
Create {{Filename|/usr/share/applications/openbox.desktop}} with the following lines:<br />
[Desktop Entry]<br />
Type=Application<br />
Encoding=UTF-8<br />
Name=OpenBox<br />
Exec=openbox<br />
NoDisplay=true<br />
# name of loadable control center module<br />
X-GNOME-WMSettingsModule=openbox<br />
# name we put on the WM spec check window<br />
X-GNOME-WMName=OpenBox<br />
In gconf, set '''{{Codeline|/desktop/gnome/session/required_components/windowmanager}}''' to '''{{Codeline|openbox}}:'''<br />
$ gconftool-2 -s -t string /desktop/gnome/session/required_components/windowmanager openbox<br />
Finally, choose '''GNOME''' session from the GDM sessions menu.<br />
<br />
=== GNOME 2.26 Redux ===<br />
'''''If the previous guide for GNOME 2.24 fails:'''''<br />
<br />
If, when attempting to log into a "Gnome/Openbox" session -- and it consistently fails to start, try the following. This is one way of achieving your goal of using Openbox as the WM anytime you open a Gnome session:<br />
<br />
#Log into your Gnome-only session (it should still be using Metacity as its window manager).<br />
#Install Openbox if you have not done so already<br />
#Navigate your menus to ''System &rarr; Preferences &rarr; Startup Applications'' (possibly named 'Session' in older Gnome versions)<br />
#Open Startup Application, select '+ Add' and enter the text shown below. Omit the text after #.<br />
#Click the 'Add' button for the data entry window. Make sure the checkbox beside your new entry is selected.<br />
#Log out from your Gnome session and log back in<br />
#You should now be running openbox as your window manager.<br />
<br />
Name: Openbox Windox Manager # Can be changed<br />
Command: openbox --replace # Text should not be removed from this line, but possibly added to it<br />
Comment: Replaces metacity with openbox # Can be changed<br />
<br />
This creates a startup list entry which is executed by Gnome each time the user's session is started.<br />
<br />
=== GNOME 2.22 and prior ===<br />
# If you use GDM, select the "GNOME/Openbox" login option<br />
# If you use {{Codeline|startx}}, add {{Codeline|exec openbox-gnome-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-gnome-session<br />
<br />
=== KDE ===<br />
# If you use KDM, select the "KDE/Openbox" login option<br />
# If you use startx, add {{Codeline|exec openbox-kde-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-kde-session<br />
<br />
=== Xfce4 ===<br />
Log into a normal Xfce4 session. From your terminal, type:<br />
$ killall xfwm4 ; openbox & exit<br />
<br />
This kills xfwm4, runs Openbox, and closes the terminal. Log out, being sure to check the ''"Save session for future logins"'' box. On your next login, Xfce4 should use '''Openbox''' as its WM.<br />
<br />
To enable exiting from a session using ''xfce4-session,'' edit '''{{Filename|~/.config/openbox/menu.xml}}'''. If the file isn't there, copy it from {{Filename|/etc/xdg/openbox/}}. Look for the following entry:<br />
<item label="Exit Openbox"><br />
<action name="Exit"><br />
<prompt>yes</prompt><br />
</action><br />
</item><br />
<br />
Change it to:<br />
<item label="Exit Openbox"><br />
<action name="Execute"><br />
<prompt>yes</prompt><br />
<command>xfce4-session-logout</command><br />
</action><br />
</item><br />
<br />
Otherwise, choosing "Exit" from the root-menu causes Openbox to terminate its execution, leaving you with no window manager.<br />
<br />
If you have a problem changing virtual desktops with the mouse wheel skipping over desktops, edit '''{{Filename|~/.config/openbox/rc.xml}}'''. Move the ''mouse binds with...'' actions "DesktopPrevious" and "DesktopNext" from context ''Desktop'' to the context ''Root''. (You may need to create a definition for the ''Root'' context as well.)<br />
<br />
When using the Openbox root-menu instead of Xfce's menu, you may exit the Xfdesktop with this terminal command:<br />
$ xfdesktop --quit<br />
Xfdesktop manages the wallpaper and desktop icons, requiring you to use other utilities such as ROX for these functions.<br />
<br />
(When terminating Xfdesktop, the above issue with the virtual desktops is no longer a problem.)<br />
<br />
== Openbox for multihead users ==<br />
<br />
While Openbox provides better than average multihead support on its own, a branch called [http://aur.archlinux.org/packages.php?ID=51460 Openbox Multihead] is now available in the AUR that gives multihead users per-monitor desktops. This model is not commonly found in floating window managers, but exists mainly in tiling window managers. It is explained well on the [http://xmonad.org/tour.html#workspace Xmonad web site]. Also, please see [https://github.com/BurntSushi/openbox-multihead/blob/multihead/README.MULTIHEAD README.MULTIHEAD] for a more comprehensive description of the new features and configuration options found in Openbox Multihead.<br />
<br />
Openbox Multihead will function like normal Openbox when only a single head is available.<br />
<br />
A downside to using Openbox Multihead is that it breaks the EWMH assumption that one and only one desktop is visible at any time. Thus, existing pagers will not work well with it. To remedy this, [http://aur.archlinux.org/packages.php?ID=51536 pager-multihead] can be found in the AUR that is compatible with Openbox Multihead. [http://imgur.com/a/cnZeq#y04nk Screenshots].<br />
<br />
Finally, a new version of [http://aur.archlinux.org/packages.php?ID=51626 pytyle] can also be found in the AUR that will work with Openbox Multihead.<br />
<br />
Both pytyle3 and pager-multihead will work without Openbox Multihead if only one monitor is active.<br />
<br />
== Configuration ==<br />
<br />
There are several options for configuring Openbox settings:<br />
<br />
=== Manual configuration ===<br />
To configure Openbox manually, edit the {{Filename|~/.config/openbox/rc.xml}} file with a text editor. The file has explanatory comments throughout. See the [http://openbox.org/wiki/Help:Configuration Help:Configuration openbox wiki] for more documentation on editing this file.<br />
<br />
=== ObConf ===<br />
[http://openbox.org/wiki/ObConf:About ObConf] is an Openbox configuration tool. It is used to set most common preferences such as themes, virtual desktops, window properties, and desktop margins. It can be installed with pacman:<br />
<br />
# pacman -S obconf<br />
<br />
ObConf cannot configure keyboard shortcuts and certain other features. For these features edit {{Filename|rc.xml}} manually. Alternatively, you can try {{Package AUR|obkey}} from the [[AUR]].<br />
<br />
=== Application customization ===<br />
<br />
Openbox allows per-application customizations. This lets you define rules for a given program. For example:<br />
* Start your web browser on a specific virtual desktop.<br />
* Open your terminal program with no window decorations (window chrome).<br />
* Make your bit-torrent client open at a given screen position.<br />
<br />
Per-application settings are defined in {{Filename|~/.config/openbox/rc.xml}}. Instructions are in the file's comments. More details are found in the [http://openbox.org/wiki/Help:Applications Help:Applications openbox wiki].<br />
<br />
== Menus ==<br />
<br />
The default Openbox menu includes a variety of menu items to get you started. Many of these items launch applications you don't want, haven't installed yet, or never intend to install. You'll surely want to customize '''{{Filename|menu.xml}}''' at some point. There are a number of ways to do so.<br />
<br />
=== Manual configuration of menus ===<br />
<br />
You can edit {{Filename|~/.config/openbox/menu.xml}} with a text editor. Many of the settings are self-explanatory. The article [http://openbox.org/wiki/Help:Menus Help:Menus] has extensive details.<br />
<br />
===Icons in menu===<br />
<br />
Since version 3.5.0 you can have icons next to your menu entries. To do that :<br />
# add <showIcons>yes</showIcons> in the <menu> section of the {{Filename|rc.xml}} file<br />
# edit the menu entries in {{Filename|menu.xml}} and add icons="<path>" like this :<br />
<menu id="apps-menu" label="SomeApp" icon="/home/user/.icons/application.png"><br />
<br />
then openbox --reconfigure or openbox --restart if you have troubles updating the menu :)<br />
<br />
<br />
=== MenuMaker ===<br />
<br />
[http://menumaker.sourceforge.net/ MenuMaker] creates XML menus for several window managers including Openbox. MenuMaker searchs your computer for executable programs and creates a menu file from the result. It can be configured to exclude certain application types (GNOME, KDE, etc) if you desire.<br />
# pacman -S menumaker # Install MenuMaker from the repository<br />
<br />
Once installed, generate a menu file (named {{Filename|menu.xml}}) by running the program.<br />
$ mmaker -v OpenBox3 # Will not overwrite an existing menu file.<br />
$ mmaker -vf OpenBox3 # Force option permits overwriting the menu file.<br />
$ mmaker --help # See the full set of options for MenuMaker.<br />
<br />
MenuMaker creates a comprehensive {{Filename|menu.xml}}. You may edit this file by hand or regenerate it after installing software.<br />
<br />
=== Obmenu ===<br />
<br />
Obmenu is a menu editor for Openbox. This GUI application is the best choice for those who dislike editing XML code. Obmenu is available in the community repository:<br />
# pacman -S obmenu<br />
<br />
Once installed, run {{Codeline|obmenu}} then add and remove applications as desired.<br />
<br />
=== openbox-menu ===<br />
<br />
Openbox-menu uses [http://sourceforge.net/projects/lxde/files/menu-cache/ menu-cache] from the LXDE Project to create dynamic menus for Openbox.<br />
<br />
Project homepage here:<br />
[http://mimasgpc.free.fr/openbox-menu_en.html http://mimasgpc.free.fr/openbox-menu_en.html]<br />
<br />
AUR Package here:<br />
[http://aur.archlinux.org/packages.php?ID=31605 http://aur.archlinux.org/packages.php?ID=31605]<br />
<br />
==== Obm-xdg ====<br />
<br />
<tt>obm-xdg</tt> is a command-line tool that comes with Obmenu. It generates a categorized sub-menu of installed GTK/GNOME applications.<br />
<br />
To use obm-xdg with other menus, add the following line to '''{{Filename|~/.config/openbox/menu.xml}}''':<br />
<menu execute="obm-xdg" id="xdg-menu" label="xdg"/><br />
<br />
Then add the following line under your 'root-menu' entry where you want to have the menu appear:<br />
<menu id="xdg-menu"/><br />
<br />
To use obm-xdg by itself create '''{{Filename|~/.config/openbox/menu.xml}}''' and add these lines:<br />
<openbox_menu><br />
<menu execute="obm-xdg" id="root-menu" label="apps"/><br />
</openbox_menu><br />
<br />
<br />
Then run {{Codeline|openbox --reconfigure}} to refresh the Openbox menu. You should now see a sub-menu labeled '''xdg''' in your menu.<br />
<br />
{{Note|If you do not have GNOME installed, you need to install package '''gnome-menus''' for obm-xdg.}}<br />
<br />
=== Python-based xdg menu script ===<br />
<br />
This script is found in Fedora's Openbox package. You have only to put the script somewhere and create a menu entry.<br />
<br />
Here is the head: [http://pkgs.fedoraproject.org/gitweb/?p=openbox.git;f=xdg-menu;hb=HEAD latest script]<br />
<br />
Download from above repository. Place the file into the directory you want.<br />
<br />
Open '''{{Filename|menu.xml}}''' with your text editor and add the following entry. Of course, you can modify the label as you see fit.<br />
<menu id="apps-menu" label="xdg-menu" execute="python2 <path>/xdg-menu"/><br />
<br />
Save the file and run '''{{Codeline|openbox --reconfigure}}'''.<br />
<br />
{{Note|If you do not have GNOME installed, you need to install package '''gnome-menus''' for xdg-menu.}}<br />
<br />
=== Openbox menu generator ===<br />
<br />
Residing in the AUR as [http://aur.archlinux.org/packages.php?ID=27300 obmenugen-bin,] Openbox menu generator creates the menu file from *.desktop files. Obmenugen provides a text file which filters (hides) menu items using basic regex.<br />
$ obmenugen # Create a menu file<br />
$ openbox --reconfigure # To see the menu you generated<br />
<br />
=== Pipe menus ===<br />
<br />
Like other window managers, Openbox allows for scripts to dynamically build menus (menus on-the-fly). Examples are system monitors, media player controls, or weather monitors. Pipe menu script examples are found in the [http://openbox.org/wiki/Openbox:Pipemenus Openbox:Pipemenus] page at Openbox's site.<br />
<br />
User ''Xyne'' created a pipe menu file browser and user ''brisbin33'' created a pipe menu for scanning and connecting to wireless hot spots (using netcfg). Forum posts for these utilities are here: [http://bbs.archlinux.org/viewtopic.php?id=77197&p=1 file browser] and here: [http://bbs.archlinux.org/viewtopic.php?id=78290 wifi].<br />
<br />
User ''jnguyen'' created a pipe menu for managing removable devices using Udisks. The forum post is here: [https://bbs.archlinux.org/viewtopic.php?id=114702 obdevicemenu].<br />
<br />
== Startup programs ==<br />
<br />
Openbox supports running programs at startup. This is provided by command '''openbox-session'''.<br />
<br />
=== Enabling autostart ===<br />
<br />
There are two ways to enable autostart:<br />
# When using startx or xinit to begin a session, edit {{Filename|~/.xinitrc}}. Change the line that executes '''''openbox''''' to '''openbox-session'''.<br />
# When using GDM or KDM, selecting an ''Openbox'' session automatically runs the autostart script.<br />
<br />
=== Autostart script ===<br />
<br />
Openbox executes a user startup script located at {{Filename|~/.config/openbox/autostart}}. This script is ''not'' created by default. In the absence of a user startup script, openbox executes the system startup script {{Filename|/etc/xdg/openbox/autostart}}. The system script does not run when the user script is present.<br />
<br />
To create a personal startup script, copy the system script to your settings directory {{Filename|~/.config/openbox/}} and append your commands. This ensures your environment is properly configured.<br />
<br />
Full instructions are available from the [http://openbox.org/wiki/Help:Autostart Help:Autostart] article at the Openbox site.<br />
<br />
{{Note|This file used to be called autostart.sh before OpenBox 3.5.0. If you are upgrading, be sure you rename your copy of the file to remove the .sh from the end, or it will stop being read.}}<br />
<br />
== Themes and appearance ==<br />
<br />
:{{Box YELLOW||The supplemental article '''[[Openbox_Themes_and_Apps|Openbox Themes and Apps]]''' has detailed information about changing Openbox's GUI.}}<br />
<br />
You probably installed a selection of Linux programs that were developed using different toolkits. Configuration settings for a given program may reside in an unexpected location.<br />
<br />
For example, the double-click setting used by [http://www.geany.org/ Geany] (an editor/IDE) is set within the file '''{{Filename|~/.gtkrc-2.0,}}''' not where you might expect in '''{{Filename|~/.config/openbox/rc.xml}}'''. Some visual aspects of Geany are set by .gtkrc-2.0 as well.<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Themes_and_appearance|Openbox Themes and Apps]] for visual theming information.<br />
<br />
=== Openbox themes ===<br />
<br />
Themes control the appearance of windows, titlebars, and buttons. They also control menu appearance and on-screen display (OSD). Additional themes are available from the standard repositories.<br />
# pacman -S openbox-themes<br />
<br />
=== Cursors, icons, wallpaper ===<br />
<br />
Please see [[Openbox_Themes_and_Apps#X11_Mouse_cursors|Openbox Themes and Apps]] for information on these GUI customizations.<br />
<br />
== Recommended programs ==<br />
:{{Box YELLOW||The supplemental wiki article '''[[Openbox_Themes_and_Apps#Recommended_programs|Openbox Themes and Apps]]''' has information on applications you may use with Openbox.<br>The article gives details about panels, trays, mixer controls, and other widgets used on a desktop interface.}}<br />
<br />
There is a list of [[Lightweight_Applications|Lightweight Applications]] in the wiki. Most of these work nicely with Openbox.<br />
<br />
=== Login managers ===<br />
<br />
[http://slim.berlios.de/ SLiM] is a graphical login manager. It works for standalone Openbox configurations. Refer to the [[SLiM]] wiki article for instructions.<br />
<br />
[http://qingy.sourceforge.net/ Qingy] is a light, highly-configurable graphical login manager. It supports login to either text console or X session. Qingy uses [http://www.directfb.org DirectFB]. Qingy does not start an X session unless you choose a session that uses X Windows. Read the Arch wiki article about [[Qingy|Qingy.]]<br />
<br />
=== Compositing the desktop view ===<br />
<br />
[[Xcompmgr]] is a compositing window manager capable of rendering drop shadows, fading, and window transparency for Openbox and other window managers.<br />
Note that xcompmgr is no longer being developed. Any problems are unlikely to be fixed. (For example, Xcompmgr has shown a problem with ''tint2 0.9'': systray icons have a tendency to become corrupted.)<br />
<br />
[[Cairo Compmgr]] is a versatile compositing window manager that uses [http://en.wikipedia.org/wiki/Cairo_(software) Cairo] for rendering. It is usually the better choice.<br />
<br />
=== Panels, trays, pagers ===<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Panels, trays, pagers|Openbox Themes and Apps]] to learn about these GUI embellishments for Openbox.<br />
<br />
=== File managers ===<br />
<br />
Three popular lightweight file managers are:<br />
* [[Thunar]]. Thunar supports auto-mount features and other plugins. <br />
# pacman -S thunar<br />
* [http://rox.sourceforge.net ROX] (ROX provides desktop icons)<br />
# pacman -S rox<br />
* [http://pcmanfm.sourceforge.net PCManFM]<br />
# pacman -S pcmanfm # PcManFM package also provides desktop icons.<br />
# pacman -S ntfs-3g # Allows PCManFM to access NTFS drives.<br />
<br />
More information is found at [[Openbox_Themes_and_Apps#File_managers|Openbox Themes and Apps]]. The supplemental article has further information about application launchers such as [http://sourceforge.net/projects/gmrun gmrun], clipboard managers, volume mixers, and more.<br />
<br />
== Tips and tricks ==<br />
<br />
=== File associations ===<br />
Because Openbox and the applications you use with it are not well-integrated you might run into the issues with your browser. Your browser may not know which program it is supposed to use for certain types of files.<br />
<br />
A package in the AUR called [http://aur.archlinux.org/packages.php?ID=23170 gnome-defaults-list] contains a list of file-types and programs specific to the Gnome desktop. The list is installed to {{Filename|/etc/gnome/defaults.list.}}<br />
<br />
Open this file with your text-editor. Now you can replace a given application with the name of the program of your choosing. For example, totem <=> vlc or eog <=> mirage. Save the file to {{Filename|~/.local/share/applications/defaults.list}}.<br />
<br />
Another way of setting file associations is to install package ''perl-file-mimeinfo'' from the repository and invoke '''mimeopen''' like this:<br />
mimeopen -d /path/to/file<br />
You are asked which application to use when opening /path/to/file:<br />
Please choose a default application for files of type text/plain<br />
1) notepad (wine-extension-txt)<br />
2) Leafpad (leafpad)<br />
3) OpenOffice.org Writer (writer)<br />
4) gVim (gvim)<br />
5) Other...<br />
Your answer becomes the default handler for that type of file. Mimeopen is installed as {{Filename|/usr/bin/perlbin/vendor/mimetype}}.<br />
<br />
=== Copy and paste ===<br />
<br />
From a terminal '''Ctrl+Insert''' for copy and '''Shift+Insert''' for paste.<br />
<br />
Also '''Ctrl+Shift+C''' for copy and '''mouse middle-click''' for paste (in terminals).<br />
<br />
Other applications most likely use the conventional keyboard shortcuts for copy and paste.<br />
<br />
=== Window transparency ===<br />
<br />
The program transset-df (virtually the same as ''transset'') is installed with pacman -S transset-df. With transset-df you can enable window-transparency on-the-fly.<br />
<br />
For instance by placing the following in {{Filename|~/.config/openbox/rc.xml}} you can have your mouse adjust window transparency by scrolling while hovering over the title bar (it is in the <mouse> section):<br />
<br />
<context name="Titlebar"><br />
. . .<br />
<mousebind button="Up" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --inc </execute><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --dec </execute><br />
</action><br />
</mousebind><br />
. . .<br />
</context><br />
It appears to work only when no additional actions are defined within the action group.<br />
<br />
=== Xprop values for applications ===<br />
If you use per-application settings frequently, you might find this bash alias handy:<br />
<br />
alias xp='xprop | grep "WM_WINDOW_ROLE\|WM_CLASS" && echo "WM_CLASS(STRING) = \"NAME\", \"CLASS\""'<br />
<br />
To use, run '''{{Codeline|xp}}''' and click on the running program that you'd like to define with per-app settings. The result displays only the info that Openbox requires, namely the WM_WINDOW_ROLE and WM_CLASS (name and class) values:<br />
<br />
[thayer@dublin:~] $ xp<br />
WM_WINDOW_ROLE(STRING) = "roster"<br />
WM_CLASS(STRING) = "gajim.py", "Gajim.py"<br />
WM_CLASS(STRING) = "NAME", "CLASS"<br />
<br />
==== Xprop for Firefox ====<br />
<br />
For whatever reason, Firefox and like-minded equivalents ignore application rules (e.g. <desktop>) unless {{Codeline|class&#61;"Firefox*"}} is used. This applies irrespective of whatever values xprop may report for the program's WM_CLASS.<br />
<br />
=== Linking the menu to a button ===<br />
<br />
Some people want to link the Openbox menu (or any menu) to an object. This is useful for creating a panel button to pop up a menu. Although Openbox does not provide this, a program called '''xdotool''' simulates a keypress. Openbox can be configured to bind that keypress to the ''ShowMenu'' action.<br />
<br />
Package [http://aur.archlinux.org/packages.php?do_Details=1&ID=14789&O=0&L=0&C=0&K=xdotool&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd xdotool] is available in the AUR. After installing ''xdotool'', add the following to the <keyboard> section of your '''{{Filename|rc.xml}}''':<br />
<keybind key="A-C-q"><br />
<action name="ShowMenu"><br />
<menu>root-menu</menu><br />
</action><br />
</keybind><br />
Restart/reconfigure Openbox. The following command summons a menu at your cursor position. The command may given as-is, linked to an object, or placed in a script.<br />
$ xdotool key ctrl+alt+q<br />
<br />
Of course, change the key shortcut to your liking. Here's a snippet from a '''tint2''' (a taskbar-like panel) configuration file which pops up a menu when the clock area is clicked. Each key combination is set to open a menu within openbox's '''{{Filename|rc.xml}}''' configuration file. The right‑click menu is different from the left‑click menu:<br />
clock_rclick_command = xdotool key --clearmodifiers "ctrl+XF86PowerOff"<br />
clock_lclick_command = xdotool key --clearmodifiers "alt+XF86PowerOff"<br />
<br />
=== Urxvt in the background ===<br />
<br />
With Openbox, running a terminal as desktop background is easy. You won't need '''devilspie''' here.<br />
<br />
First you must enable transparency, open your {{Filename|.Xdefaults}} file (if it doesn't exist yet, create it in your home folder).<br />
URxvt*transparent:true<br />
URxvt*scrollBar:false<br />
URxvt*geometry:124x24 #I don't use the whole screen, if you want a full screen term don't bother with this and see below.<br />
URxvt*borderLess:true<br />
URxvt*foreground:Black #Font color. My wallpaper is White, you may wish to change this to White.<br />
<br />
Then edit your {{Filename|.config/openbox/rc.xml}} file:<br />
<application name="URxvt"><br />
<decor>no</decor><br />
<focus>yes</focus><br />
<position><br />
<x>center</x><br />
<y>20</y><br />
</position><br />
<layer>below</layer><br />
<desktop>all</desktop><br />
<maximized>true</maximized> #Only if you want a full size terminal.<br />
</application><br />
<br />
The ''magic'' comes from the {{Codeline|<layer>below</layer>}} line, which place the application under all others. Here Urxvt is displayed on all desktops, change it to your convenience.<br />
<br />
Note: Instead of using <application name="URxvt">, you can use another name ("URxvt-bg" for example), and use the -name option when starting uxrvt. That way, only the urxvt terminals which you choose to name URxvt-bg would be captured and modified by the application rule in rc.xml. For example: urxvt -name URxvt-bg (case sensitive)<br />
<br />
====ToggleShowDesktop exception====<br />
<br />
Above method still minimizes Urxvt when using the ToggleShowDesktop command. A method for avoiding this is explained in this [https://bbs.archlinux.org/viewtopic.php?pid=865844#p865844 forum post]. This involves editing Urxvt's source code.<br />
<br />
=== Keyboard volume control ===<br />
<br />
If you use ALSA for sound, you can use the amixer program to adjust the volume of sound. You can use Openbox's keybindings to act like multimedia keys. (Alternatively, you can probably find out the names of your real multimedia keys and map them.) For example, in the <keyboard> section of rc.xml:<br />
<br />
<keybind key="W-Up"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+</command><br />
</action><br />
</keybind><br />
<br />
This binds Windows key + Up arrow to increase your master ALSA volume by 5%. Corresponding binding for volume down:<br />
<br />
<keybind key="W-Down"><br />
<action name="Execute"><br />
<command>amixer set Master 5%-</command><br />
</action><br />
</keybind><br />
<br />
As another example you can also use the XF86Audio keybindings:<br />
<br />
<keybind key="XF86AudioRaiseVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+ unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioLowerVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%- unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioMute"><br />
<action name="Execute"><br />
<command>amixer set Master toggle</command><br />
</action><br />
</keybind><br />
<br />
The above example should work for the majority of multimedia keyboards. It should enable to raise, lower and mute the Master control of your audio device by using the respective multimedia keyboard keys. Notice also that in this example:<br />
<br />
* The "Mute" key should unmute the Master control if it is already in mute mode.<br />
* The "Raise" and "Lower" keys should unmute the Master control if it is in mute mode.<br />
<br />
== Troubleshooting Openbox 3.5 ==<br />
=== X server crashes ===<br />
Problems have been detected after upgrade to ver. 3.5, that the X server might crash in attempt to start openbox, ending with similar error message:<br />
(metacity:25137): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process \<br />
was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit \<br />
status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request \<br />
the exit status, or don't set the SIGCHLD action.<br />
xinit: connection to X server lost<br />
waiting for X server to shut down<br />
In this particular case, some problem with metacity package has been identified as the cause of the X server crash issue. Removal of metacity & compiz-decorator-gtk packages solved the problem. Though, later was found, that even a simple reinstall of packages might have helped, as there is no problem after new installation of previously removed packages.<br />
<br />
Also, plenty of similar cases have been found on the Internet, that not only metacity package might be causing the X server to crash.<br />
Thus, whatever else instead of metacity you get in the error output message, try to reinstall it (or remove if necessary) in an attempt to get rid of this X server crash.<br />
<br />
=== Autostarting unwanted applications in 3.5 ===<br />
Unwanted applications do start with your Openbox session, though they are not listed in your ~/.config/openbox/autostart script?<br />
<br />
Check the ~/.config/autostart/ directory, it might contain the residues from your previously used desktop environment (Gnome, KDE, etc.), and remove unwanted files.<br />
<br />
=== SSH agent no longer starting ===<br />
Whereas Openbox 3.4.x allowed launching an SSH agent from autostart.sh, with 3.5 that no longer seems to work. You need to put your code in $XDG_CONFIG_HOME/openbox/environment, e.g.:<br />
<br />
<pre><br />
SSHAGENT="/usr/bin/ssh-agent"<br />
SSHAGENTARGS="-s"<br />
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then<br />
eval `$SSHAGENT $SSHAGENTARGS`<br />
trap "kill $SSH_AGENT_PID" 0<br />
fi<br />
</pre><br />
<br />
== Resources ==<br />
<br />
* [http://openbox.org/ Openbox Website] &ndash; The official website<br />
* [http://planetob.openmonkey.com/ Planet Openbox] &ndash; Openbox news portal<br />
* [http://www.box-look.org/ Box-Look.org] &ndash; A good resource for themes and related artwork<br />
* [https://bbs.archlinux.org/viewtopic.php?id=93126 Openbox Hacks and Configs Thread] @ Arch Linux Forums<br />
* [https://bbs.archlinux.org/viewtopic.php?id=45692 Openbox Screenshots Thread] @ Arch Linux Forums<br />
* [http://snott.net/linux/using-gnome3-with-openbox/ Installation and configuration tutorial] Using gnome3 with Openbox<br />
<!-- vim: set ft=Wikipedia: --></div>Bhttps://wiki.archlinux.org/index.php?title=Lighttpd_for_SSL_and_non-SSL&diff=37433Lighttpd for SSL and non-SSL2008-02-21T12:22:39Z<p>B: /* Step 3: Add eaccelerator to php.ini and make additional changes */</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Lighttpd for both ssl and non-ssl==<br />
by CacTus<br />
----<br />
<br />
==What is Lighttpd?==<br />
The lighttpd website gives a good definition.<br />
<br />
<pre><br />
"lighttpd a secure, fast, compliant and very flexible web-server which has been optimized<br />
for high-performance environments. It has a very low memory footprint compared to other<br />
webservers and takes care of cpu-load. Its advanced feature-set (FastCGI, CGI, Auth,<br />
Output-Compression, URL-Rewriting and many more) make lighttpd the perfect<br />
webserver-software for every server that is suffering load problems."<br />
-- http://www.lighttpd.net/<br />
</pre><br />
<br />
==Goals==<br />
The goal of this how to is to setup lighttpd for servicing both ssl and non-ssl connections. php will be setup via a fastcgi prespawn, that will service both ssl and non-ssl connections. The php-fcgi instances will be run as a different user than the lighttpd daemon. eaccelerator will also be setup to increase the efficiency of our php scripts.<br />
<br />
===Required packages:===<br />
*lighttpd (compiled for mysql support)<br />
*php-cgi (compiled for cgi/fcgi support)<br />
*fast-cgi<br />
*eaccelerator<br />
*ssl<br />
<br />
If you have trouble finding a package specific to this How-To, try the resources link at the bottom.<br />
<br />
==Lighttpd Installation==<br />
===Step 1: Install the lighttpd package===<br />
I have lighttpd in my repository, and there is also a version in the AUR, courtesy of klapmuetz. The one in my repository currently contains a few extra things that we will be utilizing for this how to, but they can be obtained individually from my subversion repository if needed. The compiled binaries are the same in the two packages. Just a few different scripts and helper files.<br />
<pre><br />
[[root@computer]]$ pacman -Sy lighttpd<br />
</pre><br />
<br />
===Step 2: Add a user===<br />
We are going to be running lighttpd as a non-root user. So, we first need to create a user for this purpose, and a home directory. We will create a group too.<br />
<pre><br />
[[root@computer]]$ groupadd lighttpd<br />
[[root@computer]]$ useradd -g lighttpd -d /home/lighttpd -s /bin/false lighttpd<br />
</pre><br />
<br />
===Step 3: Ensure permissions are properly set.===<br />
<pre><br />
[[root@computer]]$ chown -R lighttpd.lighttpd /home/lighttpd<br />
</pre><br />
<br />
===Step 4: Edit the lighttpd.conf file located at /etc/lighttpd/lighttpd.conf===<br />
*Uncomment mod_fastcgi and mod_compress.<br />
*Uncomment and change server.username to "lighttpd"<br />
*Uncomment and change server.groupname to "lighttpd"<br />
*Uncomment compress.cache-dir and compress.filetype<br />
Save your changes<br />
<br />
===Step 5: Change logfile permissions===<br />
Since we are running the daemon as lighttpd user, we need to change the logfile permissions.<br />
<pre><br />
[[root@computer]]$ chown lighttpd /var/log/lighttpd/*.log<br />
</pre><br />
<br />
===Step 6: Start the daemon.===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd start<br />
</pre><br />
Check /var/log/lighttpd/error.log for any errors. Try bringing up a web page on the server. The default index page should come up. Hooray! You got lighttpd running as a user.<br />
<br />
It is currently only servicing port 80 (non-ssl), so next we add ssl to the mix.<br />
<br />
==Lighttpd SSL==<br />
===Step 1: First things first===<br />
Lighttpd can only service either ssl or non-ssl at one time. No problem. We can easily run two daemons. We need to do a little maintenance work in the lighttpd user directory first.<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd stop<br />
[[root@computer]]$ mkdir -p /home/lighttpd/ssl/html /home/lighttpd/ssl/cache<br />
[[root@computer]]$ mkdir /home/lighttpd/nonssl<br />
[[root@computer]]$ mv /home/lighttpd/html /home/lighttpd/nonssl<br />
[[root@computer]]$ mv /home/lighttpd/cache /home/lighttpd/nonssl<br />
[[root@computer]]$ cp /home/lighttpd/nonssl/html/index.html /home/lighttpd/ssl/html<br />
[[root@computer]]$ chown -R lighttpd.lighttpd /home/lighttpd<br />
</pre><br />
<br />
===Step 2: Copy things===<br />
Now we need to setup a separate config script, and init script for the ssl version.<br />
<pre><br />
[[root@computer]]$ cp /usr/sbin/lighttpd /usr/sbin/lighttpd-ssl<br />
[[root@computer]]$ cp /etc/rc.d/lighttpd /etc/rc.d/lighttpd-ssl<br />
[[root@computer]]$ cp /etc/conf.d/lighttpd /etc/conf.d/lighttpd-ssl<br />
[[root@computer]]$ cp /etc/lighttpd/lighttpd.conf /etc/lighttpd/lighttpd-ssl.conf<br />
</pre><br />
<br />
===Step 3: Edit /etc/conf.d/lighttpd-ssl===<br />
Change to the following:<br />
<pre><br />
DAEMON_NAME="lighttpd-ssl"<br />
DAEMON_CONF="/etc/lighttpd/lighttpd-ssl.conf"<br />
DAEMON_PATH="/usr/sbin/lighttpd-ssl"<br />
</pre><br />
<br />
===Step 4: Edit /etc/rc.d/lighttpd-ssl===<br />
Change to the following:<br />
<pre><br />
[ -f /etc/conf.d/lighttpd-ssl ] && . /etc/conf.d/lighttpd-ssl<br />
</pre><br />
<br />
===Step 5: Edit /etc/lighttpd/lighttpd-ssl.conf===<br />
Change to the following:<br />
<pre><br />
server.document-root = "/home/lighttpd/ssl/html"<br />
server.errorlog = "/var/log/lighttpd/error-ssl.log"<br />
accesslog.filename = "/var/log/lighttpd/access-ssl.log"<br />
server.pid-file = "/var/run/lighttpd-ssl.pid"<br />
compress.cache-dir = "/home/lighttpd/ssl/cache"<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/home/lighttpd/ssl/server.pem"<br />
</pre><br />
<br />
===Step 6: Edit /etc/lighttpd/lighttpd.conf===<br />
Now that the ssl version is correct, we have to slightly modify the non-ssl version to deal with our new directory structure.<br />
<pre><br />
server.document-root = "/home/lighttpd/nonssl/html"<br />
compress.cache-dir = "/home/lighttpd/nonssl/cache"<br />
</pre><br />
<br />
===Step 7: Create the self signed certificate===<br />
<pre><br />
[[root@computer]]$ cd /home/lighttpd/ssl<br />
[[root@computer]]$ openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes<br />
[[root@computer]]$ chown lighttpd.lighttpd server.pem<br />
[[root@computer]]$ chmod 600 server.pem<br />
</pre><br />
<br />
===Step 8: Start the daemons===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd start<br />
[[root@computer]]$ /etc/rc.d/lighttpd-ssl start<br />
</pre><br />
Check /var/log/lighttpd/error.log and /var/log/lighttpd/error-ssl.log for errors.<br />
<br />
===Step 9: Test===<br />
Try navigating with a web browser to both the http and https address of your server. Hoory!<br />
You just setup for ssl and nonssl serving using lighttpd.<br />
<br />
==FastCGI and PHP with eAcceleration==<br />
===Step 1: Install fastcgi and php compiled for cgi/fcgi===<br />
<br />
You may first need to uncomment these lines in /etc/pacman.conf.<br />
[community]<br />
Include = /etc/pacman.d/community<br />
<br />
Note: php-cgi is now obsolete, use php<br />
<pre><br />
[[root@computer]]$ pacman -Sy fcgi php eaccelerator<br />
[[root@computer]]$ /etc/rc.d/lighttpd-ssl start<br />
</pre><br />
<br />
===N.B eaccelerator currently doesnt work with php 5.1.x===<br />
<br />
===Step 2: Create a php user===<br />
<pre><br />
[[root@computer]]$ mkdir -p /home/phpuser/eaccelerator/cache<br />
[[root@computer]]$ groupadd phpuser<br />
[[root@computer]]$ useradd -g phpuser -d /home/phpuser -s /bin/false phpuser<br />
[[root@computer]]$ chown -R phpuser.phpuser /home/phpuser<br />
</pre><br />
<br />
===Step 3: Add eaccelerator to php.ini and make additional changes===<br />
Note. Make sure you use >> in the following command. If you use a single >, you will overwrite, instead of append. not good.<br />
<pre><br />
[[root@computer]]$ cat /etc/php/conf.d/eaccelerator.ini >> /etc/php/php.ini<br />
</pre><br />
<br />
===Step 4: Edit /etc/php.ini===<br />
zlib.output_compression = On<br />
cgi.fix_pathinfo=1<br />
eaccelerator.cache_dir="/home/phpuser/eaccelerator/cache"<br />
<br />
I additionally set safe_mod to On in my setup, but this is not required.<br />
<br />
===Step 5: Setup fcgi-php prespawns===<br />
Now we are going to setup a mechanism for spawning php instances to handle requests.<br />
<pre><br />
[[root@computer]]$ chmod 755 /etc/rc.d/spawn-php<br />
</pre><br />
<br />
===Step 6: Modify /etc/conf.d/spawn-php===<br />
You need to edit a few parts of the spawn-php init script<br />
<br />
Change the following to reflect the php user you created earlier:<br />
USERID=phpuser<br />
GROUPID=phpuser<br />
FCGISOCKET="/tmp/php-fastcgi.socket"<br />
<br />
===Step 7: Spawn the php instances===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/spawn-php start<br />
</pre><br />
You should get some sort of message saying that is has started child processes.<br />
<br />
To check to see if it indeed has (the spawn script is a bit buggy yet, I haven't worked out the kinks in the wrapper portion).<br />
<pre><br />
[[root@computer]]$ ps afx || grep php<br />
3192 ? Ss 0:00 /usr/bin/php<br />
3193 ? S 0:00 \_ /usr/bin/php<br />
3194 ? S 0:00 \_ /usr/bin/php<br />
3195 ? S 0:00 \_ /usr/bin/php<br />
3196 ? S 0:00 \_ /usr/bin/php<br />
3197 ? S 0:00 \_ /usr/bin/php<br />
3198 ? S 0:00 \_ /usr/bin/php<br />
3199 ? S 0:00 \_ /usr/bin/php<br />
3200 ? S 0:00 \_ /usr/bin/php<br />
3201 ? S 0:00 \_ /usr/bin/php<br />
3202 ? S 0:00 \_ /usr/bin/php<br />
3203 ? S 0:00 \_ /usr/bin/php<br />
3204 ? S 0:00 \_ /usr/bin/php<br />
</pre><br />
<br />
===Step 8: Setup lighttpd and lighttpd-ssl to use the instances===<br />
Uncomment both /etc/lighttpd/lighttpd.conf and /etc/lighttpd/lighttpd-ssl.conf to the following:<br />
<pre><br />
fastcgi.server = ( ".php" =><br />
( "localhost" =><br />
(<br />
"socket" => "/tmp/php-fastcgi.socket",<br />
"bin-path" => "/usr/bin/php-cgi"<br />
)<br />
)<br />
)<br />
<br />
</pre><br />
<br />
===Step 9: Restart both daemons===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd restart<br />
[[root@computer]]$ /etc/rc.d/lighttpd-ssl restart<br />
</pre><br />
Check /var/log/lighttpd/error.log and /var/log/lighttpd/error-ssl.log for errors.<br />
<br />
===Step 10: Try a php page.===<br />
Create the following php page, name it index.php, and place a copy in both /home/lighttpd/ssl/html and /home/lighttpd/nonssl/html<br />
<pre><br />
<?php<br />
phpinfo();<br />
?><br />
</pre><br />
Try navigating with a web browser to both the http and https address of your server. If you see the phpinfo page, then you are almost done! Hooray!<br />
<br />
<br />
===N.B eaccelerator currently doesnt work with php 5.1.x===<br />
<br />
===Step 11: Check on eaccelerator caching..===<br />
<pre><br />
[[root@computer]]$ ls -l /home/phpuser/eaccelerator/cache<br />
</pre><br />
If the above command outputs the following:<br />
<pre><br />
-rw------- 1 phpuser phpuser 456 2005-05-05 14:53 eaccelerator-277.58081<br />
-rw------- 1 phpuser phpuser 452 2005-05-05 14:53 eaccelerator-277.88081<br />
</pre><br />
Then you are done! Eaccelerator is happily caching your php scripts to help speed things up.<br />
Good luck with your setup. :D<br />
<br />
====Resources:====<br />
[[fastcgi and lighttpd]] - klapmuetz's how to on using lighttpd for ruby on rails. It also has good information on lighttpd setup.<br><br />
[http://e.solarblue.net/index.php/arch-repo/ Cacuts Repo Information] - Information about my Archlinuxrepository. Packages used in this howto can be found there.</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=36556HP Compaq 6510b2008-02-03T16:02:51Z<p>B: /* Tactile strip */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* AuthenTec AES2501 fingerprint reader<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to configure PAM. First edit /etc/pam.d/login, and make the first lines look like this:<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_fprint.so<br />
auth sufficient pam_unix.so nullok<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
This will make PAM accept a successful fingerprint scan as a valid login token, if the scan fails, it will fall back to a password. From this moment on, you'll be able to log on with a scan on a tty - enter your username, press Enter, and scan the finger you told pam_fprint_enroll to use as default. Voilà :-).<br />
<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). I have not tried yet to get [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html hal working for my multimedia keys] yet, the present solution works fine. Enter [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]]: The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35350HP Compaq 6510b2008-01-21T12:13:54Z<p>B: </p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* AuthenTec AES2501 fingerprint reader<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to configure PAM. First edit /etc/pam.d/login, and make the first lines look like this:<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_fprint.so<br />
auth sufficient pam_unix.so nullok<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
This will make PAM accept a successful fingerprint scan as a valid login token, if the scan fails, it will fall back to a password. From this moment on, you'll be able to log on with a scan on a tty - enter your username, press Enter, and scan the finger you told pam_fprint_enroll to use as default. Voilà :-).<br />
<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35349HP Compaq 6510b2008-01-21T11:42:48Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* AuthenTec AES2501 fingerprint reader<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to configure PAM. First edit /etc/pam.d/login, and make the first lines look like this:<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_fprint.so<br />
auth sufficient pam_unix.so nullok<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
This will make PAM accept a successful fingerprint scan as a valid login token, if the scan fails, it will fall back to a password. From this moment on, you'll be able to log on with a scan on a tty - enter your username, press Enter, and scan the finger you told pam_fprint_enroll to use as default. Voilà :-).<br />
<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35348HP Compaq 6510b2008-01-21T11:39:44Z<p>B: /* Hardware specifications */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* AuthenTec AES2501 fingerprint reader<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to configure PAM. First edit /etc/pam.d/login, and make the first lines look like this:<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_fprint.so<br />
auth sufficient pam_unix.so nullok<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
This will make PAM accept a successful fingerprint scan as a valid login token, if the scan fails, it will fall back to a password.<br />
<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35347HP Compaq 6510b2008-01-21T11:39:17Z<p>B: </p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to configure PAM. First edit /etc/pam.d/login, and make the first lines look like this:<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_fprint.so<br />
auth sufficient pam_unix.so nullok<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
This will make PAM accept a successful fingerprint scan as a valid login token, if the scan fails, it will fall back to a password.<br />
<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35346HP Compaq 6510b2008-01-21T11:38:51Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to configure PAM. First edit /etc/pam.d/login, and make the first lines look like this:<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_fprint.so<br />
auth sufficient pam_unix.so nullok<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
This will make PAM accept a successful fingerprint scan as a valid login token, if the scan fails, it will fall back to a password.<br />
<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35345HP Compaq 6510b2008-01-21T11:36:51Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to configure PAM. First edit /etc/pam.d/login, and make the first lines look like this:<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_fprint.so<br />
auth sufficient pam_unix.so nullok<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
This will make PAM accept a successful fingerprint scan as a valid login token, if the scan fails, it will fall back to a password.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35344HP Compaq 6510b2008-01-21T11:29:58Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to [http://reactivated.net/fprint/wiki/Pam_fprint#Configuring_PAM configure PAM]. The author has written the wiki for his Gentoo system, on Arch you need to be looking for /etc/pam.d/login, not /etc/pam.d/system.auth.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35343HP Compaq 6510b2008-01-21T11:28:12Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication. The next step is to [http://reactivated.net/fprint/wiki/Pam_fprint#Configuring_PAM configure PAM].<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35342HP Compaq 6510b2008-01-21T11:26:16Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]). Afer installing the package, run<br />
pam_fprint_enroll<br />
and follow the instructions to scan the finger you want to use for authentication.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35341HP Compaq 6510b2008-01-21T11:22:44Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
Integration with the login manager seems possible - for that you'll need amongst others the pam_fprint module installed (find a PKGBUILD [http://aur.archlinux.org/packages/pam_fprint/pam_fprint/PKGBUILD here]).<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35340HP Compaq 6510b2008-01-21T11:11:46Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [ftp://nauseamedialis.org/stijn/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35339HP Compaq 6510b2008-01-21T11:10:49Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://nauseamedialis.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://nauseamedialis.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35338HP Compaq 6510b2008-01-21T11:09:58Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more fiddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35337HP Compaq 6510b2008-01-21T11:09:27Z<p>B: /* IPW3945 ABG wireless LAN */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just touch it and the radio gets enabled :-).<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35336HP Compaq 6510b2008-01-21T11:08:48Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called [http://reactivated.net/fprint/wiki/Main_Page fprint] available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35335HP Compaq 6510b2008-01-21T11:07:27Z<p>B: /* AuthenTec AES2501 fingerprint reader */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
There is a utility called 'fprint' available, together with a libfprint library it depends on. Both are packaged for Arch Linux. The fprint program is still called fprint_demo for the moment, but it works :-).<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM, but this is with the aes2501 kernelspace driver.<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35010HP Compaq 6510b2008-01-14T08:36:26Z<p>B: </p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here]. It seems this behaviour might be changed again with 2.6.24 (before 2.6.23 the value use to be 1 by default), but until it hits stable there is of course no certainty about that :-).<br />
<br />
= Useful links =<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=35009HP Compaq 6510b2008-01-14T08:34:46Z<p>B: </p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
== Issues ==<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].<br />
<br />
==Useful links==<br />
<br />
[[Category:Laptops (English)]]</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=34904HP Compaq 6510b2008-01-10T10:24:23Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file. You'll still need to change virtual terminal though to have X resume correctly!<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=34903HP Compaq 6510b2008-01-10T10:12:32Z<p>B: /* Issues */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file.<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=34902HP Compaq 6510b2008-01-10T10:11:17Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file.<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem able to suspend to disk without needing the <br />
highres=off nohz=off<br />
options in grub.conf.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
On Debian this does not work, so I had to put this in rc.local:<br />
for DOS in /proc/acpi/video/*/DOS<br />
do<br />
echo 1 > ${DOS}<br />
done<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=34901HP Compaq 6510b2008-01-10T10:10:12Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-). The HAL quirk means the vbetool lines are no longer necessary in the 00hacks file.<br><br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem abble to suspend to disk.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
On Debian this does not work, so I had to put this in rc.local:<br />
for DOS in /proc/acpi/video/*/DOS<br />
do<br />
echo 1 > ${DOS}<br />
done<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=34900HP Compaq 6510b2008-01-10T10:08:50Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info file - 20-video-quirk-pm-hp.fdi to be specific, right below the line that says<br />
<match key="system.hardware.vendor" string="Hewlett Packard"><br />
<br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
From hal-info 20071212 on HAL provides this quirk out of the box - no more meddling needed :-).<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem abble to suspend to disk.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
On Debian this does not work, so I had to put this in rc.local:<br />
for DOS in /proc/acpi/video/*/DOS<br />
do<br />
echo 1 > ${DOS}<br />
done<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].</div>Bhttps://wiki.archlinux.org/index.php?title=User_talk:Xpertbg&diff=34029User talk:Xpertbg2007-12-23T14:00:37Z<p>B: New page: Hi there, Can you tell me why someone's experience on Debian is relevant on the Arch wiki? Cheers B</p>
<hr />
<div>Hi there,<br />
<br />
Can you tell me why someone's experience on Debian is relevant on the Arch wiki?<br />
<br />
Cheers<br />
<br />
B</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=33405HP Compaq 6510b2007-12-10T17:44:12Z<p>B: /* Issues */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info files. I have found this not to be working, however, with the present HAL implementation (0.5.10 seems to be in the works according to the HAL homepage, but tarballs are nowhere to be found yet).<br><br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem abble to suspend to disk.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=33404HP Compaq 6510b2007-12-10T17:43:47Z<p>B: </p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info files. I have found this not to be working, however, with the present HAL implementation (0.5.10 seems to be in the works according to the HAL homepage, but tarballs are nowhere to be found yet).<br><br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem abble to suspend to disk.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop seem to experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed here].</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=33403HP Compaq 6510b2007-12-10T17:41:22Z<p>B: /* Issues */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth (haven't found out from what vendor)<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info files. I have found this not to be working, however, with the present HAL implementation (0.5.10 seems to be in the works according to the HAL homepage, but tarballs are nowhere to be found yet).<br><br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem abble to suspend to disk.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop seem to experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6710b owners are affected.<br />
<br />
This is due to a fix in the ACPI video driver in 2.6.23; however, this messes things up for some hardware... You can fix it by putting this in rc.local:<br />
# echo 1 > /proc/acpi/video/*/DOS<br />
More info on this 'fix' can be found on http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=32164Dm-crypt2007-11-10T00:17:24Z<p>B: /* Applying this to a non-root partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/sda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' 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 the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. For detailed info on mkinitcpio (and its configuration) look [[Mkinitcpio|here]].You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystem ..."<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 />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<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 />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a 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/usbstick1:vfat:/secretkey<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<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 delete your temporary secretkey:<br />
rm secretkey<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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=31640HP Compaq 6510b2007-11-02T23:29:46Z<p>B: </p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth (haven't found out from what vendor)<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info files. I have found this not to be working, however, with the present HAL implementation (0.5.10 seems to be in the works according to the HAL homepage, but tarballs are nowhere to be found yet).<br><br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem abble to suspend to disk.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.<br />
<br />
= Issues =<br />
People running kernel 2.6.23 on this laptop seem to experience hard lockups when they close the laptop lid. 2.6.22 does not have this problem. It seems also 6170b owners are affected.</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=31639HP Compaq 6510b2007-11-02T22:55:42Z<p>B: /* Suspend to RAM/disk */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth (haven't found out from what vendor)<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info files. I have found this not to be working, however, with the present HAL implementation (0.5.10 seems to be in the works according to the HAL homepage, but tarballs are nowhere to be found yet).<br><br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
Suspend to disk works fine with the 2.6.22 kernels (at least up to 2.6.22.9). Newer kernels do not seem abble to suspend to disk.<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=31537HP Compaq 6510b2007-10-31T22:09:28Z<p>B: </p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen (if you pick the WXGA+ version). It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth (haven't found out from what vendor)<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info files. I have found this not to be working, however, with the present HAL implementation (0.5.10 seems to be in the works according to the HAL homepage, but tarballs are nowhere to be found yet).<br><br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.</div>Bhttps://wiki.archlinux.org/index.php?title=HP_Compaq_6510b&diff=31536HP Compaq 6510b2007-10-31T22:09:01Z<p>B: /* Hardware specifications */</p>
<hr />
<div>The HP 6510b is a compact yet powerful laptop with a high-resolution screen. It has been labeled "Novel SuSE Enterprise certified" by HP, which should mean Linux runs fine on it.<br />
<br />
= Hardware specifications =<br />
* Intel Core 2 Duo T7100 / T7300<br />
* 2 GB of DDR2 533 Mhz SO-DIMM<br />
* 14.1" 1280x800 WXGA / 1440x900 WXGA+ TFT<br />
* Intel GMA965GM chipset with X3100 onboard GPU<br />
* IPW3945 a/b/g wireless LAN miniPCI with wireless hardware switch<br />
* Broadcom Tigon Gigabit LAN adapter<br />
* Infineon <span title="Trusted Platform Module" style="border-bottom:1px dotted">TPM</span><br />
* [https://gna.org/projects/aes2501/ AuthenTec AES2501 fingerprint reader]<br />
* built-in Bluetooth (haven't found out from what vendor)<br />
* cardreader (supporting SD, MemoryStick, ea.)<br />
* 4x USB 2.0<br />
* 1x FireWire 400 4-pin connector<br />
<br />
= Setup =<br />
<br />
== Intel Core 2 Duo ==<br />
Automatic frequency throttling and voltage adjustment can be enabled by loading the acpi_cpufreq module (this one is to be preferred over the Intel Speedstep ones; those will be deprecated soon). Install cpufreqd, which will pull in cpufreq-utils along with it. Set up both utilities, and add cpufreqd as a daemon to your DAEMONS=() array (in /etc/rc.conf, that is).<br />
<br />
<br />
== X3100 onboard GPU ==<br />
Feature-wise this is an awesome GPU. Opensource drivers that support 3D out of the box. However, it has a problem many of the Intel GPUs have: it will stick to VESA resolutions in the framebuffer. Since the only fitting resolution is 1024x768, that is what you'll when using a framebuffer (on boot, and in a command line environment). You can check what modes the GPU supports like this:<br />
[stijn@lysithea ~]$ cat /sys/class/graphics/fb0/modes<br />
U:1024x768p-75<br />
As you can see this is the only resolution. According to the uvesafb FAQ, if that's all you get, not even uvesafb can fix it up for you. For earlier chipsets (865 and 915 for example) tools like <tt>855resolution</tt> and <tt>915resolution</tt> are available, but the latter does not support the Intel G965M yet. However, there is a patch that fixes that :-). You can find an [http://zero9.org/pkgbuilds/915resolution/PKGBUILD adapted PKGBUILD] and a [http://zero9.org/pkgbuilds/915resolution/965-support.patch patch] here. This allows you to set the 1440x900 resolution, but one needs to dig far deeper into the system to get the system booting in that resolution, it seems.<br />
<br />
<br />
== IPW3945 ABG wireless LAN ==<br />
You have two choices for this card, either go with the present (and soon to be phased out) ieee80211 stack, or with the successor, the mac80211 stack. Both are present in the Arch kernel from 2.6.22 on. With the former you'll need Intel's [http://archlinux.org/packages/13310/ proprietary regulatory daemon] and [http://archlinux.org/packages/13309/ firmware], and - last but not least - [http://archlinux.org/packages/14046/ the driver]; the latter does not require any regulatory daemon, but still requires the [http://archlinux.org/packages/13312/ driver] and [http://archlinux.org/packages/13313/ firmware] to be installed.<br />
<br />
<b>Note:</b> each driver needs different firmware!<br />
<br />
The radio switch is hardware (it sits on the [[HP_Compaq_6510b#Tactile_strip|tactile strip]]), which is pretty convenient. Just press the button and the radio gets enabled :-).<br />
<br />
<br />
== Broadcom NetLink BCM5787M Gigabit LAN ==<br />
No setup required, it just needs the tg3 module.<br />
<br />
<br />
== Suspend to RAM/disk ==<br />
I use pm-utils for this, which is pretty straightforward. X tends to hang once in a while after resuming, you can fix this (although not perfectly) by adding the following VBE Tool 'hack' to in /etc/pm/sleep.d/00hacks:<br><br />
#!/bin/bash<br />
case $1 in<br />
suspend)<br />
chvt 1<br />
vbetool vbestate save > /tmp/vbe<br />
;;<br />
resume)<br />
vbetool post<br />
vbetool vbestate restore < /tmp/vbe<br />
chvt 7<br />
;;<br />
esac<br />
If your screen remains blank, just try moving your mouse cursor, your screen should display just fine then.<br><br />
Alternatively, you could leave pm-utils alone and add a so-called [http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html quirk] to HAL's info files. I have found this not to be working, however, with the present HAL implementation (0.5.10 seems to be in the works according to the HAL homepage, but tarballs are nowhere to be found yet).<br><br />
This is the quirk I cooked up, following the instructions on the HAL page:<br />
<!--HP 6510b--><br />
<match key="system.hardware.product" contains="6510b"><br />
<merge key="power_management.quirk.vbe_post" type="bool">true</merge><br />
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge><br />
</match><br />
<br />
A third alternative would be to add some VbeTool options to your Xorg.conf, that seems to do the trick too. Haven't tried it myself, however.<br />
<br />
If you are using Xfce, you can suspend to RAM or disk from the Xfce logout dialog. You do need a modified session manager for this though. You can find the [http://zero9.org/pkgbuilds/xfce4-session/logout_dialog-suspend-hibernate.patch patch that adds that functionality] and the corresponding [http://zero9.org/pkgbuilds/xfce4-session/PKGBUILD PKGBUILD] online.<br />
<br />
<br />
== FireWire ==<br />
FireWire is supported out of the box, however, for FireWire HD support, you might need to load the sbp2 module (that is, if you are using the common stack, since a new one is in the works and already present in the kernel). You have the common stack if you run stock Arch kernels.<br />
<br />
<br />
== AuthenTec AES2501 fingerprint reader ==<br />
As duly pointed out on the forums, fingerprint readers are more a threat to your privacy than a safeguard. Your fingerprints (unless you are paranoid and type with gloves on) are likely to be all over your keyboard, rendering the 'security' purpose of this device useless. Keep this in mind if you intend to use the reader as a replacement for your password; fingerprints can be duplicated easily with basic stuff (graphite ea.).<br><br />
A driver can be downloaded [https://gna.org/projects/aes2501/ here], a PKGBUILD can be found [http://zero9.org/pkgbuilds/aes2501/PKGBUILD here]. You will also need a userspace utility to scan your initial fingerprint and save it for authentication purposes, called aes2501-wy. [http://packages.debian.net/unstable/graphics/aes2501-wy Debian] seems to be the only distro having a package, but then again, those guys package everything ;-).<br> The vanilla sources do not seem to work at all, while the Debian package does to a certain extent: it runs, but doesn't see my finger.<br />
[http://bbs.archlinux.org/viewtopic.php?id=36134 On the forum] you can also find a topic that covers setting up your fingerprint reader with PAM and SLiM.<br />
The aes2501 driver will not suspend correctly, so you'll have to add a module probe and a module removal to the 00hacks file you created previously.<br />
<br />
<br />
== Tactile strip ==<br />
This laptop sports a fancy tactile strip, providing some extra buttons as well as volume control (toggling mute and changing volume). Since hal seems not to be working yet for the quirks, I didn't bother trying to [http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html get hal working for my multimedia keys] either. That's where [[Extra_Keyboard_Keys#The_Keytouch_Program|keytouch]] steps in. The HP NC6320 settings (pre-supplied by keytouch) seem to work just fine for muting & adjusting the volume. The 'Help' key (left to the radio switch) fires up your DE's help center if everything goes well, the button to the right is recognised too (you have to configure it though ;-)).<br />
As a fancy plus, you'll get a nice OSD when you mute/unmute or change volume.<br />
<br />
<br />
== lspci output ==<br />
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)<br />
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)<br />
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)<br />
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)<br />
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)<br />
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)<br />
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)<br />
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)<br />
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)<br />
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)<br />
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)<br />
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)<br />
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)<br />
18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)<br />
<br />
<br />
== lsusb output ==<br />
Bus 007 Device 001: ID 0000:0000 <br />
Bus 006 Device 001: ID 0000:0000 <br />
Bus 005 Device 001: ID 0000:0000 <br />
Bus 004 Device 001: ID 0000:0000 <br />
Bus 003 Device 003: ID 08ff:2580 AuthenTec, Inc. <br />
Bus 003 Device 001: ID 0000:0000 <br />
Bus 002 Device 001: ID 0000:0000 <br />
Bus 001 Device 003: ID 03f0:171d Hewlett-Packard <br />
Bus 001 Device 001: ID 0000:0000<br />
<br />
The AuthenTec device is the fingerprint reader, the Hewlett-Packard one is the Bluetooth module.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31493Dm-crypt2007-10-30T20:57:46Z<p>B: /* Configure System */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' 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 the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. For detailed info on mkinitcpio (and its configuration) look [[Mkinitcpio|here]].You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystem ..."<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 />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a 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/usbstick1:vfat:/secretkey<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<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 delete your temporary secretkey:<br />
rm secretkey<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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31492Dm-crypt2007-10-30T20:57:14Z<p>B: /* Configure System */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' 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 the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. For detailed info on mkinitcpio (and its configuration) look [[Mkinitcpio|here]].You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystem ..."<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 />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a 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/usbstick1:vfat:/secretkey<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<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 delete your temporary secretkey:<br />
rm secretkey<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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31386Dm-crypt2007-10-27T22:33:20Z<p>B: /* Store the key externally (USB stick) */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' 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 the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a 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/usbstick1:vfat:/secretkey<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<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 delete your temporary secretkey:<br />
rm secretkey<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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31385Dm-crypt2007-10-27T22:31:25Z<p>B: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' 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 the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a plain (visible) file ===<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<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 delete your temporary secretkey:<br />
rm secretkey<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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31379Dm-crypt2007-10-27T15:02:27Z<p>B: /* Encrypted Swap */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' If you've decided to go for option two for encrypted swap (see Encryped Swap below), you should set up <tt>/dev/mapper/swap</tt> in the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<br />
<br />
==== Exit Install ====<br />
Now that the install is finished the only thing left todo 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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a plain (visible) file ===<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
And add this keyfile 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 dataloss 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 delete your temporary secretkey:<br />
rm secretkey<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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31378Dm-crypt2007-10-27T14:12:22Z<p>B: /* Store the key between the MBR and first partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' If you've decided to go for option two for encrypted swap (see Encryped Swap below), you should set up <tt>/dev/mapper/swap</tt> in the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<br />
<br />
==== Exit Install ====<br />
Now that the install is finished the only thing left todo 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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a plain (visible) file ===<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
And add this keyfile 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 dataloss 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 delete your temporary secretkey:<br />
rm secretkey<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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31377Dm-crypt2007-10-27T13:35:06Z<p>B: /* Store the key between the MBR and first partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' If you've decided to go for option two for encrypted swap (see Encryped Swap below), you should set up <tt>/dev/mapper/swap</tt> in the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<br />
<br />
==== Exit Install ====<br />
Now that the install is finished the only thing left todo 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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a plain (visible) file ===<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<br />
<br />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
And add this keyfile 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 dataloss 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 delete your temporary secretkey<br />
rm secretkey<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). All that matters is they are powers of two. 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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31376Dm-crypt2007-10-27T13:33:20Z<p>B: /* Store the key as a plain (visible) file */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' If you've decided to go for option two for encrypted swap (see Encryped Swap below), you should set up <tt>/dev/mapper/swap</tt> in the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<br />
<br />
==== Exit Install ====<br />
Now that the install is finished the only thing left todo 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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Store the key as a plain (visible) file ===<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Store the key between the MBR and first partition ===<br />
<br />
You should tell mkinitcpio about your udev-rule; add the following line into /etc/mkinitcpio.conf:<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<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 />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
And add this keyfile 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 dataloss 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 delete your temporary secretkey<br />
rm secretkey<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). All that matters is they are powers of two. 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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31375Dm-crypt2007-10-27T13:32:48Z<p>B: /* Store the key between the MBR and first partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' If you've decided to go for option two for encrypted swap (see Encryped Swap below), you should set up <tt>/dev/mapper/swap</tt> in the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<br />
<br />
==== Exit Install ====<br />
Now that the install is finished the only thing left todo 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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
=== Store the key as a plain (visible) file ===<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
<br />
=== Store the key between the MBR and first partition ===<br />
<br />
You should tell mkinitcpio about your udev-rule; add the following line into /etc/mkinitcpio.conf:<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<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 />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
And add this keyfile 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 dataloss 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 delete your temporary secretkey<br />
rm secretkey<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). All that matters is they are powers of two. 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! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31374Dm-crypt2007-10-27T13:30:39Z<p>B: /* External Key Files */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' If you've decided to go for option two for encrypted swap (see Encryped Swap below), you should set up <tt>/dev/mapper/swap</tt> in the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<br />
<br />
==== Exit Install ====<br />
Now that the install is finished the only thing left todo 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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Store the key externally (USB stick) ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
=== Store the key as a plain (visible) file ===<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
<br />
=== Store the key between the MBR and first partition ===<br />
<br />
You should tell mkinitcpio about your udev-rule; add the following line into /etc/mkinitcpio.conf:<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<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 />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
And add this keyfile 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 dataloss 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 delete your temporary secretkey<br />
rm secretkey<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
<br />
you would have to replace cryptkey=/dev/usbstick:2048:2048 with cryptkey=/dev/usbstick:8192:2048<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 />
That's all, reboot and have fun! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>Bhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=31373Dm-crypt2007-10-27T13:26:55Z<p>B: /* External Key Files */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why LUKS? ==<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 what the [[Encrypted_Root_Filesystem]] HOWTO uses. If used [http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt with the ESSIV option (Encrypted Sector Salt Initial Value)], it becomes immune to the two most serious vulnerabilities of cryptoloop.<br />
<br />
[http://luks.endorphin.org/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://luks.endorphin.org/ 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, with ESSIV enabled by default, and so should be about as secure as loop-AES (depending on how you manage passwords and key files etc). 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 />
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 />
== The Steps ==<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 />
=== Preparations ===<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 with random data. This step can take a lot of time depending on your system configuration. A Pentium M 1.2 GHz can write random data at about 100 MB per minute.<br />
# dd if=/dev/urandom of=/dev/hda<br />
<br />
=== Partitioning ===<br />
Next, 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 was encrypted, then your bootloader wouldn't be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
<br />
=== Setting up LUKS ===<br />
Now that we have our real, physical partitions set up, we need to tell cryptsetup to create a new (encrypted) block device based on our root and home partitions, <tt>/dev/sda3</tt> and <tt>/dev/sda4</tt>. But first we have to load the modules that cryptsetup needs.<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-i585".<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -y luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -y luksFormat /dev/sda4<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 />
<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, and another one called <tt>/dev/mapper/home</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> or <tt>/dev/sda4</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> or <tt>/dev/mapper/home</tt> 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:''' If you've decided to go for option two for encrypted swap (see Encryped Swap below), you should set up <tt>/dev/mapper/swap</tt> in the same way as you've just set up <tt>/dev/mapper/home</tt>.<br />
<br />
=== Arch Installer ===<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 and it will do the rest, as it normally would.<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 "Set Filesystem Mountpoints".<br />
When asked for your / (root) partition, do NOT select <tt>/dev/sda3</tt> as you normally would. Select <tt>/dev/mapper/root</tt> instead. Similarly, use <tt>/dev/mapper/home</tt> instead of <tt>/dev/sda4</tt> as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition.<br />
<br />
==== Select packages ====<br />
The base package contains all required programs. If you want you can add others but it is not required.<br />
<br />
'''Note:''' If you are installing from a release predating Voodoo (which you really shouldn't) you need to install the <tt>system/cryptsetup</tt> package.<br />
<br />
==== Install packages ====<br />
Let the setup install the packages.<br />
<br />
==== Configure System ====<br />
'''Attention:''' You need to answer the question ''Do you need support for booting from encrypted volumes?'' with ''yes''.<br />
<br />
Let the <tt>hwdetect</tt> program detect your hardware and answer the questions asked suiting your needs, respecting the above mentioned option.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio</tt>. You have to make sure that your <tt>HOOKS</tt> looks something like this:<br />
HOOKS="... encrypt ... filesystem ..."<br />
It is important that the <tt>encrypt</tt> hook comes before the <tt>filesystem</tt> one. If you store your key on an external USB device (e.g. an USB stick, you need to add the USB hook too:<br />
HOOKS="... encrypt ... usb filesystem ..."<br />
<br />
==== Install Kernel ====<br />
Select the kernel and follow the instructions presented to you by the installer.<br />
When asked to check over the <tt>/mnt/etc/mkinitcpio.d/kernel26-fallback.conf</tt> file make sure the <tt>HOOKS</tt> line looks the same as mentioned above.<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 />
<br />
'''LILO:''' If someone has experience in using LUKS with LILO please fill in.<br />
<br />
==== Exit Install ====<br />
Now that the install is finished the only thing left todo 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 />
# vim /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
If you want to use a key file, generate a key and add it to the LUKS partition by executing the following:<br />
# head -n 220 /dev/urandom | tail -n 200 > /mnt/etc/home.key<br />
# cryptsetup luksAddKey /dev/sda4 /mnt/etc/home.key<br />
Enter any LUKS passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br><br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /etc/home.key<br />
<br />
Now the only thing left to do is reboot. Upon booting you should 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 (mypassword) and everything should boot.<br />
Once you've booted and logged in, type <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 />
== Encrypted Swap ==<br />
<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, but less elegant), 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 hda4 with hda2.<br />
<br />
For the first option, we're not going to use LUKS. We're going to set up dm-crypt directly. 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/hda2 /dev/urandom "-c aes-cbc-essiv:sha256 -h sha256 -s 256" >> /mnt/etc/crypttab<br />
<br />
This will set up <tt>/dev/mapper/swap</tt>, with underlying block device <tt>/dev/hda2</tt>, using a random 256-bit key taken from /dev/urandom. Note the use of ESSIV, as in aes-cbc-essiv. That prevents a major cryptographic attack called watermarking.<br />
<br />
Now, the bootscripts won't be able to automatically use the resulting partition for swap, because mkswap needs to be run first. So delete the swap entry from <tt>/mnt/etc/fstab</tt> and add lines to <tt>rc.local</tt> to set up the swap:<br />
# sed -i /^swap/d /mnt/etc/fstab<br />
# echo "mkswap /dev/mapper/swap" >> /mnt/etc/rc.local<br />
# echo "swapon /dev/mapper/swap" >> /mnt/etc/rc.local</pre><br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== External Key Files ==<br />
<br />
First you should 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 />
udevtrigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
To store the key file, you have two options. The first is less risky than the other :-). We assume you are using a FAT-formatted USB stick here, if not, change the MODULES=() line in /etc/mkinitcpio.conf accordingly to provide support for your device.<br />
<br />
<br />
'''Store the key as a plain (visible) file'''<br />
<br />
Mount your stick, generate a keyfile and tell cryptsetup to use it like above. Then put it on your FAT partition. Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots and similar characters - the encrypt hook will fail to find the keyfile.<br />
<br />
Now you have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage:<br />
further you should tell mkinitcpio about your udev-rule:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
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 />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<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/usbstick1:vfat:/secretkey<br />
<br />
This assumes /dev/usbstick1 is the FAT partition of your choice.<br />
<br />
That's all, reboot and have fun!<br />
<br />
<br />
'''Store the key between the MBR and first partition'''<br />
<br />
You should tell mkinitcpio about your udev-rule; add the following line into /etc/mkinitcpio.conf:<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<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 />
Generate a temporary keyfile:<br />
dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
And add this keyfile 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 dataloss 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 delete your temporary secretkey<br />
rm secretkey<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
<br />
you would have to replace cryptkey=/dev/usbstick:2048:2048 with cryptkey=/dev/usbstick:8192:2048<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 />
That's all, reboot and have fun! Ad look if your partitions still work after that ;-).<br />
<br />
== Applying this to a non-root partition ==<br />
<br />
<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.</div>B