Difference between revisions of "Official Arch Linux Install Guide Appendix"

From ArchWiki
Jump to: navigation, search
(How to Build Packages: de-duplication)
(Synchronizing Your ABS Tree: de-duplication)
Line 161: Line 161:
 
==Synchronizing Your ABS Tree==
 
==Synchronizing Your ABS Tree==
  
You can synchronize all the required package building files in
+
See [[Arch Build System]]
/var/abs by running the abs script as root. A
+
working internet connection is also required, of course. Using SVN as
+
the transfer medium allows you to follow different version trees
+
within ABS - this can be configured in /etc/abs/supfile.arch. For
+
example, the default supfile is set to track the core package tree,
+
which is bleeding-edge and the recommended source to follow. You can
+
also follow specific versions. See the comments in the supfiles for
+
more info.
+
 
+
ABS supports multiple repositories, which can be enabled or disabled
+
in /etc/abs/abs.conf. By default, abs will follow the core and
+
extra repositories, but not anything else.
+
 
+
You will also see an /etc/abs/supfile.extra file. This will give you
+
access to all the unofficial build scripts that were not included in
+
the main ABS repository. If you do not want to use this repository,
+
you can delete the file, but usually it makes more sense to edit
+
abs.conf accordingly instead, and disable the repositories you don't
+
need.
+
  
 
==How to Build Packages==
 
==How to Build Packages==

Revision as of 17:43, 7 December 2010

Tango-edit-cut.pngThis section is being considered for removal.Tango-edit-cut.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:Official Arch Linux Install Guide Appendix#)
Template:Article summary start

Template:Article summary text Template:Article summary heading Template:I18n entry Template:I18n entry Template:I18n entry Template:Article summary heading Template:Article summary wiki (If you are new to Arch) Template:Article summary wiki Template:Article summary end

Adding a Window Manager/Desktop Environment

See Window Manager and Desktop Environment

Boot Scripts

See Arch Boot Process

User & Group Management

See Users and Groups

Internet Access

Due to a lack of developers for dialup issues, connecting Arch to the Internet with a dialup line is requiring a lot of manual setup. If at all possible, set up a dedicated router which you can then use as a default gateway on the Arch box.

There are quite a few dialup related documents in the Arch Linux Wiki

Analog Modem

To be able to use a Hayes-compatible, external, analog modem, you need to at least have the ppp package installed. Modify the file /etc/ppp/options to suit your needs and according to man pppd. You will need to define a chat script to supply your username and password to the ISP after the initial connection has been established. The manpages for pppd and chat have examples in them that should suffice to get a connection up and running if you're either experienced or stubborn enough. With udev, your serial ports usually are /dev/tts/0 and /dev/tts/1.

Instead of fighting a glorious battle with the plain pppd, you may opt to install wvdial or a similar tool to ease the setup process considerably.

In case you're using a so called WinModem, which is basically a PCI plugin card working as an internal analog modem, you should indulge in the vast information found on the LinModem homepage.

ISDN

Setting up ISDN is done in three steps:

  1. Install and configure hardware
  2. Install and configure the ISDN utilities
  3. Add settings for your ISP

The current Arch stock kernels include the necessary ISDN modules, meaning that you won't need to recompile your kernel unless you're about to use rather odd or old ISDN hardware. After physically installing your ISDN card in your machine or plugging in your USB ISDN-Box, you can try loading the modules with modprobe. Nearly all passive ISDN PCI cards are handled by the hisax module which needs two parameters; type and protocol. You must set protocol to '1' if your country uses the 1TR6 standard, '2' if it uses EuroISDN (EDSS1), '3' if you're hooked to a so called leased-line without D-channel, and '4' for US NI1.

Details on all those settings and how to set them is included in the kernel documentation, more specifically in the isdn subdirectory, available online. The type parameter depends on your card; A list of all possible types is to be found in the README.HiSax kernel documentation. Choose your card and load the module with the appropriate options like this:

 modprobe hisax type=18 protocol=2

This will load the hisax module for my (Dennis) ELSA Quickstep 1000PCI, being used in Germany with the EDSS1 protocol. You should find helpful debugging output in your /var/log/everything.log file in which you should see your card being prepared for action. Please note that you will probably need to load some usb modules before you can work with an external USB ISDN Adapter.

Once you confirmed that your card works with certain settings, you can add the module options to your /etc/modprobe.conf:

 alias ippp0 hisax
 options hisax type=18 protocol=2

Alternatively you can only add the options line here, and add hisax to your MODULES array in the rc.conf. Your choice, really, but this example has the advantage that the module will not be loaded until it's really needed.

That being done you should have working, supported hardware. Now you need the basic utilities to actually use it!

Install the isdn4k-utils package, and read the manpage to isdnctrl, it'll get you started. Further down in the manpage you will find explanations on how to create a configuration file that can be parsed by isdnctrl, as well as some helpful setup examples.

Please note that you have to add your SPID to your MSN setting separated by a colon if you use US NI1.

After you configured your ISDN card with the isdnctrl utility, you should be able to dial into the machine you specified with the PHONE_OUT parameter, but fail the username and password authentication. To make this work add your username and password to /etc/ppp/pap-secrets or /etc/ppp/chap-secrets as if you were configuring a normal analogous PPP link, depending on which protocol your ISP uses for authentication. If in doubt, put your data into both files.

If you set up everything correctly, you should now be able to establish a dialup connection with isdnctrl dial ippp0 as root. If you have any problems, remember to check the logfiles!

DSL (PPPoE)

These instructions are only relevant to you if your PC itself is supposed to manage the connection to your ISP. You do not need to do anything but define a correct default gateway if you are using a separate router of some sort to do the grunt work.

Before you can use your DSL online connection, you will have to physically install the network card that is supposed to be connected to the DSL-Modem into your computer. After adding your newly installed network card to the modprobe.conf or the MODULES array, you should install the rp-pppoe package and run the pppoe-setup script to configure your connection. After you have entered all required data, you can connect and disconnect your line with

# /etc/rc.d/adsl start
# /etc/rc.d/adsl stop

respectively. The setup usually is rather easy and straightforward, but feel free to read the manpages for hints. If you want to automatically dial in on bootup, add adsl to your DAEMONS array, and put a ! before the network entry, since the network is handled by adsl now.

Package Management

Pacman

See pacman

Accessing Repositories

See Official Repositories

Arch Build System (ABS)

Binary vs. Source

See Arch Build System

Synchronizing Your ABS Tree

See Arch Build System

How to Build Packages

See Creating Packages

Package Guidelines

When building a package for Arch Linux, you should adhere to the package guidelines below, especially if you would like to contribute your new package to Arch Linux.

Package Naming

  • Package names should consist of alphanumeric characters only; all letters should be lowercase.
  • Package versions should be the same as the version released by the author. Versions can include letters if need be (eg, nmap'sversion was 2.54beta32 a good while ago). Version tags may not include hyphens! Letters, numbers, and periods only.
  • Package releases are specific to Arch Linux packages. These allow users to differentiate between newer and older package builds. When a new package version is first released, the release countstarts at 1. Then as fixes and optimizations are made, the package will be re-released to the AL public and the release number will increment. When a new version comes out, the release count resets to 1. Package release tags follow the same naming restrictions as version tags.


Directories

Configuration files should be placed in the /etc directory. If there's more than one configuration file, it's customary to use a subdirectory in order to keep the /etc area as clean as possible. Use /etc/{pkgname}/ where {pkgname} is the name of your package (or a suitable alternative, eg, apache uses /etc/httpd/).

Package files should follow these general directory guidelines:

 /etc             System-essential configuration files
 /usr/bin         Application binaries
 /usr/sbin        System binaries
 /usr/lib         Libraries
 /usr/include     Header files
 /usr/lib/{pkg}   Modules, plugins, etc.
 /usr/share/man   Manpages
 /usr/share/{pkg} Application data
 /etc/{pkg}       Configuration files for {pkg}
 /opt             Packages that do not fit cleanly into the GNU filesystem layout can be
                  placed here. If a package's files can be cleanly placed into the above
                  directories, then do so. If there are other high-level directories
                  that do not fit, then you should use /opt.

For example, the acrobat package has Browser, Reader, and Resource directories sitting at the same level as the bin directory. This doesn't fit into a normal GNU filesystem layout, so we place all the files in a subdirectory of /opt.

Clear as mud? Good.


makepkg Duties

When you use makepkg to build a package for you, it does the following automatically:

  1. Checks if package dependencies are installed
  2. Downloads source files from servers
  3. Unpacks source files
  4. Performs any necessary patching, if specified in the PKGBUILD script
  5. Builds the software and installs it in a fake root
  6. Removes /usr/doc, /usr/info, /usr/share/doc, and /usr/share/info from the package
  7. Strips symbols from binaries
  8. Strips debugging symbols from libraries
  9. Generates the package meta file which is included with each package
  10. Compresses the fake root into the package file
  11. Stores the package file in the configured destination directory (cwd by default)


Other

Do not introduce new variables into your PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables used in makepkg itself. If a new variable is absolutely required, prefix the variable name with an underscore.

Avoid using /usr/libexec/ for anything. Use /usr/lib/{pkgname} instead.

The "Packager" field from the package meta file can be customized by the package builder by modifying the appropriate option in the /etc/makepkg.conf file, or alternatively by exporting the PACKAGER environment variable before building packages with makepkg:

 export PACKAGER="John Doe <your.email>"


Submitting Packages

If you'd like to submit packages, please take a look at the Arch User Repository and their guidelines. New packages should be submitted to the AUR.

If you're submitting a package, please do the following:

  • Please add a comment line to the top of your PKGBUILD file that follows this format:
 Contributor: Your Name <your.email>
  • Verify the package dependencies (eg, run ldd on dynamic executables, check tools required by scripts, etc.). It's also a good idea to use the namcap utility, written by Jason Chu jason@archlinux.org, to analyze the sanity if your package. namcap will tell you about bad permissions, missing dependencies, un-needed dependencies, and other common mistakes. You can install the namcap package with pacman as usual.
  • All packages should come as a compressed tar file containing a directory with the newly built package, the PKGBUILD, filelist, and additional files (patches, install, ...) in it. The archive name should at least contain the name of the package.
  • Read the appropriate documents regarding the AUR, and the newest version of the packaging guildelines on the AUR Homepage.

Frequently Asked Questions

The FAQs listed here are only covering any problems that may keep you from booting or installing an initial Arch Linux system. If you have questions regarding further usage of the system utilities, X11 setup, etc. or how to configure your hardware, please head over to the Wiki. If you think an issue is not covered here that should be, please notify the author of this document, whose address is to be found at the very top of this file.

During the initial package installation, pacman fails to resolve dependencies for package A because package B is not in the package set

Unless something is very broken and thus very likely to be reported by multiple people soon, you probably just forgot to mount your target partitions properly. This causes pacman to decompress the package database into the initial ramdisk, which fills up quite nicely and ultimatively leads to this error.

Make sure that you use the DONE and not the CANCEL option offered by the Filesystem Mountpoints menu to apply your choices. This error should not happen if you use the Auto-Prepare feature; If it does nevertheless, please report this as a bug.

How can I install packages from the install CD with pacman --sync (so it resolves dependencies for me)?

If you would rather have packages install from the CD instead of downloading them, then mount the install CD somewhere (eg. /mnt/cd) and add this line right below the [core] line in /etc/pacman.conf: Server = file:///mnt/cd

Replace /mnt/cd with the mountpoint you chose. Then use pacman --sync as you normally would - It will now check the /mnt/cd directory first for packages.

How can I create multiple swap partitions during the install?

Naturally you won't be able to use the Auto-Prepare feature if you want to create and use multiple swap partitions. Create the partitions manually instead, and create as many swap partitions as your little heart desires. Go through the rest of the disk preparation steps, don't mind that you're only asked for one swap partition during the mount-point setting. Once you're through with the install and are about to edit your system configuration files, you can edit the fstab file and include a line for every swap device you created earlier. Simply copy the automatically generated swap line, and modify the referenced device according to your setup. The additional swaps will be activated after the bootup when swapon -a is being run by the initscripts. Make sure you ran mkswap on all of your swap partitions manually, or else your system will complain on bootup!

If, for any odd reason, you can not wait until after the installation with activating multiple swap partitions or files, you will have to open a shell on one of the virtual terminals and issue the swapon <device> for every swap drive or file you partitioned/readied before with mkswap. Then continue as explained above with the install.

In case you are honestly contemplating setting up multiple swap files or drives, you should keep in mind that a kernel that needs to swap is actually crying bitterly for more RAM, not more swap space. Please keep your penguin well fed. Thank you.

How do I reconfigure LILO from the rescue system?

As a first step you simply boot from the Arch Install CD or disks. If your partitions are intact and don't need checking, you can try choosing one of the recovery boot options according to your partition layout, or fiddle with the GRUB boot manager settings on your own to get your existing system to boot properly. That will boot directly into your system, and you can skip all but the last step of actually reconfiguring and running LILO.

If you cannot boot your old root directly, boot from the CD as if you were going to start an installation. Once you're in a shell, you mount the root partition of your harddisk into the /mnt directory, for example like this:

 mount /dev/hda3 /mnt

Then you mount any other partitions to their respective mount points within that root of yours, for example a /boot partition:

 mount /dev/hda1 /mnt/boot

Now you need to mount a /dev tree in the /mnt area, where LILO will be able to find it:

 /mnt/bin/mount --bind /dev /mnt/dev

Once everything is mounted, make this /mnt directory your new root with the chroot /mnt command. This will start a new shell and drop you into the /mnt directory, which will be considered your / from then on.

Now you can edit /etc/lilo.conf to your liking and run lilo to fix anything that needs fixing. Simply type exit when you want to break out of this root again, back into the original file tree. You can now reboot and test your changes.

I can't ssh into my machine!

The default configuration will reject all incoming connections, not only ssh connections. Edit your /etc/hosts.allow file and add the line: sshd:all to allow all incoming ssh connections.

How should I load modules during boot now?

If you want to load a module unconditionally without a specific device binding, add the name of the module to the MODULES array of your /etc/rc.conf. For on demand loading on device access, add it as usual with the alias and optioncommands to your /etc/modprobe.conf, in the rare cases that the automatisms employed by udev don't cut it. To pass any options to a module you want to load through the MODULES array, only add the appropriate options line to your /etc/modprobe.d/modprobe.conf.

Kernel refuses to boot because of "lost interrupt"

Kernel refuses to boot. It locks at: IRQ probe failed for hda hda lost interrupt

This or a similar error occurs for some HD controllers on kernel 2.6.x. A workaround is to pass the acpi=off option to the kernel at boot time.

I get "access denied" errors trying to play music or read DVDs

Add your user to the optical and audio groups.

 gpasswd -a johndoe optical
 gpasswd -a johndoe audio

Logout, then login again as that user (eg. johndoe) so the group changes can take effect, and the device permissions shouldn't be a problem anymore.

If you have a DVD drive, you may want to create a /dev/dvd symlink to your real DVD device. Usually udev does this for you already, but this will serve well as an example for setting up similar symlinks.

For example, if your DVD drive is accessible through /dev/sdc, you can do the following as root:

 cat >>/etc/udev/rules.d/00.rules <<EOF
 > KERNEL="sdc", NAME="sdc", SYMLINK="dvd"
 > EOF
 /etc/start_udev
 mount /dev/pts
 mount /dev/shm