|
|
| (9 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | [[Category: General (English)]] | + | #REDIRECT [[General Recommendations]] |
| − | {{Deletion}}
| |
| − | {{Article summary start}}
| |
| − | {{Article summary text|Appendix of the Official Arch Linux Install Guide}}
| |
| − | {{Article summary heading|Available Languages}}
| |
| − | {{i18n_entry|English|Official Arch Linux Install Guide Appendix}}
| |
| − | {{i18n_entry|Italiano|Official Arch Linux Install Guide Appendix (Italiano)}}
| |
| − | {{i18n_entry|简体中文|Arch 官方安装指南附录 (简体中文)}}
| |
| − | {{Article summary heading|Related articles}}
| |
| − | {{Article summary wiki|Beginners Guide}} (If you are new to Arch)
| |
| − | {{Article summary wiki|Official Arch Linux Install Guide}}
| |
| − | {{Article summary end}}
| |
| − | | |
| − | ==Adding a Window Manager/Desktop Environment==
| |
| − | See [[Window Manager]] and [[Desktop Environment]]
| |
| − | | |
| − | ==Boot Scripts==
| |
| − | See [[Arch Boot Process]
| |
| − | | |
| − | ==User & Group Management==
| |
| − | | |
| − | Users and groups can be added and deleted with the standard commands
| |
| − | provided in the util-linux package: useradd, userdel, groupadd,
| |
| − | groupdel, passwd, and gpasswd. The typical way of adding a user is
| |
| − | similar to this procedure:
| |
| − | useradd -m -s /bin/bash johndoe
| |
| − | passwd johndoe
| |
| − | | |
| − | The first command will add the user named johndoe to the system,
| |
| − | create a home directory for him at /home/johndoe, and place some
| |
| − | default login files in his home directory. It will also set his login
| |
| − | shell to be /bin/bash. The second command will ask you for a password
| |
| − | for the johndoe user. A password is required to activate the account.
| |
| − | | |
| − | As an alternative to the useradd command, the adduser script is also
| |
| − | available to interactively create new users on your system simply by
| |
| − | answering questions.
| |
| − | | |
| − | See the manpages for more information on the remaining commands. It is
| |
| − | a good idea to create one or multiple normal users for your day-to-day
| |
| − | work to fully use the available security features and minimize
| |
| − | potential damage that may be the result of using the root user for
| |
| − | anything but system administration tasks.
| |
| − | | |
| − | Additional information about adding users and groups can be found on the [[User Management]] wiki and on the [[Groups]] wiki.
| |
| − | | |
| − | ==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:
| |
| − | #Install and configure hardware
| |
| − | #Install and configure the ISDN utilities
| |
| − | #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==
| |
| − | | |
| − | [[pacman|Pacman]] is the package manager which tracks all the software installed
| |
| − | on your system. It has simple dependency support and uses the standard
| |
| − | gzipped tar archive format for all packages. Some common tasks are
| |
| − | explained below with the respective commands in long and short option
| |
| − | form. For an up to date explanation of pacman's options, read man
| |
| − | pacman. This overview is merely scratching the surface of pacman's
| |
| − | current capabilities.
| |
| − | | |
| − | Typical tasks:
| |
| − | | |
| − | ===Adding/Upgrading a package with a package file===
| |
| − | | |
| − | pacman --upgrade foo.pkg.tar.gz
| |
| − | pacman -U foo.pkg.tar.gz
| |
| − | | |
| − | This will install the foo.pkg.tar.gz package on the system. If
| |
| − | dependencies are missing, pacman will exit with an error and report
| |
| − | the missing deps, but not attempt to resolve the dependencies
| |
| − | automatically. Look at the --sync option if you expect this
| |
| − | functionality. Adding multiple package files is possible, and if the
| |
| − | listed files depend on each other, the packages will be automatically
| |
| − | installed in the correct order. This will additionally upgrade an already-installed package at no extra cost.
| |
| − | | |
| − | ===Removing packages===
| |
| − | | |
| − | pacman --remove foo
| |
| − | pacman -R foo
| |
| − | | |
| − | This will remove all files belonging to the package named foo, except
| |
| − | for configuration files that have been edited. Only supply the name of
| |
| − | the package to this command, without the pkg.tar.gz suffix.
| |
| − | | |
| − | To remove any and all trace of a package, add the --nosave option to
| |
| − | the above command.
| |
| − | | |
| − | ===Refreshing the package list===
| |
| − | | |
| − | pacman --sync --refresh
| |
| − | pacman -Sy
| |
| − | | |
| − | This will retrieve a fresh master package list from the repositories
| |
| − | defined in the /etc/pacman.conf file and uncompress it into the
| |
| − | database area. You should use this before using --sysupgrade to make
| |
| − | sure you get the newest packages. Depending on your pacman.conf
| |
| − | settings, this command may require a working internet connection to
| |
| − | access FTP/HTTP-based repositories. This option is quite similar to
| |
| − | Debian's apt-get update command.
| |
| − | | |
| − | ===Upgrading the system===
| |
| − | | |
| − | pacman --sync --sysupgrade
| |
| − | pacman -Su
| |
| − | | |
| − | This command will upgrade all packages that are out-of-date on your
| |
| − | system by comparing the local package version to the versions in the
| |
| − | master package list that get downloaded with the --refresh command.
| |
| − | It's a good idea to run this regularly to keep your system up to date.
| |
| − | Note that this command does NOT implicitly refresh the master package
| |
| − | list, so it's usually wiser to combine both commands into one like
| |
| − | this:
| |
| − | pacman --sync --refresh --sysupgrade
| |
| − | pacman -Syu
| |
| − | | |
| − | With these options pacman will automatically retrieve the current
| |
| − | master package list and do a full system upgrade to the latest
| |
| − | packages with all dependencies being automagically resolved. You will
| |
| − | want to run this quite often.
| |
| − | | |
| − | ===Adding/Upgrading a package from the repositories===
| |
| − | | |
| − | pacman --sync foo
| |
| − | pacman -S foo
| |
| − | | |
| − | Retrieve and install package foo, complete with all dependencies it
| |
| − | requires. Before using any sync option, make sure you refreshed the
| |
| − | package list, or add --refresh or -y to the options to do it before
| |
| − | the installation attempt. Unlike --add, the --sync option does not
| |
| − | differ between installing and upgrading packages. Depending on your
| |
| − | pacman.conf settings this function requires working internet access.
| |
| − | | |
| − | Receiving strange errors when downloading packages from the server,
| |
| − | ie. broken downloads or files that aren't found, usually are either
| |
| − | caused by not refreshing the package list with --sync, or if you're
| |
| − | unlucky enough to try downloading from a mirror while it's syncing
| |
| − | its contents, and is thus in an inconsistent state.
| |
| − | | |
| − | ===Searching for packages===
| |
| − | | |
| − | pacman -Ss foo
| |
| − | | |
| − | Search for package foo.
| |
| − | | |
| − | ===List installed packages===
| |
| − | | |
| − | pacman --query
| |
| − | pacman -Q
| |
| − | | |
| − | Displays a list of all installed packages in the system.
| |
| − | | |
| − | ===Check if a specific package is installed===
| |
| − | | |
| − | pacman --query foo
| |
| − | pacman -Q foo
| |
| − | | |
| − | Instead of grepping the full list for a name, you can append the name
| |
| − | of the package you are looking for to the query command. This command
| |
| − | will display the name and version of the foo package if it is
| |
| − | installed, nothing otherwise.
| |
| − | | |
| − | ===Display specific package info===
| |
| − | | |
| − | pacman --query --info foo
| |
| − | pacman -Qi foo
| |
| − | | |
| − | Displays information on the installed package foo (size, install date,
| |
| − | build date, dependencies, conflicts, etc.). To display this
| |
| − | information for a package file that is not yet installed, add the
| |
| − | --file or -p option, respectively:
| |
| − | pacman --query --info --file foo.pkg.tar.gz
| |
| − | pacman -Qip foo.pkg.tar.gz
| |
| − | | |
| − | ===Display list of files contained in a package===
| |
| − | | |
| − | pacman --query --list foo
| |
| − | pacman -Ql foo
| |
| − | | |
| − | Lists all files belonging to package foo.
| |
| − | | |
| − | ===Find out which package a specific file belongs to===
| |
| − | | |
| − | pacman --query --owns /path/to/file
| |
| − | pacman -Qo /path/to/file
| |
| − | | |
| − | This query displays the name and version of the package which contains
| |
| − | the file referenced by its full path as a parameter. Just using the
| |
| − | file name without the path will not yield results.
| |
| − | | |
| − | ==Accessing Repositories==
| |
| − | | |
| − | A package repository is a collection of packages and a package
| |
| − | meta-info file that can reside in a local directory or on a remote
| |
| − | FTP/HTTP server. The default repository for an Arch system is the
| |
| − | core repository. This is kept up to date by developers with the
| |
| − | latest version of most software and stays fairly bleeding-edge.
| |
| − | | |
| − | Many users also choose to activate the extra package repository which
| |
| − | contains more packages that are not part of Arch's core package set.
| |
| − | You can activate this repo by uncommenting the appropriate lines in
| |
| − | your /etc/pacman.conf. This repository is activated by default.
| |
| − | | |
| − | You can also build, maintain and use your own package repositories.
| |
| − | See the pacman manpage for instructions.
| |
| − | | |
| − | If you install from CD-ROM and end up having problems accessing the
| |
| − | Internet, you may need to install additional packages from the CD.
| |
| − | Refer to the FAQs, specifically FAQ #3 later in this document, to find
| |
| − | out how to define a repository that uses the installation CD-ROM as a
| |
| − | package source.
| |
| − | | |
| − | ==Arch Build System (ABS)==
| |
| − | | |
| − | ==Binary vs. Source==
| |
| − | | |
| − | Where pacman is responsible for the binary side of the package world,
| |
| − | ABS is responsible for the source side: It helps you to build your own
| |
| − | custom packages from source code, also letting you rebuild Arch Linux
| |
| − | packages with your own customizations.
| |
| − | | |
| − | The procedure usually goes as follows:
| |
| − | # Install the '''abs''' package via pacman
| |
| − | # Synchronize your ABS tree with the server by running '''abs''' as root.
| |
| − | # Create a build directory, named after the package you are going to create.
| |
| − | # Copy the PKGBUILD.proto prototype from /var/abs/ into your newly created directory, remove the .proto suffix, and edit it to fit the new package.
| |
| − | # Run makepkg in the working directory with the PKGBUILD file.
| |
| − | # Install the newly built package with pacman.
| |
| − | # Send the package to your friends for bragging rights (or give it to an Archer so s/he can stick it in the master ABS tree).
| |
| − | | |
| − | ==Synchronizing Your ABS Tree==
| |
| − | | |
| − | You can synchronize all the required package building files in
| |
| − | /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==
| |
| − | | |
| − | The build process is thoroughly explained in the makepkg manpage. Read
| |
| − | it for instructions on building your own packages. If that's not
| |
| − | helping you, keep your eyes peeled for tutorials in the Wiki, or ask
| |
| − | for help in the forums or IRC.
| |
| − | | |
| − | ==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:
| |
| − | # Checks if package dependencies are installed
| |
| − | # Downloads source files from servers
| |
| − | # Unpacks source files
| |
| − | # Performs any necessary patching, if specified in the PKGBUILD script
| |
| − | # Builds the software and installs it in a fake root
| |
| − | # Removes /usr/doc, /usr/info, /usr/share/doc, and /usr/share/info from the package
| |
| − | # Strips symbols from binaries
| |
| − | # Strips debugging symbols from libraries
| |
| − | # Generates the package meta file which is included with each package
| |
| − | # Compresses the fake root into the package file
| |
| − | # 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: <code>sshd:all</code> 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
| |